«Está hecho» no significa «está terminado». En muchos proyectos el go-live se aprueba por inercia: IT despliega, el negocio asume que ya está, y el proyecto queda oficialmente «cerrado». Dos semanas después aparecen los síntomas: nadie sabe cómo operarlo, los usuarios tienen que inventarse atajos, y cuando falla algo un viernes por la tarde no está claro quién actúa ni qué hacer.
El problema no es que el equipo IT lo haga mal. Es que «terminado» suele definirse con criterios técnicos (código desplegado, pruebas pasadas), pero no con criterios de negocio y operación (que alguien pueda usarlo, medirlo y sostenerlo sin depender del que lo hizo). Por eso, ¿Está terminado… o sólo está desplegado?
Si eres responsable de negocio o dirección, hay una pregunta que conviene hacerse antes de aceptar cualquier proyecto:
- ¿Qué evidencia tengo de que esto funcionará en operación real, y de que aporta el valor prometido?
¿Está terminado… o sólo está desplegado?
Hay cinco fallos que se repiten de una manera casi aburrida. Y lo importante es esto: cuando aparece uno, normalmente no es un «detalle a pulir», sino una señal temprana de riesgo operativo.
El primero es la dependencia del «héroe». El proyecto aparentemente funciona, pero en la práctica solo una persona sabe realmente cómo está montado. Los cambios pequeños requieren preguntarle a esa persona, nadie se atreve a tocar nada sin su supervisión y, en cuanto no está disponible, el sistema se convierte en terreno prohibido. El impacto no es solo incomodidad; es tiempo de resolución alto, cambios cada vez más caros y una fragilidad estructural que se paga en el peor momento.
El segundo fallo es la ausencia de una guía real de operación. Puede que exista documentación, pero no sirve para el día a día: no explica cómo se opera en condiciones normales, qué límites tiene, qué hacer cuando algo se degrada ni cómo volver atrás con seguridad si el despliegue sale mal. Cuando llega una incidencia, cada intervención se improvisa, y eso multiplica el riesgo y el tiempo hasta recuperar el servicio.
El tercero es la falta de monitorización útil, la que te avisa antes de que te llame un usuario. A veces no hay alertas; otras veces hay dashboards «bonitos» que nadie consulta. Y muy a menudo se miden recursos (CPU, RAM) pero no el servicio extremo a extremo: errores reales, latencias, fallos de integración, colas acumulándose o procesos batch que no terminan. El resultado es que los fallos se vuelven silenciosos, la degradación se descubre tarde y la confianza del negocio cae rápido.
El cuarto problema es que el valor prometido nunca queda aterrizado en métricas de negocio. Se habla de «eficiencia» o «mejora del proceso», pero no se define un KPI, ni un baseline previo, ni un objetivo, ni un responsable que lo revise. Así, semanas o meses después, nadie puede responder con datos si el proyecto ha merecido la inversión, y cualquier debate sobre prioridades futuras se convierte en opinión contra opinión.
El quinto, y quizá el más frecuente, es la aceptación implícita: se da por aprobado porque «nadie dijo que no». No se hace una validación formal con usuarios clave ejecutando flujos críticos en condiciones reales, no se establecen criterios de «no-go» y no queda un OK explícito con nombre, rol y fecha. Cuando llegan fricciones, aparece el clásico «yo nunca aprobé esto», y el proyecto entra en una fase de desgaste que era totalmente evitable.
Si en tu próximo go-live no puedes responder con claridad quién operará, cómo se detectarán problemas, cómo se medirá el valor y quién ha aceptado formalmente el resultado, lo más probable es que todavía no esté terminado para negocio, aunque esté «hecho» para IT.
Definition of Done ejecutiva (no técnica)
No necesitas microgestionar a IT. Necesitas un estándar ejecutivo que defina cuándo algo está listo para negocio. Este es un checklist de evidencias, no de intenciones.
Operabilidad sin el autor
- Runbook de 1–3 páginas con: objetivo, dependencias, operación normal, límites, backups, rollback.
- Troubleshooting: top 5 incidencias esperables con diagnóstico y acciones.
- Prueba de handover: alguien no autor ejecuta un caso real siguiendo el runbook.
- Evidencia mínima: enlace + nombre del operador + registro de la prueba.
Monitorización end-to-end (salud real)
- Alertas sobre:
- disponibilidad del servicio
- errores (4xx/5xx o equivalentes)
- latencia
- integraciones (colas, reintentos, timeouts)
- jobs nocturnos / procesos batch
- Umbrales y escalado definidos (quién recibe, por dónde, en cuánto tiempo).
- Evidencia mínima: dashboard + alerta de prueba disparada.
Métricas de negocio (valor)
- 1–3 KPIs máximos, con baseline y objetivo:
- ahorro de tiempo (minutos por caso)
- tasa de conversión/aceptación
- reducción de errores/retrabajo
- tiempo de ciclo (lead time) del proceso
- Owner del KPI y cadencia de revisión.
- Evidencia mínima: ficha KPI + reporte.
Responsabilidad operativa (RACI) y escalado
- RACI operativo claro:
- quién opera
- quién decide cambios
- quién aprueba
- quién es «on-call»
- Árbol de escalado con tiempos (N minutos → escalar).
- Evidencia mínima: RACI + esquema de escalado.
Validación de negocio y aceptación explícita
- Sesión de validación con usuario clave ejecutando flujos críticos.
- Lista de «no-go» (lo que impide producción).
- Aceptación formal (acta/ticket/correo) con nombre, rol y fecha.
- Evidencia mínima: acta + casos probados + OK formal.
KPIs sugeridos según tipo de proyecto (para no quedarse en abstracto)
Antes de definir KPIs, conviene resolver una confusión muy habitual: no se mide igual un proceso operativo que una app de usuario, una integración técnica o un entorno de reporting. Cada tipo de iniciativa crea valor de una forma distinta y, por tanto, necesita métricas que reflejen ese valor sin ruido. Si eliges KPIs «genéricos», acabarás con dashboards bonitos pero inútiles: indicadores que no explican impacto, no permiten priorizar y no te alertan cuando el proyecto se degrada en producción.
Para facilitarlo, aquí tienes una selección de métricas recomendadas por tipo de proyecto. Son KPIs suficientemente universales como para funcionar en la mayoría de casos, pero lo bastante accionables como para que puedas exigir baseline, objetivo y responsable desde el primer día.
Si estás arrancando, quédate con tres: uno de velocidad (tiempo), uno de calidad (errores/retrabajo) y uno de fiabilidad/adopción (uso o cumplimiento).
Si es un proceso (RRHH, finanzas, compras)
- Tiempo de ciclo del proceso (inicio → fin)
- % de casos con retrabajo
- % de cumplimiento de SLA interno
Si es un portal / app de usuario
- Tasa de éxito de tarea (task completion rate)
- Tiempo medio para completar la tarea
- Incidencias por 100 usuarios / semana
Si es una integración (entre sistemas)
- % de mensajes procesados sin error
- Retrasos/latencia en cola
- Retries por transacción
## Si es un reporting / BI
- Adopción: % de usuarios activos/semana
- Tiempo para obtener insight (antes vs después)
- Calidad de dato: % de informes con reconciliación OK
Kit de preguntas que cierran el «autoengaño» (úsalas en comité)
Si te contestan con opiniones («sí, está controlado»), devuelve la pregunta pidiendo evidencia:
- ¿Quién opera esto si el autor está de vacaciones?
- ¿Dónde está el runbook y cuándo lo ha usado alguien que no sea el autor?
- ¿Qué alerta me avisará antes de que el usuario se queje?
- ¿Cuáles son los 3 KPIs de negocio y cuál era el baseline antes del cambio?
- ¿Cuál es el rollback y cuánto tardamos en volver a estado anterior?
- ¿Qué es «no-go» y quién lo decide?
Si no hay respuestas concretas (nombres, enlaces, umbrales, métricas), el proyecto no está terminado para negocio.
Plantilla de Acta de Go-Live (1 página, lista para copiar)
Este es un Acta de Go-Live de una página pensada para cerrar un proyecto con rigor y sin burocracia. Su objetivo es simple: que el «OK para producción» quede respaldado por evidencia y responsabilidades claras, evitando la típica situación en la que el sistema está desplegado pero nadie sabe quién lo opera, cómo se detectan fallos, cómo se mide el valor o quién lo aprobó realmente.
Rellénala en la reunión de validación final (idealmente con negocio e IT presentes) y no la trates como un documento administrativo: úsala como checklist de decisión. Si algún campo crítico no se puede completar con nombres, enlaces o métricas, la señal suele ser clara: el proyecto puede estar «hecho» técnicamente, pero todavía no está «terminado» para negocio.
- Proyecto:
- Objetivo de negocio (1 frase):
- Fecha go-live:
- Owner negocio:
- Owner IT:
- Operación:
- Runbook: (enlace)
- Operador responsable: (nombre)
- Rollback: (pasos + tiempo estimado)
- Monitorización:
- Dashboard: (enlace)
- Alertas clave: (lista)
- Canal/escalado: (equipo/canal/tiempos)
- KPIs de negocio: (revisión semanal/quincenal)
- KPI 1: baseline → objetivo
- KPI 2: baseline → objetivo
- KPI 3: baseline → objetivo
- Validación negocio:
- Casos críticos ejecutados: (lista)
- Incidencias abiertas: (lista + decisión)
- Criterios «no-go»: (lista)
- Aprobación:
- Negocio: Nombre + OK + fecha
- IT: Nombre + OK + fecha
Esta hoja te puede servir como «red de seguridad» para tomar decisiones sin entrar en el detalle técnico. No necesitas saber de sistemas; necesitas evitar que la empresa dependa de la memoria de una persona, que el valor del proyecto quede sin medir y que el riesgo operativo se descubra cuando ya es tarde.
Te propongo una dinámica simple: en tu próximo comité de seguimiento, pide que te devuelvan esta acta completada y toma una decisión binaria: o hay evidencia y responsables, o no hay go-live. Con eso, elevas el estándar de ejecución sin añadir burocracia: solo cambias el criterio de aprobación.
Y para cerrar te lanzo esta pregunta:
¿Y si el cliente te dice, 5 meses después del go-live que no está de acuerdo con la entrega y que no te paga?- Operación:
