Luis Gómez CabezasDivulgación desde la dirección: PropTech, transformación digital e IA aplicada.

Reflexiones

Lo más importante que aprendí, después de veinte años

·6 min de lectura

Hace muchos años participé en el desarrollo de una plataforma de BPM sobre Bizagi. Sobre el papel era una idea excelente: unía la parte técnica con el desarrollo del negocio, estandarizaba el proceso, ponía orden donde antes había excepciones sueltas y hojas de Excel heredadas de otro departamento. Todo el mundo en la sala estaba de acuerdo en que tenía sentido.

La realidad fue otra. La variabilidad del negocio y la redefinición constante del modelo operativo hicieron inviable la solución técnica tal y como la habíamos planteado. Daba la sensación de que siempre llegábamos tarde: entregábamos algo, y para cuando estaba listo, el negocio ya necesitaba otra cosa.

La tesis

Un proyecto tiene sentido mientras el retorno lo siga justificando. No mientras dure la inercia de haberlo empezado, ni mientras cueste demasiado admitir que ya no cubre lo que se necesita. Es de los principios más simples de PRINCE2, continued business justification, y de los que más tarde se aprenden de verdad, porque va contra un instinto muy humano: es natural querer acabar, y muy doloroso renunciar a cientos de horas de trabajo ya invertidas.

Dónde se rompió, exactamente

El momento de quiebre no fue una cifra que dejara de cuadrar de golpe, ni una bronca en un comité. Fue algo más incómodo: se basaba en la redefinición previa a la puesta en producción. Creábamos un proceso, y durante la propia validación de ese proceso ya se estaba diseñando en paralelo una nueva versión. El negocio, antes incluso de que lo que construíamos llegara a producción, ya pensaba que aquello no cubría lo que realmente necesitaba.

No es que el proyecto fuera malo. Es que perseguía un objetivo que se movía más rápido que la capacidad de construcción. Cada entrega llegaba correcta y, al mismo tiempo, tarde, porque el "correcta" se había definido semanas antes, y el negocio ya vivía en otra versión de la realidad.

Por qué es tan fácil no verlo

Hay una razón estructural por la que este patrón cuesta tanto detectar desde dentro: el sesgo de coste hundido no se siente como sesgo, se siente como responsabilidad. Parar un proyecto en el que ya se han invertido ocho meses y un presupuesto significativo no se experimenta como "aplicar un principio de gestión", se experimenta como fracasar, como reconocer que el equipo se equivocó, como dar explicaciones incómodas dos niveles por encima. Es mucho más cómodo seguir construyendo la siguiente entrega que parar y preguntar si el proyecto entero sigue teniendo sentido.

Y hay una segunda razón, más sutil: el diagnóstico técnico siempre parece más resoluble que el diagnóstico de fondo. Si el proceso "llega tarde", la respuesta instintiva es acelerar el desarrollo, meter más gente, ajustar el sprint. La pregunta que de verdad hacía falta, ¿tiene sentido seguir estandarizando un proceso que el propio negocio no ha terminado de decidir?, casi nunca se hacía en voz alta.

Cómo lo aplico ahora

Traté de resolverlo desde dos sitios distintos.

El primero: entender que en la solución deben estar representados todos los stakeholders y sus principales necesidades operativas desde el diseño, no como validación posterior. Y aceptar algo que en su momento me costó: si se cubre el 80% de esas necesidades, es un éxito. Perseguir el 100% es precisamente lo que alarga el ciclo de validación lo suficiente como para que el negocio cambie de opinión antes de que termines.

El segundo: pensar en modelos iterativos de MVP que permitan crear versiones rápidas y mejoras funcionales más adaptativas. En vez de un proceso monolítico validado una sola vez, entregas pequeñas que el negocio puede corregir en semanas, no en meses. El objetivo deja de ser "acertar a la primera" y pasa a ser "equivocarse barato y rápido".

Hoy, cuando reviso un proyecto de este tipo, la pregunta que hago y que antes no hacía es simple: si el negocio redefine esto dentro de seis meses, ¿lo que estamos construyendo ahora sigue teniendo valor, o lo tiramos entero? Si la respuesta es "lo tiramos entero", el problema no es de ejecución. Es de diseño del propio proyecto.

Donde el MVP no vale

Esto tiene un límite, y es importante decirlo porque "haz MVPs y ya está" es una respuesta demasiado fácil. Hay una excepción clara: los proyectos de integración entre múltiples sistemas, donde si no hay una sincronía pura de la información en la puesta en marcha, un MVP parcial puede llevar al caos operativo. No es lo mismo iterar sobre un proceso de negocio interno que iterar sobre una integración bancaria o una migración de datos entre sistemas críticos. Ahí, entregar el 80% no es un éxito parcial, es un sistema a medio sincronizar, y eso puede ser peor que no haber empezado.

La diferencia está en la reversibilidad. Un proceso operativo mal ajustado se corrige en la siguiente iteración sin que nadie se entere fuera del equipo. Una integración mal sincronizada genera datos inconsistentes que después hay que reconciliar a mano, muchas veces durante meses. El criterio no es "MVP siempre" ni "todo cerrado desde el principio". Es entender qué tipo de proyecto tienes delante antes de elegir cómo vas a construirlo.

La objeción que me tomo en serio

Un sponsor o un CFO diría algo así: llevas ocho meses y tres versiones del business case, y en algún momento el coste de seguir "validando si el ROI sigue vivo" es mayor que el de comprometerse y ejecutar. Ningún proyecto complejo sobrevive a una reevaluación constante, todos atraviesan un valle donde la inversión ya está hecha y el retorno aún no ha llegado, y si aplicas la justificación continua de forma literal, nunca vas a terminar nada ambicioso.

Es una objeción legítima. El principio de continued business justification se puede convertir en una excusa para la indecisión, parar por miedo, no por criterio, y disfrazarlo de disciplina de gestión.

La respuesta no es reevaluar el ROI cada mes de forma paranoica. Es tener puntos de control explícitos y pactados de antemano, no vigilancia constante, sino un check en momentos predefinidos donde de verdad se pregunta si esto sigue teniendo sentido con lo que sabemos ahora. Eso es lo que separa la disciplina de PRINCE2 de la simple falta de aguante para terminar algo difícil.

Para el lunes

La próxima vez que revises un proyecto que lleva tiempo en marcha, no preguntes cuánto queda para acabarlo. Pregunta si, sabiendo lo que sabes hoy, lo empezarías. Si la respuesta es no, el problema no es de ejecución, es que el proyecto dejó de tener el sentido con el que nació, y nadie se ha atrevido a decirlo en voz alta todavía.

También te puede interesar

← Volver al blog