Postmortem de Projetos: Aprendendo com os erros

Software é escrito por humanos, então fica óbvio que nenhum projeto de software é perfeito. Não importa se você está fazendo software para aviões, robôs ou uma locadora, erros serão cometidos. Mas não estou falando apenas de bugs, as falhas de programação.

Erros podem ser cometidos na escolha de tecnologias como linguagem de programação, plataforma, ferramentas, base de dados, arquitetura e vários outros pontos. Ao contrário do que se prega, criar software não é como montar carros de passeio em série e sim montar um carro único, com características que agradem o cliente. De projeto em projeto, existem lições a serem aprendidas e o postmortem é justamente isso, mas de forma organizada e raramente feito.

O desenvolvedor consegue ver os problemas porque tudo estoura na mão dele. O gerente entubou mudanças de requisitos e o escopo tornou-se movediço? Quem trabalha no sábado é o desenvolvedor. A documentação está incompleta? Lá vai o desenvolvedor parar sua tarefa principal, que é “converter aquela pasta de documentos, planilhas, cronogramas, atas de reunião e anotações em cadernos” em algo realmente útil, para encontrar como fazer. Atrasou? “O que você faz entre meia noite e seis da manhã?”

Um postmortem de projeto deveria fazer parte da cultura das empresas que criam software, mas só as que realmente estão buscando qualidade incorporam essa prática. Uma fonte excelente é o website www.gamasutra.com, que fala sobre o desenvolvimento de jogos. Eles possuem uma coluna que virou até livro e mostra porque alguns estúdios fazem tanto sucesso e outros somem do mapa: eles estão constantemente se auto-avaliando e documentando, logo após a entrega.

Para quem está começando, uma sugestão é escrever um documento simples com: pontos positivos/realizações, dificuldades/problemas e recomendações. Nada chique nem rebuscado. Detectou que a empresa precisa de uma pessoa para criar a parte visual, coloque o problema gerador disso:
- O desenvolvimento gastou 40% do seu tempo com html e css, ao invés de concentrar em regras de negócio.
Nas recomendações, coloque a sugestão para solucionar ou pelo menos tenha menor impacto futuro:
- É necessário um profissional especializado em interface e prototipação de tela, aplicando-se webstandards. Isso irá liberar o desenvolvimento na solução de bugs de sistema.

Para saber um pouco mais sobre o assunto, recomendo a leitura do artigo The Project Postmortem: An Essential Tool for the Savvy Developer. As recomendações dele vão direto ao ponto, mas obviamente, nem todas serão aplicáveis à sua rotina.

Moral do Post:

- Um bom profissional, de qualquer área, aprende com os próprios erros.
- Um excelente profissional aprende com os próprios erros, documenta-os e compartilha essas lições com outros.
- Um postmortem pode ser algo formal, uma reunião com pauta e documentação, um processo da empresa.
- Não gosta de formalidade? Sem problemas: faça num restaurante, num bar ou um churrasco, mas converse sobre o assunto, discuta os marcos, pontos positivos e o que não foi tão bom. O importante é falar sobre o assunto e depois, é claro, documentar, mesmo que num e-mail.
- E como bem diz o artigo acima: deve haver um plano de ação. De que adianta falar sobre o assunto se ninguém se mexe para fazer algo a respeito. Se a gerência não leva isso a sério… a empresa não merece você como profissional.

Fonte: Bicalho´s Memory About Fraked Up Projects