Autor

Lições Aprendidas

Começo o meu texto fazendo uma pergunta:

- Você já registrou durante ou no término de um projeto LIÇÕES APRENDIDAS ?

Se a resposta foi sim, wow, você tem exercido uma boa prática e melhorado seu banco de conhecimento.

Senão, está na hora de registrar conhecimentos positivos e/ou negativos para que possa ser melhor aproveitado em projetos futuros. No caso de projetos de maior porte durante o próprio projeto nas fases seguintes. Praticar o que já foi vivenciado pode significar economia de tempo e financeira além de facilitar avaliações de viabilidade de projetos futuros, favorecendo consultar parâmetros para obtenção de melhores estimativas.

Segundo o Guia PMBOK 4ª edição, as lições aprendidas correspondem à aprendizagem obtida durante o processo de realização do projeto. Adicionalmente, o aprendizado obtido durante a prestação de outros serviços também poderia ser documentada através do mesmo método.

Para Ricardo Vargas as lições aprendidas devem conter:

  • Simplicidade (Linguagem clara e rastreável)
  • Documentação (Registro formal de lição aprendida)
  • Relevância (Informações que façam a diferença)
  • Contexto (Cenário situacional)

Podemos utilizar uma tabela para registrar lições aprendidas.

Projeto: Qualidade Manaus 2012
Id Situação Positiva / Negativa Solução Impacto Responsável
12 Descrição do fato + Como foi solucionada a situação 3 – Médio Autor do registro
20 Descrição do fato - Como foi solucionada a situação
5 – Alto
Autor do registro

O impacto da situação pode ser classificado da seguinte forma:
1 – Baixo
2 – Pouco Baixo
3 – Médio
4 – Pouco Alto
5 – Alto

Uma dica importante é que devo documentar todas as lições aprendidas de projetos concluídos com sucesso ou não.

A capacidade de aprender e se adaptar rapidamente aos novos cenários é que fazem a diferença nas empresas da era da informação.

Onde saber mais:
Podcast 05:00 PM Ricardo Vargas
Neste podcast, o Ricardo explica o que são lições aprendidas e os benefícios gerados pelo registro dessas lições aprendidas. Ele mostra também como elas devem ser documentadas e os recursos que podem ser utilizados na documentação.
Lições Aprendidas - http://www.ricardo-vargas.com

wow- WOW é uma expressão americana usada para expressar espanto como usamos o UAU em português, aliás a pronúncia do inglês tem o mesmo som do UAU em português.

Qualidade: Treinamento + Atendimento

Escrevo há 3 anos neste blog que trata de Qualidade, Gerenciamento e Teste de Software, pois bem em um fato recente que aconteceu em meu cotidiano consegui visualizar a integração das disciplinas de forma negativa.

Case:
Em um comercial de rádio tive conhecimento de uma rede de postos que oferece um cartão fidelidade que acumula um valor a cada litro abastecido em seus postos. Fiquei com a ideia na cabeça e resolvi abandonar os postos BR para usufruir do beneficio que achei interessante.

Cheguei até o posto, solicitei ao frentista para participar do programa de benefícios ele prontamente vai pegar o Cartão junto com um flyer explicativo e logo avisa que não posso acumular pontos até que me cadastre na Internet, mesmo assim abasteci no posto.

Pós Venda

Análise
Qualidade:
- O flyer que recebi junto com o cartão estava todo amassado, sem uma boa apresentação.

Atendimento:
- Atendente foi atencioso porém passou informação incorreta “O Senhor precisa se cadastrar na Internet”, quando ao receber o cartão você já pode acumular pontos. Será falha de comunicação ou falta de treinamento ?

