👧🏼 👨🏿‍⚕️ 🛳️ "Qué hacer cuando los cambios dramáticos en los procesos desmotivan a un equipo". La experiencia del ingeniero de backend que se convirtió en un líder de equipo ✋🏽 🧦 🥌

Durante 7 años trabajé como ingeniero de back-end en Miro, luego me convertí en líder del equipo. En los últimos años, nuestro equipo de ingeniería se ha duplicado, se ha distribuido e internacional, lo que conllevó muchos cambios.

Uno de ellos fue la introducción de equipos multifuncionales que podrían resolver el problema por completo, desde el desarrollo de la idea hasta el lanzamiento de las funciones. Para esto, los ingenieros de backend y frontend tuvieron que dominar rápidamente muchas de las cosas que nunca antes habíamos hecho: probar, trabajar con lanzamientos, realizar rituales de scrum, sin perder velocidad y calidad.

Los primeros pasos en esta dirección llevaron a un aumento en el número de errores, una disminución en la velocidad de desarrollo y la desmotivación de los equipos. Durante este período difícil, me convertí en un líder de equipo, por lo que mi miedo personal al fracaso y mi propia incompetencia se sumaron al estrés general.

Como resultado, hicimos frente a la tormenta, redujimos a la mitad el tiempo de espera y avanzamos significativamente en la efectividad de los equipos multifuncionales. Esto fue ayudado en gran medida por un cambio en nuestra actitud hacia los cambios en curso, la transición de mentalidad fija a mentalidad de crecimiento.

A continuación se muestra un video y una transcripción de mi desempeño en Saint TeamLead Conf 2019, donde, usando a mi equipo como ejemplo, hablo sobre los procesos y las herramientas que hicieron posible estos cambios.

Historia No. 1. Cambiar el proceso de desarrollo para reducir el tiempo de entrega

En 2016, nuestro desarrollo consistió en 20 personas y 5 equipos. Los equipos interactuaron entre sí de manera efectiva e intercambiaron rápidamente información y experiencia. Con el crecimiento de los empleados y los equipos, la introducción de procesos de CI / CD y revisiones de código, aumentó el número de interdependencias entre los equipos.

Por ejemplo, para lanzar una gran característica en un producto, el equipo necesitaba trabajar con otros 6 equipos de ingeniería:

Dar código a la revisión de código.
Dar una característica a la prueba de control de calidad. Si es necesario, QA incluirá el comando DevOps para crear un entorno de prueba especial.
Libere la función con el administrador de versiones, que es responsable de todas las versiones de la empresa.
Conecte comandos adicionales si algo sale mal durante el lanzamiento.

Y esto sin tener en cuenta las dependencias con los equipos de marketing, diseño y soporte técnico, que también participan activamente en el lanzamiento de las funciones.

Cuantas más dependencias, más tiempo de entrega, es decir, el tiempo desde el inicio del desarrollo hasta el lanzamiento. Cuanto mayor es el tiempo de entrega, menos valor entregamos a los usuarios.

Una gran cantidad de comunicaciones y baja velocidad de entrega desmotivan al equipo. ¿Qué hacer? Reduzca las dependencias y acorte el tiempo de entrega.

Estamos tratando de construir un transportador en desarrollo

Para resolver este problema, primero intentamos construir un transportador:

Describa todas las etapas y procesos;
introducir SLA (Acuerdo de nivel de servicio, nivel de calidad requerida) para determinar el tiempo durante el cual la tarea debe pasar por cada etapa;
enderezar los flujos para evitar que la tarea retroceda a las etapas anteriores para mejoras.

Desafortunadamente, la tubería no funcionó: un error en cualquier etapa condujo a la suspensión de toda la cadena, mientras que cada equipo se vio obligado simultáneamente a resolver problemas de su propia cartera de pedidos. Por ejemplo, el control de calidad necesitaba elegir: lidiar con un error en la tubería o participar en tareas para mejorar el proceso de prueba. Este problema de priorización condujo al hecho de que lanzamos funciones, pero no logramos mejorar los procesos internos, o nos dedicamos a la optimización del proceso y no tuvimos tiempo para lanzar funciones.

