Los buenos viejos tiempos
Empecé a trabajar como jefe de proyectos de desarrollo de software en 1996. Éramos un equipo de 5 personas, jóvenes y motivados, y desarrollábamos un sistema de gestión de instalaciones (inglés: facility management) para un banco.
Sólo para darte una idea de aquel tiempo, teníamos acceso a Internet en un solo ordenador, por lo que comprobábamos el correo electrónico de todo el equipo (no el personal) dos o tres veces al día. Los teléfonos móviles eran como ves en la foto, es decir, no SMS, no WhatsApp, ni nada de este estilo.
Este fue el único proyecto sobre que trabajábamos, no compartíamos recursos con otros proyectos y los otros desarrollos tampoco nos impactaban tanto.
¿Tu también te acuerdas de ese tiempo? :-)
Como jefe de proyecto era responsable de planificar, dar seguimiento y reportar el progreso del proyecto.
El cliente esperaba un producto de alta calidad, sin embargo, fue lo suficientemente paciente para trabajar con nosotros en los requisitos y dejarnos el tiempo necesario para implementarlos y hacer las pruebas.
Está chupado, ¿verdad?
Aun así, antes de cada entrega teníamos que trabajar largas hora para asegurarnos que todo funcionaba bien. Es decir, las estimaciones no se ajustaban a los números reales.
Las estimaciones y los datos reales son diferentes valores del mismo parámetro.
No fuerces (manipules) los reales para que coincidan con las estimaciones.
La supervivencia y la sostenibilidad requieren pragmatismo
Menos de 20 años después, pocos jefes de proyectos, más bien ninguno, se puede imaginar llevar un único proyecto, con un equipo totalmente dedicado a este, sin interacciones con otros desarrollos, casi sin interrupciones, con algunos cambios de requisitos manejables, y problemas relacionados sobre todo con la tecnología.
Lo interesante es que la complejidad de los métodos de gestión de proyectos ha aumentado en paralelo con el aumento de la complejidad del desarrollo de software, mientras que el tiempo para hacer las decisiones correctas es cada vez más corto y las expectativas de los clientes cada vez superiores.
Revisé mis apuntes de los últimos años. Los jefes de proyecto comparten los siguiente acerca de su trabajo:
- Es difícil manejar la variedad de factores que influyen en un proyecto: la claridad de los requisitos, la estabilidad de las tecnologías, el nivel de conocimientos y habilidades de los miembros del equipo, los riesgos, las dependencias de otros proyectos, etc
- Cuanto más sofisticado sea el método de estimación, más esfuerzo (y tiempo) se necesita para hacer un buen plan de proyecto. De todos modos este tiene una vida muy corta hasta que cambie de nuevo
- Estimación, planificación, seguimiento y re-planificación es una carga administrativa muy alta, difícil de vender a los clientes, y por lo tanto sostener
- Hay mucha presión para dar estimaciones rápidamente y después cumplirlas
- Difícil coordinación de los proyectos.
En una situación como esta, ¿no deberíamos de revisar las prácticas de gestión de proyectos bien establecidas y buscar algunas más pragmáticas?
Enfoque Kanban de gestión de proyectos
¿Cuál es el propósito de gestión de proyectos? – Asegurarse que el proyecto se ajusta a los criterios de sus interesados (clientes y organización). ¿Correcto?
Aquí los tienes:
Aptitud del trabajo: Perspectivas |
|
Cliente
|
Organización
a. Nivel de proyecto
b. Nivel de negocio *
|
* Ver la charla de David J Anderson sobre las 3 agendas de Kanban.
Entonces, las dimensiones de la aptitud de un proyecto y las herramientas analíticas correspondientes se pueden resumir de la siguiente manera:
Aptitud del trabajo: Dimensiones |
|
Tiempo de entrega
Coste
|
Previsibilidad
Calidad
Negocio
|
Pincha en los enlaces para ver cómo se utiliza cada una de las herramientas y la valiosa información que aporta a tu proyecto.
Si te fijas en las herramientas que necesitas para gestionar la aptitud del trabajo de tu proyecto con respecto a cualquier criterio, cliente o organización, te darás cuenta que lo que necesitas fundamentalmente es suficiente y, por supuesto, buenos datos reales. (En cuanto a los datos, siempre tenemos que recordar que si entra basura – sale basura).
El poder de los datos reales, no las estimaciones especulativas, te da confianza
en tus compromisos y te permite dormir tranquilo, porque
reduce los riesgos de no cumplir tus promesas.
Además, ahorras todo el esfuerzo para inventar y actualizar un método de estimación formal y tratar de adaptarlo a las características únicas de cada proyecto.
Para las empresas CMMI:
- El tiempo de entrega se recoge principalmente en proyectos orientados a los servicios (por las necesidades de la gestión los ANS). Sin embargo este es un dato valioso para los proyectos de desarrollo de software también.
- En los proyectos de desarrollo de software por lo general se registra el esfuerzo de realización de la tarea, pero no el tiempo de entrega (el Lead time) de un requisito o historia. Esfuerzo y duración no es lo mismo. Conocer la distribución del Lead time para los tipos de trabajo o las clases de servicios ayuda a conseguir una planificación más realista.
- Conociendo el Rendimiento permite (a través de la ley de Little) dar una estimación rápida y fiable del tiempo de entrega necesario para implementar un conjunto de historias / requisitos.
- La visualización del trabajo en curso facilitan enormemente la coordinación de los proyectos.
- El DFA es quizás el mejor indicador en tiempo real del ritmo del trabajo (proyecto) y los riesgos.
