Me lanza Luís (al que añoro leer más a menudo, pero ando hasta arriba) un guante que recojo encantado esperando que pueda seros de utilidad. Luís describe la típica situación de un cliente que va descubriendo lo que en realidad necesita conforme va avanzando en el proyecto. Es la típica situación que los técnicos describen como “el cliente no sabe lo que quiere” y que los profesionales de Agile, Lean y Scrum describimos como “en un sistema de dimensión compleja, los requisitos son emergentes”. No es culpa del cliente (aunque de todo hay en la viña del Señor): es que no hay otra forma de asegurarse de acertar en el resultado de un proyecto que incrementar los ciclos de feedback cliente-proveedor mediante un desarrollo iterativo e incremental, con entregas de producto funcional y testable al final de cada iteración, algo que va en contra de lo que académicamente se ha postulado durante los últimos treinta años en el mundo de la gestión de proyectos software, que se ha basado típicamente en la aciaga herencia de los desarrollos industriales en cascada.
Hay soluciones basadas en Scrum que funcionan en entornos como el que comenta Luís (os lo aseguro), pero el cliente debe estar dispuesto a un modelo más colaborativo. Me ocurre con frecuencia que, cuando comento a un cliente la posibilidad de que contrate a sus proveedores en un modelo de “fixed time-fixed money” con funcionalidad variable (es decir, contrato al equipo por seis meses y a ver cuánto somos capaz de hacer) me dicen que estoy loco, que entonces el proveedor se dedicará a tocarse las narices todo ese tiempo y que no entregará casi nada al final del proyecto. Pero sin embargo cuando se lo comparo con los contratos de outsourcing o bodyshopping comienzan a verlo más claro: el principio es el mismo, y la forma de controlar el progreso es involucrarse en el mismo de forma diaria.
De hecho, los contratos “fixed time, fixed money, fixed functionality”, es decir, contratos basados en un supuesto conocimiento perfecto del futuro y la evolución del producto a lo largo de meses y meses de trabajo, son una aberración en un mundo de productos complejos como el software y los sistemas, de forma que lo que ocurre en realidad es que el cliente trata de trasnferir todo el riesgo tecnológico y de “mutación” al proveedor, y este se blinda metiendo más colchones que pikolin. Así expresado no parece muy colaborativo, ¿Verdad? Pues por eso no funciona. 
Algunas fórmulas intermedias que suelo recomendar incluyen lo que llamo el contrato de “scrumsourcing”, en el que los objetivos se dividen segun MOSCoW (Must, Ought, Could, Wish) y se firma, por ejemplo, hacer un 100% de los Must, un 80% de los Ought y un 50% de los Could en un tiempo determinado por el proveedor. Cualquier funcionalidad o historia en el que no se haya empezado a trabajar puede ser cambiada en cualquier momento por otra de valor / peso similar. Y en caso de que el cliente esté satisfecho con el nivel alcanzado en cualquier punto del proyecto, o al contratio, piense que el proveedor no avanza al ritmo adecuado, puede cancelar el contrato en cualquier momento por un coste equivalente al 20% de lo que quede por hacer. Así, dividimos el riesgo entre todos.
La típica queja que suelen elevar los proveedores es que un enfoque de este tipo les obliga a diseñar el sistema de una forma altamente modular y flexible para soportar los cambios de funcionalidades futuras. Típicamente lo expresan como “no se puede”, pero el caso es que miles de empresas de todo el mundo trabajan así, o sea que se puede, pero requiere un esfuerzo y una disciplina. Y por otra parte, ¿no es más valioso para el cliente contar con una arquitectura modular y flexible que permita incorporar cambios y nuevas funcionalidades en el futuro? ¿No es incluso mejor para el proveedor, de cara a la recurrencia del cliente?
En este tipo de enfoques, lo ideal es comenzar contratando a proveedores para proyectos de bajo riesgo y corta duración, seleccionando a los que mejor funcionan para proyectos a mayor duración y con un impacto mayor en la compañía. Esto tiene dos ventajas: por una parte, como comentaba, podemos seleccionar a los proveedores que funcionan bien con un modelo ágil. Y por otro podemos comenzar a acostumbrarnos al proceso con proyectos de bajo riesgo e ir perfeccionando los mecanismos de control, visibilidad y feedback.
Que por cierto, para este tipo de cosas hay una consultoría que… O:-)
Buenas tardes Angel,
Hace tiempo que no encontraba un blog tan interesante y “suculento” en información.
Muchas gracias….
Ángel, considero muy interesante y recomendable lo que llamas «el contrato de “scrumsourcing”».
En relación con «La típica queja que suelen elevar los proveedores», yo recomiendo a nuestros clientes potenciales que empleen productos software abiertos y orientados a servicios que ellos, con la asistencia de sus asesores, puedan combinar de «una forma altamente modular y flexible para soportar los cambios de funcionalidades futuras.» [Creo que los “marquistas” de las TIC llaman SOA a este enfoque].
Hola Ángel, me temo que el MOSCoW es una solución parcial y que no resuelve completamente el problema principal que es cerrar los requerimientos.
Me parece un buen enfoque para hacer un proyecto con requerimientos cambiantes, pero persiste el problema original: definirlos. Sí que es cierto que te da más flexibilidad contractual para acomodar cambios pero es un salto cultural cuántico para un cliente el firmar un contrato sin que esté definido (para él claro) el alcance – es una gran trampa, ya lo sabemos, porque ese “alcance” es el que hay que definir, y es el que se describe con más o menos vaguedades en las propuestas.
Al final los proyectos de implantación de ERPs se convierten en un tira y afloja donde sólo la mano izquierda y experiencia del implantador, así como la flexibilidad del cliente para adaptarse al sistema (y aquí suena una voz en off: ¿pero no era al revés, el sistema al proceso?)… y no olvidemos a los “facilitadores” ;-))
Me interesa mucho el enfoque scrum porque lo veo con mucho potencial para las implantaciones de ERP. No conozco nadie que lo aplique en ese contexto, si sabes (sabéis) de alguien comentadlo.
Si no habrá que desarrollar la metodología… ¿te animas?
Coincido con Luis en el tema de definición de requisitos. Lo que comentas del MOSCoW (¿de dónde viene la S?) implica una definición inicial de requisitos de forma más o menos detallada. El cliente podría argumentar que esos mismos requisitos (al menos los MUST y OUGHT) se los definieras en un proyecto cerrado a coste y tiempo prefijado. El resto es lo que siempre se ha llamado un “bolsa de horas” que es, como bien dices, subcontratación.
Desde mi punto de vista, el problema principal de vender a un cliente un modelo “fixed-time fixed-money” es que rompe completamente la idea básica de que un proyecto ha de tener un “Business case” (sí, ya sé que desgraciadamente muchos ni lo hacen) que incluya una justificación de negocio de los objetivos seguidos (con un “investment appraisal” y un “sensitive analysis”). ¿Cómo sé si voy a conseguir los objetivos definidos en un coste y tiempo determinado?
Según lo veo yo, la diferencia fundamental del modelo que propones (capacidad de cambiar algo por otra funcionalidad del mismo valor en tiempo-coste) puede hacerse también en un proyecto estándar gestionando un presupuesto de cambios.
Pues eso, polemizando un poco para hacer esto más divertido.
Imagino que en scrum se establecen los pasos para ir de N a N+1. ¿Vale también para N=0?
¿De dónde sale que un proyecto “fixed-time fixed-money” sea incompatible con su justificación económica? Yo entiendo que un «problema de negocio» tiene generalmente diversas respuestas y, en muchos casos, pueden acumularse (iteraciones).
Hola José,
con lo de “fixed-time fixed-money” me refiero a sin fijar unos objetivos cerrados, obviamente, ya que todos los proyectos son “fixed-time fixed-money” per se.
En este contexto, cuando tú tienes un problema de negocio y evalúas diferentes opciones, haces un análisis de coste-beneficio de las diferentes opciones y seleccionas una (o un conjunto de ellas). Que esta opción sea en varias etapas (o iteraciones), para mí no es ningún problema.
En mi opinión, el problema es cuando esas iteraciones no tienen un coste-tiempo y objetivos más o menos fijos ya que el cliente no puede saber si es posible obtener los objetivos que le van a dar el beneficio esperado con el coste previsto en el análisis que realizó.
Y cuidado que no estoy diciendo que sea mejor de una forma u otra, sólo digo que veo difícil justificar ante el cliente que no puedes darle un coste aproximado para un proyecto, de forma que pueda utilizarlo para sus cálculos.
Alfonso, me parece que hay proyectos que no son “FTFM”. Recordemos que hay proyectos «por administración», «time & material», «open books»… que se emplean cuando los requerimientos no están definidos a priori porque no se puede, no conviene, no se sabe, no se quiere…
También creo que, si hubiera etapas en la opción seleccionada jstificada económicamente, también puede cuantificarse en términos monetarios el seguir avanzando o dejarlo en una iteración concreta. Me parece que el método de «opciones relaes» para gestionar los riesgos en un entorno operacional dinámico aplica ese principio al poder comparar el coste de seguir con el beneficio esperado.
José, claramente tienes razón con lo de los otros modelos de proyectos.
Respecto a lo de las etapas, es precisamente a lo que me refiero. En cada etapa se realiza esa valoración, para lo que es necesario tener una idea más o menos clara de los objetivos del proyecto y de la etapa siguiente, además de la situación actual. La tolerancia del proyecto en cuanto a ámbito y beneficios es lo que, de algún modo, facilitará que esos objetivos puedan variar.
Estoy deacuerdo. Lo que si me gustaria es que unieses esa discusión con la falta de programadores. El bodyshopping es a mi entender uno de los factores de esa falta. Y en España se abusa de el. Los otros modelos son dificiles de introducir, y lo digo por experiencia. Saludos !!!