Site:
- Fiz o cadastro todo no site (gasta 5 minutos se tiver todas as informações na mão) para ao final dar a mensagem que não poderia cadastrar pois o cartão ainda não tinha pontos.
- No site da empresa (http://www.equadorpetroleo.com.br) o canal com o cliente não funciona (http://www.equadorpetroleo.com.br:81/)

Feedback:
- Para relatar o ocorrido entrei em contato via fale conosco (http://equadorpetroleo.com.br/contatos.html) no dia 24/10/2011 e até hoje 29/10/2011 sem resposta.

Como estão relacionadas as coisas:
Site com falhas (Teste de Software)
Sem feedback + Informações erradas (comunicação, processo, treinamento)
Material amassado + Site sem funcionar +  Informações erradas (Qualidade)

 

Resposta da Empresa:

Bom dia Sr. Daniel,

Primeiramente pedimos desculpas pelo ocorrido e gostaríamos de agradecer às críticas.

Informamos que estes pontos já estão sendo tratados pelos nossos colaboradores. A distribuição de material e o treinamento do corpo de frentistas é meta principal para ser resolvida a curto prazo.

Fizemos um levantamento dos postos que estão sem material e estamos fazendo a reposição.

Já estamos colocando em prática agora em Novembro um plano de treinamento para nossos frentistas, com distribuição de material informativo, pois muitos dos atendentes que foram treinados no início da campanha já não fazem mais parte do quadro de funcionários dos postos, causando este tipo de informação equivocada. E também um plano para a manutenção disto a longo prazo.

Esperamos que o senhor continue conosco e agradecemos a compreensão,

 Atenciosamente,

Paradoxo de Abilene

O Paradoxo de Abilene é um paradoxo enunciado por Jerry B. Harvey, especialista em gestão e professor da The George Washington University, especialista em dinâmica de grupos e gestão organizacional.

Neste paradoxo, um indivíduo toma uma decisão baseando-se na suposição de que um grupo vai agir de uma certa forma. Este individuo contrariou a sua vontade em função do grupo, para obter aceitação ou para não sofrer censura. Uma maneira coloquial de se referir a este paradoxo é o “desejo de não virar o barco”.

Não ocorre comunicação alguma, pois este individuo tem certeza que avaliou corretamente as intenções dos outros integrantes do grupo. O paradoxo é que esta mesma situação ocorre com todos os indivíduos do grupo.

Exemplo:

  • Você vai passear na praia supondo que todos os seus parentes querem ir.
  • Na realidade você não quer ir a praia, e nenhum de seus parentes quer ir. Dessa forma o passeio é um fracasso.

Se alguém questionar a suposição, o paradoxo desfaz-se.

Este paradoxo só existe num ambiente em que a comunicação é falha. Em empresas, o ambiente de projetos é especialmente vulnerável a este paradoxo.

Foi inicialmente observado por Jerry B. Harvey no seu artigo “The Abilene Paradox and other Meditations on Management”. O exemplo usado neste artigo conta uma viagem a Abilene (Texas), e daí o nome do paradoxo.

Resumo do Fato

Numa tarde quente em visita a Coleman (Texas), uma família está confortavelmente jogando Dominó no alpendre da casa, até que o sogro sugere um passeio a Abilene (Texas), que fica a 53 milhas, para jantar. A esposa diz, “parece uma boa idéia”. O marido, apesar de ter algumas reservas quanto ao calor e a distância, imagina que sua opinião pode estar em desacordo com o grupo e diz “por mim tudo bem. Apenas espero que sua mãe queira ir”. A sogra então diz “claro que eu quero ir. Há muito tempo que não vou a Abilene”.

A viagem é longa, empoeirada e quente. Quando chegam na cafeteria, a comida é tão ruim quanto a viagem. Eles chegam de volta em casa quatro horas depois, exaustos.

O genro fala desonestamente “Foi um bela viagem, não foi?” A sogra diz que, na verdade, ela peferia ficar em casa, mas concordou em ir já que os outros três estavam tão entusiasmados. O marido diz “Não me agradou fazer isso. Só fui para agradar vocês.”

Como saber quando esta paradoxo está instalado em uma organização?

Harvey (1974),  nos dá algumas pistas:

  1. Existem conflitos na organização.
  2. Os membros da organização sentem-se frustrados, impotentes e infelizes quando tentam lidar com os conflitos. Muitos deles estão à procura de saídas. Poderão evitar reuniões onde os conflitos são discutidos, poderão estar à procura de outros empregos, ou poderão estar fora do escritório o máximo tempo possível (chegar tarde e sair cedo, baixas, viagens desnecessárias, conferências, treinamentos, etc.).
  3. Os membros da organização colocam a culpa no chefe ou em outros departamentos ou grupos. Em conversas de corredor entre amigos o chefe é visto como incompetente, ineficaz e indisponível. Na sua presença nada é dito. Na melhor das hipóteses apenas são dadas vagas referências à sua posição relativamente aos conflitos da organização.
  4. Pequenos grupos de amigos e associados encontram-se informalmente fora da organização para discutir os conflitos. Existe bastante acordo nas ideias apresentadas para solucionar os conflitos. Estas conversas usam normalmente termos como “Devíamos fazer…”, “Se tivessemos…”, etc.
  5. Em reuniões dentro da organização esses mesmos membros não revelam totalmente as suas opiniões. Até chegam a revelar opiniões inversas só para ir ao encontro do que pensam ser a “opinião global”.
  6. Depois dessas reuniões os membros arrependem-se de não terem dito tudo o que queriam e apresentam uma lista de razões convincentes para não terem conseguido revelar as suas verdadeiras opiniões.
  7. Todas as tentativas de resolver os conflitos não dão resultado. Em alguns casos até pioram o problema.
  8. Fora da organização as pessoas se dão bem, são mais felizes e mais eficazes do que dentro da organização.

Fonte: PM Tech Blog / Wikipedia

Gerenciamento de mudança, em projetos, e a pirâmide organizacional

O gerenciamento de projetos é o conjunto de práticas, ferramentas, habilidades e conhecimentos que promovem o planejamento, execução, controle e conclusão de um projeto. Dessa maneira, somos levados a elaborar nosso plano de projeto, com todas as ferramentas necessárias: WBS, CPM, RBS, Curva S, sendo estes seguidos e mantidos inalterados até o final do projeto. Na teoria, isso funciona perfeitamente. Na prática, a coisa não acontece de forma tão simples. Necessidades mudam, desejos mudam, requisitos mudam. Tudo muda! Sob este prisma, o gerente de projetos tem o papel de gerir as mudanças, com um principal objetivo: atender o objetivo estratégico em que o projeto está inserido.

A prática nos mostra que nem sempre é possível termos escopo, requisitos, premissas inalteradas ao longo do projeto. E o gerente de projetos, como deve lidar com isso dentro de seu ecosistema? Não esqueçamos que o gerente de projetos visa atender o objetivo estratégico do projeto, mas envolve também os interesses de fornecedores, necessidades de membros da equipe, anseios dos sponsors, etc. Henry Mintzberg, em entrevista concedida a revista HSM Management (Ano 13, Volume 1, Ano 78 – Janeiro/Fevereiro de 2010) faz uma observação interessante. Ele afirma que os gestores normalmente são comparados a maestros de orquestra: em que um gesto indica o início de uma ação, demonstrando plena harmonia. Entretanto, o gestor ou líder no seu dia-a-dia assume o papel de um maestro no ENSAIO: os músicos erram, os ajudantes fazem barulho, o instrumento desafina, etc. Esta visão proposta por Mintzenberg está alinhada com a realidade de projetos!

Dentro desse cenário de transformação e incertezas, o gerente de projetos tem a obrigação de assumir o papel de líder. Este líder deve ter uma visão que propicie não apenas o gerenciamento do projeto, mas também, o gerenciamento de expectativas em um contexto de mudança. Para tanto, serão analisadas sob três aspectos: estratégico, tático e operacional.

- Estratégico: O papel do gerente de projetos moderno, além de atender a tripla restrição (requisitos, prazo e orçamento) deve ser o de obter resultados para o negócio, atingindo critérios múltiplos. Isso quer dizer que mudanças podem ser demandas pelo cliente/sponsor mas também pode ser fruto de uma análise do cenário feita pelo gerente de projetos. Ambas as abordagens tem o mesmo objetivo: maximizar os resultados do projeto. Mudanças identificadas nesse faixa da pirâmide normalmente consideram fatores como por exemplo: comparativo do ROI (com a mudança e sem a mudança), alterações no payback, mudanças no fluxo de caixa do projeto, aumento número de pessoas atendidas por um projeto social, aumento do market-share do produto, etc. Mudanças demandas sob estes critérios são comuns, pois são regidas pelo cenário macro-econômico com crises, legislações, oportunidades de mercado, etc.

- Tático: Uma vez definida a oportunidade e/ou necessidade de mudança, quais os impactos no meu projeto? Nesta etapa deve ser avaliado o contexto do projeto em si:
• Quais os pacotes de trabalho que serão adicionados no meu projeto?
• Como isso impacta no meu orçamento? Será feito um incremento do budget ou devem ser aplicadas técnicas de otimização?
• Quais os riscos agregados a esta mudança?
• Novos stakeholders estão envolvidos? Faz-se necessário o uso de novos mecanismos de comunicação?
• Qual o resultado de minha análise make-or-buy? Terei tempo hábil para preparar edital, licitação, etc? Existem parceiros que atendam minhas necessidades ou precisaremos de rodadas de negociação?
• Quais os requisitos de qualidade para esta mudança? São necessários mecanismos adicionais de testes? Como isso impactará no meu orçamento?
• São necessários mais pessoas no projeto? Qual a alteração do meu caminho crítico? Com a mudança, qual o impacto no cronograma para ajustes na simulação de Monte Carlo, SDPM ou CCPM?

Estas situações devem ser analisadas pelo gerente de projetos e sua equipe, para posterior repasse aos níveis estratégicos. Dessa maneira, o sponsor, por exemplo, poderá avaliar se o aumento do market-share está compatível com o aumento do budget necessário.

- Operacional: Tudo bem. Minha mudança tem uma motivação estratégica e é exeqüível de acordo com algumas ferramentas do meu planejamento. E quais impactos que tenho no andamento do meu projeto? Preciso construir novos formulários, projetos de engenharia, modelos de especificação de caso de uso, etc ? Outra situação possível é que o processo de mudança seja iniciado pela equipe de projeto. Exemplo: o projeto previa a instalação de um servidor de aplicação em virtude da tecnologia utilizada e esta atividade possuía um risco e um custo associado. Entretanto, durante o projeto surgiu a possibilidade de utilizar outra tecnologia em que estes riscos e custos não existiriam.

Estas três visões normalmente são ensinadas de forma separada, mas tem profundo relacionamento na prática. A mudança pode ser motivada por uma decisão ou necessidade estratégica, tática ou operacional, mas com certeza serão gerados impactos nas outras áreas da pirâmide. Assim, é fundamental que o Gerente de Projetos esteja preparado para eventuais mudanças, mas que estas sejam fruto de uma análise nas três esferas, garantindo que as transformações maximizem os objetivos desejados.

Créditos:
Daniel Tadeu Martínez Castello Branco, MBA ( daniel.tadeu@gmail.com )

Formado em Ciências da Computação, pela Universidade Federal do Amazonas, e MBA em Gerenciamento de Projetos, pela Fundação Getúlio Vargas. Possui 10 anos de experiência em projetos de desenvolvimento de software.

CrowdTest (Crowdsourcing)

O CrowdTest é um serviço realizado organizando mão-de-obra disponível na Internet para execução de testes. Esse modelo de trabalho, conhecido como crowdsourcing, permite que as empresas tenham seus produtos testados por usuários reais e que as pessoas sejam recompensadas pelo seu trabalho de encontrar as falhas.

Nos projetos de CrowdTest temos três papéis: o cliente, a equipe do CrowdTest e os testadores. O CrowdTest recebe as demandas dos clientes, organiza o projeto e a equipe que irá participar, recebe as falhas, faz a validação e disponibiliza o resultado para os clientes. O diagrama a seguir detalha como são os passos dentro de um projeto.

O modelo  começou a operar em março deste ano no Brasil e já realizou cerca de 20 ações com empresas como Buscapé, Sul-América, Via6, CupomNow, entre outras. O site (http://www.crowdtest.me/) surgiu a partir da experiência anterior de Barros à frente da a Base2, empresa especializada em testar softwares.

O Site uTest (http://www.utest.com/) é um dos maiores do mundo e conta com um grande número de testadores ao redor do globo que testam segmentos da industria de software como Mobile, Web e Sistemas Desktop.

A conversa sobre Crowdsourcing começa a fazer parte das discussões nos grupos de teste espalhados pelo Brasil, já que isso pode colocar em xeque equipes de Testes dentro de empresas que podem contar com um serviço executado coletivamente fazendo frente ao trabalho de equipes reduzidas dentro das empresas que geralmente custam mais caro.

 

Fonte:

UNIEURO realizará o I Seminário Brasiliense de Teste de Software

A Associação Latino-Americana de Teste de Software (ALATS), em parceria com o Centro Universitário UNIEURO, realizará o 1º Seminário Brasiliense de Teste de Software. O evento acontecerá no auditório do campus da Asa Sul no dia 16 de setembro.

O objetivo do seminário é disseminar práticas em teste de software e criar um ambiente onde os participantes possam trocar experiências. Outras informações no site: http://www.alats.org.br

Gerenciador de Cupons – Compra Coletiva

Com o crescimento do mercado online graças ao fenômeno das compras coletivas, novas necessidades começam a surgir para os amantes dos descontos oferecidos pelos sites de ofertas.

Consumidores necessitam controlar seus cupons, já que cada cupom tem prazo definido para utilização e são adquiridos em diferentes sites e inúmeros fornecedores. Diante deste cenário a empresa amazonense SOPIXEL desenvolveu uma solução para atender a demanda existente.

Consumidores necessitam controlar seus cupons, já que cada cupom tem prazo definido para utilização e são adquiridos em diferentes sites e inúmeros fornecedores. Diante deste cenário a empresa amazonense SOPIXEL desenvolveu uma solução para atender a demanda existente.

Depoimento:
O PortaCupom é simples, prático e evita que eu perca meus Cupons.
- Domingos Coelho

Dados do Aplicativo:
Plataforma: Android Versão 1.6 ou superior
Versão: 1.1 atualizada em 15/06/2011
Informações: http://portacupom.sopixel.com.br/
DOWNLOAD

Gold Plating

Sabe quando o consultor de vendas de sua empresa chega com o escopo de projeto para realizar estudo de custo e acaba omitindo pequenos “serviços” que a primeira vista parecem não impactar os custos. Então pode esperar que o cliente vai cobrar pelos “servicinhos” e eles irão necessitar recursos.

O Gold Plating é tudo que o escopo do projeto não atende e na negociação acabam entrando como pequenos mimos.

Segundo Karl E. Wiegers autor do livro Software Requirements “Gold plating em Engenharia de software refere-se a adicionar funcionalidades a um sistema que não foram solicitadas pelos usuários porque o desenvolvedor acha que o sistema fica melhor com as novas funcionalidades. Este processo é chamado de Gold plating.”

Crédito de Imagem: http://www.webluxo.com.br/

Na visão do negócio isso pode ser bastante prejudicial. Exemplo: Um treinamento não planejado pelo cliente é oferecido como Gold plating e este não poderá gerar receita e além de custar caro a ponto de diminuir consideravelmente os meus lucros.

Dicas (Diego Nei):

  • Assegure-se de que todos sabem e entendem qual o objetivo do projeto e que haja consenso sobre o resultado final do mesmo;
  • Ouça com atenção o que seu cliente descreve;
  • Tente entender não o que ele lhe pede para fazer, mas sim o que ele precisa para resolver o problema que lhe apresenta;
  • Descubra o que ele não quer. Muitas vezes um projeto não vai para frente por que o escopo foca em coisas que não deveriam estar lá;
  • Estabeleça o que não vai ser feito no projeto enquanto o cliente ainda estiver disponível. Se ele pedir X e Y, mas você perceber que Z e W devem ser providenciados, mas somente W é da sua responsabilidade, deixe claro que Z está fora do escopo do projeto;
  • Estabeleça o que será necessário para que o projeto seja atingido, defina os pressupostos, de forma que todos saibam de antemão quais as necessidades básicas do projeto antes que elas atrapalhem seu andamento;
  • Seja realista quanto ao que pode ou não ser realizado, quanto mais “pé-no-chão” é o escopo, maior a chance de sucesso do projeto;
  • Evite o GoldPlating. Se não faz parte do escopo do projeto, não adianta tentar agradar o cliente com aplicações/funções ‘firula’. Elas podem acabar acarretando em um atraso no cronograma;
  • Não tenho medo nem pena de fazer perguntas. Pode parecer óbvio para você, mas se não estiver absolutamente claro, pergunte;
  • Tenha o time de projeto (ou os gerentes dos mesmos) na mesa de reunião quando o escopo for definido, assim qualquer problema técnico ou dúvida operacional poderá ser sanada na hora, em vez de descoberta posteriormente, causando problemas para o projeto.

Referências:
- Wiegers, Karl E. Software Requirements. 2nd ed. Microsoft Press. 2003
- Diego Nei – http://papogp.wordpress.com/
- Aulas de Gerenciamento de Escopo FGV