Los proyectos tecnológicos son un terreno complejo. A lo largo de mi carrera, he participado en miles de ellos y en todos los niveles: desde pequeñas empresas que buscaban dar sus primeros pasos digitales, hasta corporaciones del Fortune 500 con desarrollos de una complejidad enorme. En ambos mundos me ha tocado ver de todo: grandes éxitos y fracasos rotundos. Pero, sobre todo, he tenido la suerte de aprender de profesionales brillantes en el camino.
Hoy quiero detenerme a escribir sobre lo que considero una de las causas de fallo más comunes en los productos digitales. Mi intención es que estas reflexiones ayuden a líderes y empresas a planificar y ejecutar sus proyectos con más puntería.
A menudo veo una obsesión excesiva con el cómo de un proyecto. Es fácil entender por qué: uno se encariña con sus ideas y quiere que el resultado sea perfecto bajo su propio criterio. Yo mismo he caído en esa trampa más veces de las que me gustaría admitir. Todo empieza con una frase tipo: "Necesito un nuevo CRM que haga esto y aquello". Aunque ese entusiasmo es necesario, los proyectos que realmente triunfan son los que nacen de un objetivo de negocio y no de una simple lista de funcionalidades. De hecho, lo más normal es que esa lista de funciones cambie durante la ejecución para adaptarse a las metas reales de la empresa. Para eso inventamos el desarrollo ágil, aunque este artículo no va de eso.
Cuando un proyecto empieza a atascarse, rara vez es por falta de capacidad técnica. Generalmente, es un síntoma de un proceso mal planteado: la herramienta empieza a dictar la estrategia, cuando debería ser al revés. Esto suele inflar la complejidad de la solución, disparar el alcance de forma descontrolada (scope creep) y hacernos perder tiempo en detalles innecesarios que solo encarecen el proceso sin mejorar el resultado.
Para evitarlo, propongo un cambio de enfoque: la tecnología no es la solución, es el vehículo para llegar a un resultado de negocio concreto.
Conocí el concepto del "Doble Diamante" durante mi posgrado y me impactó lo sencillo y potente que es. Con los años, aplicarlo se ha vuelto fundamental en mi forma de trabajar. Si sientes que tus proyectos sufren los problemas que mencioné antes, te recomiendo probarlo.
Pensemos en el ciclo de vida de un proyecto en dos etapas clave:
La segunda fase es vital, pero si te enfocas solo en ella, corres el riesgo de fabricar el martillo más sofisticado del mundo cuando lo que el negocio te pedía a gritos era un destornillador.
En el primer diamante, el objetivo es distinguir claramente entre un Requerimiento de Negocio y una Funcionalidad de Software. Aquí es donde se marcan las distancias. El requerimiento es la necesidad real: "Necesitamos que el equipo de ventas pierda menos tiempo en tareas administrativas para que pueda estar más tiempo con los clientes". La funcionalidad es solo la respuesta técnica: "La app debe poder sincronizarse sin conexión".
Si saltamos directo a la funcionalidad, perdemos el norte. Documentar el "porqué" antes que nada te da una "Estrella Polar"; un punto de referencia que mantiene al equipo enfocado cuando aparecen distracciones o propuestas que no aportan al objetivo final.
Entre estos dos diamantes hay un paso crucial: el Análisis de Brechas (Gap Analysis). Aunque suene muy teórico, es simplemente una pausa necesaria. Antes de picar código, medimos la distancia entre la realidad actual de la empresa y ese "porqué" que definimos. A veces, la conclusión es que no hace falta una plataforma faraónica; quizás solo hay que arreglar una integración que no funciona. Esta pausa ahorra presupuestos, tiempo y muchos dolores de cabeza.
En el segundo diamante (Construir la cosa correctamente) es donde entra el oficio técnico, y donde solemos invertir más energía. Pero ojo: la excelencia técnica no es suficiente por sí sola. Un software puede ser veloz y no tener ni un solo error, pero si para el usuario final es un laberinto confuso, el proyecto ha fracasado en su objetivo de negocio. Esta fase debe ser un equilibrio perfecto entre solidez técnica y usabilidad.
Gestionar estas dos fases no es fácil desde adentro. Cuando estás inmerso en la operación diaria, es casi imposible ver tus propios puntos ciegos. Por eso, a veces buscar apoyo externo no es un gasto, sino una inversión para asegurar que el producto final aporte valor real al usuario y a la organización, en lugar de ser un gasto más en la cuenta de resultados.
Tras años de experiencia, mi conclusión es simple: la tecnología está para servir al negocio, nunca al revés. Si vemos el software como el medio y no como el fin, el camino al éxito se vuelve mucho más claro para todos.
.svg)