Luego decidimos reconstruir el transportador para moverlo dentro de cada equipo.

Intentando construir equipos multifuncionales

Los equipos interfuncionales pueden ocuparse de la tarea de principio a fin: desde resolver la idea hasta poner la función final en el producto. Para esto, el equipo necesita tener todas las competencias, conocimientos y procesos necesarios.

Decidimos realizar un experimento en varios equipos antes de implementar los cambios en toda la empresa. Mi equipo también participó en el experimento, que se ocupa principalmente de tareas de bajo nivel ( escribí sobre uno de nuestros ejemplos de trabajo : implementar ActiveMQ y Hazelcast). El equipo estaba formado por 3 desarrolladores de back-end, un ingeniero de control de calidad a tiempo parcial y yo como líder del equipo.

Determinamos las interdependencias.

En primer lugar, determinamos las dependencias actuales de las que queremos deshacernos:

No hay un ingeniero de control de calidad a tiempo completo, por lo que podemos esperar las pruebas de unos pocos días a una semana.
, -.
full-time -, , .

Había otras dependencias, pero decidimos centrarnos principalmente en las tres. Ahora necesitábamos aprender mucho de lo que el ingeniero de control de calidad, el maestro Scrum y el administrador de versiones hicieron antes.

Aprendemos a probar de forma independiente.
Anteriormente, los ingenieros escribían de forma independiente pruebas unitarias y probaban la funcionalidad básica, el resto verificaba el control de calidad. Ahora hemos aprendido cómo probar de forma independiente las situaciones límite y escribir pruebas de extremo a extremo para probar la interacción entre el cliente y el servidor.

Aprender a liberarse
Estamos de acuerdo en que queremos liberar al menos una vez a la semana. Para hacer esto, necesitamos un administrador de versiones dentro del equipo. Uno de los desarrolladores de back-end se convirtió por propia voluntad.

Realizamos rituales de scrum por nuestra cuenta.
El maestro de scrum externo no tuvo tiempo para tratar con todos los equipos, por lo que dentro de nuestro equipo elegimos al que deseaba este papel. Necesitaba aprender cómo llevar a cabo de forma independiente la planificación, el aseo y la retro.

Naturalmente, nadie nos arrojó a las barricadas. El control de calidad, el administrador de versiones y el maestro scrum pasaron conocimientos y asesoraron en casos difíciles.

Primeros fracasos

Los resultados del primer sprint no tuvieron éxito. Realmente comenzamos a llevar las tareas a la rama maestra mucho más rápido, pero no pudimos realizar una única versión de forma independiente. Resultó que nuestros procesos y scripts no estaban listos para esto. El script de lanzamiento solo pudo liberar todos los servicios a la vez, por lo que no pudimos liberar nuestra parte del servicio por separado.

Giramos una parte de los procesos y al final del segundo sprint colocamos las tareas del primer sprint en el lanzamiento. Sin embargo, algo salió mal nuevamente. La mitad de la funcionalidad lanzada contenía errores críticos, por lo que decidimos revertir el lanzamiento. Y se enfrentaron a un nuevo problema: nuestro desarrollador de backend y el administrador de lanzamientos a tiempo parcial del equipo aprendieron a lanzar, pero aún no aprendieron a revertir los cambios. Por lo tanto, necesitábamos la ayuda de un administrador de versiones externo.

Todo esto llevó a la desmotivación del equipo: fallamos el segundo sprint consecutivo, lanzamos la funcionalidad con errores críticos, la sensación de que no podemos hacer nada por nuestra cuenta.

Historia No. 2. Un nuevo papel y miedo al error

Al comienzo del experimento con equipos multifuncionales, Max, uno de los ingenieros de back-end, se ofreció como voluntario para convertirse en un maestro scrum. Sin embargo, después del primer sprint, se me acercó y me dijo que ya no quería ser un maestro scrum. Después de Max, vino Andrei, otro ingeniero, y dijo que no probaría: "Soy un desarrollador, no un probador". Como líder de equipo, era importante para mí comprender las causas de ambos fracasos.

Como regla general, una de las 4 razones que pueden funcionar con cada una de ellas es la piedra angular de la decisión de abandonar la tarea:

   → , , .
