¿La reunión posterior al proyecto es una pérdida de tiempo?

En mi lugar de trabajo, hemos tenido algunos dolores de crecimiento graves. Pasamos de un equipo de desarrollo de 3 a 10, y la propia empresa ha crecido un 30% en el último año. Según la mayoría de las mediciones, lo estamos haciendo bien. Desafortunadamente, la calidad de nuestro software ha sufrido.

En una reunión de hoy con el gerente de mi división, propuse una reunión del equipo del proyecto uno o dos días después del lanzamiento del producto. Podríamos discutir las preocupaciones presupuestarias, el alcance, lo que salió mal y lo que salió bien. Idealmente, aprender de nuestros errores. Creamos sitios / aplicaciones para otras personas, por lo que nuestro tiempo es facturable o no facturable. Una reunión como esta caería bajo este último.

Mi gerente lo derribó casi de inmediato: "Ese tiempo no es facturable. Nos hará retrasarnos en otro proyecto porque perdemos el tiempo al final de ese hablando de eso". Esta lógica me tomó tan desprevenido que ni siquiera me molesté en pelear contra él.

Entonces mi pregunta: veo que el valor son las reuniones posteriores al proyecto, pero él no. ¿Hay pruebas documentadas de las reuniones posteriores al proyecto que ayudan a ahorrar tiempo y dinero a largo (o corto) plazo? Intuitivamente creo que lo hará / lo haría, pero claramente está más preocupado por una pequeña cantidad de tiempo no facturable de las 5 personas que necesitarían estar allí.

Mirando hacia atrás, mirando hacia adelante estaría cerca de la prueba documentada de la idea. El proyecto Post-Mortem: una herramienta valiosa para la mejora continua sería una publicación de blog al respecto.

The Art Of The Post-Mortem tiene este punto sobre la idea:

Los orígenes del Post-Mortem están en el ejército, que utiliza este tipo de proceso de forma rutinaria para interrogar a las personas en el frente. Pero su aplicación de gestión es esencial para cualquier organización de aprendizaje de alto rendimiento.

Su gerente no entiende el concepto de deuda técnica .

Las reuniones posteriores al proyecto son una inversión, no un costo. Así es como tienes que venderlos. El propósito de cualquier reunión es intercambiar ideas sobre cómo ahorrar dinero y cumplir los objetivos de la compañía a largo plazo.

Su gerente es un gerente porque se ocupa de estos objetivos a largo plazo. En mi opinión, hay dos verdades posibles: su gerente quiere todo el control para sí mismo, o su gerente no está haciendo su trabajo. Si la empresa tiene una historia y una filosofía de hacer las cosas "de la manera correcta" e invertir en su propio éxito, considere abordar el problema por encima de su gerente.

Esta es esencialmente una revisión posterior a la acción , que es particularmente útil en muchos contextos diferentes, no solo en el ejército.

Mi propio ciclo de desarrollo implica analizar tanto lo que se debe hacer en la próxima iteración o proyecto como lo que se podría hacer mejor en el proyecto anterior. Incluso si un proyecto se archiva por un tiempo, tener una lista de cosas para trabajar ayuda cuando sale del estante (o retroceso ...) y nuevamente es un proyecto activo. La próxima vez que lo toque, no tengo que pasar tanto tiempo revisando lo que necesito hacer.

Además, al revisar un proyecto y encontrar los buenos trucos que yo u otros hemos implementado, estos se difunden y el próximo proyecto o próxima iteración es mucho mejor. (Puede no sorprender que piense con frecuencia en términos de iteraciones).

El valor de esto es lógica simple e inherentemente obvio. ¿Cómo puede mejorar en proyectos futuros si nunca aprende de sus errores en sus proyectos anteriores?

Si bien no es específicamente documentación, la revisión del proceso (durante o después de la finalización) es un componente importante de casi todos los sistemas de control de calidad basados ​​en estándares que conozco, especialmente CMMI y Lean 6 Sigma.

¿Tal vez podría proponerlo como una obligación, algo que se hace voluntariamente durante una reunión de almuerzo o algo así? Hay muchas posibilidades de que un buen número de su equipo de desarrollo esté ansioso por venir y probar cosas nuevas ... así que si puede cambiar al menos el primero, los resultados hablarán por sí mismos.

Puede ser que su gerente esté bajo presión presupuestaria. Eso tiene que ser una gran preocupación cuando se expande de 3 a 10 desarrolladores en poco tiempo. Si ese es el caso, entonces probablemente sea una buena idea saltear las reuniones post mortem por ahora y sugerirlas nuevamente en unos meses, cuando esperamos que los problemas presupuestarios inmediatos no sean tan apremiantes.

Una razón por la cual la calidad puede estar sufriendo es que la comunicación entre 10 personas es un problema mucho mayor que la comunicación entre 3 personas: ¡3! << 10 !. Si bien es probable que pueda salir adelante un poco, tendrá que hacer algunos cambios para fomentar una mejor comunicación entre los desarrolladores y para asegurarse de que los principios que establecieron los 3 desarrolladores originales se difundan en el personas más nuevas y actualizadas para funcionar bien en su nuevo grupo más grande. Las reuniones post mortem del proyecto son una forma de hacerlo; revisiones periódicas del código son otra. No estaría de más señalar que las reuniones post mortem son una parte crítica de la mejora de la calidad en las industrias, desde la medicina hasta la fabricación.

Es difícil imaginar que su gerente crea que puede expandir su equipo de desarrollo simplemente contratando personas adicionales. Absolutamente tiene que haber algunas inversiones en capacitación y trabajo en equipo; sin eso, su organización colapsará bajo su propio peso. Si espera un poco, su organización puede comenzar a experimentar algunos problemas concretos que se pueden atribuir directamente a una comunicación deficiente. En ese momento, su gerente probablemente dirá: "¡Tenemos que poner a todos en la misma página! ¡Programe una reunión con todos los desarrolladores!" Y si parece ayudar, probablemente dirá: "¡Deberíamos estar haciendo esto después de cada proyecto!" ;-)

Entonces, sea paciente, pero sea persistente.

Romperé con la tendencia: estoy de acuerdo con el gerente.

Las revisiones posteriores al proyecto me parecen en gran medida inútiles porque es demasiado tarde para hacer algo para corregir los problemas revelados.

Lo que más recomiendo es retrospectivas periódicas realizadas durante el proyecto. Una o dos veces al mes, haga que el equipo hable sobre lo que salió bien y lo que no; qué hacer más, qué hacer menos. Haga esto durante el proyecto para que pueda aplicar inmediatamente las sugerencias y ver qué tan bien funcionan.

Mira fomalizar la reunión. Muchas reuniones posteriores al proyecto son charlatanes y su gerente es absolutamente correcto al no apoyarlos.

Invítelo a la reunión (pídale que presida / modere), haga circular una agenda y tenga resultados específicos. Como gerente, puede ver el valor en la reunión.

Usamos y recomiendo el proceso de revisión "6 Thinking Hats" de de Bono ( consulte Wikipidia ). El resultado son unos pocos (2 o 3) puntos de acción que la reunión identifica como el leason más importante aprendido. Las primeras veces tenemos problemas para salir de los bloques iniciales, pero una vez que nos acostumbremos, no volveremos.

No realizar una revisión posterior al proyecto lo condena a cometer los mismos errores que cometió en el proyecto anterior.