Autopsia de proyectos de desarrollo de software

Si has participado en algún proyecto de desarrollo de software, sabes que las cosas no siempre salen como se habían planeado. En teoría, los proyectos tienen dos posibles resultados extremos: éxito o fracaso. En realidad, todos los proyectos cuentan una mezcla de componentes de éxito y de fracaso si se tienen en cuenta un gran número de factores. Y en Apiumhub pensamos que la mejor manera de analizar lo que ocurre durante un incidente y asimilar las lecciones aprendidas es realizar una autopsia de proyectos de desarrollo de software, lo que conocemos como un proyecto de desarrollo postmortem.

¿Qué es autopsia de proyectos de desarrollo de software?

La autopsia de un proyecto de desarrollo de software reúne a las personas para discutir los detalles sobre un incidente: por qué ocurrió, su impacto, qué acciones se tomaron para mitigarlo y resolverlo, y qué debería hacerse para evitar que vuelva a ocurrir.
La autopsia de un proyecto se lleva a cabo al final del mismo para determinar y analizar los elementos del proyecto que han tenido éxito o no, lo que se conoce como lecciones aprendidas.
Las autopsias de proyectos tienen como objetivo informar sobre las mejoras de los procesos que mitigan los riesgos futuros y promueven las mejores prácticas iterativas.

Reunir a las personas para que participen en un proceso estructurado y colaborativo permite que todos reflexionen y aporten lo que han aprendido ya que puede generar confianza y resistencia en el equipo. Además, documentar el incidente y la forma en que el equipo lo soluciona puede servir de base para la gestión de futuros incidentes. Es decir, ayuda a impulsar la mejora continua.

Nos falta un detalle importante: autopsia de proyectos de desarrollo de software no consiste en culpar a nadie. Hay que encontrar los fallos del proceso, no los fallos personales.

Autopsia de proyectos de desarrollo de software puede abarcar datos cuantitativos, cualitativos y subjetivos

• Datos cuantitativos
  Los datos cuantitativos incluyen la variación entre las horas estimadas para un proyecto y las horas reales realizadas. Se refieren a preguntas estándar afirmativas o negativas. ¿Se han cumplido o no los plazos? ¿Proporcionamos todos los productos previstos en el alcance del proyecto? ¿Se alcanzaron los parámetros de éxito predefinidos? ¿Se siguieron los flujos de trabajo y los procesos previstos? ¿Hubo un exceso de presupuesto?
• Datos cualitativos
  Los datos cualitativos suelen incluir la satisfacción de las partes interesadas, la satisfacción del usuario final, la satisfacción del equipo, la posibilidad de reutilización y la calidad percibida de los productos finales.

  Estas preguntas abiertas deben evaluar el proyecto más allá de los simples datos y la planificación. ¿Hemos entregado el trabajo con el alto nivel que nosotros y nuestro cliente esperamos? ¿Está de acuerdo el cliente? ¿Sintieron las personas involucradas que disponían de los recursos, la información y el apoyo que necesitaban para realizar sus propias tareas? ¿Las expectativas de las tareas estaban mal definidas o comunicadas?

• Datos subjetivos
  Las preguntas subjetivas ayudan a evaluar cómo se sienten los miembros de su equipo, y pueden ayudar a la dirección a identificar signos preocupantes de agotamiento y fatiga. Estas preguntas también permiten a la dirección saber qué procesos funcionan mejor con su equipo, lo que les ayuda a planificar futuros proyectos. ¿Qué es lo que más y lo que menos les gustó del proyecto? ¿Cómo fue el trabajo con el cliente? ¿Qué cambios harían en este tipo de proyectos en el futuro? ¿Cómo podría funcionar mejor el trabajo con este cliente o entre determinados departamentos en el futuro? ¿Deseas volver a trabajar en un proyecto similar? Si no es así, ¿por qué no?

  Para que las autoevaluaciones sean efectivas y nos permitan construir una cultura de mejora continua, se debe implementar un proceso simple e iterativo en el que todos puedan participar:

