Cada proyecto que entregamos deja algo más que un sistema funcionando: deja un patrón. Hace poco nos sentamos a revisar decenas de proyectos —manufactura, hospitalidad, construcción, agencias de viajes, plataformas internas— buscando una respuesta a una sola pregunta: ¿qué se repite antes de que un proyecto tecnológico funcione, y qué se repite antes de que se atrase o se complique?

No eran casos elegidos para lucir bien. Eran proyectos reales, con clientes reales, con decisiones que tomamos bajo presión y con cosas que, en retrospectiva, haríamos distinto. Esto es lo que encontramos.

1. El problema casi nunca es 100% tecnológico.

En más de un proyecto, lo que el cliente describía como "necesitamos un sistema" era, en el fondo, un proceso que nunca se había definido con claridad. Vimos empresas con hojas de cálculo compartidas que "generaban falta de integridad en la información", instrucciones que se daban por llamada o mensaje y quedaban "en el aire", y reportes que tomaban horas armar manualmente porque nadie había estandarizado cómo se debían generar.

La tecnología resuelve la ejecución. Pero si el proceso de fondo está mal diseñado, un sistema nuevo solo automatiza el desorden más rápido. Por eso la primera pregunta que hacemos nunca es "¿qué quieres que construyamos?", sino "¿cómo funciona esto hoy, aunque sea mal?".

2. La comunicación falla antes que la tecnología.

Uno de los casos más claros: una empresa de manufactura perdía fechas de entrega no por falta de capacidad técnica, sino porque los correos "se traspapelaban" y las instrucciones importantes se diluían entre llamadas, mensajes y hojas de cálculo que nadie actualizaba a tiempo.

El patrón se repite en distintas industrias con distintos nombres: falta de visibilidad en tiempo real, duplicidad de información, dependencia del conocimiento de una sola persona. Antes de proponer una solución técnica, hay que entender dónde se rompe la comunicación entre las personas y los sistemas que ya existen.

3. La confianza se construye con cumplimiento, no con funcionalidades.

Cuando le preguntamos a nuestros propios clientes qué generó confianza en nosotros, casi nadie mencionó una característica del software. Las respuestas se repitieron con distintas palabras: comunicación constante, apego a los estándares del cliente, disposición para entender el negocio, atención rápida, documentación de los procesos, cumplimiento de compromisos.

Ningún cliente eligió seguir trabajando con nosotros por un botón bien diseñado. Eligieron seguir porque hicimos lo que dijimos que haríamos, cuando dijimos que lo haríamos.

4. Los workshops de discovery ahorran más de lo que cuestan.

En los proyectos donde invertimos tiempo real en sesiones de descubrimiento —entender la operación antes de tocar una línea de código— la fase de desarrollo fue más fluida y con menos retrabajo. En los proyectos donde el discovery fue superficial, los ajustes llegaron después, ya en producción, que es el momento más caro para corregir un mal supuesto.

Uno de nuestros propios equipos lo resumió así en la retrospectiva de un proyecto interno: "fortaleceríamos aún más la fase inicial de discovery técnico y funcional, dedicando más tiempo a la definición de casos de uso y escenarios límite, para reducir ajustes durante el desarrollo." Es una autocrítica que hemos escuchado más de una vez, y que hemos ido corrigiendo proyecto tras proyecto.

5. Documentar no es burocracia, es velocidad.

En los proyectos de largo plazo —sobre todo en staff augmentation con equipos que rotan o crecen— documentar procesos, estándares y decisiones en herramientas como Confluence resultó ser una de las prácticas que más se repitió como "esto lo volveríamos a hacer". No por disciplina, sino porque acelera el onboarding de gente nueva y evita que el conocimiento crítico viva solo en la cabeza de una persona.

6. Comprar antes de agotar lo que ya se tiene es un error común.

En más de un caso, la solución final terminó siendo más simple de lo que se pensó al principio, porque parte del problema ya se podía resolver con lo que el cliente tenía internamente. Adquirir una herramienta externa sin evaluar primero las capacidades de los sistemas actuales llevó, en al menos un proyecto, a invertir tiempo y presupuesto en una integración que pudo evitarse.

La lección que nos llevamos: antes de proponer algo nuevo, hay que agotar primero lo que ya existe.

7. La prioridad la define el impacto de negocio, no el volumen de quejas.

Cuando un cliente llega con una lista larga de problemas, la tentación es atacar lo que suena más urgente o lo que más se repite en las conversaciones. Pero en los proyectos con mejores resultados, la priorización se hizo con otra pregunta: ¿qué problema, resuelto primero, desbloquea todo lo demás? En un caso fue un reporte específico que condicionaba la operación completa de un área. En otro, fue la estabilidad y seguridad del sistema antes que cualquier funcionalidad nueva.

Resolver por volumen de quejas da la sensación de avance. Resolver por impacto real es lo que efectivamente lo genera.

Lo que esto significa para cualquier empresa que esté evaluando un proyecto tecnológico.

Ningún proyecto tecnológico exitoso empezó con la pregunta correcta sobre tecnología. Empezó con la pregunta correcta sobre la operación: qué se hace hoy, por qué se hace así, y qué pasa si nada cambia.

Si estás evaluando digitalizar un proceso, automatizar una tarea o desarrollar un sistema a medida, este es el filtro que nosotros aplicamos primero, antes de hablar de una sola tecnología:

• ¿El problema es del proceso o de la herramienta?
• ¿Dónde se está perdiendo información o comunicación hoy?
• ¿Qué parte de esto ya se puede resolver con lo que ya tienes?
• ¿Cuál es el problema que, resuelto primero, desbloquea los demás?

Preguntas frecuentes.

¿Estos aprendizajes aplican solo a proyectos grandes? No. Los patrones se repitieron tanto en proyectos de pymes de 11 a 50 empleados como en compañías de más de 200. El tamaño cambia la escala del problema, no la naturaleza del error.

¿Por qué comparten esto públicamente en lugar de guardarlo como ventaja interna? Porque la mayoría de estos aprendizajes no dependen de una tecnología específica ni de un secreto de método: dependen de hacer las preguntas correctas antes de construir. Compartirlos no le quita valor a lo que hacemos, lo confirma.

¿Cómo aplican esto en un proyecto nuevo? Empezamos siempre con una sesión Discovery, que es justamente donde se identifican la mayoría de estos patrones antes de que se conviertan en un problema costoso.

‍

‍