Cómo hacer ship de un proyecto en Big Tech

Por qué es difícil lanzar (shipping)

• Mucha gente cree por error que “lanzar” es algo fácil, pero en realidad lo normal es que el lanzamiento se retrase, se cancele o salga con baja calidad y cause problemas.
• No porque ya se haya escrito todo el código o se hayan resuelto todos los tickets de Jira significa que el lanzamiento ocurre automáticamente. Para lanzar, alguien tiene que asumir el rol de liderazgo.
• El lanzamiento debe convertirse en la máxima prioridad. Si uno se enfoca demasiado en la experiencia de usuario (UX), el lanzamiento puede retrasarse más.
• Para lanzar un proyecto con éxito, hace falta un líder técnico o un DRI (Directly Responsible Individual). Los equipos que tienen un ingeniero en ese rol tienden a tener más probabilidades de éxito.

¿Qué significa “lanzar”?

• Muchos ingenieros piensan que “lanzar” es simplemente desplegar código o activar una función, pero en las grandes empresas tecnológicas se define de otra manera.
• Un lanzamiento ocurre cuando las personas importantes dentro de la empresa creen que “ya se lanzó”. Si el VP o el CEO no están satisfechos, aunque el código ya se haya desplegado, en la práctica no se considera “lanzado”.
• Si el proyecto logra un gran éxito entre los usuarios o genera ingresos, entonces se considera lanzado; pero incluso si la respuesta de los usuarios no es buena, si el liderazgo está satisfecho, también se considera lanzado.

La importancia de la comunicación

• Hay que tener muy claro cuál es el objetivo del proyecto. Según el objetivo, cambia la forma de trabajar y la estrategia de comunicación.
• El liderazgo de la empresa casi no conoce los detalles técnicos del proyecto. Por eso, para mantener la confianza, son importantes estimaciones precisas, resolver problemas y dar actualizaciones adecuadas.
• Formas de mantener la confianza:
• Ayuda mucho haber tenido lanzamientos exitosos en el pasado.
• Hay que mostrar una actitud segura.
• Hay que comunicarse como el control de misión de la NASA: de forma profesional y concisa.
• Hay que compartir información de forma proactiva mediante hilos de actualización diarios o semanales.

Resolver problemas de despliegue en producción

• La mayoría de los problemas surgen en detalles inesperados. Por ejemplo, problemas con el tamaño de bloque de Memcached, errores al predecir el tráfico o temas relacionados con datos sensibles de usuarios.
• Para resolver los problemas rápido, hace falta un entendimiento técnico profundo del sistema.
• Hay que poder responder rápidamente a los problemas previstos y explicar con claridad si un problema es grave o no.

¿Se puede lanzar ahora mismo?

• Es importante preguntarse si se puede lanzar ahora mismo. Si no, hay que pensar qué tendría que cambiar para que sí fuera posible.
• Hay que usar feature flags y entornos de staging para poder recibir feedback lo antes posible.
• Justo antes del lanzamiento, hay que reducir el trabajo técnico y prepararse para responder rápido si surge algún problema.

Resumen

• Lanzar es muy difícil y debe tratarse como la máxima prioridad.
• Lanzar no significa simplemente desplegar, sino lograr que el equipo de liderazgo quede satisfecho.
• Conseguir la confianza del equipo de liderazgo es la clave de un lanzamiento exitoso.
• Es importante tener planes de respaldo para anticipar y manejar problemas.
• Justo antes del lanzamiento, hay que reducir el trabajo de desarrollo y poder concentrarse en resolver problemas.
• Siempre hay que hacerse la pregunta: “¿Se puede lanzar ahora mismo?”.
• Hay que dejar el miedo atrás y tener valentía.

[GN⁺]

Comentarios en Hacker News

• Resulta llamativa la observación de que "shipping" es una construcción social dentro de la empresa. Está terminado cuando las personas importantes creen que el proyecto está terminado
• Este artículo no trata sobre desplegar software, sino sobre satisfacer a los ejecutivos. Aunque a los usuarios no les guste y el mercado se burle, si a los ejecutivos les gusta, entonces ya fue enviado
• Así como en los deportes ganar resuelve todos los problemas, en el software hacer shipping resuelve todos los problemas. No existe un producto perfecto, pero si se lanza temprano, los usuarios pueden quedar satisfechos
• A veces los ingenieros que resuelven problemas reciben más reconocimiento que quienes los previenen. Uno intenta prevenir problemas, pero los líderes a veces no lo perciben
• En las grandes empresas, "deploy" no debe entenderse solo como materializar una función, sino dentro de un contexto más amplio. Algunos podrían decir que esto es poco ético, pero en las grandes empresas es una especie de "juego"
• He enviado muchos proyectos, pero sin casos concretos cuesta confiar en ello. Si hubiera incluido ejemplos de proyectos reales, habría sido más fácil de entender
• Este artículo es spam de blog de autopromoción
• Coincide con mi experiencia, pero le faltan consejos prácticos. Hacen falta ejemplos concretos sobre cómo obtener el reconocimiento del liderazgo
• Es distinto de mi experiencia en grandes empresas. Incluso sin apoyo de los ejecutivos, si la retroalimentación de los usuarios o las métricas son positivas, se considera un éxito. Incluso los proyectos pequeños pueden tener valor
• Para que resulte creíble, hay que cuantificar y cualificar las afirmaciones. "Hacer shipping en big tech" es una afirmación demasiado amplia y necesita una explicación más específica

[signaling]

He seleccionado una opinión impactante.

"Algunas personas solo quieren construir un territorio técnico para sí mismas, o quieren recibir elogios de personas que están por encima de ellas en cualquier nivel. Así es como "se juega el juego". Jugar ese juego termina llevando a la muerte de la organización, y esa es justamente la razón por la que existen los ciclos de vida empresariales. Al final, esas personas arruinan la organización desde dentro y desplazan a quienes tienen opiniones reales o a quienes están optimizados para realmente sacar el trabajo adelante."

"La forma de ganar el juego es no jugarlo"