Scotty: El Maestro de la Gestión de Expectativas en el Siglo XXIII
Últimamente he estado pasando bastante tiempo a bordo de la USS Enterprise original. Si bien es fácil dejarse cautivar por el caótico carisma del Capitán Kirk o la fría lógica de Spock, hay que decir la verdad. El verdadero genio de esa nave no viste de dorado ni de azul. Viste de rojo y tiene un cuestionable acento escocés.
Estoy hablando de Montgomery “Scotty” Scott.
Muchos miran al Ingeniero Jefe y ven un alivio cómico o a un hombre que disfruta quejarse de que “los motores no lo soportarán” un poco demasiado. Están equivocados. Scotty es el único adulto en la sala. Es el mayor practicante del arte perdido de la Gestión de Expectativas.
El Hacedor de Milagros Calculado
Hay una estructura clásica en casi todos los episodios. Dondequiera que vaya la Enterprise, sucede algo terrible. Los escudos caen. El motor de curvatura muere. Los Klingons están atacando.
Kirk, con la urgencia de alguien que tiene un guion que terminar en 45 minutos, grita por el comunicador: “¡Scotty! ¿Cuánto tiempo hasta que tengamos potencia de curvatura?”
Scotty, con la voz temblorosa de alguien que está presenciando el apocalipsis, responde: “¡Capitán! ¡Los cristales están fracturados! ¡Necesito al menos ocho horas o todos seremos polvo espacial!”
Kirk, impasible, replica: “Tienes dos.”
¿Y qué sucede? Exactamente en la marca de una hora y cincuenta y nueve minutos, Scotty entrega el motor completamente funcional. Kirk sonríe y lo llama un “hacedor de milagros”.
Para un observador no entrenado, Scotty parece incompetente por errar tanto en la estimación o deshonesto por inflar los números. Pero esto no es deshonestidad. Esto es Ingeniería Defensiva.
La Psicología del Mando
Scotty comprende una verdad fundamental sobre el liderazgo y la gestión de proyectos que muchos de nosotros ignoramos. El Mando (ya sea el Capitán Kirk o tu Product Manager) no se preocupa por la termodinámica. No les importa la complejidad del código o la deuda técnica. Les importa el resultado.
Si Scotty dijera la verdad honesta (“Capitán, esto lleva dos horas si todo sale bien”), Kirk, siendo un gerente agresivo, exigiría que se hiciera en una. Y cuando algo inevitablemente saliera mal a mitad de camino, la nave explotaría y la culpa recaería sobre el ingeniero.
Al decir “ocho horas”, Scotty crea tres cosas vitales:
- Margen de Seguridad: Si algo se rompe (y siempre lo hace), tiene seis horas de “colchón” para resolver el problema sin que el Capitán entre en pánico.
- Control Narrativo: Él define la gravedad de la situación. Le recuerda al mando que las leyes de la física no son sugerencias.
- Valor Percibido: Cuando entrega en dos horas, no solo hizo “su trabajo”. Realizó un milagro.
Este es el concepto de “Prometer Menos y Entregar Más” elevado al nivel de arte. Scotty no solo protege su reputación. Protege la integridad del sistema contra las demandas absurdas de personas que piensan que resolver problemas complejos es solo cuestión de “presionar más fuerte”.
La Lección para los Desarrolladores Junior
Si estás empezando en el mundo del desarrollo, escucha lo que digo.
Hay un impulso natural de querer complacer. Tu Tech Lead o tu PM se acercarán a tu escritorio y preguntarán: “¿Cuánto tiempo para implementar esta API de pago?” Mirarás, pensarás en el mejor escenario posible donde el café está caliente y Stack Overflow (ahora la IA) tiene todas las respuestas, y dirás: “Oh, puedo hacer esto en dos días”.
Acabas de firmar tu sentencia de muerte.
En el momento en que encuentres un error en una librería de terceros o el servidor de pruebas se caiga, estarás retrasado. Harás noches en vela. Enviarás código sucio. Y al final, nadie te agradecerá el esfuerzo. Solo recordarán que llegaste tarde.
Haz lo que hace Scotty.
Si crees que lleva dos días, di cuatro. Si el PM llora, negocia a tres. Usa ese tiempo extra para probar tu código, para documentar, para manejar lo imprevisto.
¿Si terminas en dos días? Genial. Entrégalo antes de tiempo. Serás visto como eficiente y proactivo. Serás el hacedor de milagros que salvó el Sprint.
No se trata de mentir. Se trata de comprender que el desarrollo de software, al igual que mantener un motor de curvatura con cristales inestables, es un proceso caótico. Tu trabajo no es solo escribir código. Es gestionar el caos para que tu Capitán no tenga que hacerlo.
