Empezaste un sistema sencillo y ha crecido por encima de las previsiones.
Quisiste o te impusieron probar una tecnología y te das cuenta que te está complicando la vida o simplemente no cumple los requerimientos.
Aparecen requerimientos técnicos y no técnicos nuevos, las planificaciones no se cumplen, el equipo empieza a ir desbordado y la información comienza a disgregarse en silos (cada uno se parapeta en "lo suyo".. lo mío va.. aunque nadie sabe muy bien qué es "lo suyo").
La presión aumenta, se intenta mantener las planificaciones a base de horas extras y la facilidad casi mágica e infinita de las tareas de paralelizarse, al menos en un diagrama de Gantt.
No está bien claro quién es el responsable del proyecto, hay muchos interlocutores pero no está claro quién tiene que decidir qué y a medida que el proyecto se tuerce, muchos de ellos desaparecen o buscan perfiles más planos..
Los motivos pueden ser múltiples
pero la cosa no pinta bien.
No puedes hacer estimaciones fiables, porque tampoco tienes controlado lo que se está desplegando.. la urgencia te obliga a hacer entrega casi continua pero sin los medios para poder hacer pruebas unitarias, de integración, de regresión..
Primero.. necesitas valor para no ignorar los síntomas y escalar el problema.
Y segundo.. necesitas un plan para enfocar los problemas y sus vías de resolución.
Seguro que cuando salgas del hoyo tendrás muchas cosas que debatir, mejorar, herramientas que necesitabas y no tienes, cultura de empresa y organización, cómo reforzar el equipo para desterrar malas prácticas, quizás cambios en el proceso para facilitar la entrega continua, etc. pero en medio de la crisis no es el momento.
Hay que coger el toro por los cuernos con lo que tengas en ese momento.
Lo imprescindible:
1: Detener el desarrollo: Te va a costar, va a ser duro de negociar, pero, por eso necesitas un plan.. para ti y para comunicarlo.
No es lo mismo decir "tenemos problemas técnicos y necesitamos 1 mes".. sin más.. que especificar en detalle lo que se quiere hacer, por qué es necesario y qué problemas actuales y futuros soluciona.
Aunque la gestión de esta replanificación corresponde al Project Leader, es tarea del Responsable Técnico o Arquitecto, hacer un diagnóstico claro y transparente de la situación y el plan de estabilización.
2: Identificar y aislar los componentes / partes de código problemáticas.
En la estabilización se irán refinando pero hay que hacer una propuesta inicial de compartimentación.
3: Definir e implantar un mínimo plan de testing a nivel de estosgrandes componentes. Si no puedo probar todas las clases e interfícies, por lo menos que un problema generado en la ficha del cliente no me aparezca en el momento de guardar una factura.. etc.
4: Refactorización continua: El proceso de estabilización enfocado iterativamente permitirá ir reduciendo el tamaño y complejidad de los puntos oscuros del sistema, que inicialmente hemos encapsulado en cajas negras.
La encapsulación aqui nos permite ir eliminando/sustituyendo código y componentes de forma controlada.
Cuando ya tenemos el roadmap en marcha:
A partir del aislamiento de las partes problemáticas y la planificación de las prioridades de resolución es momento de contemplar (no antes) si puede ser productivo incorporar más gente al equipo, por volumen de trabajoo por necesidad de conocimiento experto específico.
Análisis post-mortem:
Es una buena práctica porque permite aprender de los problemas y mejorar en conjunto, aunque no siempre se hace y menos en los proyectos que han sido problemáticos.. ya que en caliente se corre el riesgo de caer en personalismos no del todo profesionales.
Más que un careo debería ser una fuente valiosa de propuestas de mejora.
Es momento de recuperar la wish list que querías plantear en medio de la crisis y debatirla con espíritu constructivo.
La calidad de un equipo también se consolida iterativamente.
No hay comentarios:
Publicar un comentario