Desde mi segundo año shipeando escucho la misma frase: "está en producción". La dije yo, la dijeron gerentes y la dijeron CTOs antes de reunir datos suficientes.
Un feature puede estar desplegado y seguir sin demostrar que funciona. Estas son las señales que uso para decidir si terminó.
Deploy no equivale a done
Deploy ocurre en un momento. Done describe un estado operativo. El segundo necesita más evidencia.
Un feature recién deployado está en uno de estos estados posibles:
- Shadow: deployado pero detrás de un flag, nadie lo ve.
- Beta: 1-5% del tráfico, métricas en vivo.
- GA: 100% del tráfico.
- Habituado: usuarios ya dependen de él, el equipo sabe cómo operarlo.
- Medido: tenés datos de un mes completo sobre si mueve la aguja.
Por qué nos mentimos
Cuando el equipo hace deploy, siente un cierre: el PR se mergea, CI pasa, staging termina y producción recibe el cambio. El equipo celebra ese momento.
La organización suele celebrar el estado 3 y dejar sin dueño el estado 5. Ese incentivo corta la observación.
En un agente de qualification de leads, los backtests mostraban 34% de conversión frente a una métrica humana de 9%. Celebré el resultado, di una charla y compartí el screenshot en Slack.
Tres semanas después, la métrica real en producción era 17%. La mitad de lo que el backtest decía. ¿Mentía el backtest? No. El backtest no tenía la misma distribución de leads que producción, porque en producción los comerciales empezaron a filtrar antes los leads fáciles y le daban al agente solo los difíciles.
No detecté ese cambio de distribución en el backtest. La medición en producción sí lo mostró.
Cómo cambió mi workflow
1. "Ship" se separa de "done" en la tracking tool
No uso más un solo estado "done". Uso:
shipped— en producción, detrás de un flag si hace faltameasured— con un mes de datos limpiosretired— feature vieja que ya removí
Los tickets no se cierran hasta measured. Los dashboards se arman sobre esa columna, no sobre shipped.
2. El runbook es entregable, no documentación
Antes escribía runbooks después de incidentes. Ahora los escribo antes del deploy. Si no puedo escribir "cómo operar este feature", el feature no está listo.
El runbook mínimo viable:
## Feature: [nombre] ### Métrica de éxito - Cuál es la aguja que debería mover - Cuánto tiempo hasta señal estadística - Cuál es el umbral de rollback ### Modos de falla conocidos - Qué puede pasar - Cómo se detecta en logs/metrics - Cómo se mitiga ### Kill switch - Cómo apagarlo, quién puede apagarlo - Tiempo de propagación del apagado
3. Ventanas de observación explícitas
En cada feature nuevo, defino antes del deploy una ventana de observación. Ej: "mido 2 semanas, si la métrica X se mueve < Y%, rollback".
Defino el criterio de salida en esa ventana. Mantengo el feature si supera la prueba.
El costo escondido
Los features que shippearon pero nunca se midieron siguen cobrando:
- Espacio cognitivo en el equipo
- Superficie de bugs
- Complejidad en onboarding de nueva gente
- Coste de infra
- Costo de oportunidad (tiempo no dedicado a otra cosa)
El equipo sigue pagando esos costos aunque ningún dashboard los muestre.
Yo ahora cada trimestre hago un ejercicio: listo todos los features shipped del último año que no son measured. Y decido: ¿medirlo ahora, o retirarlo?
La mayoría los retiro.
Criterio actual
"Ship" requiere un deploy. "Done" requiere operación y datos. Si el equipo no puede mantener el feature y leer su resultado, el trabajo sigue abierto.
Mi criterio actual: un feature termina cuando el equipo puede operarlo y los datos muestran qué cambió. Antes de eso, es una apuesta en producción.