La cultura del gran proyecto de desarrollo (Q.E.P.D.): ¿Cómo derribar sus 6 excusas?

Aviso al lector: Con este post me estoy postulando para el Premio Bin Laden del festival de la polémica y a la vez para el Premio Ghandi del festival del idealismo. Para eso escribo...


Compañeros, ya empezó la lucha!


Veo muchas preguntas en los medios ágiles sobre como hacer convivir el agilismo frente al paradigma de grandes licitaciones de desarrollo, gestión de proyectos largos con desarrollos de alcance fijo, estimaciones gigantescas al inicio, etc. Crece cada vez más mi creencia de que no hay que convivir sino tratar de cambiar el paradigma. Creo que hay esperanza y que hay que armarse de coraje para intentar cambiar las cosas, quizás de a poco, a veces con violencia.

Así que estoy luchando, a veces con timidez, a veces con más violencia, a veces me sale y a veces no. Estoy luchando contra la Cultura del Gran Proyecto de Desarrollo.


¿Que es la Cultura del Gran Proyecto de Desarrollo?

Escucho y veo una fuerte tendencia en empaquetar desarrollos de software en proyectos enormes (mayor a un año de duración). Muchas veces es la única forma de desarrollar algo en estas empresas. Y para mi genera muchos riesgos y problemas comparado con sus pocas ventajas. Los problemas generados por esta cultura son muchos, como por ejemplo:

• Pasamos meses/años antes de iniciar el desarrollo, y eso sale caro.
• Cuando más largo es el proyecto, mayor chances tiene de cancelarse y/o de desviarse de sus estimaciones.
• El contrato inicial con el proveedor elegido nos obliga a terminar el proyecto como fue pensado inicialmente, aunque surgieron nuevas necesidades y cambios importantes.
• No podemos cortar el desarrollo antes del final, cuando quizás el costo/beneficio del resto del proyecto no rinde.
• Se dimensiona al inicio una infraestructura, que luego se vuelve inadecuada a medida que se avanza, por los descubrimiento que se hacen en el camino y/o los cambios que surgen.
• Sale mucho más caro de lo que se estimo al inicio con la poca información que estaba disponible.

¿Porque esta Cultura del Gran Proyecto de Desarrollo? ¿Cómo podemos luchar?

No tengo una respuesta muy elaborada a la primera pregunta. Sin embargo relevé algunas excusas comunes para gestionar los desarrollos como grandes proyectos. A continuación enumero las excusas más comunes y aporto algunas ideas o contra-argumentos para derribarlas:


Excusa 1

"Los altos costos de infraestructura hacen que debamos tomar antes de empezar una decisión de go o no go sobre el gran proyecto de desarrollo." 

Mi pequeño aporte extremista: en el 2012 eso no puede ser una excusa. Existen variadas soluciones de hosting, virtualización y cloud para poder montar una infraestructura casi sin gastos y luego hacerla escalar a medida que se necesita. Y si la infraestructura actual no se banca eso, quizás antes de pensar en desarrollar algo nuevo habría que pensar en modernizarla...


Excusa 2

"Deployar la solución es costoso/complicado, por las siguientes razones: hay que instalar en muchas maquinas, capacitar a muchas personas, hacer un cambio importante en la forma de trabajar, etc. Eso hace que preferimos armar un gran proyecto para deployar una sola vez."

Mi pequeño aporte extremista: dos ideas: 1/ Toma un porción pequeña de la organización como equipo piloto donde se puede trabajar en proyecto chicos (iteraciones), y después de un tiempo razonable se podrá hacer el deploy completo, aprovechando la experiencia del piloto. 2/ Justamente el problema del gran proyecto es que el cambio final es muy importante/violento. Hacer proyectos más chicos permite minimizar este cambio, y quizás simplificar el deploy, la capacitación, los cambios organizacionales, etc.


Excusa 3

"Necesitamos definir al inicio la arquitectura de toda la solución del gran proyecto, porque sino los cambios arquitectónicos posteriores van a ser muy costosos." 

Mi pequeño aporte extremista: en general no coincido, y en varias oportunidades pude observar exactamente el contrario: el big up front design donde se trata de pensar toda la arquitectura para poder sostener una cantidad impresionante de requerimiento lleva mucho tiempo y sale caro, y luego a medida que avanza el proyecto cambian los requerimientos. Y ya no podemos volver atrás en la arquitectura y seguimos desarrollando para una arquitectura no adecuada, lo cual trae muchos problemas al final. 


Excusa 4

Los usuarios tenemos muy pocas oportunidades de pedir (y lograr) algo de software, entonces cuando aparece una posibilidad de proyecto intentamos sumar todos los posibles requerimientos que quizás nos podrían ser de utilidad de acá a 10 años. 

Mi pequeño aporte extremista: es una consecuencia misma de la cultura del gran proyecto. Trabajar con proyectos chicos permite manejar mejor la ansiedad de los usuarios y darles varias oportunidades de pedir soluciones a sus verdaderas necesidades a intervalos periódicos (iteraciones).


Excusa 5

Cuesta mucho dividir un gran proyecto en pequeños proyectos de valor para el negocio, y poder definir el costo/beneficio de estos pequeños proyectos. Por eso mejor gestionar proyectos grandes. 

Mi pequeño aporte extremista: En este caso dudo que el proyecto grande sea exitoso, y tendría muchas dudas sobre un eventual análisis de costo/beneficio del gran proyecto. Si no se puede dividir, es probable que estemos sufriendo las consecuencias de varias de las otras excusas, pero quizás antes de meterse en un gran proyecto de desarrollo sería conveniente dedicarle tiempo en entender mejor los pequeños problemas o necesidades que se busca resolver para el negocio, y organizarlo en pequeñas unidades en lugar de un solo gran proyecto ambiguo.


Excusa 6

Para poder desarrollar tenemos que contratar a un proveedor. Y nos conviene más contratar un solo proveedor por proyecto grande (para negociar descuentos, no tener que cambiar de proveedor todo el tiempo, etc.). 

Mi pequeño aporte extremista: dos cosas: 1/ Si el proceso de contratación hace que así sea, quizás convenga mejorarlo antes de pensar en contratar nuevos desarrollos. 2/ Hay mucho riesgo en contratar un solo proveedor para un proyecto grande, y necesito tener mucha confianza en este proveedor para estar seguro que va a funcionar bien. También el contrato grande se vuelve una limitación en muchos casos a cambiar el alcance del proyecto, terminarlo antes, etc. Y finalmente escuché de varias subastas de desarrollos para elegir proveedores, donde seguramente se consiguió muy buen descuento  para el gran proyecto, pero al final no funciono para nada, se cancelo el proyecto, se fundió el proveedor,o se entrego algo de mala calidad o que no sirve, y eso hace que al final sale mucho más caro con un alcance entregado menor a lo planificado.


Te enfrentaste también a estas excusas? Encontraste otras?

Animo compañeros: ¡Muerte a la Cultura del Gran Proyecto de Desarrollo!