(, , ) → , .
  , → : , .
   → .

Max entendió el valor que el scrum master aporta al equipo, pero temía no hacer frente a las difíciles tareas de facilitar las reuniones. Al aceptar un nuevo rol, sabía poco sobre el trabajo del maestro scrum y no se dio cuenta completa de las habilidades que necesitaría para esto. Max temía no poder hacer frente, perdería el tiempo del equipo y parecería incompetente a los ojos de sus colegas.

En la situación con Andrei, resultó que probó su código por su cuenta y estaba seguro de que todo estaba bien. Sin embargo, por si acaso, di QA para verificación, y encontró 5 errores en el código. Esto se repitió varias veces, lo que desmotivó a Andrei, y decidió no hacer más pruebas.

Conocía bien las situaciones de Max y Andrei. Recientemente, yo mismo he pasado de ser un ingeniero de backend experimentado a un líder de equipo sin experiencia. Y al igual que temía no poder hacer frente a las tareas, no estaría a la altura de las expectativas y, en general, el liderazgo del equipo no era mío.

Instalación en crecimiento e instalación en un determinado

Cuando me convertí en líder del equipo, la profesora Carol Dweck de la Universidad de Stanford me aconsejó leer el libro " Conciencia flexible " . En resumen, describe dos tipos de pensamiento:

Mentalidad fija: la creencia de que la inteligencia y las habilidades se arreglan de una vez por todas, es imposible influir en ellas, y el fracaso indica una falta de talento. Las personas con tal pensamiento intentan no realizar tareas complejas para no perder la motivación y la fe en sí mismas.
La mentalidad de crecimiento es la creencia de que la inteligencia y las habilidades se pueden mejorar a lo largo de la vida si se hacen esfuerzos para hacerlo. El fracaso es una razón para aprender algo, por lo que las personas con este tipo de pensamiento están constantemente tratando de salir de su zona de confort y asumir tareas complejas.

Naturalmente, el mundo no está dividido en blanco y negro, en diferentes situaciones la misma persona puede estar dominada por un tipo diferente de pensamiento. Por ejemplo, una persona puede considerar que la programación es una habilidad que cualquier persona puede aprender, pero al mismo tiempo cree que cocinar deliciosamente es un talento inherente a la naturaleza, y esto no se puede aprender.

Todo el esquema está en el sitio web de Carol Duque.

Este enfoque describe la actitud de una persona hacia los cambios que están teniendo lugar.

Personas con predominio de mentalidad fija (configuración por sentado)
: « , ».
, . , , .

Growth mindset ( )

, , .
, .
, .

Este enfoque me ha ayudado a cambiar mi actitud hacia los errores. Por lo tanto, decidí hablar sobre el enfoque del equipo, ya que podría darnos un único sistema de coordenadas, enseñarnos a tratar los cambios de manera diferente y reducir el miedo a los errores. Al igual que cualquier herramienta, la orientación al crecimiento funciona para resolver problemas específicos, por lo que hablé sobre ello en las reuniones 1: 1 para brindar a todos la información que le sería útil específicamente para resolver su situación.

Además, les conté a todos en el equipo sobre mi propio ejemplo de trabajar con la configuración en el momento de cambiar los roles de ingeniero a líder de equipo. Esto se sumó al resto de la confianza en sí mismo ("No fui el único en encontrar esto", "esta situación realmente puede cambiar").

Continuación de la historia número 2

Un experimento reduce las expectativas y el estrés. Después de discutir el enfoque con la mentalidad de Crecimiento y Fijo, acordamos con Max lanzar un experimento en el que probará un nuevo rol como maestro de scrum. La palabra "experimento" reduce bien el grado de estrés. En el experimento, no da miedo cometer errores, pero es importante hacer el trabajo sobre los errores y hacer una experiencia útil. En la misma línea, hablamos sobre el nuevo papel de Max para el equipo, lo que redujo las expectativas del equipo.

