Mmmm el verano, dónde quedó, ese tiempo de piscinas, playa, calor, salir… y de hacer las limpiezas que no te ha dado tiempo a hacer durante todo el año. El caso es que en una de dichas limpiezas, de discos duros en este caso, di con un postmortem que escribí, según la fecha del fichero, en 2004, cuando trabajaba, en una empresa de desarrollo, llamemos ACME Soft.
Yo siempre he sido muy dado a anotar todo, ideas, reflexiones, etc., para luego leerlas en el futuro. Y apareció este llamado postmortem, así le llamábamos antes a la reflexión sobre cómo había ido un proyecto, en aquellos tiempos en los que la palabra retrospectiva no era de uso tan común (aún salvando las diferencias).
No sabía que hacer con él. No sabía si volver a dejarlo en el olvido, si sacar alguna lección que compartir contigo en forma de post, pero no tenía claro cuál, así que he decidido dejártelo como lo encontré y escribí en su día, te lo he copy pegado literal del word en el que está, tablas retro incluidas, sólo quitando nombres, cualquier pista o referencia a empresas o personas (mas con sus 8 años algunos, algunas, etc., ya ni existen) .
Quizá, después de leerlo, y fíjate que tampoco es que tenga una estructura muy elaborada, la reflexión que me plantee, y te planteo es… ¿cosas como estas ya no pasan? ¿hemos evolucionado para dejar ciertas malas practicas atrás para siempre en el olvido? No sé, a ve tú que opinas…
Postmortem, septiembre 2004
GESTIÓN PLAN DEL PROYECTO
| HALLAZGO | CONSECUENCIA |
| El desarrollo se realiza entre [PROVEEDOR] y [CLIENTE]. Definidos los requisitos estos se repartieron entre estas empresas y se pidió a cada una que realizara un plan de proyecto con los requisitos asignados. | Existen dos planes de proyecto separados y ninguno global. Así las dependencias entre los equipos de las dos empresas son constantes y estas no están escritas. El proyecto se bloquea de forma constante. |
GESTIÓN DE CONFIGURACIÓN
| HALLAZGO | CONSECUENCIA |
| Los documentos de requisitos y plan de proyectos, se encuentran en ficheros locales del PM [PROJECT MANAGER] anterior o en el repositorio de [CLIENTE] (XXXXX). | Varias jornadas para localizar el plan de proyecto y los requisitos, sin la seguridad de que estos sean las últimas versiones de los mismos. |
| En ocasiones se piden cosas y no sabemos si se tienen o no que hacer, ya que no las encontramos en los requisitos, y como no sabemos si tenemos la versión final de los mismos muchas veces se hacen (por ejemplo el alta de usuarios en XXXXXXX) | |
| En las dependencias software entre clases, [CLIENTE] no proporciona la descripción de sus interfaces. | Perdida de tiempo en esperar su desarrollo o retrabajo. |
| No se tiene claro dónde están los fuentes que producen el .jar de XXXX que se instaló en XXXX | Así, cuando se produjo un bug en una “insert” de XXX (debido al cambio de la tabla de alertas del XXXXX), el bug no se sabía en que jar introducirlo ya que no se encontraba los fuentes que lo produjeron. Finalmente no se pudieron encontrar. |
CALIDAD DEL PRODUCTO
| HALLAZGO | CONSECUENCIA |
| Acoplamiento | Las sentencias SQL en vez de trabajar con los nombres de los atributos como tal utilizan comodines del tipo “?”, así cuando se añadió un campo más a la tabla de XXXXX todos los insert quedaron invalidados. |
| Modularidad | El sistema es tan monolítico y acoplado que al cambiar alguna tabla (punto anterior) no se conocen los efectos, ya que se depende de las mismas en varios sitios desconocidos a priori. Esto implica que un cambio de este tipo obliga aprobar la plataforma y todas las aplicaciones (XXXXXX, YYYYYY, etc.). Cuando se modificó la tabla “XXXXX” se tuvo que probar todo, lo que supuso 1 semana – hombre de trabajo. |
ESTIMACIONES DEL PROYECTO
| HALLAZGO | CONSECUENCIA |
| Se entregó una oferta con fechas concretas sin haber cerrado su aceptación a una fecha concreta. Se entregó al cliente una oferta de XXXXX jornadas de duración, asegurando la puesta en producción la segunda semana de XXXX 2004. |
El comienzo real del proyecto fue el 1 Sep 04, según las XXXX jornadas, la finalización real sería la primera semana de XXXX, lo que desde el comienzo supone 2 semanas de retraso. |
GESTIÓN DE CONFIGURACIÓN
| HALLAZGO | CONSECUENCIA |
| Existen múltiples repositorios de documentos (CVS, unidad G, correos, ficheros locales) y no están controlados. | La especificación de requisitos software fue enviada por el PM por correo al comercial y este la envió al cliente también por correo sin hacer copia al PM. El plan de proyecto tampoco estaba localizable. Al comenzar el proyecto no se sabía cuál era la última versión de los requisitos, ya que existían versiones en CVS, en correos, etc. Finalmente la última versión estaba en el correo del comercial. Así, el primer día y segundo día de proyecto se gastaron en buscar las versiones finales del plan de proyecto y de los requisitos. En costes supuso aprox. 4 jornadas / hombre (2 jornadas de un desarrollador y 2 del PM) |
| El repositorio CVS está mal gestionado. Los elementos se versionan anárquicamente e incluso con directorios tipo “versión 4.0”. Dentro de estos directorios puede encontrarse, por ejemplo, dentro de doc ficheros sobre peticiones de intervención, etc. | El coste en tiempo para encontrar algo es altísimo igual que la probabilidad de errores. |
GESTIÓN DE RECURSOS
| HALLAZGO | CONSECUENCIA |
| Somos recursos no fijos y cambiantes. Se asignó un recurso durante los 5 primeros días de proyecto (dos de los cuales se perdieron buscando versiones de documentos) y se sustituyó. | Perdida de tiempo. |
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
¡Qué divertido! No entiendo por qué te fuiste… XDD
Buscaba más tensión 😛
Hola Javier Garzás!
Muy interesante el post y el tema que abordas en el mismo. Los informes postmortem al finalizar un proyecto son esenciales para que no se cometan los mismos errores en futuros proyectos, para que sean utilizadas las tecnologías que fueron de gran utilidad y tomar experiencia de las soluciones dadas a determinado problema o situación. Hace dos meses aproximadamente confeccioné el postmortem de un proyecto que finalizó, los puntos que tuve en cuenta fueron:
* Cliente.(Información sobre el cliente)
* Situación (Planificación inicial vs Planificación Real)
* Resuelto (Herramientas utilizadas, Soluciones)
* Resultados obtenidos (Incidentes por Sprint y por tipo de pruebas realizadas, información sobre la Prioridad y Severidad dada a los incidentes detectados)
* Aspectos positivos del proyecto.
* Aspectos a mejorar del proyecto.
Lo considero como una buena práctica siempre que sea consultado y no quede en el olvido o engavetado para siempre. Espero este post sea de utilidad para todos los que confeccionen informes postmortem en los proyectos finalizados.
Muchas gracias!
Saludos.
Jejeje, ¡qué tiempos aquellos!
Aún me sigo encontrando gente que guarda documentos, ofertas, librerías, binarios, datos de configuración y test en el repositorio de código fuente.
Sin embargo, en general, creo que gracias a la difusión de las metodologías agiles y sus prácticas algunas cosas han mejorado en la mayoría de las empresas. Parece, por ejemplo, que cada vez más gente ve normal tener un repositorio de versiones compiladas y de dependencias (maven o lo que sea)
Aún queda mucho camino por recorrer y siempre quedaran los recalcitrantes pero comparado con aquello… ya sabes… «he visto naves arder en las puertas de Tannhäuser…»
Sabía que te iba a gustar 🙂