← Diario

Recuperar un programa digital a la deriva

Seis decisiones para recuperar una trayectoria entregable sin añadir otra capa de gobernanza.

EntregaArquitecturaSector público

El problema casi nunca es la falta de informes

Un programa a la deriva suele producir mucha información y pocas decisiones. Existen cuadros de mando y reuniones, pero nadie puede vincular una prioridad con un responsable, una fecha y una prueba de entrega. La organización ve la actividad. Ya no ve la trayectoria.

El primer impulso suele ser añadir control. Un comité adicional pide nuevos indicadores, que requieren herramientas y tiempo de preparación. La gobernanza describe el pasado con mayor precisión, pero no aclara la siguiente elección. Recuperar el programa exige el movimiento contrario: reducir las variables hasta obtener una cadena de decisión corta y operable.

Empezar por una verdad operativa

Antes de hablar de arquitectura o metodología, hay que nombrar el resultado que el servicio debe producir en noventa días. No es una fase terminada ni un porcentaje de avance. Es un resultado observable por una persona usuaria, un agente o un equipo de operaciones.

Esa formulación separa el trabajo en tres grupos:

  1. lo que contribuye directamente al resultado;
  2. lo que protege una restricción real, como la seguridad o la continuidad;
  3. lo que existe porque el programa se ha acostumbrado a producirlo.

El tercer grupo no siempre es inútil. Simplemente debe volver a ser una elección deliberada en lugar de una obligación que nadie cuestiona.

Cartografiar solo las dependencias que pueden bloquear

Un mapa útil no busca ser exhaustivo. Muestra las dependencias capaces de detener la entrega: una decisión jurídica, un dato ausente, un entorno imposible de reproducir, una interfaz controlada por un tercero o un rol sin persona responsable.

Cada dependencia necesita propietario, fecha de decisión y alternativa. Si falta uno de esos elementos, la dependencia no está gestionada. Solo está identificada.

El ejercicio debe admitir el desacuerdo. Producto, tecnología, negocio y operaciones perciben riesgos diferentes. Esa diferencia es información valiosa cuando se convierte en hipótesis verificables y no en una negociación política permanente.

Sustituir el avance declarado por pruebas

Un lote anunciado al 80 % puede seguir bloqueado durante seis meses. Una prueba binaria resulta menos cómoda, pero es más útil: el recorrido funciona en un entorno representativo, los datos se reconcilian, se ha ejecutado la vuelta atrás o el equipo receptor puede operar el servicio.

La prueba debe ser proporcionada. Una recuperación no exige industrializarlo todo de inmediato. Necesita un primer recorrido completo lo bastante real para revelar interfaces, responsabilidades y costes ocultos por la estructura del programa.

Seis decisiones que cambian la trayectoria

  1. Nombrar el resultado operativo esperado en noventa días.
  2. Cartografiar únicamente las dependencias que pueden bloquearlo.
  3. Asignar una persona responsable a cada decisión difícil de revertir.
  4. Sustituir porcentajes por pruebas ejecutables.
  5. Aislar un primer recorrido completo, desde la entrada hasta la operación.
  6. Registrar los arbitrajes rechazados con la misma claridad que los aceptados.

Estas decisiones crean un lenguaje común. También muestran si el programa carece de capacidad, autoridad o claridad. Los tres problemas pueden parecer iguales en un cuadro de mando, pero requieren respuestas distintas.

Dejar una organización más autónoma

Una intervención breve no debe crear una nueva dependencia del consultor. Debe dejar un registro de decisiones legible, una arquitectura explicada por sus restricciones, una trayectoria a treinta, sesenta y noventa días y un equipo capaz de continuar.

El éxito no consiste en que un indicador vuelva al verde. Llega cuando las personas implicadas pueden explicar la siguiente decisión, la prueba que permitirá tomarla y qué ocurrirá si la hipótesis resulta falsa.