¿Existe un factor de relación entre el tiempo de reunión y el ahorro de tiempo de desarrollo?

Estoy trabajando en un proyecto y tenemos reuniones informales periódicas (generalmente semanales), donde discutimos el estado del proyecto y la GUI del mismo.

Soy el único desarrollador allí, las otras 4-5 personas no tienen experiencia en TI.

Esta reunión tomó mucho más tiempo de lo habitual, pero en un momento, uno de mis colegas preguntó acerca de algunos campos en el programa y cómo se llenan. Respondí y en la discusión me di cuenta de que entendí totalmente mal el proceso.

Pero dado que hablamos sobre ello y encontramos el error de antemano, puedo cambiarlo bastante rápido.

Al pensar en esto, me he preguntado si hay un factor entre el tiempo de reunión para ahorrar tiempo de desarrollo.

Por ejemplo, 1 minuto de tiempo de reunión puede ahorrar X minutos de tiempo de desarrollo.

Si es así, esto ayudaría a definir, con qué frecuencia y por cuánto tiempo deberían ser nuestras reuniones.

(Solo para aclarar: no quiero hacer mejores reuniones, incluso poder determinar aproximadamente la duración de las reuniones es opcional. ¡Estoy principalmente interesado SI hay una relación entre el tiempo de reunión y el tiempo de desarrollo! Mi razón para preguntar: ¡curiosidad! )

"Mientras lo necesiten, y no más".

Lo que hay que tener en cuenta aquí es que el tiempo de reunión para ahorrar tiempo de desarrollo no es de ninguna manera lineal. Para su equipo, para su empresa, para este tema, 1 hora de reuniones podría ahorrar 2 horas de trabajo de desarrollo. Si tiene 10 horas de reuniones, otra hora de reuniones podría ahorrar 0 trabajos de desarrollo. Demonios, puede ahorrarte -2 horas de trabajo de desarrollo debido a interrupciones o impacto en la moral.

Al final, el objetivo de las reuniones es que la comunicación y la colaboración lo ayudan a hacer las cosas. Si las reuniones no te ayudan a hacer las cosas, entonces deberían ser eliminadas.

No exactamente.

Comprender al cliente / parte interesada puede ahorrar tiempo de desarrollo. Y las conversaciones deben ser lo suficientemente largas para facilitar la comprensión. Pero, discutir una característica que ya presume comprender no necesariamente mejorará su comprensión.

Si nadie en la sala tiene sospechas de malentendidos o suposiciones falsas, abandone la sala. La prolongación artificial de una "discusión" con la esperanza de que el tiempo de cizallamiento y la presión empujen un conflicto y creen armonía es desesperante y desmoralizante.

Y recuerde que comunicarse es una combinación de habilidad y suerte; la discusión no necesariamente implica comunicación (comprensión mutua). Todos mejorarán al exponer malas suposiciones cuanto más tiempo trabajen en el campo y más tiempo trabajen juntos.

Mientras tanto, "Agilidad" puede ser útil.

Mantenga las reuniones "cortas" e implemente interfaces de usuario o maquetas crudas tan pronto como sea posible después de cada reunión, mucho antes de que sospeche que tiene una comprensión completa. Sus UI / simulacros servirán como material para aclarar malentendidos. El tiempo entre reuniones ayudará a todos a descomprimirse y reflexionar sobre lo que se dijo. Y si implementa sus materiales show-and-tell en código , también ha comenzado el desarrollo. (¡Y sus clientes / colegas estarán encantados de escuchar esto!)

Y el peor de los casos, cuando ha implementado una pequeña porción de código visible : está totalmente fuera de lugar y lo tira. Pero, si solo ha dedicado una pequeña cantidad de tiempo, la inversión vale mucho para aclarar los malentendidos.

Y recuerde, a la compañía no le importa el tiempo de desarrollo ; solo le importa el tiempo de persona . (Como un medio para calcular el costo total , ten en cuenta). Por lo tanto, debes buscar el equilibrio en el que se minimiza el tiempo de persona ; no tiempo dedicado a escribir código.

No creo que haya ningún tipo de correlación que pueda aplicarse en general. Realmente depende de la reunión y de las cosas que haces allí relacionadas con el desarrollo.

En la situación que describe, en unos minutos pasó de tener un requisito malo o mal entendido a tener uno mejor. Sabemos que tener buenos requisitos tiene un impacto directo en el tiempo de desarrollo.

Pero, ¿qué pasaría si su reunión fuera algo así como una reunión sobre el estado de la empresa? Compartes buena información para saber cómo le está yendo a la empresa, estar al tanto de otras cosas que suceden, etc. Pero, en su mayor parte, eso no tendrá ningún efecto en el tiempo de desarrollo de tu proyecto. Todo ese tiempo se "desperdicia" cuando se mira desde una perspectiva de desarrollo.

Una vez que haya tenido que ir a suficientes reuniones, comenzará a darse cuenta de que algunas son realmente productivas (por ejemplo, tome un pequeño equipo de desarrollo y un buen conjunto de requisitos y comience a poner en pizarra una arquitectura. Puede hacer mucho si se mantiene enfocado .). También encontrará algunos que no son productivos o que incluso tienen una productividad negativa (una vez que un cliente tuvo un debate de 15 minutos entre algunos de ellos sobre si una página de inicio de sesión debería decir "Iniciar sesión" o "Iniciar sesión". Al final de eso, nadie lo sabía y tuvo que ser presentado hasta más tarde).

TL / DR: Depende de la reunión, las personas y los objetivos de la reunión.