Hay una frase que me persigue desde mi segundo año shipeando: "está en producción". Dicho por mí. Dicho por gerentes. Dicho por CTOs. Dicho, casi siempre, antes de tiempo.
Esta es una reflexión sobre qué significa que un feature "esté en producción", por qué nos mentimos, y qué hago distinto ahora.
La mentira del deploy
Deploy es un evento. "Done" es un estado. Los dos no tienen por qué coincidir — y casi nunca coinciden.
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
Porque deploy se siente como terminar. El PR se mergea, CI pasa, el staging muere, producción respira. Hay dopamina en ese momento.
Pero la organización casi nunca está calibrada para celebrar (5). Celebra (3). El incentivo está mal puesto.
Mi ejemplo favorito: deployé un agente de qualification de leads que, en backtests, convertía al 34%. La métrica humana era 9%. Celebré. Di la charla. Mandé el screenshot al 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.
Eso no lo pude prever. Lo tenía que medir.
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 cuentan por measured. No por 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".
Esto elimina la ambigüedad. El feature no "se queda porque sí" — se queda porque pasó una prueba definida.
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)
Nadie los cuenta. No aparecen en ningún dashboard. Pero están ahí, devorando.
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.
Reflexión
"Ship" es fácil. "Done" es una disciplina. El mundo recompensa el primero y se olvida del segundo, y por eso los productos tienen tanta grasa acumulada.
Mi heurística actual: un feature sólo existe cuando el equipo puede operarlo dormido y los datos cuentan una historia clara. Antes de eso, es una apuesta en producción.
Las apuestas están bien. Pero llamémoslas así.