Por qué fracasan los proyectos de software (y no es por el código)

Cuando un proyecto de software sale mal, la explicación oficial casi siempre es técnica: el proveedor no estuvo a la altura, la tecnología no era la adecuada, hubo problemas de integración.

Casi nunca es cierto. En los proyectos fallidos que nos tocó rescatar, el código andaba. Lo que había fallado estaba antes, y era visible desde la primera semana.

1. Nadie era dueño del proceso

El síntoma: en las reuniones hay ocho personas y ninguna puede decidir. Cada decisión "hay que consultarla". El proyecto avanza a la velocidad de la próxima reunión de comité.

Cuando el proceso no tiene un dueño con autoridad para definir cómo se trabaja, el software termina implementando todas las versiones del proceso a la vez, para no contradecir a nadie. El resultado es un sistema con quince opciones de configuración que no le sirve bien a ninguno de los quince.

La señal temprana: si en la primera semana no podés nombrar a la persona que firma las decisiones de alcance, el proyecto ya está en riesgo.

2. Se automatizó un proceso que nadie cuestionó

Muchos procesos tienen pasos que existen porque el sistema anterior los pedía, o porque hace ocho años hubo un problema y se agregó un control que ya no protege de nada.

Automatizar eso lo cristaliza: ahora el paso inútil es más rápido, más consistente y mucho más difícil de sacar, porque está en el código.

Antes de automatizar, cada paso tiene que responder "¿por qué existe?". Es una conversación incómoda —siempre hay alguien que ese paso lo puso— y es donde suele aparecer el 30% del ahorro del proyecto, antes de escribir una línea.

3. El alcance se cerró por doce meses

Se firma en enero un documento que describe lo que la empresa necesita en enero. En marzo cambia una prioridad. A partir de ahí, cada cambio necesario se vuelve una negociación contractual, y todos empiezan a defender el documento en vez del resultado.

Al final se entrega exactamente lo firmado y no le sirve a nadie, y ambas partes tienen razón: el proveedor cumplió y el cliente no recibió lo que necesitaba.

El antídoto no es firmar menos. Es firmar más seguido, por tramos más chicos: etapas de cuatro a ocho semanas con precio cerrado, donde al final de cada una se reordenan las prioridades con la información nueva.

4. Se construyó lejos de quien iba a usarlo

El proyecto se define con la gerencia, se construye tres meses, y se presenta al equipo el día del lanzamiento. Ese día aparecen los cinco casos que ocurren todas las semanas y que nadie mencionó, porque para la gente que hace el trabajo son tan obvios que no valía la pena decirlos.

La versión sana: la persona que va a usar el sistema lo ve en la semana dos, cuando todavía es barato cambiarlo. No en una demo formal: sentada adelante, usándolo.

5. "Terminado" significaba "entregado"

Es la trampa más silenciosa. El proveedor entrega, factura y se va. El sistema queda instalado y el equipo sigue usando la planilla, porque nadie acompañó las tres semanas en que lo nuevo cuesta más que lo viejo.

Un proyecto termina cuando el proceso viejo está apagado. Todo lo anterior es entrega, no adopción. Y la etapa de adopción tiene que estar presupuestada desde el principio, porque si aparece como un extra al final, nadie la va a pagar.

6. No se midió nada antes de empezar

Sin la línea de base, es imposible demostrar que el proyecto sirvió. Y un proyecto que no puede demostrar su retorno no consigue la segunda etapa, aunque haya funcionado perfecto.

Toma media hora: antes de arrancar, anotá cuántas horas lleva el proceso hoy, cuántos errores tiene por mes, cuánto tarda un caso de punta a punta. Tres números. Después de la puesta en producción, medí de nuevo.

Lo que sí correlaciona con el éxito

Mirando para atrás los proyectos que salieron bien, comparten cuatro cosas, y ninguna es tecnológica:

• Un dueño con autoridad, disponible todas las semanas, no solo en los hitos.
• Etapas cortas que llegan a producción, en vez de una entrega grande al final.
• Un usuario real involucrado desde el principio, con poder de veto sobre lo que no sirve.
• Un número acordado de antemano que define si funcionó.

Ninguna de esas cuatro depende del lenguaje de programación, del framework ni del proveedor. Dependen de cómo se encara el proyecto — y son, casi siempre, la diferencia entre un sistema que se usa y uno que se instala.

Si tenés un proyecto que se está estirando o uno que arranca en breve, charlemos media hora. A veces alcanza con reordenar las etapas.