Existe um fator de relação entre o tempo de reunião e a economia de tempo de desenvolvimento?

Estou trabalhando em um projeto e temos reuniões informais regulares (geralmente semanais), nas quais discutimos o status do projeto e a GUI do mesmo.

Eu sou o único desenvolvedor lá, as outras 4-5 pessoas têm um background que não é de TI.

Essa reunião levou muito mais tempo do que o normal, mas a certa altura, um dos meus colegas perguntou sobre alguns campos do programa e como eles são preenchidos. Eu respondi e, na discussão, notei que entendi totalmente o processo errado.

Mas, como conversamos sobre o assunto e descobrimos o erro de antemão, posso alterá-lo rapidamente.

Enquanto pensava nisso, perguntei-me: se existe um fator entre o horário da reunião e o tempo de desenvolvimento?

Por exemplo, 1 minuto do tempo da reunião pode economizar X minutos do tempo de desenvolvimento.

Nesse caso, isso ajudaria a definir qual a frequência e a duração de nossas reuniões.

(Apenas para esclarecer: não quero fazer reuniões melhores, mesmo sendo capaz de determinar aproximadamente a duração das reuniões é opcional. Estou mais interessado se houver uma relação entre o tempo da reunião e o tempo de desenvolvimento! Meu motivo para perguntar: curiosidade! )

"Enquanto eles precisarem, e não mais".

O que se deve perceber aqui é que o tempo de reunião para economizar tempo de desenvolvimento não é linear. Para sua equipe, sua empresa e este tópico, uma hora de reuniões pode economizar 2 horas de trabalho de desenvolvedor. Se você tiver 10 horas de reuniões, outra hora poderá economizar 0 trabalho de desenvolvimento. Inferno, você pode economizar -2 horas de trabalho de desenvolvimento devido a interrupções ou impacto no moral.

No final, o objetivo principal das reuniões é que a comunicação e a colaboração ajudem você a realizar as tarefas. Se as reuniões não estiverem ajudando você a fazer as coisas, elas devem ser mortas.

Não exatamente.

Compreender o cliente / parte interessada pode economizar tempo de desenvolvimento. E as conversas precisam ser longas o suficiente para facilitar o entendimento. Porém, discutir um recurso que você já presume entender não melhorará necessariamente sua compreensão.

Se ninguém na sala suspeitar de mal-entendidos ou suposições falsas, saia da sala. Prolongar artificialmente uma "discussão" na esperança de que o tempo e a pressão de cisalhamento empurrem um conflito para fora e criem harmonia é desesperador e desmoralizante.

E lembre-se de que a comunicação é uma combinação de habilidade e sorte; discussão não implica necessariamente comunicação (entendimento mútuo). Todos vocês ficarão melhores em expor suposições ruins quanto mais tempo trabalharem em campo e mais tempo trabalharem juntos.

Enquanto isso, "Agilidade" pode ser útil.

Mantenha as reuniões "breves" e implemente UIs ou modelos brutos assim que possível após cada reunião - muito antes de você suspeitar ter um entendimento completo. Sua interface do usuário / zombaria servirá como material para esclarecer mal-entendidos. O tempo entre as reuniões ajudará todos a descomprimir e refletir sobre o que foi dito. E se você implementar seus materiais show-and-tell no código , também começará o desenvolvimento. (E seus clientes / colegas ficarão emocionados ao ouvir isso!)

E o pior cenário, quando você implementou um pequeno pedaço de código visível : você está totalmente fora da base e o joga fora. Mas, se você dedicou apenas uma pequena quantidade de tempo, o investimento compensa bastante esclarecendo um mal-entendido.

E lembre-se, a empresa não se importa com o tempo de desenvolvimento ; apenas se preocupa com o tempo da pessoa . (Como forma de calcular o custo total , lembre-se.) Portanto, você precisa procurar o equilíbrio em que o tempo da pessoa é minimizado; não tempo gasto escrevendo código.

Não acredito que exista qualquer tipo de correlação que possa ser aplicada em geral. Realmente depende da reunião e das coisas que você faz lá relacionadas ao desenvolvimento.

Na situação que você descreve, em poucos minutos você deixou de ter um requisito ruim ou mal compreendido para ter um requisito melhor. Sabemos que ter bons requisitos tem um impacto direto no tempo de desenvolvimento.

Mas e se a sua reunião fosse algo como uma reunião de status da empresa. Você compartilha boas informações para saber como está a empresa, conhecer outras coisas, etc. Mas, na maioria das vezes, isso não afetará o tempo de desenvolvimento do seu projeto. Todo esse tempo é "desperdiçado" quando se olha para ele de uma perspectiva de desenvolvimento.

Depois de ter participado de reuniões suficientes, você começa a perceber que alguns são realmente produtivos (por exemplo, pegue uma equipe de desenvolvimento pequena e um bom conjunto de requisitos e inicie o quadro branco de uma arquitetura. Você pode fazer muito se permanecer focado .). Você também encontra alguns que não são produtivos ou que têm produtividade negativa (uma vez que um cliente teve um debate de 15 minutos entre alguns deles sobre se uma página de login deveria dizer "Login" ou "Logon". no final, ninguém sabia e tinha que ser entregue até mais tarde).

TL / DR: Depende da reunião, das pessoas e dos objetivos da reunião.