El liderazgo de equipo es un rol que puede ser una trampa para un desarrollador y puede brindar enormes oportunidades para el desarrollo de software.

Regresemos hace dos años cuando era desarrollador. ¿Qué estaba pensando? “Quiero convertirme en líder de equipo. Es genial, resuelve todos los problemas, obtiene más dinero, se vuelven después del senior " . Entonces no había nadie que me hubiera dicho: esto generalmente se trata de otra cosa. Tuve que aprender de mis errores.







Me convertí en líder de equipo dos veces



Tengo este rasgo: intentar establecer un orden perfecto en todo, sistematizar, construir procesos. Por eso, siempre me ha atraído hacer algo más que codificar. Mi primera puesta en marcha, llamémosla "T", fue un caos total en el proceso de desarrollo.



Ahora difícilmente empezaría a trabajar allí, pero entonces era muy atmosférico. Solo imagina. Muchos clientes paralelos. El gerente fue directamente (y puntualmente) a los desarrolladores. A menudo no cumplimos con los plazos anunciados y nos quedamos despiertos hasta tarde. Recuerdo cómo un día el jefe llamó a las 20 en punto y le pidió que viniera a trabajar para modificar la función para el cliente, porque "anunció la fecha límite mañana por la mañana". Pero en T, éramos familia.







E hicieron todo por sí mismos, lo mejor que pudieron. Recuerdo haber instalado Ubuntu en un servidor en rack que nos dio uno de los inversores. Cuando lo encendí, ¡hizo el sonido de un helicóptero despegando!



Allí crecí hasta la categoría de director técnico y trabajé con un equipo de 10 personas. De hecho, la primera, por capricho, la experiencia de liderazgo de equipo sucedió allí.



En D, donde vine como desarrollador, las cosas eran diferentes, especialmente cuando se trataba de procesos.



La compañía ha implementado Scrum clásico: sprints claros, gráficos de evolución, demostraciones, planificación, puntos de historia, preparación para preparar el sprint futuro. Me sorprendió la calidad del proceso, escribí el código en silencio y vi cómo funcionaba todo. Luego se hizo amigo del Scrum Master y comenzó a hacerle preguntas. Respondió con entusiasmo y compartió libros interesantes.





Recuerdo especialmente "Scrum y XP: Notes from the Front Line" de Henrik Kniberg. El proceso en "D" se construyó cerca de esta metodología: como resultado, todos los gerentes y vendedores sabían perfectamente cuándo sería el resultado.



También me uní a Skyeng como desarrollador. A diferencia de mis otras empresas, la integración continua se implementa de manera excelente aquí: todos los días se lanzan funciones para la producción. En mi equipo, el proceso se parecía más a Kanban.



Tuvimos un excelente equipo al frente de Petya. En llamadas individuales, podríamos discutir todo: desde problemas por no cumplir con los plazos hasta la configuración del rastreador de tareas. A veces solo daba retroalimentación, a veces aconsejaba algo.



Entonces Petya vio a través de mí y aprendió sobre la experiencia de liderazgo de equipo en T y el aprendizaje a distancia Scrum en D.



En algún momento, sugirió que hiciera un stand-up.





La operación "sucesor" en mi caso se veía así y tomó 6 minutos)



Y una semana después resultó que se estaba abriendo una nueva dirección en la empresa, y Petya con una parte del equipo se fue a ese proyecto. Los chicos restantes necesitan una nueva pista.



Todo sucede por sí solo, como si la Ley de Atracción invisible lo empujara en la dirección del liderazgo del equipo.



Cuando una empresa necesita un líder de equipo y todos piensan "¿Dónde puedo conseguirlo?", A menudo toman de los tipos que:



  • mejor organizado
  • se involucran rápidamente en los procesos e ideas del equipo,
  • motivado y ganando credibilidad a los ojos de otros desarrolladores.


Estas personas se notan rápidamente en la administración, de hecho, por lo tanto, cuando aparece una vacante, acuden a ellas. Así que funcionó para mí y al menos para varios compañeros de otras empresas con las que hablé sobre este tema. Y es curioso que todos notaron que la transición no tuvo que hacer casi ningún esfuerzo.



