Como fracasar en tus proyectos de forma elegante

la hipótesis C2I2

En su libro “Anti Frágil”, el matemático Nassim Nicholas Taleb escribe:

“Para lo perecedero, cada día adicional de vida se traduce en una esperanza de vida adicional más corta. Para lo imperecedero, cada día adicional puede suponer una esperanza de vida más larga.”

Para hacerlo más útil, lo traduce a la vida de un proyecto:

“Digamos que se espera que un proyecto termine en 79 días[..] En el día 79, si el proyecto no ha finalizado, se esperará que tome otros 25 días para completarse. Pero en el día 90, si el proyecto aún no se ha completado debería tener 58 días más de duración. En el día 100, debería tener 89 días más adicionales. En el día 119, debería esperarse otros 149 días adicionales. En el día 600, si el proyecto no está listo, debería esperar necesitar un extra de 1.590 días. Cómo pueden ver, mientras más esperas, más tendrás que seguir esperando.”

La vida media de los proyectos, sobretodo los de software, tiende a crecer, muchas veces de forma exponencial.

Ante esto, cuál es la estrategia que deberíamos tomar?

Me he topado con esta consulta muchas veces, me han preguntado que hacer ante un proyecto atrasado, incendiado, o simplemente ante un “proyecto cacho”.

La Hipótesis C2I2

Zed Shaw tiene una propuesta bien simple para entender por qué los proyectos fracasan, o se demoran.

La idea parte de la formulación de cinco sentencias:

1. Los clientes pueden ser Clientes o Colaboradores (Clients can be either Customers or Collaborators).

2. Los proyectos pueden ser Implementaciones o Invenciones.

3. Los Clientes esperan que las implementaciones sean productos terminados y odian verte “hacer embutidos”. (En otras palabras a los clientes sólo les interesa el producto final, no el proceso de producción)

4. Los Colaboradores esperan ayudar a construir los Inventos y quieren ayudarte a meter la carne de cerdo en la picadora. (Los colaboradores sí están interesados en el proceso y quieren entenderlo y participar en este).

5. Las otras combinaciones (Clientes → Invenciones; Colaboradores → Implementaciones) terminan en desastre.

A esto Shaw lo llama la hipótesis C2I2, y elabora estrategias para abordar los distintos tipos de proyectos, usando este cuadrante:

Como pueden apreciar, en los dos cuadrantes en que Shaw predice el desastre el coloca Scrum como la metodología a usar. Mostrando el estilo sarcástico de este autor.

Pero tiene razón. Scrum sirve para dar la sensación de control, sabemos que un proyecto que cae en esos cuadrantes está condenado al fracaso y para nuestra desgracia la mayoría de los proyectos caen en esos cuadrantes.

Tratar de movernos hacia los cuadrantes felices (XP - Exploratorio, CMM - Racional, Definido) es una quimera para Shaw y en su ensayo explica cómo fracasar del modo correcto.

En suma, estamos jodidos. Tienes un proyecto y un cliente que están mal. El proyecto es una implementación y tienes un cliente con gran injerencia y que pretende ser un colaborador, que está cuestionando continuamente y tomando decisiones horribles que hacen que el software apeste y tome diez veces más en construir. O por otro lado tienes una Invención, de la que no sabes nada, y el cliente se comporta como Cliente, esperando la perfección en la primera demostración. O estás en un proyecto mal clasificado. Los programadores te dicen que es fácil, pero nunca han hecho algo parecido. O los gerentes deberían involucrarse más, pero vuelan apenas ven un prototipo a medio terminar al principio del proyecto.

Y el consejo más sabio de Shaw es:

“Mi filosofía general es: “mátalo tempranamente y salva tu dinero.” Hay un enorme mito en TI de que tenemos más fracasos que en otras industrias. El problema es que hemos definido “fracaso” como “no finalizar a pesar de toda adversidad.”

La mayoría de las otras industrias no hacen esto y matarán un proyecto tempranamente si obviamente no lo van a realizar. Emprenderemos un proyecto sin importar que, aún si es obvio que fracasará miserablemente. En TI hemos perdido la noción de que podemos evadir proyectos o matarlos tempranamente y evitar el gasto de todo ese dinero.”

Es mejor evitar los malos proyecto. La vida es demasiado corta para perderla desarrollando software inútil.

Pero volvamos al cuadrante. Ya estamos acá, y algo tenemos que hacer. Quizás ya no es posible matar ese maldito proyecto. Aprendamos a fracasar de manera elegante, ¿les parece?

De Implementación a Invención

Queremos mover un proyecto de Implementación a Invención, eso es lo que un gurú agilista nos recomendaría. Esto normalmente requiere convencer a todos de que es más difícil de lo que se estimó originalmente. Uno se da cuenta que está en esta situación cuando después de leer la descripción técnica del proyecto, y percatarse que tiene un montón de módulos e integraciones, que además se quiere que funcione en una infraestructura nueva, en la que el equipo no tiene experiencia, termina con la frase “el proyecto debería tomar unos seis meses”.

Seis meses es el número mágico, el favorito de los gerentes, y de los que les gusta complacer gerentes. Saben que es lo que quieren escuchar. Normalmente estas estimaciones no están respaldadas en nada, y te das cuenta que hay un conocimiento bien limitados del problema a abordar, así que queda claro que estás ante una Invención.

Cómo puedes demostrarles que esa estimación era mala? Puedes hacerla tú. Calcular meticulosamente en función de los módulos, los recursos asignados (personas, dinero, infra), integraciones, etc. Shaw recomienda usar la vieja, pero útil técnica de los Puntos por Función, puedes usar esta calculadora de PF, con eso tendrás un primer estimado. Busca proyectos similares, que haya ejecutado la empresa. Mira cuantas lineas de código tiene ese proyecto similar.

Lo que estás buscando es: FP/dia/desarrollador y FP/LOC (FP punto por función, LOC: lineas de código).

Yo tengo la hipótesis de que por cada 20.000 a 10.000 lineas de código necesita un desarrollador/año.

De todas maneras, tomes mi hipótesis, o calcules en función de FP/dia/desarollador, vas a llegar a un estimado de cuanto tiempo requieres realmente. Y así desarmarás esa ridícula esperanza de los seis meses.

De Invención a Implementación

Este es el caso cuando algún desarrollador ambicioso y de pocas luces quiere embarcarse en un proyecto que luzca bien en su currículum. También pasa cuando estás ante un cliente micro controlador, pero como el cliente no tiene control real sobre el proceso (no debería), puedes mover el proyecto de invención a implementación sin mucha protesta. Convencer al desarrollador que su joyita en realidad es una vulgar piedrita es más difícil.

Acá es clave que como gestor tengas conocimientos técnicos adecuados, para objetar esas arquitecturas ridículas, o adviertas que este no es un proyecto para jugar en el último framework o lenguaje que acaba de salir en Hacker News. Si es necesario, debes alejar a esas personas, típicamente un arquitecto, del proyecto.

Clientes vs Colaboradores

Finalmente debes ver que haces con tus clientes

De esos hablaremos en otro artículo, porque este ya está quedando demasiado largo.

Mientras los invito a suscribirse, y seguir discutiendo este y otros temas que nos afectan cuando desarrollamos software.