Por qué los proyectos de software empresarial fracasan incluso antes de que comience el desarrollo

La mayoría de los proyectos de software empresarial que fracasan no lo hacen por un código deficiente. Fracasan porque se construyó lo incorrecto. Para cuando alguien escribe una línea de código, el resultado ya está definido, moldeado por decisiones tomadas durante el descubrimiento que nadie cuestionó lo suficiente.

Esto es incómodo porque significa que los errores más costosos ocurren cuando todavía parece que todo va bien. Las partes interesadas están alineadas. El documento de requisitos es extenso. Se ha seleccionado al proveedor. Y, sin embargo, silenciosamente, el proyecto ya se dirige hacia un resultado que decepcionará.

La ilusión de claridad

La fase más peligrosa de cualquier proyecto empresarial es la que se siente más ordenada: la recopilación de requisitos. Los equipos organizan talleres. Los analistas de negocios producen documentos de especificaciones. Las partes interesadas dan su aprobación. Todos están de acuerdo en lo que se debe construir.

El problema es que el acuerdo no es lo mismo que la comprensión. En la mayoría de las organizaciones, diferentes partes interesadas usan las mismas palabras para referirse a cosas diferentes. “Informes en tiempo real” significa una cosa para el CFO y algo completamente diferente para el equipo de ingeniería. “Integración con el ERP” podría significar una exportación por lotes diaria o una API en vivo con una latencia de menos de un segundo. Estas ambigüedades sobreviven porque nadie se siente lo suficientemente seguro como para reducir la velocidad y decir: “Espera, ¿qué queremos decir exactamente con eso?”

Los documentos de requisitos crean una falsa sensación de precisión. Describen características, no problemas. Y cuando comienzas con las características, te saltas el paso que más importa: asegurarte de que estás resolviendo el problema correcto en primer lugar.

Pensamiento primero en la solución

Los proyectos empresariales suelen comenzar con una solución ya elegida. Alguien ha decidido que la empresa necesita una aplicación móvil, un portal para clientes, un lago de datos o una migración a la nube. La fase de descubrimiento se convierte en un ejercicio para justificar una decisión que ya se tomó, en lugar de investigar si es la decisión correcta.

Esto sucede por razones comprensibles. Un líder sénior asistió a una conferencia. Un competidor lanzó algo. Un proveedor dio una demostración convincente. La presión para actuar es real, y “estudiemos esto durante otro mes” no es lo que nadie quiere escuchar.

Pero el costo de omitir el encuadre genuino del problema es enorme. Hemos visto organizaciones gastar dieciocho meses en la construcción de un portal para clientes solo para descubrir que el verdadero cuello de botella era un proceso interno que podría haberse resuelto con una automatización del flujo de trabajo que costaba una fracción del esfuerzo. El portal era técnicamente sólido. Simplemente no abordó el problema real.

La desalineación de las partes interesadas es estructural, no personal

En las grandes organizaciones, la desalineación entre las partes interesadas no es un fallo de comunicación, es una realidad estructural. Los diferentes departamentos tienen diferentes incentivos, diferentes definiciones de éxito y diferente tolerancia al cambio.

El equipo de ventas quiere velocidad. Finanzas quiere previsibilidad. Operaciones quiere estabilidad. IT quiere facilidad de mantenimiento. Estas no son prioridades equivocadas. Son restricciones reales que existen en tensión entre sí. El fallo no es que estas tensiones existan, sino que la mayoría de los procesos de descubrimiento pretenden que no existen.

Cuando un proyecto se inicia con un único documento de requisitos que ha sido “aprobado por todas las partes interesadas”, lo que suele suceder es que cada grupo lee las partes relevantes para ellos y asume que el resto es problema de otra persona. Seis meses después, cuando hay que hacer concesiones, la desalineación surge como conflicto, y para entonces, cambiar de dirección es costoso.

Lo que realmente funciona

Los proyectos que tienen éxito tienden a compartir algunas características que no tienen nada que ver con las opciones tecnológicas.

Comienzan definiendo cómo se ve el éxito en términos medibles.No “mejorar la experiencia del cliente”, sino “reducir el tiempo promedio de resolución de tickets de soporte de 48 horas a 8 horas”. Si no puedes medirlo, no puedes gestionarlo, y ciertamente no puedes saber si el proyecto aportó valor.

Separan la validación del problema del diseño de la solución.La primera fase debe producir una comprensión clara y compartida del problema y sus restricciones, antes de que nadie empiece a dibujar diagramas de arquitectura. Esto significa entrevistar a usuarios reales, no solo a sus gerentes. Significa mapear los flujos de trabajo existentes, no solo documentar los aspiracionales.

Sacan a la luz los desacuerdos temprano y los resuelven explícitamente.Esto requiere el tipo de facilitación que la mayoría de las organizaciones subestiman. No basta con poner a las partes interesadas en una sala. Alguien necesita hacer las preguntas incómodas: ¿Qué pasa cuando se retrasa el cronograma? ¿Qué características recortamos primero? ¿Quién decide?

Invierten en la creación de prototipos antes de comprometerse con una construcción completa.Un prototipo funcional probado con usuarios reales en el primer mes revelará más sobre lo que el proyecto debería entregar realmente que tres meses de talleres de requisitos.

Lo que esto significa para los líderes

Si usted es un CEO o CTO que aprueba una inversión de software significativa, la pregunta más importante que puede hacer no es sobre la tecnología, el proveedor o el cronograma. Es esta:¿Qué problema estamos resolviendo y cómo sabremos que lo hemos resuelto?

Si el equipo no puede responder a esa pregunta de forma clara y específica, el proyecto no está listo para comenzar, sin importar lo pulida que parezca la propuesta.

La segunda pregunta es:¿Hemos probado nuestras suposiciones con las personas que realmente usarán este sistema?No sus gerentes. No los patrocinadores del proyecto. Las personas cuyo trabajo diario cambiará.

El descubrimiento no es una formalidad. Es la fase en la que el proyecto se gana el derecho a continuar o revela que el problema real es diferente del que todos asumieron. El proyecto de software más caro es el que entrega exactamente lo que se especificó, y no resuelve nada.