Aquí tenemos que explicar quién es el líder del equipo en nuestro caso.
, (, - , ). : , . , .



Skyeng :







Pero una cosa es asumir las tareas de un líder de equipo y otra muy distinta hacer frente a ellas.



Qué ha cambiado y cómo lo afronto



Los primeros días los vives con una sensación de euforia, triunfo y deleite. Aún así: estás al mando de todo el equipo, se apuesta por ti, ¡tienes más oportunidades y responsabilidad! Han pasado varios años desde que salí de T, gané experiencia, analicé mis errores, vi procesos y metodologías avanzadas y trabajé en ellos. Todo esto me dio fuerza y ​​confianza para la segunda entrada al liderazgo del equipo.



Sin embargo, con el tiempo, la sensación de euforia pasó y comenzó la vida cotidiana. Esto es lo que noté.



Necesita estar mentalmente preparado para separarse del "Zen de todas las noches" ... y hacerse amigo del "trimestral". El resultado del trabajo de un líder de equipo generalmente no se ve en un día o incluso en una semana. Esto es tanto un positivo como un negativo.





En su informe "Averías y averías durante la transición de ingeniero a jefe de equipo", Artem Kalichkin va directo al grano, diciendo que "los programadores son una de las personas más felices del mundo".



Cuando eres un desarrollador, todos los días tienes una compilación compilada, una tarea completada, una nueva característica en producción, y hay un cierto placer en eso. Una especie de zen: he hecho el trabajo, puedes ir a descansar por la noche con tranquilidad.



El líder del equipo rara vez tiene algo que compartir en el stand-up: porque ayer "hiciste la planificación, estuviste en las llamadas telefónicas, leíste el correo y agregaste tareas a la acumulación". Los resultados, como una nueva sección en un sitio web o una gran función en una aplicación, se componen de pequeños pasos que usted y su equipo realizan todos los días. Durante este tiempo, es posible que no escriba una sola línea de código, pero en general arrastrará un volumen de trabajo tal que nunca habría dominado durante este tiempo.



Por ejemplo, mi equipo creó una sección de Temas de estudio para la aplicación Skyeng en iOS y Android: implementamos un mapa de nivel de ejercicio, una escala de energía para diferentes categorías de estudiantes, metas diarias, rastreadores de progreso de tareas, diferentes mecánicas para tarjetas de tareas, actuación de voz y más.







La misma sección en el apéndice.
Puede estimar el número de pantallas y la mecánica de una lección en el GIF: el movimiento se acelera




Esta es en gran parte una historia sobre la delegación. Tienes que luchar contra el hábito de hacer todo tú mismo. Básicamente, para convertirse en un líder de equipo real, debe aprender a programar con las manos de los desarrolladores de su equipo.



Un líder de equipo sin experiencia puede convertirse fácilmente en el "cuello de botella" de un equipo . Cuanto menos se distraiga el desarrollador del trabajo, más ideal será el resultado y el equipo. Por lo tanto, tiene una acumulación de tareas pendientes con prioridades, un stand-up y un par de reuniones más a la semana. Y si necesita planificar una nueva función para el trabajo, se encuentra un error crítico, el producto no funciona o el equipo tiene una pregunta, ellos toman el liderazgo del equipo. Para que todo y todos funcionen, hay que comunicarse mucho.



« -» — , - .



Aquí quiero saludar y agradecer sinceramente mi producto. Al ver este problema, me envió a leer "Técnicas Jedi" de Dorofeev, "Gestión del tiempo" de Arkhangelsky, así como canales de estudio y chats para líderes de equipo, grabaciones de conferencias, etc.



Las prácticas que aprendí ayudaron a eliminar el desenfoque. Les advertí a todos que revisaría los mensajes entrantes 1 o 2 veces al día, comencé a organizar días sin reuniones ni llamadas, planifiqué mi jornada laboral por escrito (incluso intenté introducir esta práctica en el equipo, pero a los desarrolladores no les gusta). Cambié las prioridades solo si sucedía algo realmente crítico. Como resultado, las cosas que había planeado ya no se pospusieron.



