La Gestión de los Tiempos del proyecto ha sido algo impuesto sobre todo por el cliente y el mercado, en la que nosotros como proveedores hemos tenido muy poco peso a la hora de decidir más allá de limitarnos a decir que es imposible realizar tal entrega en esta fecha en estas circunstancias.
Antes de este proyecto creía que la Gestión de los Tiempos era fundamental dentro de la gestión de un proyecto, y sin embargo ahora pienso que este aspecto es más bien secundario y que hay que dedicarle menos esfuerzo. El énfasis hay que ponerlo en trabajar bien centrándonos en otras actividades : una correcta gestión del alcance, de los riesgos y de la calidad es el camino más corto en tiempos y en costes, y el que cumplamos con el plan previsto dependerá de una buena estimación y un mínimo de control.
Si anteriormente comentaba que uno de los grandes problemas que hemos sufrido ha sido la indecisión y mutabilidad del alcance, otro de los grandes problemas con los que nos hemos encontrado ha sido la constante imposición de tiempos nada realistas y cambiantes, lo cual no podía dar como resultado nada más que retrasos y un producto de baja calidad : mala calidad de código, constantes rediseños y juegos de pruebas inútiles y confusos.
Como ejemplo, los que hayáis leído esta sección estaréis pensando en Mutua Madrileña, pero con Barclays es más grave: se planificó una carga de trabajo de más de 100 jornadas de las que disponíamos para completarlas en 1 mes y medio y arrancar el proyecto mañana, lo cual suponía aumentar el número de personas en el equipo en una semana, que vengan aprendidas y con experiencia y formarlas en un producto tan complejo durante la entrevista. Condiciones innegociables con el cliente, una situación ideal para nosotros como proveedores.
Ya hablaré en otra entrega de la inexistente Gestión de Riesgos (paradójico en una empresa de seguros). Identificar los riesgos es parte del trabajo que he realizado, así como informar al resto de los stakesholders del proyecto. Sin embargo eran constantemente ignorados y nunca incluidos en la planificación, lo cual evidentemente provocaba aún más retrasos al materializarse alguno de ellos. Más prisas y menos calidad aún.
Además cada parte ha intentado resolver este problema por su parte en lugar de en común, lo cual no ha hecho nada más que empeorar la situación. Se debieron establecer fechas más realistas.
- Por un lado el cliente nos daba fechas cada vez más ajustadas para reservarse un par de semanas de colchón con sus responsables.
- Por otro lado no disponíamos de los recursos necesarios para cumplir con las fechas comprometidas con el cliente porque mi empresa daba por hecho que habría retrasos y no quería asumir ese sobrecoste.
Me resulta incomprensible realizar planificaciones y aceptarlas sabiendo que no se van a cumplir. Yo soy más de la escuela de hacer una planificación realista y poner los medios para que se cumplan, o no hacer planificación y centrarse sólo en trabajar y estará listo cuando terminemos.
Ni que decir tiene que la situación empeoró hasta llegar al límite de no me quedó más remedio que
- Desligar jornadas de trabajo a facturar y jornadas de trabajo necesarias para completar las tareas. Hasta ahora el coste del proyecto venía determinado por las jornadas de trabajo completadas, y yo intenté desligar este concepto para que se tuviesen que buscar otras formas de facturación.
- Eficiencia. He intentado que cada miembro del equipo fuera lo más eficiente posible en lugar de que trabajasen más, y al menos he conseguido que durante una temporada yo fuese el miembro más ineficiente del equipo ya que no he podido saltarme todas las reuniones improductivas que me hubiese gustado, ni toda la documentación inútil (porque quedaba obsoleta antes de terminarla).
- Más despacio y mejor. Ya lo dice el refranero, vísteme despacio que tengo prisa, y los siglos de sabiduría popular nos ayudaron. Paramos el desarrollo planificado para intercalar tareas despreciadas como rediseño, diseño de pruebas, limpieza de código, formación… Además las fechas que manejábamos internamente eran lo más realistas posibles para completarlas con un mínimo de calidad, intentado que toda la presión y culpa se quedasen únicamente en un punto : yo mismo.
- Planificar a más corto : planificación ágil mediante iteraciones. En todo momento hay cientos de jornadas de trabajo pendiente (pero no aprobado por el cliente), en parte hacer bien lo que teníamos que haber hecho desde el principio (como una arquitectura para el cliente, testeo, automatización de pruebas, refactorización…) y otras mejoras que se han ido detectando con el tiempo por los usuarios. He perdido jornadas enteras en planificar y replanificar ese trabajo sabiendo que era tiempo totalmente perdido, así que he tenido que imponer sacarlo todo de la planificación y mandarlo al backlog para preocuparnos únicamente de las iteraciones. No obstante, ni siquiera podemos completar una iteración de dos semanas sin que nos cuelen trabajo no planificado.
También he intentado sin éxito hacer ver la realidad tanto al cliente como a mi empresa de que en estas circunstancias es imposible comprometernos ni a unas fechas ni a una calidad mínima como para dar garantía del producto : trabajamos en un modelo "best-effort", hacemos lo que podemos pero sin compromisos.
La verdad es que está presión a la que me ví sometido ha estado a punto de poder conmigo. Con problemas tan graves como evitables, sin soluciones disponibles a pesar de su simplicidad y bajo coste, sin poder razonar, un camino en que cada día era peor que el anterior… No os lo recomiendo. Cada día me acordaba de la conversación con Chema en la cafetería del Ministerio, sobre si estaba bien pagada la responsabilidad y aguantar toda esta mierda.
Actualmente la situación es sostenible, hemos aprendido todos a sobrellevar esta situación de indefinición en el alcance y pagar las consecuencias con el mantenimiento de producción, en lugar de pagar el coste de hacer bien las cosas. Hace un año se decidió no gastar pesetas para ahorrar duros. Hoy no gastamos duros para ahorrar euros. Y mañana?
Éxitos
- Retomar el control de los tiempos del proyecto : más despacio, mejor hecho, menos trabajo más eficiente.
- Planificaciones flexibles más cortas
- Mejorada la gestión del estrés tanto personal como del grupo.
Oportunidades de mejora para el futuro
- Hacer explícito los retrasos provocados por el alcance indefinido, baja calidad, "best-effort", riesgos… Y mantenerlos en la planificación aunque el cliente se niegue.
Imprescindible para el futuro
- No aceptar compromisos cuando todo lo que puedes hacer es un "best-effort". Quizás uno de los problemas que tengamos es que las cosas no están saliendo tan mal como se están haciendo, gracias a heroicidades personales de los participantes (Gracias!).
Aún recuerdo sus primeros pasos en la etapa de preventa, planificación y desarrollo, desde sus primeros meses de indefinición y bandazos en su alcance recortando funcionalidades y añadiendo otras o las mismas que se sacaron previamente, preparando nuevos productos inesperados a gestionar, tirar un diseño y otro y otro mientras las líneas de código se apilaban olvidando por completo calidad y pruebas, desplegando la aplicación en un sistema montado el último día y probado en producción…
