Um dos desafios no desenvolvimento de produtos é criar uma visão única que o descreve e que é compartilhada por todos os envolvidos na sua criação. Cada stakeholder tem as suas próprias opiniões sobre quais problemas esse produto deve resolver, de que forma e para quem. Reunir todas essas expectativas em uma única visão coerente significa que toda decisão tomada no desenvolvimento do produto, por menor e mais insignificante que possa parecer, será tomada com o direcionamento adequado. Uma visão de produto bem construída e disseminada entre todos os stakeholders envolvidos na criação do produto ajuda a gerar um resultado mais focado e também reduz o tempo de tomada de decisão, já que muitas decisões tornam-se óbvias uma vez que conhecemos aonde queremos chegar.

Existem várias técnicas que podem nos auxiliar na criação dessa visão de produto. Uma delas, descrita por Luke Hohmann no seu livro Innovation Games, é  a ”Product Box”, ou “Caixa do Produto”. É uma dinâmica a ser executada pela equipe de desenvolvimento do produto (quando essa equipe não é tão grande), podendo (devendo?) envolver não só a equipe técnica mas também integrantes das áreas de marketing, comercial, etc. O princípio do funcionamento da dinâmica é o seguinte: imagine que o seu produto estará exposto em uma prateleira no supermercado. Ele deverá disputar a atenção dos clientes que passam pela prateleira, muitas vezes cercado por concorrentes. Assim, a caixa do produto deve chamar a atenção rapidamente dos clientes em potencial, exibindo muito claramente quais são os seus principais atributos e porque devo comprá-lo ao invés do produto ao lado.

O exercício, que a princípio pode parecer uma brincadeira boba, na verdade fará com que a sua equipe reflita e discuta quais são os atributos mais importantes do seu produto, uma vez que para montar uma caixa que chame a atenção na prateleira não podemos enchê-la de texto, e sim usar algumas poucas características principais para atrair o cliente. A discussão em torno de quais atributos realmente são os mais evidentes do produto, e quais chamam mais a atenção do público-alvo (quem é o público-alvo do seu produto mesmo?) contribui bastante para que a equipe chegue a uma visão consensual do que é de fato esse produto, quais são os seus atributos chave e quem são os compradores que vão se interessar pelo produto quando estiverem passando pela prateleira.

Como recomendação prática, acho que um bom formato para as caixas são as caixinhas de DVD que se compra em qualquer loja de acessórios de informática, ou mesmo em supermercados. Essas caixinhas são baratas para se comprar, são de um tamanho ideal em que é possível desenhar confortavelmente mas também não são grandes o suficiente para encher de texto, e permitem que o desenho da caixa em si seja feito com papel A4 comum, barateando e simplificando a logística da atividade.

Reúna a sua equipe de produto, e tire uma hora da sua semana para essa atividade. Além de divertida, você verá como contribuirá e muito para que toda a sua equipe compartilhe a mesma visão de produto, construída colaborativamente. E você pode se surpreender como essa visão pode ser divergente no começo da brincadeira. Como dica final, algumas equipes deixam a caixa do produto gerada na dinâmica exposta na sala de trabalho, para que todos possam consultar os atributos escritos na caixa a qualquer momento. Experimente, divirta-se com a sua equipe e ainda por cima melhore os seus produtos!

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Um dos benefícios mais importantes de qualquer iniciativa de gerenciamento de requisitos dentro de uma metodologia para gestão de projetos está no gerenciamento e controle de mudanças no escopo destes projetos. Com mecanismos eficazes para elicitar, documentar e controlar nossos requisitos, conseguimos garantir que temos um retrato adequado do escopo do nosso projeto no seu início e que conseguiremos acompanhar a evolução desse escopo de forma adequada. Uma das ferramentas de que dispomos para nos auxiliar nesse acompanhamento é a matriz de rastreabilidade.

Antes de tratarmos da matriz de rastreabilidade propriamente dita, precisamos definir claramente o que entendemos por “rastreablidade”. Segundo o dicionário, a palavra rastrear significa “seguir o rastro ou pegada de”. Aplicada ao gerenciamento de requisitos, significa registrar e manter o relacionamento entre os objetos que estamos gerenciando. Podemos manter a rastreabilidade entre requisitos e objetivos de negócio, por exemplo, para procurar saber especificamente qual objetivo de negócio cada requisito contribui para atender. O BABOK v2 (Business Analysis Body of Knowledge) recomenda o gerenciamento da rastreabilidade dos requisitos como uma das tarefas da área de conhecimento “Gerenciamento e Comunicação dos Requisitos”. O seu objetivo, ainda segundo o BABOK, é “criar e manter relacionamentos entre objetivos de negócios, requisitos, outros entregáveis da equipe, e componentes da solução para apoiar a análise de negócios e outras atividades”.

A matriz de rastreabilidade surge então como uma ferramenta para facilitar a visualização dos relacionamento entre requisitos e outros artefatos ou objetos. É possível gerar matrizes de vários tipos. Pressman sugere algumas no seu “Software Engineering” (ele usa o nome tabela e não matriz, mas o resultado é o mesmo):

Matriz de rastreabilidade entre funcionalidades

Mostra o relacionamento entre partes do sistema visíveis aos clientes/usuários.

Matriz de rastreabilidade de fontes

Permite identificar a fonte, isto é, a origem de cada requisito.

Matriz de rastreabilidade de dependências

Essa é a forma mais comum da matriz, e identifica os relacionamentos entre os requisitos. Por ser a mais comum, quando dizemos apenas “matriz de rastreabilidade” geralmente estamos nos referindo à matriz de rastreabilidade de dependências.

Matriz de rastreabilidade de subsistemas

Relaciona os requisitos pelos subsistemas a que estão relacionados.

Matriz de rastreabilidade de interfaces

Identifica como os requisitos se relacionam com as interfaces internas e externas do sistema.

Qualquer que seja o tipo de matriz, ela sempre segue o mesmo modelo. Basicamente, coloca-se os objetos sendo rastreados nos eixos de uma tabela e marca-se os pontos de intersecção. No caso mais comum, da matriz de rastreabilidade entre requisitos ou de dependências, repete-se os requisitos nos eixos horizontal e vertical.

É possível manter a matriz de rastreabilidade manualmente em uma planilha, mas é fácil perceber como isso rapidamente se torna inviável para sistemas um pouco mais complexos. Nesses casos, muitas ferramentas de software para gerenciamento de requisitos montam as matrizes automaticamente e as mantém atualizadas conforme atualizamos o banco de requisitos.

Imagine agora que na metade do desenvolvimento do seu projeto você recebe uma solicitação de mudança que envolve alterar um determinado requisito. Sem uma matriz de rastreabilidade, você pode não perceber todo o impacto dessa mudança no seu sistema e acabar tomando decisões equivocadas por não poder realizar uma análise de impacto completa e confiável. Com a matriz, facilmente conseguimos identificar quantos e quais requisitos são afetados por qualquer alteração no sistema, e assim tornamos nossa avaliação de impacto muito mais eficaz.

Permalink | Leave a comment  »

Para quem quer se preparar para obter a certificação Agile do PMI aqui vão algumas dicas sobre o que pode cair na prova.