En general, tuve que romper mis hábitos y dominar urgentemente un montón de técnicas útiles.



Las habilidades que necesita un líder no se desarrollan durante el desarrollo. Como líder de equipo, se convierte en un participante activo en la relación comercial entre negocios y desarrollo. El objetivo de cualquier empresa es obtener ganancias, por lo que el cliente desea obtener muchas características de alta calidad del desarrollo en poco tiempo. Los desarrolladores se esfuerzan por ofrecer calidad, pero no tienen prisa. En esta imagen, el líder del equipo debe mantener el equilibrio adecuado entre calidad, velocidad y volumen de tareas a resolver.



Para hacer esto, debe construir una relación de confianza con el cliente para que comprenda lo que está haciendo el equipo, cuánto tiempo se tarda en cortar esta o aquella característica, si tenemos tiempo o no, qué hacer para tener tiempo. Necesita desarrollar esas "habilidades blandas" y al mismo tiempo defender firmemente la posición y los principios del equipo. Y también piense en procesos, formatos, arquitectura de canalización: cómo le llegan las tareas, cómo se ejecutan, cómo se arreglan, cómo van a producción.



Por supuesto, las habilidades en sí mismas se pueden desarrollar. Pero debe estar preparado para que esto conduzca a una cierta transformación de la personalidad.



No más liderazgo de equipo: cómo no perderse y encontrarse de nuevo



Hace dos años, creía que el líder del equipo era el siguiente paso en la evolución de un programador. Ahora creo que esta es otra rama paralela del desarrollo. El resultado de la transición depende en gran medida de cada persona específica, y no lo sabrá hasta que lo intente.



Este rol necesita ser probado. Y no un mes, no dos. Al menos seis, creo. Aún mejor, uno o dos años. Existe una alta probabilidad de que sea difícil, querrás volver sin lograr un resultado. Le aconsejo que se fije un plazo y diga: “No sacaré conclusiones intermedias hasta el final de este plazo. Lo probaré y al final tomaré una decisión si es mío o no ". Personalmente, hice precisamente eso.



Después de trabajar como líder durante un año y medio (desde septiembre de 2018 hasta febrero de 2020), decidí conscientemente dejar este puesto y volver al desarrollo. Durante el mismo tiempo, el líder del equipo, el canala quien leí creció como CTO en mi empresa.







Siempre estamos a distancia, la comunicación principal está en Slack: así "todos los movimientos quedan registrados". Todo resultó como en la imagen: el colega que le propuse se está probando a sí mismo como líder de equipo, y yo estoy disfrutando de la "noche zen" en el marco de otro equipo.



Y este verano, con un par de chicos que han seguido un camino similar, hicimos una reunión interna sobre nuestra experiencia. Y la pregunta más importante que surgió entre los oyentes: ok, ¿cómo entender, cuando piensas en dónde desarrollarte más, el rol del líder del equipo es tuyo o no?



Entonces surgió la idea de discutirlo en formato público con:



  • Egor Tolstoy (podcast y cursos de Podlodka): tomó una decisión a favor de la gestión de productos y hablará sobre el momento en que se dio cuenta de que estaba cansado del liderazgo de desarrollo,
  • Vadim Martynov (Kontur y la comunidad RndTech): regresó a los desarrolladores y les contará cómo se volvió a capacitar para escribir código y cómo todo afectó las finanzas.
  • y Eugene Kot (Wrike y la misma conferencia sobre dolores de cabeza de equipo) como moderador.


Todo se llevará a cabo en línea el próximo miércoles (2 de septiembre) a las 7 pm Moscú / Kiev / Minsk en YouTube: los espectadores tendrán una charla y una simple oportunidad de encender por voz. Y si aún tienes fuerzas, hablemos en el zoom.





Aquí puede agregar un recordatorio a su calendario .



Únase al debate "MoreNeTimlead" o mírelo en la grabación. Espero que nuestra experiencia te sea de utilidad, porque hace dos años también pensé que ...



All Articles