De vez en cuando, los equipos de ingeniería se meten en problemas por cualquier número de razones. A veces, el crecimiento explosivo pilla al equipo por sorpresa. O, la guardia se ha descontrolado, con alertas que se disparan cada cinco minutos. O bien, los equipos de desarrollo y operaciones simplemente han dejado de coincidir. Sea cual sea el motivo, el equipo se encuentra en una mala situación y hay que hacer algo para resolverla.
Si se trata de un problema nuevo, la solución puede ser fácil: añadir unos cuantos servidores más, volver a una versión de la aplicación que se conozca como buena o reunir a todos con pizza y cervezas para aclarar las cosas. Sin embargo, a menudo el problema se arrastra con el tiempo y de repente el agujero es tan profundo que no se puede encontrar la salida. En LinkedIn, un equipo que ha llegado a este punto suele declarar un estado conocido como «Código Amarillo»
Alerta amarilla
Algunas personas suponen que el nombre de Código Amarillo se basa en los semáforos, pero más exactamente -y con un giro más geek- es en realidad de su serie favorita «Star Trek». Más concretamente, es la forma en que la tripulación de la nave Enterprise indica su estado defensivo actual. En cualquier caso, la definición es clara: algo va mal y hay que avanzar con precaución. Fieles a ambas metáforas, también tenemos un Código Rojo. Eso se describe mejor como una crisis inmediata, con todo el mundo trabajando las 24 horas del día hasta que se resuelva. El Código Amarillo es algo más relajado: Todo el mundo se concentra en él, pero sólo durante las horas de trabajo. El Código Amarillo también tiende a durar del orden de meses, mientras que un Código Rojo debería durar del orden de días.
Otras empresas pueden utilizar un término diferente al de Código Amarillo, pero el efecto es el mismo: el equipo está comunicando al resto de la empresa que han identificado un problema grave que es prioritario solucionar para asegurar el éxito del equipo y, por tanto, de la empresa. La capacidad de hacer esto es un aspecto importante de la comunicación abierta y honesta, un valor que es fundamental para una cultura saludable y que a menudo puede pasarse por alto. Hablar de nuestros problemas es tan importante, si no más, que celebrar nuestros éxitos. Los equipos pueden aprender más de la solución de un problema que de un éxito total.
Esto no es un fracaso
El primer paso para iniciar un Código Amarillo es entender que esto no es un fracaso. No hay que avergonzarse de admitir que el equipo tiene un problema que necesita ser arreglado. Los errores ocurren, a pesar de nuestros mejores esfuerzos para evitarlos. Lo único que podemos hacer es diagnosticar el problema y remediarlo. La única vez que fallamos es cuando hacemos la vista gorda ante estos problemas. Esto se aplica tanto a la forma en que nuestros equipos de ingeniería interactúan entre sí como al software y los sistemas que producimos y ejecutamos.
Sin embargo, es fundamental que se aborden los problemas correctos. La mayoría de las veces, hemos llegado a la situación actual debido a una lenta ebullición -una deuda técnica cada vez mayor, muchos pequeños problemas o averías en un proceso- que finalmente se convirtió en una crisis. El objetivo del Código Amarillo debe ser no sólo remediar los problemas actuales (un componente reactivo), sino también asegurarse de que no se repitan en el futuro (el componente proactivo).
Planificación para un Código Amarillo exitoso
Hay varios componentes requeridos para un Código Amarillo exitoso, así como piezas necesarias para conseguir la participación del resto de la organización:
- Declaración del problema: Debe haber una declaración clara y consensuada de los problemas a los que se enfrenta el equipo y que han motivado el Código Amarillo. Esto debe incluir no sólo cuáles son los problemas actuales, sino también cuál es la comprensión actual de su causa raíz.
- Criterios de salida: A continuación, es necesario tener objetivos específicos que el equipo trabajará para salir del Código Amarillo. Estos deben ser los tradicionales objetivos SMART: específicos, medibles, alcanzables, relevantes y con plazos. Estos objetivos son los que hacen posible que el equipo entre en un Código Amarillo en primer lugar, ya que cubre un ámbito fijo y no es abierto.
- Comunicación: Toda la información sobre el Código Amarillo, incluido el anuncio (que incluye el enunciado del problema y los criterios de salida), la conclusión satisfactoria y las actualizaciones periódicas del estado deben enviarse a la organización más amplia. Este puede ser su departamento, o puede ser toda la organización de ingeniería. Incluso puede ser toda la empresa, dependiendo de la naturaleza de los problemas.
- Gestión de proyectos: Como en todos los grandes proyectos, es necesario que haya alguien responsable de organizar el trabajo y comunicar la información. Como esto representa un escenario de «todas las manos en la cubierta» para el equipo afectado, por lo general es útil tener un gerente de proyecto dedicado (PM) para ayudar con esto. Por lo general, se trata de un PM que conoce el equipo y el trabajo, pero que no participa directamente en la ejecución. Esto libera a los gestores y a los colaboradores individuales para que se centren en el trabajo que tienen entre manos.
Una vez que se ha pensado en cada uno de estos aspectos y se ha tomado la decisión de entrar en el Código Amarillo, el primer acto del equipo es reorganizar sus prioridades en torno a los criterios de salida. Esto suele significar dejar de lado los objetivos trimestrales. También puede ser necesario establecer una reunión dedicada a discutir el estado de los criterios de salida.
Espacio para respirar
Está muy bien que un equipo entre en Código Amarillo y trabaje con un único enfoque en los objetivos que se han establecido para hacer las cosas bien, pero esto no es suficiente para que el equipo tenga éxito. Para lograr el verdadero éxito, todos los que rodean al equipo deben entender la situación y darles el espacio necesario para hacer su trabajo. Aquí es donde una cultura de ingeniería sana se levanta para afrontar el reto.
- Esperar retrasos: La forma más común en que un equipo tangencial se verá afectado es a través de los retrasos. Deben esperar que cualquier solicitud que se haya hecho al equipo impactado pueda retrasarse si no está dentro del alcance de los criterios de salida. El Código Amarillo implica, en esencia, una reordenación de las prioridades para abordar el problema planteado. Los equipos externos deben tener esto en cuenta y comprender que puede ser necesario ajustar los plazos de sus propios proyectos.
- Minimizar las nuevas solicitudes: Otros equipos también deben abstenerse de pedir al equipo impactado cosas nuevas que estén fuera del alcance de los criterios de salida definidos. Minimizar estas peticiones, además de aceptar retrasos en cualquier petición existente, permite al equipo impactado gastar sus limitadas horas de ingeniería en llegar al otro lado del Código Amarillo.
- Solicitudes de Asistencia de otros equipos: El equipo en Código Amarillo puede encontrar que necesita ayuda externa para alcanzar sus objetivos. Por ejemplo, si hay un crecimiento repentino y explosivo del tráfico, pueden necesitar acelerar el aprovisionamiento de nuevo hardware. Encontrarse en el extremo receptor de una solicitud de este tipo puede requerir un cambio en sus propias prioridades. Recuerde siempre que el equipo forma parte de la misma empresa y, como tal, todos tienen éxito o fracasan juntos.
Los equipos de ingeniería rara vez están solos, y es importante que todo el mundo entienda el valor de que esos equipos trabajen bien, y trabajen bien juntos. Un pequeño retraso temporal en los objetivos para asegurar que este es el caso bien vale la pena.
Luz al final del túnel
El código amarillo representa una cantidad significativa de trabajo de alta prioridad y trabajar a través de él a menudo será estresante para el equipo. Decir «no» a los compañeros de trabajo que están haciendo una petición razonable es difícil, y el trabajo que está en el ámbito de aplicación rara vez implica dedicar tiempo a nuevas características interesantes. Además, si los problemas que se abordan incluyen problemas de comunicación entre grupos, habrá que mantener algunas conversaciones difíciles. Sin embargo, a medida que el equipo se acerca al final del trabajo, será mucho más fácil ver lo que hay al otro lado de los criterios de salida.
El objetivo final del Código Amarillo es sacar al equipo de un modo reactivo en el que están corriendo de crisis en crisis y en un estado proactivo en el que son capaces de trabajar en los grandes proyectos adecuados. Alcanzar los criterios de salida significará que los ingenieros son más eficaces y capaces de trabajar de forma proactiva. Se trata de un equipo más fuerte: los ingenieros están más contentos porque no están sometidos a un fuerte estrés de trabajo de operaciones, el equipo está trabajando bien porque están hablando entre sí con eficacia, y los clientes están satisfechos porque las solicitudes se manejan a través de la automatización o en un tiempo razonable.
¿Tiene su empresa un proceso interno que es similar a cómo LinkedIn hace un Código Amarillo?
– Todd Palino