O PMI não tem um BOOK Agile, mas uma base do conteúdo da prova com alguma descrição dos assuntos abordados está publicado no PMI-ACP Examination Content Outline (http://www.pmi.org/en/Certification/~/media/Files/PDF/Agile/PMI_Agile_Certification_Content_Outline.ashx)

Minha percepção é que a certificação PMI-ACP está bastante focada em projetos de Software, ou seja, não vai agregar muito para profissionais de outras áreas.

Abaixo alguns pontos mais relevantes que devem ser tratados com bastante atenção pelos candidatos e alguns links que podem servir de apoio para estudo:

•    Princípios gerais de Gestão de Projetos

Sim, a certificação PMI-ACP vai muito além do Scrum.

Alguns conceitos gerais de gestão de projetos que são cobertos superficialmente pelas metodologias ágeis podem ser abordadas como, por exemplo, a gestão de riscos, a fase de iniciação de um projeto, escopo, cronograma, custos, valor agregado, enfim, um estudo de boas práticas de gestão de projetos vai ajudar bastante.

•    Manifesto Ágil

Entenda muito bem o Manifetos Ágil. Não é decoreba, mas sim o que significa cada um dos princípios descritos.

http://agilemanifesto.org/iso/ptbr/

•    Scrum

Entenda muito bem a estrutura:

•    Os papéis de Scrum Master, Product Owner e Team.
•    As cerimônias de Sprint Plannig, Sprint Review e Sprint Retrospective.
•    Os artefatos de Product Backlog, Sprint Backlog e Burn Charts.

•    eXtreme Programming

Assunto bastante abordado também, merecendo especial atenção de estudo.

Entenda os valores, princípios e práticas XP.

•    Outros frameworks ágeis

É importante ainda estudar frameworks como:

•    Crystal Clear
•    Adaptive Software Development
•    Feature Driven Development
•    Dynamic System Development Method

•    Estimativas Ágeis

Saiba em detalhes como funciona o Planning Poker e outras técnicas de estimativa por referência.

http://blog.euax.com.br/estimativa-utilizando-planning-poker

Também é importante entender conceitos como Velocidade do Time e Story Points.

•    Técnicas de Comunicação

Esta é a base para redução da documentação de um projeto, então merece especial atenção para entender o que são:

•    Radiadores de informação (Kanban, por exemplo)
•    Sala de guerra ou espaço do time
•    Comunicação osmótica
•    Reuniões diárias

•    Técnicas de Qualidade

Também é uma boa fonte de informação, sendo necessário entender conceitos como:

•    TDD
•    Definition of Done
•    Continuous Integration
•    Refactoring

•    Lean

Também é bom estar preparado para responder questões sobre conceitos relacionados a Lean como:

•    Eliminar Desperdícios
•    Incluir a Qualidade no Processo
•    Criar Conhecimento
•    Adiar Decisões e Comprometimentos
•    Entregar o quanto antes
•    Respeitar as Pessoas e delegar poder a equipe
•    Otimizar o Todo

É um conjunto bastante amplo de conhecimento e vale a pena estuda-los, não só por causa da prova, mas também por que eles agregam muito a vida de um GP.

Esteja preparado pois a prova não é nenhum absurdo de complicada, mas não imagine que apenas o conhecimento profundo do Scrum vai garantir a sua aprovação.

Bom estudo e boa prova.

Leitura complementar:

PMI-ACP Certification Content Outline: (http://www.pmi.org/en/Certification/~/media/Files/PDF/Agile/PMI_Agile_Certification_Content_Outline.ashx)

PMI-ACP reference list: (http://www.pmi.org/en/Certification/~/media/Files/PDF/Agile/PMI000-GainInsightsAIGLE418.ashx)

Permalink | Leave a comment  »

Depois de algum tempo na expectativa sobre o resultado da minha certificação PMI-ACP, finalmente recebi o resultado: aprovado.

Gostaria então de compartilhar algumas dicas e informações que podem ajudar quem estiver interessado em buscar este selo.

Em primeiro lugar, o que é o PMI-ACP?

Esse assunto já foi abordado aqui em nosso blog no posts “PMI lança Certificação de Gestão de Projetos Ágil - será que pega?” e “Nova Certificação Ágil do PMI - O que deve cair no Exame?”, mas resumindo, PMI-ACP ou PMI Agile Certified Practitioner é o programa de certificação ágil do PMI, que busca demonstrar que não é contra a aplicação de métodos ágeis, mas que essa abordagem pode e deve ser utilizada em projetos  passíveis das práticas ágeis.

Vamos à experiência que lembra bem o processo de certificação PMP.

Os passos para se certificar são:

1.       Elegibilidade

O candidato deve submeter um conjunto de informações que comprovam que ele atende aos pré-requisitos para ser um PMI-ACP.  São eles:

·         Escolaridade: ensino médio ou superior.

·         Experiência geral em gestão de projetos: pelo menos 2.000 horas trabalhando em times de projetos nos últimos 5 anos, sendo que os certificados PMP ou PgMP são automaticamente aprovados neste critério.

·         Experiência em projetos ágeis: pelo menos 1.500 horas trabalhando com projetos utilizando metodologias ágeis nos últimos 2 anos.

·         Capacitação: pelo menos 21 horas de treinamento em métodos ágeis.

Estas informações são preenchidas pelo candidato em formulários no próprio site do PMI.

2.       Pagamento

(*) Existe a opção de realizar a prova em papel para regiões muito distantes de centros de certificação ou para grupos que se organizem para isto. Para maiores informações e preços, consulte o site do PMI.

Minha sugestão é que o candidato primeiro faça a afiliação (129 dólares), pois com isto ele passa a ter acesso a um volume muito grande de informações que são disponibilizadas apenas para associados ao PMI.

3.       Auditoria

Um percentual das candidaturas para a certificação passa por um processo de auditoria.

Caso isso aconteça você terá que cumprir algumas exigências do PMI para comprovar as informações submetidas no primeiro passo.

Se não passar por auditoria ou se suas informações forem aprovadas, você poderá realizar a prova.

4.       Agendamento

Você terá 1 ano após ser considerado elegível para realizar a prova de certificação.

O site do PMI direciona você para a Prometric e por consequência aos centros habilitados para aplicar a prova baseada em computador.

5.       Prova

A prova é composta por 120 questões de múltipla escolha, sendo 100 questões que pontuam e 20 que não pontuam.

Essas 20 que não pontuam servem para o PMI realizar testes em novas questões e aprimorar seu banco de perguntas.

O candidato tem 3 horas para realizar a prova e esse tempo é mais que suficiente. Dá para fazer com calma e no final ainda é possível voltar e revisar perguntas que geraram dúvidas.

Quando eu fiz a minha prova, as questões estavam disponíveis somente em inglês, então é bom estar habituado com os termos técnicos neste idioma.

6.       Renovação

A certificação tem validade de 3 anos e pode ser renovada comprovando que o profissional continua se aprimorando com relação aos assuntos da certificação.

De forma simplificada, esse processo é chamado de CCR ou Continuing Certification Requirements, onde o profissional submete PDUs ou Professional Development Units ao PMI. Os PDUs que são as atividades realizadas que dão pontos para o profissional continuar com a certificação. Um curso, por exemplo, atribui um número X de PDUs ao profissional e quando ele atingir os 30 necessários e pagar as taxas apresentadas acima, poderá renovar a certificação por mais um ciclo de 3 anos.

Espero ter ajudado e logo publicarei mais um post sobre o conteúdo a ser estudado.

Referências e leituras complementares:

PMI-ACP Examp Prep (http://www.pmi.org/Certification/New-PMI-Agile-Certification/PMI-ACP-Exam-Prep.aspx)

PMI-ACP Handbook (http://www.pmi.org/Certification/New-PMI-Agile-Certification/~/media/PDF/Certifications/PMI-ACP_Handbook.ashx)

PMI-ACP reference list (http://www.pmi.org/en/Certification/~/media/Files/PDF/Agile/PMI000-GainInsightsAIGLE418.ashx)

Permalink | Leave a comment  »

Continuando a série de artigos sobre técnicas de criativdade em grupo citadas pelo guia PMBOK 4a Edição (item 5.2.1.4), hoje vamos discutir os mapas mentais. Mapas mentais são diagramas usados para representar idéias, palavras ou tarefas. Podem ser usados para organizar a classificar grandes quantidades de informação em torno de um tópico específico.

Um mapa mental é criado a partir de um tópico central. Esse tópico deve ser escrito no centro do diagrama. A partir desse tópico central, vamos derivando tópicos, conceitos ou idéias relacionadas e escrevendo-as em torno da idéia central, e ligados a ela através de um traço. Assim, começamos a criar uma estrutura em árvore que mostra os conceitos sugeridos mas também o relacionamento entre eles.

O psicólogo britânico Tony Buzan é o auto-proclamado criador do mapa mental moderno, embora técnicas semelhantes para organizar o conhecimento existam desde o século III. O mapa mental é um “parente” próximo do mapa conceitual, embora o primeiro seja muitas vezes considerado mais simples por utilizar sempre uma estrutura de árvore a partir de um nó central enquanto que o mapa conceitual não possui nenhuma estrutura ou organização definida.

Esse tipo de diagrama é preconizado como uma ótima forma para se tomar notas. Seu formato ajuda a facilmente distinguir entre palavras e idéias de forma visual. Tony Buzan afirma que o mapa mental auxilia na compreensão do tópico sendo analisado pois estimula o uso equilibrado dos hemisférios do cérebro na sua elaboração, melhorando a compreensão e retenção da informação do mapa. Essa idéia, porém, não é amplamente aceita na comunidade científica.

Mapas mentais são também uma excelente forma de organizar o resultado de uma sessão de brainstorming. A capacidade que esse diagrama possui de inter-relacionar conceitos e idéias faz com que possamos visualizar muito mais facilmente as estruturas existentes dentro das inúmeras idéias que surgem em uma sessão de brainstorming. Existem ferramentas de software para mind-mapping que possuem modos de “brainstorming”, facilitando ainda mais a geração desses diagramas.

Na prática, existem algumas dicas a se seguir na elaboração dos mapas mentais, segundo o próprio Tony Buzan:

• Comece no centro com uma imagem do tópico, usando pelo menos 3 cores;
•Use imagens, símbolos e códigos no seu mapa;
•Selecione palavras-chave e as escreva usando letrar maiúsculas em letra de forma; •Cada palavra/imagem fica melhor sozinha e na sua própria linha;
• Todas as linhas devem estar conectadas, a partir da imagem central. As linhas centrais são mais grossas, tornando-se orgânicas e mais finas conforme nos distanciamos do centro;
• Desenhe linhas do mesmo tamanho da palavra que comportam;
• Use várias cores no seu diagrama, para estimulação visual mas também para codificar e agrupar;
• Desenvolva seu estilo próprio de mapa mental;
• Use ênfase e mostre associações no seu mapa mental;
• Mantenha o diagrama organizado usando uma hierarquia radial, ordenação numérica ou resumos para organizar os seus “galhos”.

Além dessas dicas práticas, existem inúmeros aplicativos que nos ajudam a desenhar mapas mentais. Talvez o mais popular seja o Freemind, aplicativo que pode ser baixado gratuitamente por ser software livre. No âmbito dos produtos comerciais, bons exempos incluem o Mind Manager (líder do setor) e o Concept Draw Mind Map. Ferrmentas de diagramação como o Visio também são perfeitamente capazes de gerar mapas mentais. Para os usuários de Mac, o OmniGraffle permite criar mapas mentais belíssimos e funcionais. Atualmente acompanhamos o surgimento de várias ferramentas web para a criação de mapas mentais. Podemos citar como exemplos o Mindmeister, o Bubbl.us e o Comapping.

Permalink | Leave a comment  »

Continuando a nossa série de artigos sobre as ferramentas para criatividade em grupo sugeridas pelo Guia PMBOK (veja o nosso post sobre brainstorming), falaremos hoje sobre o diagrama de afinidade.

O diagrama de afinidade é, de certa forma, uma extensão ou sequencia do resultado final de uma sessão de brainstorming. Também conhecido como método Kawakita Jiro ou método KJ, em homenagem ao seu criador, o método surgiu na década de 60 para permitir que as várias idéias oriundas de uma sessão de brainstorming possam ser classificadas e organizadas para revisão e análise.

O princípio básico então do diagrama de afinidade consiste em coletar todas as idéias anotadas em uma sessão de brainstorming e agrupá-las em categorias ou grupos. Assim, conseguimos de imediato perceber os relacionamentos existentes entre as várias idéias, detectar inconsistências entre idéias contraditórias, e enxergar prioridades ou direcionamentos nas idéias coletadas que não são visíveis quando as idéias são tomadas no seu total, sem nenhuma organização.

A maneira mais tradicional de se agrupar as idéias é, primeiramente, anotar as idéias usando post-its. Assim fica mais fácil colar os papéis em diferentes posições na segunda etapa. Depois, pode-se ou escrever os agrupamentos em um quadro e colar os post-its no próprio quadro, ou então usar post-its de cores diferentes para idetificar as categorias ou agrupamentos.

Caso você tenha usado no seu brainstorming uma ferramenta computacional, existem aplicativos que permitem que você agrupe os itens facilmente. Veja abaixo um exemplo criado no OmniGraffle, um aplicativo para Mac. Para Windows, existe um aplicativo gratuito criado pela própria Microsoft, o “Sticky Sorter”, feito especificamente para uso em sessões de brainstorming e para a criação de diagramas de afinidade.

Cada ferramenta usa uma notação e nomenclatura particulares, mas não há nenhum padrão ou orientação oficial. Use as cores e formas que preferir. Existe inclusive a possibilidade de usar formas e cores diferentes para representar informações diferentes no seu diagrama, enriquecendo ainda mais as informações contidas no mapa.

Assim, vemos que a técnica do diagrama de afinidade é uma técnica bastante simples porém útil para organizar os resultados do nosso brainstorming, e ajudar a colocar ordem na enxurrada de idéias que surge a partir dela. Você já criou diagramas de afinidade nas suas sessões de brainstorming? Tem alguma dica para nos dar a respeito?

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Você e sua equipe estão usando o Microsoft Project Standard a algum tempo, a equipe tem um nível de conhecimento razoável da ferramenta, a organização já tem seu próprio método de trabalho com a ferramenta. Qual o próximo passo? Quando vale a pena considerar a adoção de uma ferramenta corporativa, como o Microsoft Project Server?

Mesmo o Project Standard tem uma série de recursos que auxiliam o uso colaborativo da ferramenta. Funcionalidades como pools de recursos, projetos mestres e o compartilhamento de objetos através do arquivo global fazem com que o Project funcione bem em ambientes de rede, mesmo na versão Standard. Antes de pensar em trocar de versão, certifique-se que todos esses recursos já foram pelo menos explorados na sua organização.

As limitações que você e sua equipe enfrentarão provavelmente se enquadram na seguinte lista:

• Você precisa que os membros das equipes dos seus projetos apontem horas, e não é viável ou seguro permitir que todos acessem diretamente o cronograma. Você já criou mecanismos manuais de apontamento, como um planilha de horas padronizada que o PMO transfere para o cronograma, mas a falta de segurança e transparência fazem com que os gerentes de projeto não confiem muito nos cronogramas. Além disso, a equipe do PMO começa a ficar sobrecarreagada pela quantidade de dados que precisam ser “copiados” das planilhas de horas para os cronogramas.
• Você tem um número muito grande de projetos com recursos compartilhados, o que faz com que cada vez que você tem que nivelar recursos seja necessário abrir muitos projetos. O cálculo do nivelamento começa a travar por falta de recursos da sua máquina.
• Você acredita que sua organização se beneficiaria dos recursos de colaboração oferecidos pelo Project Server, como por exemplo a criação de um site para cada projeto onde é possível compartilhar documentos e acompanhar discussões relacionadas ao projeto.
• Você tem muitos gerentes de projeto trabalhando em projetos com recursos compartilhados, e começa a ter problemas com arquivos de rede (pools de recursos ou projetos mestre) travados para escrita quando tenta salvar os seus cronogramas.
• Você precisa de um mecanismo para comunicar à sua equipe as tarefas nas quais estão envolvidas, sem necessariamente dar acesso a todo o cronograma de um projeto. Ou então, precisa que gerentes de projeto tenham acesso irrestrito aos seus projetos, mas não a todos os cronogramas da empresa. Isto é, você está começando a precisar ter controles de segurança mais granulares do que é possível no Project Standard.

Claro que existem outros fatores além desses, mas é bastante provável que ao menos um deles faça parte da sua lista de justificativas para a migração para uma solução corporativa. Faça as contas da migração, e veja se o retorno esperado compensa o investimento. E não esqueça de considerar na sua estimativa de custos para o projeto de migração o valor dos serviços associados à uma implantação. É relativamente comum as empresas se preocuparem excessivamente (quando não somente) com os custos de licenciamento, e não dão a devida atenção a um acompanhamento da implantação por profissionais qualificados. Isso acaba resultando em ferramentas implantadas pela metade, que não resolvem os problemas originais, e acabam caindo em desuso.

Permalink | Leave a comment  »

No terceiro artigo da série sobre priorização de requisitos, apresentaremos uma técnica baseada no modelo de Kano, uma teoria sobre desenvolvimento de produtos e satisfação dos clientes desenvolvida na década de 80. 

O modelo de Kano classifica os desejos dos usuários de um produto em cinco categorias, e o modelo descreve uma forma de questionar os usuários para descobrir quais funcionalidades se enquadram em quais categorias. Para nossas necessidades de priorização de requisitos, o que fazemos é aplicar um questionário especialmente preparado aos nossos usuários, e baseado nas respostas obtidas aplicamos o modelo de Kano para descobrir em que categorias nossos requisitos ou grupos de requisitos se enquadram. Essa informação é então usada como entrada para o processo de priorização.

As categorias usadas no modelo de Kano são as seguintes:

• Obrigatório

Os usuários consideram as funcionalidades enquadradas nessa categoria como absolutamente necessárias. Sem elas, o produto perde a sua razão de ser,

• Linear

As funcionalidades caracterizadas como “lineares” são aquelas do tipo “quanto mais melhor”. Exemplos típicos aqui incluem funcionalidades relacionadas a preço (quanto mais barato melhor), desempenho (quanto mais rápido melhor), e outros requisitos não-funcionais típicos. Deve-se ter cuidado ao planejar a execução de funcionalidades lineares, para que se tenha certeza de identificar o momento certo de parar, já que é possível continuar melhorando-as indefinidamente - embora com retornos cada vez menores, tipicamente.

• Brilho

As funcionalidades enquadradas na categoria “brilho” são aquelas que são inesperadas, e quando encontradas encantam o cliente. Elas não são necessárias para o funcionamento do produto, mas funcionam como um diferencial para encantar o cliente quando estão presentes.

• Negativo

São funcionalidades das quais os usuários não gostam quando as encontram.

• Indiferente

São funcionalidades que não causam uma reação relevante no usuário, e que ele não consegue classificar nem como positivas nem negativas.

Para montar o questionário, precisamos primeiro selecionar um conjunto de requisitos que queremos pesquisar. Novamente ,dependendo das necessidades os requisitos podem ser agrupados em temas se sentirmos que dessa forma teremos melhores resultados. Como cada requisito ou tema vai gerar duas perguntas no nosso questionário, temos que avaliar quantos requisitos podemos incluir sem tornar o questionário excessivamente longo.

Em seguida, precisar elaborar duas perguntas para cada requisito selecionado: uma pergunta chamada “funcional” e outra pergunta chamada “disfuncional”. A pergunta funcional questiona o entrevistado sobre como ele se sente sobre a presença daquela funcionalidade no produto. Por exemplo, se estivermos falando sobre um carro, poderíamos perguntar “como você se sente sobre a presença de um sistema de ar condicionado com controle automático de temperatura?”. A pergunta disfuncional sobre o mesmo requisito questiona o entrevistado sobre como ele se sente se essa funcionalidade não estiver presente no produto. Voltando ao exempo do carro, perguntaríamos algo como “como você se sente se no sistema de ar condicionado do carro não houver controle automático de temperatura?”.

O questionário do modelo de Kano é sempre de múltipla escolha, e as opções são sempre as mesmas:

• Gosto
• Espero
• Neutro
• Suporto
• Não gosto

Naturalmente as palavras usadas podem ser adaptadas para se adequarem ao texto da pergunta, mas o sentido das respostas deve sempre ser mantido. 

Cada usuário que receber o questionário vai então responder a duas perguntas sobre cada requisito. Anotamos as respostas de cada usuário, e comparamos o par de respostas (funcional e disfuncional) com a tabela de classificação para obter a percepção desse usuário sobre esse requisito. Vamos acompanhar no exemplo abaixo, que mostra as respostas (funcional e disfuncional) de um usuário para dois requisitos.

No primeiro requisito ("permitir desdobramento de atividades"), o usuário disse que gosta se o recurso estiver presente (resposta funcional), e quando perguntado sobre a ausência do requisito (disfuncional) afirmou que espera que seja assim - isto é, ele considera normal que esse recurso esteja ausente. Veja na tabela abaixo as respostas individuais desse usuário tabuladas.

Agora, basta somar a classificação obtida para esse requisito para todos os entrevistados, conforme ilustrado abaixo. A categoria que obtiver o maior número de respostas é a que devemos assumir para esse requisito. Em casos onde os números em mais de uma categoria forem muito próximos, teremos que usar nosso próprio julgamento na hora de categorizar o requisito.

Assim, conseguimos ver que se aplicarmos o questionário a um número maior de entrevistados (a partir de 30), teremos respostas estatisticamente relevantes sobre a percepção que os entrevistados tem sobre as funcionalidades propostas. Fica claro então que os requisitos considerados “obrigatórios” pela maioria dos entrevistados devem ser priorizados no nosso backlog.

O modelo de Kano é uma excelente técnica para aplicação rápida quando se tem um número um pouco maior de potenciais entrevistados, e gera resultados muito ricos para a classificação e priorização de requisitos. Como é aplicado através de questionários de múltipla escolha, é também uma técnica “não intrusiva”, que toma pouco tempo do entrevistado e pode ser respondida quando lhe for mais conveniente, diferente de outros métodos que requerem entrevista individual ou sessões em grupo. Assim, também se torna uma técnica de aplicação bem mais barata.

Permalink | Leave a comment  »

Novamente tive o prazer de falar sobre Redes Sociais na Gestão de Projetos e assuntos relacionados como Tecnologia e Comportamento Social nas empresas, tendências corporativas e na gestão de projetos.

Desta vez foi especialmente agradável por reencontrar alguns colegas do PMI ES. Evento de excelente nível, muitos participantes, organização impecável.

Como as redes sociais ainda são um fenômeno pessoal que não contagiou o mundo corporativo, o tema ainda provoca muitas dúvidas de como o privado influenciará o mundo dentro das empresas. Teremos no escritório um ambiente de colaboração, de troca de informações e de comunicação que se pareça com um facebook? Será que o mundo corporativo emprestará conceitos, a nova linguagem, o design, a “User Experience” (UX) que temos em casa?

Bom, tudo demonstra que sim. Não sabemos se a tecnologia irá impulsionar isto ou se o comportamento das pessoas no trabalho exigirá esta nova formatação.

Grandes players de tecnologia já apresentam suas soluções ao estilo Facebook para uso nas empresas, como IBM, Microsoft e a brasileira TOTVS com o seu novo produto By You. Para usos mais específicos, já temos um bom volume de aplicações, como o Sales Force ou o Artia.com (da minha empresa).

Entenda que não estamos falando de usar o facebook nas empresas, mas sim de criar um ambiente semelhante, mas que proteja as informações as pessoas e a empresa. O facebook mantem seu papel importante para as empresas como ferramenta de Webmarketing.

Do outro lado temos uma geração nova invadindo as empresas. Ela gosta de uma comunicação diferente, mais intensa mas em outro formato. Não tem simpatizado com as tradicionais reuniões intermináveis e frequentes (quem simpatiza?) e com aquela tonelada de e-mails usada para se dizer algo que ninguém quer saber. A geração atual dominante nas empresas também não gosta disto e começa a simpatizar com novas formas de comunicação. Assim passamos a trabalhar não como a geração X ou Y, mas como o pessoal que trabalha em 2012, em 2013, em 2014 e assim por diante. Cada ano teremos um novo perfil, uma mescla de gerações, tecnologias e culturas.

Qualquer que seja o início da mudança, uma nova cultura é exigida, caso contrário não teremos uma rede social corporativa, teremos um ambiente de troca de documentos e de comunicação tradicional (os GED e as intranets), que já são populares nas empresas há mais de uma década, sem grandes novidades. Estes ambientes já incluem fóruns, blogs e perfis mas não mudaram a forma de se relacionar.

Refiro-me a alterações no estilo de trabalho, na forma de comunicação, como por exemplo, trocando as infindáveis reuniões com gente de todos os lados da organização por reuniões rápidas de sincronização sobre assuntos previamente discutidos pelos envolvidos diretos, substituindo a ata de reunião por um registro em tempo real das pendências novas, apenas para usar um pequeno exemplo do dia-a-dia.

Nossa cultura organizacional permitirá alterações como esta? Veremos que sim, aos poucos pelo menos, alguns mais rápido, outros menos.

Finalmente, aproveito para citar o livro do Rodrigo Raineri  “No Teto do Mundo”. Ele fez a brilhante palestra de abertura do dia no evento (keynote) e tive o prazer de almoçar e retornar no voo para SP falando sobre de tudo um pouco. Além do 1º Brasileiro a subir o Everest por duas vezes, entre tantas aventuras, o Alpinista é um empresário visionário, inspirador e estimulante. Espero ler em breve o livro, com a expectativa de um belíssima leitura com várias lições para a vida corporativa e pessoal. Arrisco recomendar aos colegas antes mesmo de ter lido.

Também aproveito para recomendar artigo da Isto É Independente sobre Redes Sociais nas Empresas: http://www.istoe.com.br/reportagens/160608_REDES+SOCIAIS+NAS+EMPRESAS?pathImagens=&path=&actualArea=internalPage

Convido também a conhecer o Artia.com, uma rede social para a gestão de projetos.

Para os que quiserem baixar os slides da minha palestra, estão em no slideshare no canal da Euax: http://www.slideshare.net/euax

<div style="width:425px" id="__ss_9487340"> <strong style="display:block;margin:12px 0 4px">Redes sociais na gestão de projetos no Seminário do PMI ES</strong> <div style="padding:5px 0 12px"> View more presentations from Euax Gestão de Projetos </div> </div>

Permalink | Leave a comment  »

Encaminhamos comunicação (abaixo) sendo feita pelos capítulos Brasileiros do PMI convidando organizações a participar da 9ª edição da pesquisa de benchmarking.

O material resultante é sempre liberado gratuitamente e ajuda profissionais em todo o Brasil no amadurecimento de suas organizações.

Reforçamos o convite, participe!

Jackson Rovina

Gostaríamos de convidar a sua organização para participar da nona edição da mais importante pesquisa na área de Gerenciamento de Projetos desenvolvida no país, o Estudo de Benchmarking em Gerenciamento de Projetos. 

Criada no Brasil em 2003 e, desde então, realizada anualmente pelos treze Chapters do Project Management Institute no país, em 2011 o Estudo de Benchmarking em Gerenciamento de Projetos alcança a sua maturidade, tornando-se internacional e adotando um novo nome: PM SURVEY.ORG.

Em 2011, chapters do PMI de outros quatro países associam-se ao PM SURVEY.ORG: Argentina, França, Estados Unidos e Uruguai. Dessa forma, torna-se possível não apenas conhecer em profundidade a situação do mercado brasileiro no que tange as práticas de gerenciamento de projetos, mas também compará-la a outros países do mundo.

Em sua última edição, o PM SURVEY.ORG contou com a participação de cerca de 500 organizações, dos mais variados setores e regiões. Em 2011, a expectativa é que esse número seja amplamente superado, e a participação da sua organização é fundamental para que esse objetivo seja atingido.

Não há pré-requisito nem custo algum para participar. Todas as organizações são bem vindas, independentemente do seu nível de experiência em projetos, porte ou setor.

Lembramos que as informações fornecidas são tratadas de forma absolutamente confidencial, ponto crítico de sucesso para a credibilidade conquistada nos últimos anos.

Ao participar, sua organização terá acesso antecipado aos resultados, conhecendo em primeira mão as tendências e perspectivas para a área de gerenciamento de projetos. Os resultados devem ser disponibilizados a partir de novembro de 2011 e você será comunicado quando isso acontecer.

Para participar, basta acessar www.pmsurvey.org e criar uma conta. A data limite para a participação é 30 de setembro de 2011, mas não deixe para a última hora! Acesse já!

Importante: Esta pesquisa é exclusiva para organizações, o que significa que você responderá em nome da organização onde trabalha e, naturalmente, deve estar autorizado para isso.

E lembre-se que para participar respondendo a pesquisa, certifique-se ao criar sua conta que não está utilizando emails gratuitos, como Gmail, Hotmail ou Yahoo. Por questões de segurança, somente serão aceitas respostas que tenham uma conta cadastrada com um email no domínio da organização participante.

Caso tenha alguma dúvida, envie uma mensagem para globalcoordination@pmsurvey.org

Colabore com o desenvolvimento da comunidade de gerenciamento de projetos no Brasil e no mundo. Participe do PM SURVEY.ORG 2011 !

Americo Pinto
Global Coordinator
PM SURVEY – A Global Initiative of PMI® Chapters

WWW.PMSURVEY.ORG

Permalink | Leave a comment  »

Quando finalizamos o planejamento de um projeto temos um retrato do que é esperado em relação a datas, recursos, esforço e custo para a realização das atividades que estão descritas no cronograma. Porém, ao longo do tempo, a medida em que vamos atualizando o cronograma com o que estamos realizando, este plano inicial acaba se perdendo no cronograma já que as datas são recalculadas para refletir a nova realidade e datas esperadas de execução das atividades do projeto. Porém,  precisamos de uma referência para compararmos se o que foi planejado está efetivamente acontecendo. Dentro deste contexto surge o conceito de linha de base (ou baseline para os que estão mais acostumados com o termo em inglês). A linha de base nada mais é do que a foto inicial do planejamento armazenada para que durante a execução do projeto seja possível efetuar um comparativo do quanto aquilo que foi planejado está efetivamente sendo cumprido.

O MS-Project trata as linhas de base de uma maneira muito fácil de entendimento e bastante útil. Para utilizarmos as linhas de base os seguintes passos são necessários:

Passo 1: Finalização do Planejamento

O primeiro passo é ter o cronograma pronto com todas as atividades do projeto. Isto indica que a fase de planejamento foi finalizada. Vamos tomar como base o cronograma abaixo como o planejamento do projeto:

O que podemos notar ao término do planejamento é que os campos referenciados como linha de base (inicio, término, trabalho e duração) ainda não possuem nenhum valor.

Passo 2: Criação da Linha de Base

Para associar o valor a estas colunas temos que acessar a pasta “Projeto” acessar o botão “Definir Linha de Base” e selecionar a opção “Definir Linha de Base”.

A seguinte tela será aberta:

Nesta tela, selecionar “Definir Linha de Base” e escolher a opção “Linha de Base”.  Para este caso vou selecionar “Projeto Inteiro” pois quero adicionar a linha de base para todas as atividades do meu projeto. Como uma opção eu poderia setar a linha de base apenas para algumas atividades que acabei de incluir, deixando as demais linhas de base intocadas. Neste caso é preciso selecionar a opção “Tarefas Selecionadas”. O resultado da seleção foi o meu cronograma com a Linha de base atualizada, conforme abaixo: 

 

E pronto. Minha linha de base está criada. A partir de agora é possível acompanhar o andamento do meu projeto comparando o planejado x o realizado. É possível criar e utilizar faróis no MS-Project para um acompanhamento visual da linha de base. Caso você necessite desta funcionalidade o post Dicas MS-Project 2010 - Dica #3 - Criando Farois.

E se for necessário replanejar o projeto? Posso manter os dois planos?

O MS-Project permite que sejam armazenadas até 10 Linhas de Base adicionais a Linha de Base Padrão. Para salvar uma nova Linha de Base basta seguir o mesmo procedimento acima e ao invés e selecionar “Linha de Base” basta selecionar uma das outras 10 linhas de base: 

A minha sugestão, no entanto é de que a “Linha de Base” permaneça sempre com a Linha de Base do último planejamento. Para que isto seja possível é necessário copiar a linha de base atual para uma nova linha de base e salvar o novo planejamento como “Linha de Base” novamente. Para copiar a linha de base atual para uma nova linha de base basta utilizar a opção abaixo:

Esta opção irá transferir todos os dados que estão salvos na “Linha de Base” para a “Linha de Base 1”. Neste caso, ao salvar a nova linha de base na sequencia, ficam salvas as duas linhas de base: a original (salva como “Linha de Base 1”) e a nova (salva como “Linha de Base). Caso seja necessário um novo planejamento, basta copiar a “Linha de Base” para a “Linha de Base 2” e assim ficaremos com 3 linhas de base e assim por diante.

Um forte abraço e bons projetos!

 

 

 

Permalink | Leave a comment  »

Ano passado visitei a área de Tecnologia (P&D) de uma empresa com o objetivo de discutir a utilização de um software de gerenciamento de projetos. O fato curioso da história é que se trata da empresa para a qual ministrei meu primeiro curso Microsoft Project, em 1995. Naquela época a área, entrando no mundo Windows, estava avaliando a ferramenta para aquisição porque era algo muito importante para eles... até o momento nenhum software foi realmente implantado e o pessoal continua “se virando” com as planilhas eletrônicas.

Qual a dificuldade encontrada pelas empresas em implantar ferramentas de gerenciamento de projetos? Refaço esta pergunta constantemente até para avaliar a minha atuação como professor e consultor visto que, como o caso relatado acima, muitos outros poderiam ser citados. Eis algumas razões para refletirmos:

·         Muitos acreditam que ferramenta (software) resolve todos os problemas. É impressionante como ainda encontramos este tipo de abordagem. Ferramentas sem processos bem definidos e institucionalizados (sendo usados) e sem pessoas capacitadas, dificilmente geram resultados efetivos. É só questão de tempo para ouvirmos alguém dizer que a ferramenta abandonada não funcionou adequadamente ou outra “desculpa” qualquer.

·         Falta de conhecimento da ferramenta. Por mais que o pessoal tenha familiaridade com as planilhas eletrônicas, os softwares de gerenciamento de projetos possuem aplicação particular e muitas funcionalidades específicas. Frequentemente recebemos telefonemas e e-mails com afirmações como: “_ o software ficou doido”.  Não preciso dizer que o diagnóstico precoce normalmente não está correto... Pessoal, não existe demérito em fazer um estudo estruturado ou procurar cursos dos softwares de gerenciamento de projetos, além de planejar adequadamente a implantação como seria comum para qualquer outro software de gestão. Criar os ambientes adequados, a estrutura de suporte, buscar especialistas, capacitar os envolvidos, dentre outras ações, devem acontecer de forma estruturada antes de achar que os produtos são inadequados e voltar para as planilhas.

·         Formação em gerenciamento de projetos. As funcionalidades encontradas nos softwares possuem uma base conceitual que deve ser conhecida. Lembro-me de uma reunião para a qual fui convidado porque o pessoal queria saber se eu já tinha visto o “bug” da ferramenta que alterou o Caminho Crítico. Ao final da reunião ficou caracterizado que a ferramenta não tinha bug e se tratava de “deficiência conceitual dos participantes”. Considero fundamental a participação em cursos de Gerenciamento de Projetos, mas uma boa formação vai além e exige experiência para que os conhecimentos sejam vivenciados e as habilidades desenvolvidas. Uma boa formação em GP é essencial.

·         Avaliação inadequada da aderência do software: outra situação que vivenciamos com freqüência é a tentativa de implantar ferramentas mais complexas do que a necessidade da empresa ou área. Vemos empresas que estão iniciando a implantação de boas práticas de gestão de projetos querendo, e muitas vezes comprando, ferramentas com muito mais funcionalidades do que o necessário para o momento. Se, para iniciar, uma solução simples pode resolver boa parte dos problemas, então podemos parar de procurar e utilizar esta solução. Com o tempo a empresa descobrirá novas necessidades não atendidas e outros softwares mais completos poderão ser implantados com menos impacto, menos resistência e, consequentemente, com maiores chances de sucesso.

·         Metodologia e padrões. É preciso saber o que fazer e como fazer. Os processos de gerenciamento de projetos devem ser definidos, lembrando que as ferramentas são uma parte deste processo. Desta forma saberemos como usá-las e o que esperar delas. Vocês devem conhecer algumas empresas que fizeram o caminho contrário (primeiro compraram uma ferramenta) e agora estão com os softwares parados...

·         Falta de tempo para a gestão do projeto. Alguns não têm tempo para o planejamento, outros após o planejamento se enfronham na execução como se o monitoramento e o controle não necessitassem de tempo e energia. Estes normalmente são os mesmos que arranjam tempo para apagar os incêndios (apenas os incêndios mais urgentes) decorrentes da falta de gestão. Lembro ainda que durante todo o projeto teremos reprogramações... sim, o planejamento não termina quando o plano está aprovado, é composto por processos necessários durante todo o projeto, para que o empreendimento atinja os objetivos para os quais foi criado. E o uso das ferramentas, em decorrência destes processos, também exige tempo.

·         Falta de crença de que Gerenciamento de Projetos vale à pena. Isto é o mais grave! Existem profissionais que estudam o assunto e desenvolvem um bom discurso visando o crescimento profissional, mas não incorporam o valor (ou a crença) de que gerenciar projetos é uma boa idéia e gera benefícios. Cada vez mais tenho incentivado as pessoas a pensarem sobre a essência de suas atividades profissionais... Notem que as razões citadas acima vão do detalhe (Métodos, técnicas e ferramentas) à essência (crenças e valores), e estes últimos são mais importantes.

Como adoro softwares de gerenciamento de projetos, tanto quanto contar histórias, lembrei que há dois anos fiquei muito orgulhoso ao encontrar em uma caixa velha a documentação de um evento para aproximadamente 300 pessoas, organizado em 1988. Foi um projeto bem sucedido com reedições nos anos posteriores, a documentação cobria desde a iniciação até os números finais do evento e, inclusive, usei como exemplo em um curso ministrado este ano. A ferramenta utilizada na época? Uma máquina de escrever Olivetti portátil e, para o Gráfico de Barras (Gantt), um software para DOS chamado FlowChart. Um luxo permitido pela empresa na qual fazia estágio.

Para finalizar, além de aconselhar os amigos que atentem para as questões acima, vou usar Joseph M. Juran, lembrando que a melhor ferramenta é aquela mais adequada ao uso.

Permalink | Leave a comment  »

Dando sequencia ao post anterior da série sobre priorização de requisitos, dessa vez apresentaremos outra técnica para priorizar seus requisitos (ou projetos) de forma objetiva e quantitativa. A técnica apresentada nesse post é chamada “Theme Screening”, e embora tenha muitas semelhanças com o Theme Scoring apresentado anteriormente as duas técnicas tem algumas diferenças com impactos significativos.

O primeiro passo para  aplicação do Theme Scoring é a escolha de temas de requisitos. Temas são grupos de requisitos funcionalmente ligados, tipicamente compondo um sub-sistema específico ou que tenham objetivos de negócio complementares. A justificativa para o agrupamento em temas é que tipicamente requisitos individuais podem ser pequenos demais para fazer sentido para os entrevistados pela técnica, então agrupa-se os requisitos em unidades maiores e mais fáceis de avaliar. No caso da aplicação da técnica para a priorização de projetos, bastaria escolher quais projetos desejamos comparar. 

Depois de escolher os temas de requisitos ou projetos sendo avaliados, precisamos definir critérios de análise. De forma análoga ao que fazemos na Theme Scoring, os critérios de análise são quesitos contra os quais avaliaremos nossos requisitos e devem representar aspectos do nosso produto que consideramos importantes para a priorização de requisitos. Esses critérios podem ser definidos a partir da nossa visão de produto, ou de requisitos de negócio a que desejamos atender. Exemplos comuns podem incluir itens como “Alinhamento estratégico”, “Aquisição de usuários”, “Ampliação do uso do produto”, “Facilidade de desenvolvimento”, “Posicionamento do produto”, etc. 

Um fator importantíssimo a ser considerado na escolha dos critérios de análise (e também dos temas, na verdade), é o público a que nossa pesquisa será dirigida. Naturalmente, as pessoas entrevistadas pelo método devem ser capazes de entender o significado de cada critério de análise e também ser capazes de avaliar cada tema relativo a esses critérios.

É depois de definidos os temas e os critérios de análise que o método do Theme Screening passa a se diferenciar do Theme Scoring. Devemos agora escolher um tema como baseline, isto é, um tema que servirá de base de comparação para todos os demais temas. A idéia é escolher um tema que imaginamos que tenha uma prioridade intermediária entre os temas escolhidos.

Agora, comparamos cada critério de análise com o nosso baseline, ou seja, perguntamos pros nossos entrevistados se determinado tema é melhor ou pior que o baseline em cada critério de análise. Na planilha de acompanhamento mostrada abaixo, damos 1 ponto quando o tema em análise é melhor do que o baseline nesse critério, e marcamos -1 ponto (um ponto negativo) quando o tema em questão é pior que o baseline nesse critério. Somamos o total para cada temas, e teremos uma pontuação total para o tema. Basta então ordenar nossos temas - os requisitos do tema com a maior pontuação devem ser executados primeiro, e assim seguimos em ordem decrescente.

Conseguimos perceber um risco grande no uso do Theme Scoring - se errarmos na escolha do baseline, poderemos criar distorções nos resultados. Um baseline com prioridade muito alta fará com que muitos quesitos pontuem negativo. Um baseline muito baixo fará com que muitos quesitos pontuem muito alto. Assim, a escolha de um baseline intermediário na escala de prioridade é bem importante. Naturalmente, pode ser difícil escolher um baseline de prioridade intermediário antes de priorizarmos os requisitos, e esse é um problema inerente ao método.

Qual a diferença entre o Theme Scoring e o Theme Screening? Ambos os métodos são bastante semelhantes, e embora o Theme Scoring não traga o risco da escolha errada do baseline, há quem diga que a resposta que se pede do participante é mais complexa - é mais difícil dar uma nota de 1 a 5 do que simplesmente dizer se algo é melhor ou pior. Na prática, há que se avaliar o público que participará da entrevista e definir se esse público tem discernimento suficiente sobre o negócio para dar uma resposta mais detalhada (e nesse caso usa-se o Theme Scoring) ou se os nossos participantes preferirão respostas mais simples mesmo que a gente tenha que correr o risco de errar na escolha do baseline(e nesse caso usa-se o Theme Screening).

Independentemente do método escolhido, o mais importante é que se use algum método objetivo de priorização, e que os participantes nas atividades de priorização entendam claramente o funcionamento do método empregado.

Permalink | Leave a comment  »

Eu particularmente gosto muito de usar atalhos de teclado e quem tem o hábito de utilizá-los para ativar funções, seja do Microsoft Project ou de qualquer outro programa, sem dúvida consegue economizar muitos cliques que seriam feitos com o mouse. Não se preocupe em memorizar a lista com as combinações abaixo: ao identificar uma combinação que seja bastante útil para a sua forma de trabalho, ela vai acabar se incorporando na sua rotina de forma natural.

Abaixo, a lista com os principais atalhos de teclado disponíveis no Microsoft Project 2010.

Usar o modo de exibição Diagrama de Rede

Mover para outra caixa de diagrama de rede.
Pressione: Teclas de direção

Adicionar caixas de diagrama de rede à seleção.
Pressione: SHIFT+Teclas de direção

Mover uma caixa de diagrama de rede. (Observação   O posicionamento manual deve ser definido primeiro. Selecione a caixa que deseja mover. Na guia Formatar, clique em Layout no grupo Formatar. Clique em Permitir posicionamento manual da caixa.)
Pressione: CTRL+Teclas de direção

Mover para a caixa de diagrama de rede superior no modo de exibição ou no projeto.
Pressione: CTRL+HOME ou SHIFT+CTRL+HOME

Mover para a caixa de diagrama de rede inferior no projeto.
Pressione: CTRL+END ou SHIFT+CTRL+END

Mover para a caixa de diagrama de rede à esquerda no projeto.
Pressione: HOME ou SHIFT+HOME

Mover para a caixa de diagrama de rede à direita no projeto.
Pressione: END ou SHIFT+END

Mover para cima uma altura de janela.
Pressione: PAGE UP ou SHIFT+PAGE UP

Mover para baixo uma altura de janela.
Pressione: PAGE DOWN ou SHIFT+PAGE DOWN

Mover para a esquerda uma largura de janela.
Pressione: CTRL+PAGE UP ou SHIFT+CTRL+PAGE UP

Mover para a direita uma largura de janela.
Pressione: CTRL+PAGE DOWN ou SHIFT+CTRL+PAGE DOWN

Selecionar o próximo campo na caixa de diagrama de rede.
Pressione: ENTER ou TAB

Selecionar o campo anterior na caixa de diagrama de rede.
Pressione: SHIFT+ENTER

Navegar em modos de exibição e janelas

Ativar o menu Controle.
Pressione: ALT+BARRA DE ESPAÇOS

Ativar a barra de entrada para editar o texto em um campo.
Pressione: F2

Ativar a barra de menus.
Pressione: F10 ou ALT

Ativar o menu de controle do projeto.
Pressione: ALT+HÍFEN

Ativar a barra de divisão.
Pressione: SHIFT+F6

Fechar a janela do programa.
Pressione: ALT+F4

Exibir todos os recursos ou tarefas filtrados.
Pressione: F3

Exibir a caixa de diálogo Configurações de Campo.
Pressione: ALT+F3

Abrir uma nova janela.
Pressione: SHIFT+F11

Reduzir uma seleção a um único campo.
Pressione: SHIFT+BACKSPACE

Redefinir a ordem de classificação para ordem de identificação e desativar o agrupamento.
Pressione: SHIFT+F3

Selecionar um objeto de desenho.
Pressione: F6

Exibir informações sobre tarefas.
Pressione: SHIFT+F2

Exibir informações sobre recursos.
Pressione: SHIFT+F2

Exibir informações sobre atribuições.
Pressione: SHIFT+F2

Ativar ou desativar o modo Adicionar à Seleção.
Pressione: SHIFT+F8

Ativar ou desativar o recurso AutoCálculo.
Pressione: CTRL+F9

Ativar ou desativar o modo Estender Seleção.
Pressione: F8

Mover para a esquerda, para a direita, para cima ou para baixo a fim de exibir páginas diferentes na janela Visualização de Impressão.
Pressione: ALT+Teclas de direção

Descrever um projeto

Ocultar subtarefas.
Pressione: ALT+SHIFT+HÍFEN ou ALT+SHIFT+SINAL DE SUBTRAÇÃO (sinal de subtração no teclado numérico)

Recuar a tarefa selecionada.
Pressione: ALT+SHIFT+SETA PARA A DIREITA

Mostrar subtarefas.
Pressione: ALT+SHIFT+ = ou ALT+SHIFT+SINAL DE ADIÇÃO (sinal de adição no teclado numérico)

Mostrar todas as tarefas.
Pressione: ALT+SHIFT+* (asterisco no teclado numérico)

Aplicar recuo deslocado à tarefa selecionada.
Pressione: ALT+SHIFT+SETA PARA A ESQUERDA

Selecionar e editar em uma caixa de diálogo

Mover entre os campos na parte inferior de um formulário.
Pressione: Teclas de direção

Mover nas tabelas na parte inferior de um formulário.
Pressione: ALT+1 (esquerda) ou ALT+2 (direita)

Mover para a próxima tarefa ou recurso.
Pressione: ENTER

Mover para a tarefa ou o recurso anterior.
Pressione: SHIFT+ENTER

Selecionar e editar em um modo de exibição de planilha

Editar em um modo de exibição

Cancelar uma entrada.
Pressione: ESC

Limpar ou redefinir o campo selecionado.
Pressione: CTRL+DELETE

Copiar os dados selecionados.
Pressione: CTRL+C

Recortar os dados selecionados.
Pressione: CTRL+X

Excluir os dados selecionados.
Pressione: DELETE

Excluir a linha que tem uma célula selecionada.
Pressione: CTRL+SINAL DE SUBTRAÇÃO (no teclado numérico)

Preencher abaixo.
Pressione: CTRL+D

Exibir a caixa de diálogo Localizar.
Pressione: CTRL+F ou SHIFT+F5

Na caixa de diálogo Localizar, ir para a próxima instância dos resultados de pesquisa.
Pressione: SHIFT+F4

Usar o comando Ir para (menu Editar).
Pressione: F5

Vincular tarefas.
Pressione: CTRL+F2

Colar os dados copiados ou recortados.
Pressione: CTRL+V

Reduzir a seleção a um campo.
Pressione: SHIFT+BACKSPACE

Desfazer a última ação.
Pressione: CTRL+Z

Desvincular tarefas.
Pressione: CTRL+SHIFT+F2

Definir a tarefa para agendar manualmente.
Pressione: CTRL+SHIFT+M

Definir a tarefa para agenda automática.
Pressione: CTRL+SHIFT+A

Mover-se em um modo de exibição

Mover para o início de um projeto (escala de tempo).
Pressione: ALT+HOME

Mover para o final de um projeto (escala de tempo).
Pressione: ALT+END

Mover a escala de tempo para a esquerda.
Pressione: ALT+SETA PARA A ESQUERDA

Mover a escala de tempo para a direita.
Pressione: ALT+SETA PARA A DIREITA

Mover para o primeiro campo de uma linha.
Pressione: HOME ou CTRL+SETA PARA A ESQUERDA

Mover para a primeira linha.
Pressione: CTRL+SETA PARA CIMA

Mover para o primeiro campo da primeira linha.
Pressione: CTRL+HOME

Mover para o último campo de uma linha.
Pressione: END ou CTRL+SETA PARA A DIREITA

Mover para o último campo da última linha.
Pressione: CTRL+END

Mover para a última linha.
Pressione: CTRL+SETA PARA BAIXO

Mover-se no painel lateral

Mover o foco entre o painel lateral e o modo de exibição à direita.
Pressione: CTRL+TAB ou CTRL+SHIFT+TAB

Selecionar diferentes controles no painel lateral se o foco estiver nesse painel.
Pressione: TAB

Marcar ou desmarcar caixas de seleção e botões de opção se o foco estiver no painel lateral.
Pressione: BARRA DE ESPAÇOS

Selecionar em um modo de exibição

Estender a seleção uma página para baixo.
Pressione: SHIFT+PAGE DOWN

Estender a seleção uma página para cima.
Pressione: SHIFT+PAGE UP

Estender a seleção uma linha para baixo.
Pressione: SHIFT+SETA PARA BAIXO

Estender a seleção uma linha para cima.
Pressione: SHIFT+SETA PARA CIMA

Estender a seleção até o primeiro campo de uma linha.
Pressione: SHIFT+HOME

Estender a seleção até o último campo de uma linha.
Pressione: SHIFT+END

Estender a seleção até o início das informações.
Pressione: CTRL+SHIFT+HOME

Estender a seleção até o final das informações.
Pressione: CTRL+SHIFT+END

Estender a seleção até a primeira linha.
Pressione: CTRL+SHIFT+SETA PARA CIMA

Estender a seleção até a última linha.
Pressione: CTRL+SHIFT+SETA PARA BAIXO

Estender a seleção até o primeiro campo da primeira linha.
Pressione: CTRL+SHIFT+HOME

Estender a seleção até o último campo da última linha.
Pressione: CTRL+SHIFT+END

Selecionar todas as linhas e colunas.
Pressione: CTRL+SHIFT+BARRA DE ESPAÇOS

Selecionar uma coluna.
Pressione: CTRL+BARRA DE ESPAÇOS

Selecionar uma linha.
Pressione: SHIFT+BARRA DE ESPAÇO

Mover-se em uma seleção um campo para baixo.
Pressione: ENTER

Mover-se em uma seleção um campo para cima.
Pressione: SHIFT+ENTER

Mover-se em uma seleção um campo para a direita.
Pressione: TAB

Mover-se em uma seleção um campo para a esquerda.
Pressione: SHIFT+TAB

Selecionar e editar na barra de entrada

Aceitar uma entrada.
Pressione: ENTER

Cancelar uma entrada.
Pressione: ESC

Excluir um caractere à esquerda.
Pressione: BACKSPACE

Excluir um caractere à direita.
Pressione: DELETE

Excluir uma palavra à direita.
Pressione: CTRL+DELETE

Estender a seleção até o final do texto.
Pressione: SHIFT+END

Estender a seleção até o início do texto.
Pressione: SHIFT+HOME

Ativar ou desativar o modo Sobrescrever.
Pressione: INSERT

Usar uma escala de tempo

Mover a escala de tempo uma página para a esquerda.
Pressione: ALT+PAGE UP

Mover a escala de tempo uma página para a direita.
Pressione: ALT+PAGE DOWN

Mover a escala de tempo para o início do projeto.
Pressione: ALT+HOME

Mover a escala de tempo para o final do projeto.
Pressione: ALT+END

Rolar a escala de tempo para a esquerda.
Pressione: ALT+SETA PARA A ESQUERDA

Rolar a escala de tempo para a direita.
Pressione: ALT+SETA PARA A DIREITA

Mostrar unidades de tempo menores.
Pressione: CTRL+ / (barra no teclado numérico)

Mostrar unidades de tempo maiores.
Pressione: CTRL+* (asterisco no teclado numérico)

Quais são os atalhos que você mais usa no seu dia-a-dia com o Microsoft Project 2010?
Lembrou de algum atalho que não está na lista? Deixe seu comentário.

Permalink | Leave a comment  »

Uma grande dificuldade que encontramos no desenvolvimento de qualquer produto - e me refiro a produto aqui num sentido bem amplo, como qualquer capacidade que entregamos -  é saber o que é mais importante para o nosso usuário final. Determinar de forma objetiva o que traz mais valor para o nosso produto do ponto de vista desse grupo de stakeholders é fundamental para garantirmos o sequenciamento adequado das atividades do(s) projeto(s) de desenvolvimento desse produto, sem recorrer a suposições individuais dos participantes nesse processo e a inevitável queda de braço para definir qual funcionalidade “entra primeiro na fila”. 

Para esse fim, existem várias técnicas que envolvem, de diferentes maneiras, o usuário final, para guiar ou nos dar dicas de quais funcionalidades devemos priorizar. Algumas dessas técnicas inlcuem:

• Theme Scoring
• Theme Screening
• Modelo de Kano

Podemos também pensar em variações dessas técnicas aplicáveis a cada ambiente, sendo papel do analista de negócios (ou equivalente de acordo com cada ambiente organizacional) definir quais técnicas aplicar, de que forma e em que momento.

Essa série de posts tratará de cada uma dessas técnicas brevemente, apresentando a forma de utilização e abrindo a discussão sobre sua aplicação nos mais diferentes contextos. No post atual, discutiremos a técnica chamada “Theme Scoring”.

O Theme Scoring é uma técnica para ajudar a priorizar entre grupos de requisitos (temas), mas que pode igualmente ser aplicada para priorizar projetos ou até mesmo produtos. A técnica parte da escolha de critérios de análise contra os quais nossos temas serão analisados. Esses critérios devem partir de uma avaliação de cada ambiente, identificando que fatores nos levariam a escolher, ou a não escolher, um determinado tema. Exemplos típicos seriam coisas como “alinhamento estratégico”, “capacidade de trazer novos usuários”, “capacidade de reter usuários”, “amplia o uso do produto”, etc.

Uma vez definidos os temas e os critérios de análise, damos um peso para cada um dos critérios de análise. Esses pesos indicam a importância relativa de cada um dos nossos critérios. O peso pode ser qualquer valor positivo, desde que reflita de fato a importância relativa dos critérios - por exemplo, se escolho “1” para o peso do critério A e “2” para o peso do critério B, estou indicando que o critério B é duas vezes mais importante para mim do que o critério A. 

Definidos os temas, critérios de análise e pesos, agora precisamos montar nossa planilha de avaliação. Nessa planilha, usamos uma linha para cada critério de análise e nas colunas colocamos os temas sendo analisados, conforme o exemplo abaixo.

Uma vez concluída a preparação, apresentamos nossos temas a um grupo de usuários finais ou especialistas de negócio, e pedimos a eles que deem notas de um a cinco para cada tema em cada critério, com um sendo a pior nota e cinco a melhor. Assim, or exemplo, se um determinado tema está fortemente alinhado ao planejamento estratégico da empresa, daríamos a ele uma nota 5 no critério “alinhamento estratégico”. 

Existem diferentes maneiras de tabular os resultados. Para pequenos grupos de respostas, podemos discutir cada tema em grupo e chegar a uma nota consensual para cada critério. Alternativamente, pode-se coletar respostas individuais de cada usuário ou especialista e no final calcular a média de cada pontuação. Qualquer que seja o método escolhido, no final do processo teremos um valor de prioridade para cada tema pesquisado, dando uma indicação da sequencia de implementação a ser seguida.

Essa técnica é uma maneira de tratar nossa priorização de requisitos de maneira mais objetiva, e ao mesmo tempo envolver grupos externos nessas decisões, podendo ser aplicada igualmente com usuários finais e com especialistas de negócio. Devemos lançar mão desses métodos para ajudar nas nossas escolhas e para estabelecermos um diálogo com esses grupos de stakeholders, validando assim nossas suposições sobre o que realmente agrega valor ao nosso produto.

Permalink | Leave a comment  »

O Agile Brazil 2011 confirmou a força do assunto e da comunidade Agile brasileira.

Considero que o congresso agregou muito com palestras e assuntos para todos os níveis de conhecimento e atuação.

Eu achava difícil superar o evento de 2010, mas a equipe organizadora e os palestrantes estão de parabéns pois conseguiram aumentar a qualidade geral.

Alguns números (não oficiais):

A quantidade de participantes não foi divulgada ainda, mas passou fácil de 500 pessoas.

Vieram pessoas de 20 Estados + Distrito Federal, sendo que os 3 principais foram:

·         CE  com 48,7% dos participantes

·         SP com 19,6% dos participantes

·         RJ com 5,1% dos participantes

Houve muito conteúdo em vários formatos com oportunidade para todos se desenvolverem:

·         5 cursos de alto nível, muito desejados pela comunidade Ágil

·         3 ótimos Keynotes, contando inclusive com Jim Highsmith, um dos autores do Manifesto Ágil

·         10 workshops

·         52 palestras

·         4 tutoriais

·         4 seções Lightning Talks com assuntos de todos os tipos.

Em outras atividades práticas que a comunidade foi planejando e realizando durante o evento foi possível participar de vários Open Space e Dojo.

Durante o congresso ainda foram iniciados os desenvolvimentos de alguns aplicativos que quem sabe em breve teremos mais notícias sobre eles.

Para tudo isto funcionar, foram quase 100 pessoas envolvidas na organização do evento.

Agora é torcer para que 2012 seja ainda melhor.

Permalink | Leave a comment  »

Sabe quando alguém da sua família (mãe, pai, esposa, filhos, primos, etc) lhe pergunta com o que você trabalha, você gentilmente responde que trabalha com gestão de projetos e tenta explicar o que é isto, normalmente utilizamos termos usuais do nosso meio profissional, assim como os advogados (Ex: Data Vênia), os médicos com seus termos técnicos (Ex. Cefaléia), o pessoal de Informática com as suas siglas (Ex. ERP, BI, CRM, ASP, SAAS, etc.) e outras profissões, cada qual utilizando suas “gravatas” nas palavras para demonstrar que somos especialistas naquilo e passar um pouco de poder, para não dizer uma pitada de arrogância.  E quanto a preocupação de saber se quem perguntou entendeu alguma coisa, deixa pra lá.

Como o pessoal é da família e a intimidade é maior, normalmente recebemos o feedback assim: a tá, entendi ! e fazem aquela expressão que não entenderam nada e para não perder a amizade, mudam de assunto rapidamente.

E na próxima festa ou confraternização da família a pergunta volta a se repetir, e a mesma pessoa que já lhe perguntou pelo menos umas 3 vezes, repete a pergunta: ei, fulano, você trabalha com o quê mesmo, estes dias fui falar para um amigo e não lembrava mais, pode me explicar novamente?  Ou quando o seu filho vem lhe perguntar dizendo que tem que contar para os amigos no colégio com o quê você trabalha; Ai você para, pensa e vê que a comunicação não está legal.

Pois é, depois de passar por estas situações algumas vezes, e verificar que da forma que estava tentando me comunicar não estava funcionando muito bem, resolvi pensar em situações reais que vivenciamos no dia-a-dia para explicar os conceitos de gestão de projetos, evitando usar “gravatas” nas palavras.

O que quero dizer com o termo “Gravatas” nas palavras é que muitas vezes usamos uma linguagem usual do nosso meio profissional para explicar coisas para pessoas que não são do mesmo ambiente, ou seja, a linguagem e a forma não estão adequadas para o público que estamos transmitindo a mensagem, fazendo com que a comunicação não fique na mesma sintonia.

Para conseguir explicar com o que trabalho, pensei no exemplo abaixo para exemplificar o conceito de gestão de projetos que usamos nas empresas, traduzindo para nossa vida pessoal.

Gestão de Projetos: Sabe aquela viagem de férias que você está planejamento há um bom tempo para a Disney nos EUA, onde pretende ficar 10 dias conhecendo pelo menos 5 parques, ficar num Hotel da própria rede com a família e tirar alguns dias de compras, pois é, isto é um projeto, por que?

·         É temporário – tem início, meio e fim;

·         A experiência vai ser única, mesmo que você volte outras vezes, nunca será a mesma coisa;

·         Tem que definir o que se quer na viagem (qual tipo de hotel e padrão de qualidade, quantas pessoas irão viajar, que parques visitar, quanto tempo para cada atividade de lazer e compras, que lugares conhecer, etc. – Gestão do Escopo e do Tempo;

·         Vai definir quanto pretende gastar na viagem - Gestão de Custo;

·         Terá que pensar nos riscos desta viagem (Ex. E se alguém não conseguir o visto americano, quais os brinquedos mais perigosos para crianças para evitar acidentes, e se alguém ficar doente, o que fazer, etc.) – Gestão de Riscos;

·         Qual a agência de viagem deve contratar, considerando o preço, serviços, atendimento e que lhe dê o suporte para qualquer imprevisto – Gestão de Aquisições;

·         Quem da família irá na viagem e se alguém conhece o idioma inglês para facilitar a comunicação, caso não, como deverá se preparar para isto, fazendo aula particular ou um curso em alguma escola de idiomas, etc. – Gestão de Recursos Humanos;

·         Qual a forma e meio que será utilizado para comunicar todas as informações da viagem, de forma que todos entendam claramente o seu papel neste projeto, evitando usar “gravatas” nesta comunicação – Gestão da Comunicação;

·         Definir o padrão de qualidade que se espera durante a viagem, como por exemplo, qual a categoria do hotel (quantas estrelas), companhia aérea da viagem e tipo de classe do assento (Econômica, Executiva ou Primeira Classe), consulta a sites especializados para ver a pesquisa de satisfação de outros hospedes. – Gestão da Qualidade;

·         E após todas estas definições, verificar se tudo que foi previsto e se espera na viagem está integrado e coerente com o planejamento do todo, pois não faz sentido dizer que se espera gastar USD 2.000,00 por pessoa neste projeto e planejar viajar em classe Executiva e ficar em hotel 5 estrelas, que irá gastar muito mais que o valor previsto – Gestão da Integração;

Quem já viajou sabe que devemos pensar em tudo isto que foi colocado e em mais coisas ainda, e para que a viagem corra tudo bem e seja bem proveitosa, sabe que este projeto de férias deve ser bem planejado para evitar surpresas indesejáveis que podem estragar o passeio, antes, durante e depois da viagem, quando chegar a fatura do cartão de crédito, por exemplo.

Pois é, se você já foi a pessoa responsável por cuidar de todo este planejamento e gerenciar estas atividades para que tudo aconteça no prazo, no orçamento e dentro das expectativas dos envolvidos, parabéns, você foi o Gerente de Projeto deste projeto.

Podemos fazer a mesma analogia com o projeto para a construção, compra ou reforma da casa, o projeto da Pós Graduação, o Projeto do Intercâmbio de estudos, Projeto da Construção do Skate, Projeto da Reeducação alimentar, etc.

Vejam que os projetos fazem parte da nossa vida pessoal também, e se não forem gerenciados da forma adequada, podemos perder muito com isto: tempo, dinheiro, saúde e até amigos em situações mais extremas (quem já viajou em grupo sabe o que isto significa, alinhar as expectativas de todos não é fácil, em gestão de projetos chamamos isto de gestão das partes interessadas ou gestão de stakeholders, se preferir usar uma “gravata”).

Bem, agora que já alinhamos o que são projetos, no próximo post vamos tirar as “gravatas” do conceito Gestão de Programas, buscando ilustrar de que forma a gestão de programas faz parte da nossa vida também.

Permalink | Leave a comment  »