Establecer un límite
Los incidentes en nuestra organización deben tener niveles de severidad claros y medibles. Estos niveles de severidad pueden utilizarse para activar el proceso de autopsia. Por ejemplo, cualquier incidente Sev-1 o superior desencadena el proceso postmortem, mientras que la autopsia puede ser opcional para incidentes menos graves. Consideramos la posibilidad de permitir a los jefes de equipo o a la dirección la oportunidad de solicitar una autopsia para cualquier incidente que no alcance el umbral descrito.

Hazlo a tiempo
Es importante tomarse un descanso después de un incidente. Pero no retrases la redacción de la autopsia del incidente. Si esperas demasiado, es posible que se pierdan u olviden detalles importantes. Lo ideal es redactarlo inmediatamente después del incidente y hasta no más de cinco días hábiles.

Asignar responsabilidades
Es bueno delegar la autopsia en una persona que tenga el nivel necesario de conocimientos técnicos y organizativos para entender las causas y las mitigaciones.

Sigue el checklist
Una plantilla puede evitar que te olvides de los detalles clave. Además, es una buena manera de mantener la coherencia en todas las autopsias.

Ejemplo de agenda para una autopsia de proyectos de desarrollo de software eficaz

Envía un cuestionario a todos los participantes antes de la reunión. El orden del día o agenda es muy importante, pero será difícil respetar el calendario si los participantes no se preparan ellos mismos habiendo pensado en todas las cuestiones que se van a tratar.

Además de un orden del día, debe haber una persona responsable de moderar la reunión. Por lo general, se trata de la misma persona que estableció la agenda y programó la reunión posterior. Tener un moderador no sólo crea rieles de contención para la conversación, sino que permite a todos los demás miembros del equipo la libertad de decir lo que piensan sin preocuparse excesivamente por la estructura o el proceso.

1. Establecer el tono
Es el momento en el que recuerdas a los participantes el análisis constructivo. Es nuestra oportunidad para guiar la mentalidad del grupo y, con suerte, conseguir que se relajen y se sientan lo suficientemente seguros para una sesión realmente productiva.

2. Recapitulación del proyecto
Realizarás una sinopsis de lo que fue el proyecto y de cuáles eran las expectativas iniciales. Esto te permitirá centrarte en los objetivos medibles para poder evaluar objetivamente los fracasos.

3. Recapitular el resultado
¿Quedó satisfecho el cliente? ¿Superó el coste el presupuesto? ¿Se entregó el producto a tiempo? etc.

4. Preguntas de los miembros del equipo
Es el momento en el que la conversación se pone realmente en marcha y los miembros de tu equipo tienen la oportunidad de hablar. Es útil empezar haciendo una pregunta a una persona y permitir que los demás se expresen. Lo importante es que todos tengan la oportunidad de contribuir.

Estas son las preguntas que se pueden utilizar:

• ¿Estás orgulloso de los resultados obtenidos? Si la respuesta es afirmativa, ¿qué es lo que hace que sea excelente? Si la respuesta es negativa, ¿qué es lo que no funciona o falta?
• ¿Obtuvimos los resultados que queríamos y tuvieron impacto?
• ¿Qué métodos o procesos funcionaron especialmente bien?
• ¿Qué métodos o procesos fueron difíciles o frustrantes?
• ¿Cómo harías las cosas de forma diferente la próxima vez para evitar esta frustración?
• ¿Qué más podríamos hacer mejor la próxima vez?
• ¿Cuál fue la parte más gratificante o profesionalmente satisfactoria del proyecto?
• ¿Había algo demasiado poco concreto en el plan? ¿Faltó alguna información clave en el plan?
• ¿Se asignaron correctamente las herramientas, los presupuestos y los miembros del equipo? ¿Eran adecuados los recursos necesarios para el proyecto?
• ¿Fueron los plazos alcanzables y realistas?
• etc.

5. Recapitulación
Aquí es donde se agradece a todos la participación y se les informa de que pronto se publicarán notas.

Compartir las lecciones de un postmortem o una autopsia de proyectos de desarrollo de software con otros equipos que trabajan en proyectos similares ayuda a todos los miembros de la organización. Autopsia de proyectos de desarrollo de software permite a los participantes señalar los problemas y asegurarse de que se resuelven. Los avances aumentan la moral porque la gente sabe que puede contribuir directamente a la calidad de su lugar de trabajo y de su producto.