SCRUM es más productivo que los proyectos a precio cerrado
Un poco de historia
Desarrollar un sistema a partir de unas especificaciones es igual que caminar sobre las aguas. Solo hay que congelarlas.
Leí esta frase a mediados de los años noventa. Eran mis primeras experiencias profesionales y devoraba cada libro de gestión que caía a mi alcance. Me pareció una receta graciosa que escondía algo de verdad. Como todo buen programador junior, me dolía cada vez que teníamos que rehacer buena parte del código por una nueva ocurrencia del cliente.
Encontré también el caso de un jefe de proyecto que se hizo famoso por un cartel en su escritorio que rezaba «He dicho que NO». Así dejaba claro que, una vez firmado el contrato, no estaba dispuesto a cambiar una coma. Era la aplicación práctica de la congelación de especificaciones. Lamentablemente el artículo no mencionaba la reacción de los clientes cuando les entregaban lo que habían firmado y no lo que necesitaban.
Pasaron años hasta que entendí, de la mano de Brooks, DeMarco y Putnam, qué se escondía tras todos esos artículos. El cliente no puede saber lo que quiere. No existe un lenguaje para describir de forma precisa los sistemas informáticos. El desarrollo es un proceso iterativo de prueba y error. En general, al tercer intento, construyes lo que el cliente en realidad necesita.
De manera inexplicable, las principales teorías de gestión de proyectos informáticos eran desconocidas para el sector cincuenta años después de publicadas. Para que os hagáis una idea de lo perdidos que estábamos, hacia el año 2.000 la metodología de moda era CMM, basada en más y mas y mas documentación. Absurdo.
Entonces apareció SCRUM
Afortunadamente, en EEUU un grupo de líderes técnicos empezó a desarrollar, a partir de las ideas de Brooks, una nueva forma de organizar los desarrollos, más centrada en las personas y menos en la especificación. El 12 de febrero de 2001 se presentó el manifiesto ágil, un nuevo paradigma para construir sistemas informáticos que ha ido ganando impulso desde entonces.
Curiosamente, se parecía mucho a la forma de trabajar de Ceselsa (ahora Indra) en los años 90. Sus clientes la definían como una organización ‘perfectamente desorganizada’, lo que da una idea de su metodología, informal y centrada en las personas. Y funcionaba muy bien. Durante años consiguieron una productividad espectacular y una rotación mínima, a pesar de que los salarios no eran brillantes.
Pero una cosa es el manifiesto Agile y otra muy distinta llevarlo a la práctica. Cincuenta años de gestión de proyectos a precio cerrado producen unas inercias que dificultan su implantación.
Hay, por ejemplo, dificultades de tipo organizativo. Estamos acostumbrados a la figura del jefe de proyecto, que negocia con el cliente y prioriza las actividades de desarrollo. Las organizaciones son reacias a delegar la priorización de tareas en el cliente. En buena parte de los proyectos presuntamente SCRUM, o sigue existiendo el jefe de proyecto, o el Product Owner pertenece a la empresa desarrolladora.
Otra barrera, quizás la más determinante, es de tipo comercial. En SCRUM no se pacta un alcance entre cliente y consultora. No es que el precio no esté cerrado, es que no se define cual será el resultado del proyecto. El contrato es un acto de fe, donde el proveedor se compromete a entregar ‘lo mejor que se pueda construir con ese presupuesto’. Eso dificulta cualquier tipo de control. ¿Cómo saber si la empresa desarrolladora ha hecho un gran trabajo o me está engañando?
SCRUM es más productivo que los proyectos a precio cerrado
Aunque no sea posible medirlo, Scrum es más productivo que los proyectos a precio cerrado porque genera importantes ahorros, tanto para el cliente como para el proveedor.
El primero es, sin duda, el ahorro de costes de seguimiento. Según el Chaos Report que elabora la consultora The Standish Group, el 30% de los grandes proyectos se cancela, el 50% multiplica por tres coste y plazo y de media solo se entrega el 50% de la funcionalidad acordada… En resumen, el resultado -si lo hay- no se parece en nada a lo firmado.
Si cada uno de esos cambios implica una compleja negociación entre cliente y proveedor, ¿Cuál es el coste de gestión necesario para unas modificaciones tan dramáticas? Estamos hablando de miles de horas de trabajo de ambas organizaciones, para identificar desviaciones, proponer modificaciones y justificar cambios de precios y plazos. Por no hablar de las horas perdidas por los equipos de desarrollo, que no pueden proseguir su actividad hasta que se alcance un nuevo acuerdo.
Otro de los motivos por los que Scrum es más productivo es porque se ahorra buena parte de la fase de diseño. ¿Para que emplear cientos de horas de analistas para construir una especificación que, de todas formas, va a sufrir importantes alteraciones?
Tampoco podemos olvidar el ahorro de los desarrollos que no se hacen por ser los menos usados. Si el Product Owner conoce bien su negocio, en los primeros sprints se desarrollarán y se pondrán en funcionamiento los módulos más utilizados. Recordad la regla de Pareto, con el 20% de los desarrollos consigues el 80% de la funcionalidad del sistema. ¿De verdad es productivo desarrollar el resto?
Desde precio cerrado y Scrum hacia Time & Material
Time & Material es el modelo de trabajo en el que el cliente lidera el proyecto y solo necesita programadores, testers, y administradores de sistemas, pagando un fee mensual por cada uno de estos profesionales.
De forma natural, los proyectos largos y complejos suelen evolucionar hacia Time & Material, con independencia de que hayan comenzado en la modalidad de precio cerrado o de Scrum.
El proceso es simple, el cliente identifica y contrata a los consultores clave, aquellos con mayor conocimiento funcional y técnico. De esta forma les fideliza y se asegura de que trabajen a su favor.
Y una vez que tiene en su plantilla a los líderes del proyecto, ya no necesita una empresa consultora, solo buenos programadores.
Con Time & Material obtienes eficiencias similares a las de Scrum, con la ventaja de que puedes pedir los programadores a varias empresas. Así el proceso de reclutamiento de consultores es más rápido, una ventaja importante en un entorno donde cada vez es mas difícil encontrar programadores.
Como conclusión, Time & Material es posiblemente el modelo más eficiente para construir sistemas informáticos, por delante de Scrum y a años luz de los proyectos a precio cerrado. Por eso es todavía uno de los modelos más empleados a nivel mundial.