El talento es experiencia ganada.Andrei, cuando discutía su negativa a probar, dejó caer la frase: "Soy talentoso en programación". Resultó que Andrei consideraba que la programación y las pruebas eran talentos innatos. Tenía el primero, pero no el segundo. Comenzamos a discutir la experiencia de Andrei y nos dimos cuenta de que Andrei pasó por la programación a través de noches de insomnio en busca de errores, días de inmersión en proyectos de otras personas, de forma independiente escribió decenas de miles de líneas de código. Resulta que su experiencia en programación no es un talento, sino una experiencia a la que fue durante mucho tiempo y con un propósito. Simplemente aprendiendo algo, a menudo nos olvidamos de los primeros pasos dados en esta dirección.

OKR personales.Para que nuestro progreso sea visible incluso con un ligero avance, acordamos con el equipo que realizaremos un seguimiento del progreso de cada entrenamiento. Esto ayudará no solo a ver el camino recorrido, sino también a comprender cuánto más necesita llegar a la meta deseada.

A nivel de empresa, tenemos OKR, por lo que decidimos aplicarlo para el nivel de entrenamiento personal. Las condiciones fueron las siguientes:

Agregamos a los OKR personales solo lo que ayuda en el trabajo actual;
Los resultados clave deben ser medibles en cualquier momento y ayudar a responder la pregunta "¿Hasta dónde he progresado en comparación con la semana pasada?
Cada resultado clave tiene una lista de iniciativas que permiten alcanzarlo;
(, ), , ;
OKRs 1:1.

Implementación de OKR personales para el trimestre
Algunas semanas después del lanzamiento de la iniciativa, nos dimos cuenta de que no estaba sucediendo nada. Resultó que estábamos en nuestro propio rastrillo, exageramos nuestras propias expectativas. Al equipo le preocupaba que fuera necesario hacer OKR ideales durante mucho tiempo y esto fue un estupor.

Luego acordamos que consideraríamos esto como una de las iteraciones. Los OKR siempre se pueden revisar y refinar, esto no es algo tallado en piedra, sino solo la dirección que desea desarrollar. Esto ayudó a percibir la iniciativa como un juego interesante, y las cosas se fueron.

Ejemplo de OKR de Andrey

Bonus, acordamos compartir los OKR personales dentro del equipo. Ayuda a aprender unos de otros y funciona como un compromiso público.

Continuación de la historia número 1

Gracias a un cambio de actitud, en retrospectiva, comenzamos a buscar las causas de las dificultades en nosotros mismos y no en el exterior. Ahora no había excusas que pudieran haber sonado antes: "Entonces, el proceso está construido, ¿qué puedo hacer?" Comenzamos a refinar procesos que no nos convenían. El equipo tuvo un sentido de propiedad de los procesos en curso.

Esto nos permitió comenzar a implementar de manera estable una pequeña cantidad de tareas. Aunque era la mitad que antes, lo pusimos a la venta de forma completamente independiente y sin errores.

Todo esto nos agregó confianza en sí mismo. Después de un tiempo, Andrey automatizó de forma independiente casos de prueba complejos. Roma, quien es responsable de los lanzamientos, optimizó el proceso para que cada miembro del equipo ahora pueda lanzar de forma independiente.

Como resultado, en función de los resultados del trimestre, pudimos reducir el tiempo de entrega en 2 veces debido a la reducción de dependencias, el aumento de competencias dentro del equipo y el cambio de actitud hacia las dificultades y los errores.

Nuestra productividad se ve afectada no solo por el conocimiento y las habilidades que poseemos ahora, sino también por cómo nos relacionamos con los cambios en la empresa. A veces, los nuevos procesos pueden desmotivarse, y las tareas que son demasiado complejas pueden socavar la autoconfianza. Pero con esto puede trabajar tanto para usted como para el nivel de todo el equipo.

Se ayudó a mi equipo a hacer frente a los cambios y la actitud hacia los errores de la mentalidad Crecimiento y Fijo. Lo tratamos como una herramienta de trabajo que resuelve problemas específicos. Por supuesto, la instalación no cambió en unas pocas semanas y meses. Pero al cambiar la actitud hacia situaciones específicas, pudimos avanzar significativamente en el trimestre en relación con las tareas diarias y las dificultades.

"Qué hacer cuando los cambios dramáticos en los procesos desmotivan a un equipo". La experiencia del ingeniero de backend que se convirtió en un líder de equipo