… y lo sabéis en el fondo de vuestro corazón, ¿o no? Bueno, a lo mejor sí que existen, pero a mi me parece que no. En este post os voy a contar mi punto de vista sobre esto de los proyectos cerrados ¡ Bien, hoy no hay TDD, menos mal ! Creo que es importante tratar este tema de los proyectos cerrados, sobre todo en relación a las metodologías ágiles, ya que está muy extendida la idea de que dichas metodologías no pueden aplicarse en proyectos cerrados. Mi idea es que eso de los proyectos cerrados no existe, y que cuando se dice que un proyecto es cerrado en realidad estamos soltando una buena mentira.
¿Os acordais del teorema CAP? Bueno, pues lo que voy a contar a continuación se parece mucho. A alto nivel y desde el punto de vista de planificación y preventa de un proyecto hay tres variables: el alcance, el tiempo de entrega y el coste unitario. Veamos que son estas tres variables:
- Alcance. El alcance es la cantidad de funcionalidad o de historias de usuario que va a tener el proyecto. También se puede interpretar como el tamaño del proyecto. En los proyectos de alcance pequeño sólo hay que implementar unas pocas funcionalidades, en los de alcance grande tenemos una lista de requisitos grande (o unos pocos requisitos enormes). Algunos factores no funcionales, como la complejidad de las tecnologías implicadas en el proyecto, o la complejidad a nivel de interlocución, también pueden afectar al alcance.
- Tiempo de entrega. Cuanto tiempo tenemos para terminar el proyecto.
- Coste unitario. El coste de mantener un equipo de trabajo y toda su infraestructura por unidad de tiempo. Cuanta más gente en el equipo, mayor coste unitario. Cuantas más máquinas y más caras, más coste unitario. Cuantas más licencias de pago tengamos, más coste unitario. No confundir con el coste total, que lo da la suma del coste unitario a lo largo de todo el proyecto.
Bien, todo sencillo. En este contexto podemos definir un proyecto cerrado como aquel que tiene un coste unitario, tiempo de entrega y alcance fijo. Sin embargo esto en la práctica no existe. Un proyecto cerrado sólo podría existir en un mundo estático, donde el entorno no cambia y las cosas son totalmente predecibles y repetibles, y el mundo real no es así. En la realidad las necesidades de negocio cambian durante el desarrollo de los proyectos, los clientes y usuarios se equivocan y cambian de opinión, la productividad de un equipo de desarrollo cambia con el tiempo. Sólo un novato puede pensar que un cliente no va a cambiar de opinión o que un acta de reunión se va a respetar (en Alemania tal vez, en España no). He visto demasiadas actas de reunión y contratos y análisis funcionales haciendo compañía al papel higiénico (hay que reciclar). Todo esto lo sabe la gran mayoría de los profesionales y por ello en la práctica tenemos mecanismos de defensa como:
- Las notas de cambio de alcance y la gestión del cambio. Es el mecanismo de defensa típico del proveedor. ¿Que el cliente cambia el alcance? Pues pagas dinero. La opción de quitar alguna funcionalidad a cambio no es tan popular.
- Las cláusulas de penalización si un proyecto se retrasa. Con esto el cliente se defiende tanto de un proveedor en el que no confia como de posibles retrasos debido a imponderables.
- Precio total del proyecto cerrado. Como el anterior permite al cliente defenderse de proveedores malvados o ineptos o simplemente ante cualquier tipo de desgracia acaecida durante el proyecto.
Fijaros en la contradicción, todo el mundo habla de que los proyectos de verdad son cerrados, pero todo el mundo asume que habrá retrasos, malentendidos, incompetencia, imponderables y cambios de necesidades de negocio. Todo el mundo hace proyectos cerrados, pero a la vez usan tácticas de defensa. El problema real es que la gente tiene en cuenta la realidad, pero las metodologías tradicionales no. Las metodologías tradicionales asumen que una vez pasada la fase de análisis de requisitos (o preventa como se llama en España), se puede hacer un proyecto cerrado, ya que presuponen que el mundo es estático e inamovible. Como la realidad es caótica y cambiante, pero todos se empeña en usar metodologías pesadas, se producen estas contradicciones. Usar metodologías basadas en concepciones irreales es peligroso para tu negocio, no me extraña que la mayoría de los proyectos no sean exitosos. En vez de usar metodologías que no se ajustan a la realidad y que tienen una visión inocente respecto al nivel de caos de un proyecto real, es más eficiente usar metodologías diseñadas con la cruda realidad en mente, y que se basan en aceptar el cambio y gestionarlo. ¿Cúales pueden ser estas metodologías? Mmmm, ah, sí, eso raro del agile.
Visto que el caos de la realidad nos impide tener proyectos cerrados, ¿qué hacemos? Tal vez no podamos cerrar las tres variables, pero si algunas de ellas y jugar con las demás. Veamos que posibilidades tenemos:
- Alcance abierto, coste unitario y tiempo de entrega cerrado. Este tipo de proyectos es el clásico ejemplo en las metodologías ágiles. Se tiene un tiempo de entrega cerrado, ya que en estos casos el time to market suele ser vital en el negocio. Dada una estimación del alcance, se propone un equipo cerrado (coste unitario cerrado). Se cierra el equipo ya que normalmente añadir o quitar miembros a un equipo suele ser malo para la productividad (costes de formación, ponerse al día con el proyecto, etc). Durante el proyecto se acepta cualquier cambio de alcance, pero al acabar el tiempo pactado, se entrega. Esto permite ofertar a coste total cerrado. El proyecto se considera exitoso si el alcance conseguido es similar al estimado. Más vale estimar bien, sino el cliente quedará descontento.
- Alcance cerrado, coste unitario cerrado y tiempo de entrega abierto. Como ya he comentado con anterioridad este caso no se produce en el mundo real, excepto tal vez, en proyectos pequeños, debido a que el alcance siempre cambia, ya sea por cambios en necesidades de negocio o por malentendidos. Aun suponiendo que el alcance es cerrado, el que el tiempo de entrega sea abierto, implica que la eficiencia o productividad del equipo varía o se ha estimado mal la capacidad del equipo. Otra posibilidad es que el time to market no afecte al valor del proyecto, pero esto es poco realista. En este caso el coste total del proyecto es abierto, ya que no sabemos por cuanto tiempo vamos a tener al equipo trabajando.
- Alcance cerrado, coste unitario abierto y tiempo de entrega cerrado. De nuevo como el anterior este caso no es muy real, tal vez se puede dar en aplicaciones pequeñas pero con un time to market muy estricto. Para conseguir llegar a la entrega se invertirán los recursos que hagan falta. De nuevo el coste total del proyecto es abierto.
- Alcance y coste unitario abierto, pero tiempo de entrega cerrado. Se corresponde con un proyecto crítico, no sabemos exactamente lo que se va a implementar, pero tiene que estar listo en una fecha concreta. Para conseguirlo se pondrán todos los recursos que sean necesarios.
- Alcance y tiempo de entrega abierto, pero coste unitario cerrado. Esto es un proyecto sin prioridad ni ningún tipo de urgencia. Puede ser un proyecto personal o entre amigos.
El tipo de proyecto que os podéis encontrar más frecuentemente en la realidad es el primero, el que deja abierto el alcance y cerrado lo demás. Qué casualidad que es el tipo de proyecto en el que se centran las metodologías ágiles. Este tipo de proyectos tiene unas cualidades muy interesantes: el coste total es cerrado y por otro lado se ajusta mejor a la realidad. Esto es bueno para el proveedor, ya que evita entrar en perdidas y puede asegurarse un beneficio económico. También es bueno para el cliente, pero sólo si el alcance conseguido es suficientemente bueno.
Esta circunstancia pone al cliente en una posición de debilidad con respecto al proveedor. Muchas consultoras sin escrúpulos se aprovecharon de esto en el pasado. Por eso los clientes ahora demandan «proyectos cerrados». Lo que en realidad hacen es protegerse contractualmente. Es muy raro que un cliente admita «alcance abierto» debido a esa debilidad. Sin embargo si la relación cliente/proveedor es de una gran confianza y la experiencia pasada sea buena, si puede admitir este modelo de proyecto con alcance abierto, al fin y al cabo lo que le suele interesar al cliente es protegerse de proyectos que no se acaban nunca y que consumen dinero sin fin. Si el fracaso del proyecto no supone un gran perjuicio para el cliente, aumenta la posibilidad de que éste se preste a un contrato abierto. Otro caso es el de los proyectos internos, donde es absurdo penalizarse a uno mismo, y es mejor aceptar la realidad. En este caso el poder hacer «lo máximo posible» en un tiempo y coste acotado es bastante atractivo.
En el resto de los casos el cliente querrá un modelo de penalización o bien de precio cerrado. Esto no significa que no tengamos un proyecto con alcance abierto, sino que tenemos un contrato cerrado. Sólo debemos aceptar contratos cerrados si estamos muy seguros de poder cumplirlos o si estamos muy desesperados. Para tener esa seguridad nuestra organización debe ser lo suficientemente madura como para poder hacer estimaciones certeras. En este caso se trata de estimar el alcance, y en función de esta estimación saber que coste unitario hay que invertir para cumplir los plazos. Esto no es fácil, sobre todo si tenemos en cuenta que el coste unitario no afecta de forma muy predecible a la productividad del equipo. Podemos gastar mucho pero mal, por ejemplo comprando caras licencias de productos que no son adecuados o poniendo un pelotón de becarios en vez de unos pocos desarrolladores expertos.
En cualquier caso debemos estar preparados para lo peor. Sabemos que aunque el proyecto sea abierto el cliente normalmente se protegerá con un contrato cerrado, asi que ¿qué puede ocurrir si fracasa el proyecto? Es decir, ¿que pasa si el alcance logrado no da el valor suficiente al cliente? En estos casos el cliente tiene diferentes mecanismos para protegerse:
- Si lo más importante para el negocio es alcanzar un nivel de funcionalidad aceptable, se da un tiempo extra al proyecto, a cambio de una penalización económica debido a los «daños» de no tener el sistema a tiempo.
- Si lo que realmente importa es el time to market, se pone en producción pero se penaliza al proveedor en función de la cantidad de funcionalidad que falte, para compensar los inconvenientes de que el sistema no tenga suficiente funcionalidad.
- Precio cerrado. El proyecto es precio cerrado, y el cliente no te pagará ni un céntimo más del pactado. Si el time to market es lo importante tendrás que aumentar el coste unitario para reforzar el equipo. Si lo importante es la funcionalidad, tu equipo estará más tiempo del planificado. Combinaciones de ambos escenarios son bastante típicas. Todo esto puede lleva a proyectos con poca rentabilidad o pérdidas si no consigues estimar bien.
- Te demandan y/o devuelves el dinero más el perjuicio recibido por el cliente debido a no conseguir tener la aplicación.
- Si aplicas una metodología que lo permita, se puede abortar el proyecto en cuanto se vea que se va a fallar. Las metodologías ágiles son especialmente adecuadas en este sentido. Si se falla al principio, el cliente aun está a tiempo de contratar a otro, con lo que tiene menos perjuicio. Desgraciadamente en España es raro ver proyectos abortados aunque claramente se encaminen al fracaso.
¿Cómo afrontamos los contratos cerrados? ¿Nos rendimos y hacemos lo «mismo de siempre»? Muy al contrario, lo ideal en estos casos es usar metodologías ágiles, aunque la idea parezca de poco sentido común. Desde el punto de vista de los contratos cerrados, las metodologías ágiles son muy eficaces, ya que nos permiten gestionar el riesgo mejor y por otro lado nos permiten tener estimaciones precisas. Uno de los pilares de dichas metodologías es el uso de ciclos de feedback frecuentes, lo que nos permite:
- Enterarnos rápidamente de los cambios de alcance. Mediante entregas frecuentes y desarrollo incremental el cliente tiene acceso rápidamente a la funcionalidad con lo que nos puede advertir de los cambios de requisitos. Este es un mecanismo muy útil para mitigar uno de los riesgos más típicos: construir funcionalidad que el cliente no quiere.
- Aceptar cambios e implementar la funcionalidad más importante primero. Cuando se llegue a la fecha de entrega, al menos se habrá cubierto la funcionalidad más importante, con lo que la posibilidad de fracasar disminuye.
- Mediante las reuniones diarias nos enteramos de los posibles impedimentos al proyecto, lo que nos permite tomar acciones correctivas, mitigando riesgos tecnológicos y organizativos.
- Análisis de viabilidad frecuente. Por ejemplo, en Scrum, podemos decidir al final de cada iteración o sprint, cancelar el proyecto, de acuerdo al feedback del usuario y de los equipos de desarrollo.
- Las estimaciones mejoran más rápidamente, ya que al tener un feedback más rápido, tenemos más datos y por lo tanto podemos ajustar mejor las estimaciones. Con una metodología pesada el feedback es al final del proyecto, y las estimaciones sólo se pueden ajustar al final del proyecto. En Scrum ajustas las estimaciones al menos una vez por iteración (sprint). En kanban, una vez cada vez que se termina una historia de usuario.
También hay que tener en cuenta que cada sprint o iteración se puede considerar como un proyecto en si mismo, pero de alcance muy pequeño y duración corta. Si el alcance es pequeño y la duración corta, pensar que el alcance está cerrado, sí es una buena aproximación a la realidad. Al contrario que en un proyecto real, durante un sprint, hay muy poco tiempo, y por lo tanto poca probabilidad de que el alcance del sprint cambie. Podemos considerar pues, que cada sprint es un verdadero proyecto cerrado en el sentido estricto del término. De esta forma gestionar un sprint sí es sencillo, comparado con gestionar un proyecto. De todas formas, en proyectos muy cambiantes (o altamente caóticos), el alcance cambia incluso durante el sprint. En estos caso Scrum puede que no sea la mejor opción, y habría que utilizar enfoques más ágiles todavía, como kanban o el agilismo minimalista.
Como vemos, los proyectos cerrados no existen, pero los contratos cerrados sí, lo que hace los proyectos sean arriesgados para el proveedor. Sin embargo el mito de que una metodología ágil no es útil con contratos cerrados se cae bajo su propio peso. Al contrario de lo que muchos piensan, las metodologías ágiles permiten una mejor estimación y gestión del riesgo de un proyecto con contrato cerrado, además de incorporar de forma natural la gestión del cambio. Tal vez, cuando tu cliente vea que no lo engañas y que cumples tus contratos, te deje hacer un «contrato abierto».
[…] This post was mentioned on Twitter by Enrique Amodeo Rubio. Enrique Amodeo Rubio said: Te lo dije…Los proyectos cerrados no existen http://wp.me/pQAdW-4d #agile […]
Felicitaciones, me gusta que se le de una visión realmente seria al tema y super aplicable.
¡ Gracias ! Me alegro que guste.
¡Muy buen post! Weiter so!
fyi, las actas de reunión tampoco se respetan siempre en Alemania. Lo que se hace es un acta de cambio del acta de cambio del etc… Lo que no hay es «Lo hacemos porque me sale de los cojones».
En la manera de afrontar un proyecto se refleja bastante bien el contexto cultural y no tanto la razón. Yo creo que en España no se suelen abortar proyectos con un fracaso asegurado porque abortar huele mucho a «maricón» y abortar no es algo que hace un «macho iberico con dos cojones».
Ignorar riesgos y simplemente aguantarlos tiene algo de un héroe, está claro. Pero en el mundo de los proyectos de software y del dinero que cuestan, los fines no suelen justificar todos los medios. Por lo tanto sólo hay sitio para un héroe en los proyectos de software dónde todos están desesperados e indignados por la complejidad y el coste del asunto y acuden a la magia del proyeto cerrado.
p.s.
El porqué de que el contexto cultural influye mucho más en las decisiones de los hombres que la razón, se explica bastante bien en el libro «El viaje al poder de la mente» de Eduardo Punset.
Lamento tener que untar el blog con la grasa saturada de la realidad.
Los proyectos cerrados existen.
Cerrados en alcance, en precio y en duración. Incluso algunos contienen clausulas de penalización.
Lo que tambien existe son proyectos cerrados, mal estimados en tiempo y esfuerzo, en consecuencia no se cumplen ni en precio final ni en duración.
El exito del proyecto no reside en que metodología se aplique para llevarlo adelante, sino en dos factores claves:
· La preventa basada en una RFP
· El control del proyecto.
Con una buena preventa que diseccione la RFP presentada por el cliente, llevada adelante por un tecnico de preventa con la experiencia suficiente (como alguno de los nuestros) para evaluar el esfuerzo, se logrará calcular correctamente el tiempo y esfuerzo necesario.
(Fijaos que no he incluido el precio).
El control del proyecto debe ser llevado adelante por un Jefe de Proyecto que lo defienda. Fijaos que he dicho que debe defender el proyecto, no al proveedor ni al cliente.
Generalmente la tarea del Jefe de Proyecto esta mediatizada por factores de indole comercial que coartan la labor del Jefe de Proyecto, que normalmente pertenece al Proveedor. Esto le impide adoptar posturas rigurosas en la relación con el cliente, cediendo en tareas que el cliente debe realizar en tiempo y forma pero que siempre (siempre) se retrasan o no se hacen o termina haciendolas el proveedor.
Una buena practica es que el cliente contrate la Jefatura de proyecto a otro proveedor, diferente del que aportará la solución. Esto creo que ha dado resultados en clientes que usan esta táctica.
El precio: Es el elemento decisiorio para ganar un proyecto. Muchas veces el posible proveedor debe resignar en precio para ganar una oferta. Si este es el caso, ligar el precio final reducido a los recursos que se asignarán al proyecto es sinonimo de fracaso. El proyecto se retrasará con seguridad si es que no fracasa definitivamente.
Aqui concluyo mi comentario, aunque da para mucho más. Como veis no he hablado nada de Scrum, TDD y todas esas nuevas estrategías de intentar hacer las cosas bien, porque en realidad nada tienen que ver con el exito de un proyecto.
Os invito a convertiros en Jefe de Proyecto durante dos años, llevando dos o tres proyectos, poniendo la cara ante el cliente y ante vuestros subordinados, asumiendo responsabilidades.
Es la unica forma de que se os abra la mente para poder adaptar todas vuestras ideas a la untuosa grasa saturada de la realidad.
Jose María, los proyectos cerrados no existen, lo que puede (y a menudo) está cerrado es el contrato. El alcance de un proyecto cambia frecuentemente durante la ejecución del mismo, ya que normalmente el cliente no suele tener claro todos los requisitos, y las circunstancias en el negocio del cliente cambian. No podemos pretender lanzar un proyecto y que el mundo se congele a nuestro alrededor hasta que el proyecto se entregue.
Precisamente, como dices, el control del proyecto y la estimación de la RFP, son vitales para el éxito de un proyecto (abierto) con contrato cerrado. Ambas cosas forman parte de la metodología. Si una metodología no cubre esto, pues es bastante incompleta. En concreto mi punto de vista es que las metodologías ágiles son claramente superiores a las tradicionales en estos dos puntos.
Otro punto vital que comentas es el Jefe de proyecto, en esto estoy totalmente de acuerdo contigo. Precisamente un buen jefe de proyecto debe defender el proyecto en si, de forma neutral con respecto al cliente y al proveedor. También debe saber que es lo que se trae entre manos y asumir responsabilidades. Curiosamente esta descripción de un jefe de proyecto se parece bastante a lo que en algunos círculos se llama un Product Owner (PO). Demasiado a menudo encontramos jefes de proyecto que no están suficientemente capacitados, tienen intereses ocultos, escurren el bulto o simplemente no quieren trabajar y partirse los cuernos. Eso sí, suelen lleva traje caro, hablar muy bien inglés y autoproclamarse (normalmente de forma falsa) como «expertos en business».
Lo del precio es obvio. Si se da un precio muy caro casi seguro pierdes, a no ser que exista algún tipo de corruptela o que tu empresa sea altamente prestigiosa. Si das un precio bajo puede ser que ganes… un proyecto con pérdidas claro.
Bueno, un poquito de grasa de vez en cuando no viene mal. Un día tienes que escribir un post sobre «reality projects».
Mi experiencia en los proyectos por los que he ido pasando es que al final el peso lo tiene el «comercial», que termina vendiendo casi siempre tirando a la baja el precio y con márgenes de tiempos ridículos e imposibles de cumplir, y ofreciendo una lista de personal que al final no es el que contrata para el proyecto (normalmente siempre es menos cualificado de lo que ha ofertado).
Por ello, para compensar, toca echar horas extras a los pringaos de abajo como siempre, y en lugar de contratar a personas con experiencia, contratan a personas sin apenas experiencia y que salen más baratos (ya aprenderán) y que tienen que hacer funciones por las que no se les está pagando, o contratan a gente con cierta experiencia por salarios bajos (o con promesas falsas) y éstos terminan quemados y yéndose al poco o totalmente desmotivados y rindiendo la cuarta parte de lo que podrían rendir.
El resultado que se suele repetir es que al final el proyecto suele ser un caos y un desastre (por supuesto siempre culpa de los programadores), pero el comercial se ha llevado su comisión y la disfruta felizmente en su casa, mientras el resto pringa a causa de sus decisiones.
Es el escenario que más veces he vivido o visto a mi alrededor en casi todas las empresas por las que he ido pasando (incluyendo grandes consultoras y grandes clientes). No sé en qué metodología encaja mejor este escenario, pero a mi alrededor es la realidad que veo habitualmente.
Scherzo