Da igual que haya escrito sobre esto muchas veces, será que no debo de contarlo muy bien. Hasta hice un vídeo, pero tampoco es suficiente. Aunque en mi propia defensa, tengo que decir, que cuando lo hablo con alguien, cara a cara, no he encontrado a nadie que no dijera algo así como… “pues es cierto, si”.
Así que hoy voy una vez más, esta vez con la idea de sintetizar los peligros de pensar en proyectos.
Para que nos quede claro qué es un proyecto, y qué problemas tiene esa visión cuando la llevamos a organizar la creación y evolución de negocios basados en software, te dejo aquí lo que dice el instituto quizá más famoso sobre gestión de proyectos:
Recortado en noviembre 2016 de la web PMI.org
https://www.pmi.org/about/learn-about-pmi/what-is-project-management
Resalto algunos conceptos de la definición anterior, proyecto es… Temporary, Defined Beginning, end in time (con un final en el tiempo). Y como nota curiosa… “The development of software […], the construction of building or bridge” (razones por las que fabricar software no es lo mismo que fabricar coches o construir casas)
Y ahora vamos… ¿por qué es un peligro pensar en “proyectos” cuando se está desarrollando software que da soporte a un negocio? o ¿por qué el sector (la mayor parte) se ha tirado años y años intentando gestionarse por proyectos y no le acababa saliendo nada bien?
1 – Temporalidad (frente flujo continuo)
Ya lo has leído en la anterior definición, un proyecto es temporal, fecha inicio y fecha fin. Pero el software es continuo e indefinido en el tiempo. El mantenimiento, evolución y desarrollo del (producto) software no tiene fin salvo que muera el negocio al que da servicio.
No es lo mismo estructurarse para un momento final que estructurarse para un flujo continuo sin fin.
2 – Equipos temporales (frente a estables)
Esta temporalidad de estructurarse por proyecto implica, incluso, por lo general, montar un equipo para ese proyecto y luego desmontar ese equipo.
Estructurarse por equipo, frente a proyectos, pone la premisa del equipo estable como buena práctica, como hablamos en ¿Es bueno tener equipos estables? (vamos, que no rote constantemente la gente)
3 – Cumplir tiempos (frente a olvidar entregar verdadero valor a los usuarios)
Para tener un plan de proyectos se hace una fase de planificación y como resultado sale un plan (que hasta incluso, a veces, se pinta en un Gantt, de esos peligrosos). Para hacer el plan del proyecto, con sus fechas, hay que saber qué se quiere obtener, es decir, hay que tener requisitos… cerrados.
Y el problema de cerrar los requisitos es dejar el éxito del proyecto en manos de cumplir tiempos y presupuesto… pasando por alto si los requisitos son los que debían ser o si habían cambiado mientras el proyecto se desarrollaba. Esto incluso lleva a situaciones sin sentido, cumplimientos de tiempos y presupuestos, es decir, “éxito” del proyecto… pero habiendo creado productos que nadie quería, requisitos erróneos.
4 – Estimaciones peligrosas
La estimación típica de los proyectos es predictiva, basada en los requisitos, una razón más que lleva a cerrarlos, depende, esa estimación, de cómo están los requisitos, cuando van a cambiar y la experiencia que se tiene… el resultado en proyectos suele ser con bastante error (mírate esto “Ya, pero al final… mi cliente quiere tiempo y presupuesto”).
Estructurarse por equipos implica estimación basada en el pasado, empírica, en la capacidad de trabajo efectivo que tiene el equipo por unidad de tiempo (iteración o sprint), estimacion empirica, en lo que se llama velocidad (Qué es la velocidad en un proyecto software, normalmente ágil o Scrum). Conociendo la velocidad de un equipo se hacen previsiones, estimaciones, para terminar tareas.
5 – Cambios de contexto, múltiples prioridades, múltiples tareas abiertas
Estructurarse por proyecto implica, muchas veces, que una persona está en varios, o muchos, proyectos, cada uno con sus prioridades y, en ocasiones, en muchos equipos. Estructurarse por equipos implica que el equipo es estable y hace tareas de varios proyectos, si es necesario, o de uno único, o de ningún proyecto (ya que el concepto proyecto apenas aplica).
6 – Falta de enfoque en el aumento de la productividad
Con estimaciones con tanta probabilidad de error, las tentaciones en el mundo proyectos de saltarse etapas imprescindibles, como el testing, para entregar antes, son mucho mayores que en equipos estables, porque esos saltos de tareas necesarias lastrarán la velocidad del equipo en las siguientes iteraciones o sprints (deuda técnica), y, cómo se hace uso de la velocidad… esos bajones de productividad se verán muy claramente.
.
.
Más post de este tipo que yo que tu me leería…
- Gestión orientada a proyectos vs orientada a equipos (llámala ágil)
- Más allá del concepto “proyecto” en tecnología #noprojects #beyondproject
- Planificación clásica vs planificación ágil (1/2)
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
Pues yo no estoy de acuerdo.
Según PRINCE2 un proyecto es «Un proyecto es una organización temporal que se crea con el propósito de entregar uno o más productos desde una visión de negocio según un Business Case convenido».
En muchísimas ocasiones se estable una relación de proyecto entre cliente y proveedor que, no siempre da lugar a una continuidad con soporte y evolución del resultado del proyecto.
Las características de las personas que forman un proyecto no tiene por qué coincidir con la que mantienen y evolucionan un producto pues la problemática es totalmente distinta.
En PRINCE2 por encima del cumplimiento del plazo está el Business Case, es decir, la visión de proyecto como inversión.
Queda chulo hablar de NO projects, pero NO siempre aplica.
Saludos,
Ángel Águeda
Ángel,
No es cuestión de que quede «chulo», el tema tiene más importancia que el objetivo de hablar de algo «chulo» (si es que lo es).
Que no siempre aplica, pues seguramente, porque decir siempre es jugar demasiado a ser adivino… pero que aplica muchas, muchisimas, más veces de las que se aplica esta idea… ahí me la juego más. Y que demasiadas veces pensar primero en proyectos, en vez de equipo – producto, no ha terminado bien.
Es que el modelo por proyectos en la mayoría de las veces no encaja con el software. Si quieres, no encaja como objetivo prioritario, mejor piensa primero en equipos – productos, y luego, si quieres, en proyectos, pero no al revés, que es lo que hemos hecho durante años.
Aunque en un momento el equipo cambie, el trabajo sobre el producto continua. Que la relación cliente – proveedor termine no implica que la evolución del software termine, por eso de tener claro que el modelo de trabajo debe tener presente esa continuidad, mirar más allá de una fecha fin de proyecto.
Respecto al mantenimiento, no es lo mismo hablar de fases de mantenimiento, que equipos de mantenimiento e, incluso, de equipo que evoluciona (desarrollo y mantenimiento), son tres opciones.
Gracias por el comentario, interesante debate.
Saludos
Hola Javier,
El problema no es el enfoque de construcción de software a través de un proyecto. En mi opinión la causa raíz son los modelos de contratación y la falta de conocimiento de lo que significa calidad en software y cómo medirla e incluirla en las condiciones de contratación.
Mi posición es identificar las causas y abordarlas mencionándolas para que sean explícitas para todas las partes y todas contribuyan a su solución.
Saludos,
Ángel
Estimados.
Muchas gracias por «dar en el clavo».
Es interesante notar que en el mundo del sw no estoy solo pensando que lo importante es el producto y su evolución, más que del proyecto y su temporalidad.
Obviamente no hay absolutos pero es tiempo de concretar los cambios de mirada necesarios y esta es una mirada imprescindible.
Saludos.
Leyendo el blog y el debate, a partir de ahora en mi cabeza cada vez que lea o escuche equipo, haré una pausa para contextualmente traducirla a:
¿equipo de personas deseosas de participar y con posibilidad de entradas/salidas sin perjuicio del business?
¿equipo de personas que han sido asignadas forzosamente?
¿equipo de robots?
¿equipo de ya veremos??????
saludos
gracias a todos
Un interesante articulo Javier.
Entiendo que el cambio de punto de vista es en vez de centrarnos en el ciclo de vida del proyecto, ¿darle el enfoque de ciclo de vida del producto?.
Si es así, y pensaramos en proyectos desarrollo de software, ¿solo abarcaría la parte de la creación y continuidad del equipo durante todo el posible ciclo de vida del producto antes de comenzar el desarrollo del mismo?
Aunque de esta manera es un poco enfoque de operacion de desarrollo.
Sería mantener equipos multifuncionales y estables, que harían «cosas», sini hay más remedio… harían proyectos. Bajo un único backlog priorizado por un único Product Owner.
Saludos