Tomando prestados los niveles de preparación tecnológica para equipos que no construyen naves espaciales

La idea central

Una escala de preparación es útil no porque mida la madurez con precisión, sino porque obliga a dos personas en desacuerdo a señalar el mismo peldaño y explicar qué evidencia falta.

Los niveles de preparación tecnológica fueron concebidos para adquisición de hardware, donde la diferencia entre un componente probado en laboratorio y otro usado en misión es cuestión de física y costo. Los equipos de software suelen descartar la escala como burocrática, y para su forma original de nueve niveles aplicada literalmente, ese rechazo es justo. Lo que sobrevive en la traducción es el movimiento subyacente: definir la madurez por el ambiente en que algo se ha demostrado, no por qué tan acabado se siente.

Qué cambió y por qué importa ahora

El argumento recurrente en la mayoría de las organizaciones de producto es alguna versión de si esto está listo. Es irresoluble tal como se plantea, porque los participantes usan cada uno una definición privada: el ingeniero entiende que el código funciona, el responsable de operaciones que puede ser soportado a las tres de la mañana, el responsable comercial que puede venderse sin salvedades. Los tres tienen razón y no están discutiendo sobre la misma propiedad. Los equipos que adoptan una escala explícita no dejan de discrepar; empiezan a discrepar sobre qué nivel se ha demostrado, que es una cuestión que la evidencia puede resolver. El cambio es visible en cómo cambian las estimaciones. Antes de una escala, un equipo preguntado sobre cuándo algo estará listo produce una fecha; después de una, el mismo equipo produce un nivel y una lista de lo que falta para alcanzar el siguiente. La fecha suele ser menos optimista y considerablemente más precisa, porque se construye a partir de brechas nombradas en lugar de una sensación general de progreso, y puede ser cuestionada en detalle por alguien que no estuvo presente cuando se hizo. La escala también es útil en la dirección contraria, como una forma honesta de rechazar trabajo. Una solicitud para enviar algo el mes que viene puede ser respondida con el nivel que ocupa actualmente y la evidencia aún pendiente, lo cual es una respuesta más productiva que un no y más defendible que un sí.

Construir el modelo operativo

Reducir los nueve niveles a cinco, definir cada uno por el ambiente donde ha sido probado y la evidencia que lo prueba, y exigir nombrar la evidencia antes de reclamar el nivel.

Una versión práctica de cinco peldaños: uno, funciona en máquina de desarrollador con entradas seleccionadas; dos, funciona en infraestructura compartida con datos históricos reales; tres, ha servido a usuarios reales en una porción limitada con posibilidad de reversión; cuatro, ha soportado carga de producción representativa incluyendo un pico, con alertas y responsable; cinco, ha completado un ciclo comercial completo incluyendo casos extremos estacionales y una transferencia de personal. El último peldaño es el que los equipos suelen saltarse y el que diferencia un sistema que funciona de uno que la organización puede operar.

Medir qué produjo la decisión

Registrar el nivel declarado frente a la evidencia documentada, el tiempo en cada peldaño y cuán a menudo se promueve algo sin la evidencia requerida.

El tiempo en peldaño es la medida reveladora. Un componente que se queda en el peldaño dos durante ocho meses no está madurando; está estacionado, y la escala lo hace visible de modo que una columna de estado no lo hace. Las promociones sin evidencia son el dato más importante, porque indican cómo la escala pasa de ser un control a convertirse en una etiqueta: una vez que dos o tres cosas se han declarado peldaño cuatro por afirmación, la escala deja de ser un control y se vuelve una etiqueta.

Dónde falla la ejecución

El riesgo principal es que la escala se convierta en una capa de reporte — cada proyecto se auto-informa un nivel, nadie documenta la evidencia y los números suben según lo que la hoja de ruta necesita.

El segundo riesgo es aplicarla a trabajos donde no encaja. Una escala de este tipo asume algo que puede demostrarse en ambientes progresivamente más exigentes. Funciona para un modelo, un servicio, una integración. Funciona mal para dirección de diseño, cambio organizacional o cualquier cosa cuyo éxito dependa de adopción más que de función, y forzar esos casos produce una falsa precisión peor que la ambigüedad que reemplaza.

Así se ve en la práctica

En uso es una sola columna en un tablero existente y una oración por ítem nombrando la evidencia. Cambia la conversación de planificación: pedir entregar algo en peldaño dos se vuelve una negociación específica sobre qué se necesita para llegar al cuatro y cuánto tarda, en vez de un intercambio general sobre confianza. Los equipos reportan que el efecto principal no son mejores decisiones sino reuniones más cortas, porque se eliminó la ambigüedad que consumía la mitad del tiempo.

El argumento más fuerte en contra

La objeción que debe tomarse en serio es que las escalas de preparación codifican una visión lineal, propia del hardware, que el desarrollo moderno abandonó deliberadamente. El software está pensado para llegar temprano a usuarios reales y madurar en producción, y un marco que trata la exposición en producción como peldaño tardío puede justificar justamente las largas fases previas al lanzamiento que la entrega continua busca evitar.

La solución es que los peldaños describen alcance de exposición, no secuencia temporal. Alcanzar el peldaño tres en la primera quincena con un 1% de exposición es el uso previsto, no una violación. El marco se vuelve dañino cuando los peldaños se leen como fases con puertas y aprobaciones, lo que ocurrirá si lo introduce una función de gobernanza en lugar del equipo que debe usarlo.

Una secuencia de implementación de 30 días

Añade una columna de preparación al tablero esta semana, complétala para todo lo activo y exige una oración de evidencia junto a cada número.

Día uno, escribe las definiciones de los cinco peldaños con tus propias palabras y compártelas — las definiciones prestadas no sobreviven el contacto con un equipo específico. Día dos, que cada responsable asigne un peldaño a su trabajo y nombre la evidencia. Día tres, revisen juntos las asignaciones y esperen que un tercio baje su nivel tras expresar la evidencia en voz alta. Semana dos, usen los peldaños en una sesión de planificación y observen si cambia la conversación. Semana cuatro, manténganlos solo si la discusión se mantuvo más corta.

Audita la evidencia, no los números

Cada trimestre, toma cinco ítems y verifica la evidencia registrada en la realidad: ¿ocurrió esa prueba de carga?, ¿esa alerta está configurada?, ¿se completó el ciclo estacional? Cinco son suficientes. El propósito no es una verificación exhaustiva sino establecer que las afirmaciones se revisan ocasionalmente, lo que mantiene honesta una escala auto-reportada. Registra el resultado junto a la afirmación para que el historial sea visible cuando se discuta el ítem nuevamente.

Reevalúa los niveles cuando cambia el ambiente, no en un calendario fijo. Una actualización de dependencia, un cambio en el tráfico o la salida del único que entendía el sistema pueden mover algo hacia abajo, y este último caso es el que ningún marco detecta automáticamente. Haz que la transferencia de personal sea un disparador explícito de degradación y la escala comenzará a reflejar la realidad operacional en lugar de la historia técnica.

Conclusión editorial

Los marcos tomados de otras industrias suelen fracasar porque se adoptan completos. Éste sobrevive la traducción si se reduce a cinco peldaños, se define localmente y lo usan quienes hacen el trabajo en lugar de reportarlo hacia arriba. Lo que ofrece es modesto y real: pone fin a la discusión sobre si algo está listo, reemplazada por una discusión más corta sobre qué falta.