Reunião pós-projeto uma perda de tempo?

No meu local de trabalho, tivemos algumas sérias dores de crescimento. Passamos de uma equipe de desenvolvimento de 3 para 10, e a própria empresa cresceu 30% no ano passado. Pela maioria das medições, estamos indo bem. Infelizmente, a qualidade do nosso software sofreu.

Em uma reunião hoje com o gerente da minha divisão, propus uma reunião da equipe de projeto um ou dois dias após o lançamento do produto. Poderíamos discutir questões orçamentárias, escopo, o que deu errado e o que deu certo. Idealmente, aprendendo com nossos erros. Criamos sites / aplicativos para outras pessoas, portanto nosso tempo é cobrado por não faturável. Uma reunião como essa seria abrangida por este último.

Meu gerente descartou quase imediatamente: "Esse tempo não é faturável. Isso nos fará ficar para trás em outro projeto, porque perdemos tempo no final daquele falando sobre isso". Fiquei tão pego de surpresa por essa lógica que nem me incomodei em lutar contra ele.

Então, minha pergunta: vejo que o valor são as reuniões pós-projeto, mas ele não. Existem provas documentadas de reuniões pós-projeto que ajudam a economizar tempo e dinheiro no longo (ou curto) prazo? Intuitivamente, acho que sim, mas ele claramente está mais preocupado com uma pequena quantidade de tempo não faturável das 5 pessoas que precisariam estar lá.

Olhando para trás, olhando para frente estaria perto de uma prova documentada da idéia. O Projeto Post-Mortem: Uma Ferramenta Valiosa para Melhoria Contínua seria um post sobre isso.

A Arte do Post-Mortem tem este ponto sobre a idéia:

As origens do Post-Mortem estão com os militares, que rotineiramente usam esse tipo de processo para interrogar as pessoas na linha de frente. Mas seu aplicativo de gerenciamento é essencial para qualquer organização de alto desempenho e aprendizagem.

Seu gerente não entende o conceito de Dívida técnica .

As reuniões pós-projeto são um investimento, não um custo. É assim que você precisa vendê-los. O objetivo de qualquer reunião é trocar idéias sobre como economizar dinheiro e cumprir os objetivos da empresa a longo prazo.

Seu gerente é um gerente porque ele lida com esses objetivos de longo prazo. Então, na minha opinião, existem duas verdades possíveis: seu gerente deseja todo o controle para si mesmo ou seu gerente não está fazendo o trabalho dele. Se a empresa tem uma história e filosofia de fazer as coisas "da maneira certa" e investir em seu próprio sucesso, considere levar a questão acima ao seu gerente.

Esta é essencialmente uma revisão pós-ação , que é particularmente útil em muitos contextos diferentes, não apenas nas forças armadas.

Meu próprio ciclo de desenvolvimento envolve a análise do que deve ser feito na próxima iteração ou projeto e do que poderia ser feito melhor no projeto anterior. Mesmo que um projeto seja arquivado por um tempo, ter uma lista de itens para trabalhar ajuda quando ele sai da prateleira (ou backburner ...) e é novamente um projeto ativo. Na próxima vez que tocá-lo, não preciso gastar muito tempo revisando o que preciso fazer.

Além disso, analisando um projeto e descobrindo os truques legais que eu ou outros implementamos, eles são disseminados e o próximo projeto ou a próxima iteração é muito melhor. (Não é de surpreender que eu pense com frequência em termos de iterações.)

O valor disso é lógica simples e inerentemente óbvia. Como você pode melhorar os projetos futuros se nunca aprender com seus erros nos projetos anteriores?

Embora não seja especificamente uma documentação, a revisão do processo (durante ou após a conclusão) é um componente importante de praticamente todos os sistemas de controle de qualidade baseados em padrões que conheço, especialmente o CMMI e o Lean 6 Sigma.

Talvez você possa propor isso como uma obrigação, algo que é feito voluntariamente durante uma reunião de almoço ou algo assim? É bem provável que uma grande parte da sua equipe de desenvolvimento esteja ansiosa para vir e experimentar coisas novas ... portanto, se você puder usar pelo menos a primeira, os resultados serão por si mesmos.

Pode ser que seu gerente esteja sob pressão orçamentária. Essa deve ser uma grande preocupação ao expandir de 3 para 10 desenvolvedores em pouco tempo. Se for esse o caso, provavelmente é uma boa idéia pular as reuniões post-mortem por enquanto e sugeri-las novamente em alguns meses, quando, esperançosamente, as questões orçamentárias imediatas não serão tão urgentes.

Uma razão pela qual a qualidade pode estar sofrendo é que a comunicação entre 10 pessoas é um problema muito maior do que a comunicação entre 3 pessoas: 3! << 10 !. Embora você possa provavelmente ficar confuso por um tempo, eventualmente precisará fazer algumas alterações para promover uma melhor comunicação entre os desenvolvedores e garantir que os princípios estabelecidos pelos 3 desenvolvedores originais sejam disseminados para o pessoas mais novas e atualizadas para funcionarem bem em seu novo grupo maior. As reuniões post mortem do projeto são uma maneira de fazer isso; revisões periódicas de código são outra. Não faria mal salientar que as reuniões post mortem são uma parte crítica da melhoria da qualidade nas indústrias, da medicina à manufatura.

É difícil imaginar que seu gerente acredite poder expandir sua equipe de desenvolvimento simplesmente contratando pessoas adicionais. É absolutamente necessário haver investimentos em treinamento e formação de equipes; sem isso, sua organização entrará em colapso com seu próprio peso. Se você esperar um pouco, sua organização pode começar a enfrentar alguns problemas concretos que são diretamente atribuíveis à falta de comunicação. Nesse momento, seu gerente provavelmente dirá: "Temos que colocar todos na mesma página! Agende uma reunião com todos os desenvolvedores!" E se parece ajudar, ele provavelmente dirá: "Deveríamos estar fazendo isso após cada projeto!" ;-)

Portanto, seja paciente, mas seja persistente.

Vou mudar a tendência: concordo com o gerente.

Eu achei as revisões pós-projeto em grande parte inúteis, porque é tarde demais para fazer qualquer coisa para corrigir os problemas revelados.

O que eu mais recomendaria são retrospectivas periódicas feitas durante o projeto. Uma ou duas vezes por mês, peça à equipe que fale sobre o que correu bem, o que não correu; o que fazer mais, o que fazer menos. Faça isso durante o projeto para poder aplicar imediatamente as sugestões e ver como elas funcionam.

Olhe para concretizar a reunião. Muitas reuniões pós-projeto são palestras e seu gerente está absolutamente correto em não apoiá-las.

Convide você para a reunião (peça para ele presidir / moderar), faça circular uma agenda e tenha resultados específicos. Como gerente, ele pode ver o valor na reunião.

Usamos e recomendo o processo de revisão "6 Thinking Hats" de Bono ( consulte Wikipediaidia ). O resultado são alguns (2 ou 3) pontos de ação que a reunião identifica como sendo o motivo mais importante aprendido. Nas primeiras vezes em que temos problemas para sair dos blocos de partida, mas quando nos acostumamos, não voltamos.

Não executar uma revisão pós-projeto o condena a cometer os mesmos erros que você cometeu no projeto anterior.