Cuando leo en las noticias del fracaso de un proyecto de millones de Euros o de un proyecto más pequeño, pero más cercano me pregunto ¿por qué?

Somos gente inteligente en informática. ¿Cómo puede ser esto?

Analizando proyectos fracasados que he visto estos 20 años, hay tres razones principales, hay tres puntos principales que pueden «matar» un proyecto software si fallan.

Aquí va la primera razón para la «muerte» de un proyecto.

¿Alguna vez has preparado un software que estabas seguro que sería «la bomba» y cientos o miles de horas de trabajo después nadie quería comprarlo o usarlo?

¿Alguna vez seguiste los «requisitos» – ya fueran 1 párrafo o 100 páginas – y una vez finalizado, o incluso a mitad del proyecto te dijeron que eso no era lo que se quería y empezó una tremenda cantidad de cambios que multiplicó por varias veces el trabajo necesario en el proyecto, o peor, se perdió el proyecto?

Algunos «buenos» fracasos

• En un caso real, una «startup» empleó años y millones de Euros en el desarrollo de un producto y un servicio software online suponiendo que funcionaría, pero sin examinar la demanda real del mismo y lo que el usuario realmente quería. La consecuencia fue el cierre y la pérdida de la inversión.
• En otro caso cientos de millones de Euros y años fueron desperdiciados en un sistema para automatizar una parte importante de la administración del Estado. Hablando con usuarios finales que conocemos de esa área averiguamos que el sistema es inútil, ya que no incluye funciones básicas que ellos necesitan en su día a día y que ni siquiera son difíciles de implementar.

Todo esto se resume en el tema de:

¿Qué quiere o necesita realmente el cliente y/o el usuario?

Se pueden desperdiciar decenas de miles de horas yendo en la dirección equivocada. Este es un error tan radical que bien puede ser la fuente de la mayor parte de «grandes fracasos totales».

Los fallos más comunes

• Podemos no estar hablando con el usuario final, si no con un intermediario que «sabe» lo que se necesita, pero realmente no lo sabe (por ej. con el departamento de informática del cliente si no ha chequeado con sus usuarios reales, sino que «sabe más que nadie» – pero no sabe realmente).
• El usuario puede darnos su (mala) «solución» en vez del problema que intenta resolver. Salvo pocas y honrosas excepciones, su solución será un fracaso si la seguimos. En cualquier caso hay que examinarla en detalle, llegar al problema real y conseguir una buena solución para el problema.
• El usuario es incapaz de analizar por su cuenta lo que necesita por falta de capacidad organizativa, técnica, etc. Nosotros tendremos que hacerlo por él.
• Y lo peor – nunca hemos examinado lo que realmente quiere o necesita el usuario – simplemente lo «suponemos» porque «nosotros lo sabemos«. Esta es una buena vía al fracaso, si no va acompañada de una investigación real.

El problema de todo esto es que unos requisitos incorrectos nos golpearán en la cara, incluso si no es «culpa nuestra».

Cuando «la basura golpea el ventilador» da a todo el mundo.

Es muy difícil cobrar un «proyecto fallido» aunque no sea «culpa nuestra» y podemos incluso acabar con mala reputación o acciones legales.

La solución

La solución es asegurarnos de que los requisitos son realmente correctos, sin importar si es «responsabilidad nuestra» o no. Requiere disciplina, ya que es demasiado fácil «atajar» y «suponer». Unas reglas funcionales al respecto son:

1. Nunca aceptar «sin más» unos requisitos sin un análisis minucioso propio. ¿Tienen sentido los requisitos? ¿Tienen contradicciones? ¿Si nosotros fuéramos los usuarios finales, querríamos este sistema? Si algo falla en cualquiera de estas preguntas, tenemos que empezar a investigar.
2. Nunca aceptar que nos den unos requisitos muy poco detallados para un proyecto. Por ej. de vez en cuando alguien nos pregunta «¿Qué costaría hacer un Facebook?» o algo similar. Lo siento por el que de un presupuesto para esto (y por el que luego lo acepte). Obteniendo más datos y concretando el proyecto podemos llegar a algo.
3. Verificar los supuestos requisitos de un proyecto con los usuarios finales, asegurándonos que tiene sentido para ellos. En muy pocos casos podemos aceptar que el cliente ha hecho este análisis correctamente con sus usuarios finales, sobre todo si vemos cosas en el análisis que no tienen sentido.
4. Asegurarnos de hacer el análisis de requisitos al completo y a fondo antes de empezar el desarrollo. A veces las «prisas comerciales» llevan a comenzar sin más, con requisitos «medio hechos» y la consecuencia son cambios a mitad de proyecto y cientos o miles de horas perdidas. Si el cliente no puede cerrar en buen detalle sus requisitos, es muy posible que (todavía) no sepa lo que quiere o necesita y que nos lo vaya a querer cambiar a mitad de proyecto con grandes pérdidas para todos.
5. Nunca comenzar un proyecto propio sólo porque es una «buena idea» en nuestra imaginación, sin un mínimo de investigación de mercado, aunque sea informal, pero a un número de personas suficientes. Hacer ese análisis.

Seguro que hay muchos refinamientos y detalles, pero es el 1-2-3-4-5 más básico que hemos encontrado que si no lo respetamos en un proyecto, es muy posible que este fracase – y que muy para nuestro pesar hemos encontrado en alguno de nuestros proyectos donde relajamos estos requisitos y luego se requirió mucho trabajo para reconducir o rescatar el proyecto.

Espero que te sea útil.