Barbecue IA: ¿por qué los proyectos informáticos se desvían tan a menudo?
Primer episodio de Barbecue IA: por qué los proyectos informáticos suelen superar los presupuestos, los plazos y las expectativas.
Las ideas pasan por la parrilla
Episodio 1: ¿Por qué los proyectos informáticos se desvían tan a menudo?
«Aquí no juzgamos a las personas. Ponemos las ideas en la parrilla. Y a veces... salen mejores.»
He revisado cientos de artículos sobre gestión de proyectos. Todos hablan de agilidad, de métodos, de comunicación o de organización. Sin embargo, los proyectos siguen superando los presupuestos, los plazos y las expectativas.
Así que te voy a hacer una pregunta muy simple.
¿Por qué se desvían los proyectos informáticos?
Quizá te sorprenda, pero casi nunca me he encontrado con un proyecto que arrancara a partir de una necesidad falsa.
Cuando una empresa invierte en un software, no lo hace por capricho. Siempre hay un problema real que resolver.
La necesidad existe.
El problema llega después.
Entonces no sería la necesidad la que está mal... sino lo que hacemos con ella.
Exactamente.
Al principio, respondemos a una necesidad concreta.
Luego alguien dice:
"Ya que estamos, también podríamos..."
Y esa frase es peligrosísima.
Una idea llama a otra.
Luego una tercera.
Luego una cuarta.
Ninguna es absurda. Al contrario. Suelen ser pertinentes.
Pero su acumulación termina convirtiendo un proyecto simple en un proyecto complejo.
Espera...
¿Me estás diciendo que un proyecto fracasa... porque los equipos quieren hacer bien su trabajo?
Es paradójico.
No es querer hacerlo bien lo que plantea el problema.
Es querer hacerlo todo.
Ahora mismo.
A menudo confundimos calidad con exhaustividad.
Creemos que un buen software es un software que ha pensado en todo.
Yo pienso justo lo contrario.
Un buen software es un software que responde perfectamente a una necesidad concreta.
Lo demás puede venir después.
Sin embargo, los usuarios siempre piden más.
Una nueva funcionalidad.
Una mejora.
Un atajo.
¿Les dices que no?
No lo bastante a menudo.
Y creo que muchos desarrolladores son como yo.
Nos gusta ayudar.
Queremos que el cliente esté satisfecho.
Queremos que diga:
"¡Hasta en eso pensaron!"
El problema es que cada pequeño "extra" parece insignificante.
Pero al final, forman una montaña.
Entonces el verdadero problema quizá no sea el cliente.
Es nuestra incapacidad para decir:
"Ahora no."
Sí.
Porque existe otro error.
A menudo imaginamos que un pliego de condiciones puede ser completo.
No me lo creo.
Después de más de veinticinco años de desarrollo, nunca he visto uno solo que lo anticipe todo.
Y es normal.
No se pueden prever las excepciones.
Menos aún las excepciones... de las excepciones.
El uso real de un software solo aparece cuando alguien empieza de verdad a utilizarlo.
Entonces, al final...
Ya no buscas construir un proyecto perfecto.
Buscas construir un proyecto que acepte estar incompleto.
Exactamente.
Para mí, el enfoque correcto es casi contraintuitivo.
Primero se realiza el alcance previsto.
Nada más.
Se valida que la necesidad inicial quede realmente cubierta.
Observamos.
Probamos.
Escuchamos.
Y solo después...
mejoramos.
El software crece con su usuario.
No en la imaginación de quien lo diseñó.
Creo que acabo de entender algo.
Durante toda esta conversación, pensaba que ibas a hablarme de métodos ágiles, de Scrum o de arquitectura de software.
En realidad...
me has hablado sobre todo de humildad.
Aceptar que no lo sabemos todo.
Aceptar que un proyecto descubre su forma a medida que avanza.
Y sobre todo...
resistirse a la tentación de querer construir la versión perfecta antes incluso de haber validado la primera.
Lo que sobrevivió a la parrilla
Un proyecto informático no se desvía porque haya demasiadas ideas.
Se desvía porque queremos realizarlas todas antes de haber validado la primera.
Hasta la semana que viene.
Una nueva idea pasará por la parrilla.