Hola a todos! Me llamo Alexander Afenov. Soy el líder del equipo de procesamiento de pedidos de Lamoda. El año pasado hablé en TeamLead Conf 2018. La grabación de la actuación está disponible aquí .

En mi informe, contaré la historia de cómo me convertí en un líder de equipo, qué problemas encontré y compartiré varias estrategias que pueden parecerle familiares individualmente. Sin embargo, me concentro en qué tipo de beneficio dan en el complejo.



El informe se dividirá en 3 partes:

1. En la primera parte, hablaremos un poco sobre la compañía y las características de nuestra TI. Esto es necesario para comprender el contexto en el que sucede todo.
2. En el segundo hablaré sobre mi camino en la empresa.
3. En el tercero, sobre los métodos utilizados, sus ventajas y desventajas.

Lamoda como empresa de TI

Lamoda es conocido principalmente como un importante minorista de ropa, zapatos y accesorios de moda en Rusia y la CEI. Sin embargo, pocas personas saben que por un porcentaje o un monto fijo brindamos servicios a diferentes empresas / entidades legales.

Déjame darte un buen ejemplo. Digamos que tienes un sótano para coser carteras. Ha creado un sitio web para sus productos y lo ha promovido con éxito. Ahora mucha gente sabe de usted, pero a pesar de esto, tiene problemas con la entrega, el almacenamiento y la comunicación con los clientes.

Lamoda puede resolver estos problemas de las siguientes maneras:

1. Brinde los servicios de su servicio de entrega.
   
   LM Express es nuestro propio servicio de entrega, que hemos estado desarrollando y automatizando por nuestra cuenta durante mucho tiempo.
2. Proporcionar comunicación con el cliente. Para hacer esto, tenemos nuestro propio centro de llamadas.
3. Mantenga los productos en casa o incluso véndalos por usted (comisión).
4. Mercado Los productos de los socios se pueden mostrar en nuestra aplicación móvil, en el sitio o en su versión móvil, y los socios hacen el resto ellos mismos.

Surge la pregunta: "¿Cómo se las arregla para resolver sus problemas y satisfacer las necesidades de los socios?" Tenemos un negocio cambiante y en desarrollo con nuestras propias necesidades. De alguna manera mejoramos, desarrollamos y avanzamos. Al mismo tiempo, aún debe coincidir con la lista de deseos que viene del exterior. Parece que esto requiere su propia TI, y no una pequeña.

Estamos hablando del desarrollo interno en todas las conferencias desde 2016. Automatizamos todos los procesos nosotros mismos. Se trata de un centenar de servicios diferentes: desde el procesamiento de pedidos y pagos hasta el trabajo con objetos de dirección y certificados de regalo. Apoyo a todo esto es un equipo de aproximadamente 300 personas.

¿Por qué estoy hablando de nuestra TI y su alcance? Porque 300 personas son muchos equipos. Cuando algunos equipos trabajan en una sola pila tecnológica, intentamos reutilizar todos estos desarrollos. Pueden ser paquetes, bibliotecas, prácticas en el campo técnico. Pero también tratamos de buscar prácticas de proceso exitosas entre los líderes de equipo, y hablaré sobre esto más adelante.

Cuestiones clave

Me uní a la empresa en 2015. Tres días después de mi empleo, se programó una fiesta corporativa de Año Nuevo, a la que decidí no asistir. Mi prioridad era quedarme y pensar en mis tareas durante un período de prueba.

El evento corporativo en Lamoda es una fiesta temática para la que a todos les encanta prepararse. Por lo tanto, el día X, el arquitecto de mi departamento vino a trabajar al desfile, con un abrigo de cola. En ese momento, nuestro equipo se dedicaba a los servicios de procesamiento de pedidos. Era un monolito en el antiguo marco Zend1 . ¿Qué observé? Los muchachos prepararon una liberación forzada y quisieron arreglar algo. Después de asegurarnos de que todo estaba bien, empacamos y nos fuimos de vacaciones.

Y aquí estoy sentado. El lanzamiento entró en producción con una revisión, y frente a mí hay un hermoso televisor de 50 pulgadas con algún tipo de tablero de instrumentos. En el tablero había un gráfico que decía "Problemas de Rabbit MQ". Parece que si hay datos en él, entonces algo se ha roto. Pero no sé dónde mirar para probar esta hipótesis.

Probablemente pueda ver algún tipo de registro. Sin embargo, solo estoy el tercer día en el trabajo y no sé dónde están. Creo que puedo encontrar un enlace al tablero de grafana. ¿Quizás vale la pena mirar a través de él la fuente de métricas y cavar allí? Sí, pero está muy lleno de baches. Me gustaría que esto se documentara de alguna manera. Y de nuevo, está la pregunta: ¿quiénes son todas estas personas que están sentadas? Dos o tres pisos en los que se distribuye TI. Todos están haciendo algo, y no sé con quién comunicarme si algo salió mal. No hay una tabla dinámica que tenga claro con quién podría contactar si me di cuenta de que el lanzamiento está roto. ¿O tal vez hay una persona de guardia, pero no estoy al tanto?
* (por supuesto que lo era) *

Hubo otras preguntas. La primera y más ridícula, a la que volveremos repetidamente: "¿Dónde está la documentación?". La respuesta es simple: simultáneamente en todas partes, en cualquier lugar y en la mente de los empleados con experiencia. Como todos se fueron a la fiesta corporativa, pero no sé dónde están los muelles, la respuesta me pareció "en ninguna parte". Tenía un archivo Léame en el que desplegué el proyecto en mi computadora portátil. Pero eso no fue suficiente. Quería obtener respuestas a muchas otras preguntas. Por ejemplo, ¿cuáles son las reglas básicas de "comportamiento" para un desarrollador?

Déjame explicarte: decidí solicitar acceso al sistema de combate para ingresar a la interfaz de usuario. Sería muy útil para mí, ya que mi tarea para el período de prueba fue reelaborar el sistema de autorización, y quería presionar botones, iniciar sesión en el puesto de producción. Lancé una solicitud al servicio de seguridad, a la que rápidamente recibí una respuesta sucinta: "No, no daremos acceso". Resultó que solo los usuarios reales tienen acceso al sistema de combate: trabajadores del almacén, un centro de llamadas, etc. Como anteriormente había trabajado en telecomunicaciones, me acostumbré al hecho de que tenía acceso de lectura y escritura a las bases de producción de varios operadores móviles. Y aquí resulta que es imposible. Hay un protocolo

Además, me encontré con muchas otras condiciones y restricciones que el líder del equipo me contó. En los primeros días, me dedicó a muchos momentos fascinantes diferentes. Había tanta información que no todo podía ser recordado y escrito.

Las siguientes preguntas que me interesan se refieren a una perspectiva a largo plazo. Por ejemplo, ¿cómo y dónde crecer?

¿Por qué es esto importante? Porque desde el principio necesito comportarme de alguna manera. Llegué al puesto de desarrollador de php medio. ¿Qué debo hacer luego para superar las expectativas y en el futuro para obtener una calificación más alta, por ejemplo, Senior? Y una pregunta más: "¿Qué se espera de mí en mi calificación actual?" Es decir, ¿cuánto debería involucrarme en procesos como la revisión de códigos, lanzamientos, tareas?

Todas las preguntas que he enumerado ahora fueron respondidas por nuestro líder de equipo. Las dos últimas, más estratégicas, fueron respondidas a través del sistema de evaluación del desempeño. Te contaré más al respecto.

Revisión de desempeño

Cada 6 meses, una persona realiza una auto revisión. Él habla sobre las cosas geniales que logró hacer en el tiempo asignado. Sin embargo, hay una trampa. Está relacionado con el hecho de que las personas generalmente indican esos logros en la autoevaluación, que están subjetivamente inclinados a considerar como tales. Pensar en términos de negocios es inusual, e incluso si el proyecto de rutina permitiera a la compañía ganar una tonelada de dinero, entonces para el desarrollador podría no ser un desafío o interés. Existe el peligro de que en dicha revisión este proyecto no se indique.

El siguiente paso es una revisión por pares. Esto es seguido por una serie de comisiones sobre las cuales hay comunicación entre los líderes de equipo, gerentes de departamento, estaciones de servicio y, si es necesario, el director de recursos humanos. Luego un mensaje sobre los resultados.

¿Cuáles son los posibles resultados?

La primera opción: una persona logró empeorar en seis meses que antes del inicio del trabajo. Parece tiempo de decir adiós. Esto sucede extremadamente raramente, pero seremos realistas, sucede.

Otra opción es un deuce. Parece que falta algo. Puede haber velocidad, previsibilidad, perseverancia. Algo necesita ser mejorado.

Tres: lo que esperaban, lo consiguieron. Una persona trabaja a un ritmo adecuado y en todos los aspectos corresponde a su grado.

Cuatro - hizo más de lo acordado. Candidato a ascenso / salario.

Cinco - lobo de lana. Parece que es hora de subir, dar bonos, etc.

Revisé varias iteraciones de tal revisión yo mismo. Anteriormente, se realizaba cada trimestre, lo que no era muy conveniente, ya que durante 3 meses la oportunidad de probarse a sí mismo no siempre ocurre. Ahora la revisión ocurre cada seis meses.

Entonces, al principio crecí de desarrollador senior a senior. Luego, el líder de mi equipo decidió que ahora quiere trabajar más con la tecnología y se mudó al puesto de equipo técnico (arquitecto), y yo me convertí en líder del equipo.

Entonces, ¿qué sigue? Necesito hacer algo, de alguna manera dominar.

Lo primero que se encuentra son las mismas preguntas de las que hablamos antes, solo que ahora en un nivel ligeramente diferente. Es decir, todavía no está claro: ¿dónde está esa documentación? Ahora necesito comunicarme de alguna manera con otros departamentos, comunicarme con otros clientes potenciales, arquitectos y otra persona, pensar en un nivel superior. Pero en este mismo nivel de documentación, probablemente tampoco.

Otro punto son las mismas "reglas básicas". Que puedo hacer

Supongo que puedo hacer un seguimiento de las tareas, hacer una revisión del código. Quizás ahora tenga el poder de cambiar los procesos, de alguna manera comunicarme con la gente.

¿Cómo y dónde crecer? Esta pregunta no desaparece, porque es posible que desee convertirse en el jefe del departamento (líder del grupo).

Bueno, la pregunta: qué se espera de mí, también me parece bastante comprensible.

Y ahora necesita poder responder todas estas preguntas no solo a usted, sino a todo el equipo. En mi caso, el equipo fue reclutado casi desde cero. Resulta que para cinco o para siete personas tengo que decir todo, explicar, establecer metas. Se necesita tiempo y esfuerzo. Tales cosas deben ser planificadas y pensadas. Entonces, ¿cuál es la responsabilidad del líder del equipo?

¿Qué debe liderar un equipo?

En primer lugar, es trabajar con tareas : su formulación, ajuste, descripción de la persona que recibe la tarea bajo el grado. Por ejemplo, para un junior, preferiría hacer una descripción muy detallada y esperar que escriba el código y las pruebas correctas. Como senior, comunicaré un objetivo técnico o comercial, y él será libre de decidir por sí mismo cómo lograrlo. En cualquier caso, todo esto lleva tiempo.

Por supuesto, debe realizar una revisión del código cuando surjan conflictos durante el mismo. Monitoree lo que está sucediendo, mueva las tareas por estado. También realizo las tareas de un ingeniero de lanzamiento de forma regular. A menudo debe pensar en cómo nuestra implementación afecta a todos los demás. El servicio que hago es el procesamiento de pedidos. Está asociado con casi todos los sistemas Lamoda y, en consecuencia, es capaz de afectar muchos procesos comerciales durante su lanzamiento.

Otro punto es el monitoreo, alertas y cambios asociados con esto. Si ha aparecido una característica comercial, es necesario monitorearla, introducir nuevas métricas, colgar notificaciones, informar al servicio de soporte, etc. Todos estos son problemas arquitectónicos. No tengo un arquitecto dedicado en mi departamento en este momento. Llevo a cabo sus funciones en aquellos casos en los que necesita alguna solución específica dentro del marco de una tarea / proyecto específico.

Todavía hay que prestar atención a las comunicaciones . Esto incluye reuniones personales que tienen lugar aproximadamente cada dos semanas con cada desarrollador; retrospectivas, planificación, comunicaciones con gerentes y otros departamentos. Pero aún así sería bueno no cometer una falta.

Muchos dicen que sería genial después de 10 años de desarrollo obtener una relación de "gestión a desarrollo" de alrededor de 80 a 20. Incluso esto no siempre es posible. Como resultado, inevitablemente perderá experiencia y caerá de las tendencias actuales. Es necesario seguir creciendo más.

Existen posibles estrategias sobre cómo puede crecer en términos de su posición. En la siguiente sección, hablaremos sobre cómo la rotación de roles en un equipo ayuda a aumentar el factor del autobús.

Rotación de roles

Voy a poner al día a los que no saben y le diré cuál es el factor del autobús.

El factor de bus es un número que indica que si cierto número de desarrolladores "golpea un bus", entonces el trabajo en el proyecto se detendrá. Puede manifestarse en una variedad de niveles. Por ejemplo, puede ser un factor de bus para algún elemento complejo específico del sistema.

Supongamos que tenemos un caso en el que necesitamos resolver un determinado sistema de informes. El desarrollador pasó 5 días para hacer esto. El error fue complicado, pero se solucionó y todo estuvo bien. Luego surge otro problema en el mismo módulo, y el mismo desarrollador se encuentra en baja por enfermedad. Esto significa que la siguiente persona debe pasar la misma cantidad de tiempo resolviendo el problema. Tendrás que resolverlo desde cero, porque no hay documentación (jaja).

Lo que se discutirá más adelante es precisamente las estrategias para aumentar el factor del bus. Y se unirán en una imagen bastante agradable con todos los deberes anteriores del líder del equipo, sobre lo que hablé.

Además de la documentación, se necesita experiencia real. Es decir, necesita un equipo que ya haya logrado tocar diferentes partes del sistema y que ahora esté listo para hacer frente a cualquier tarea. Pero si el equipo acaba de reunirse, entonces todo esto no vendrá de la nada desde cero. Mi objetivo principal es decir cómo es posible combinar varios enfoques diferentes que permitan resolver problemas con la documentación y la experiencia.

Ingeniero de soporte

Todos han escuchado sobre desarrolladores virtuales. Pero no hablaremos sobre kits de realidad virtual y no sobre personas en un sitio remoto, sino sobre el papel de un ingeniero de soporte.

¿Quién es un ingeniero de soporte?

Tenemos un tipo que analiza una acumulación de soporte. Vino a trabajar, no tiene una sola tarea. Abrió una cartera de pedidos de apoyo en el rastreador de tareas (Jira), y allí las tareas ordenadas por criticidad. Tomó lo más importante y comienza a reparar. Después de resolver todos los problemas, escribe por qué se rompió y cómo evitarlo en el futuro. Si no tiene otro soporte (esto es gracioso, porque el soporte nunca termina), entonces mira el atraso técnico, que ya es bastante grande.

Una pequeña distracción: estamos hablando de un sistema de mil quinientos mil líneas en el antiguo marco Zend 1 . El arquitecto del equipo anterior dijo una vez que, según nuestro sistema, tenemos una deuda de este tamaño; no se trata de una deuda técnica, sino de una hipoteca técnica. De ahí el título del informe.

Si no hay nada que hacer, el ingeniero de soporte puede realizar alguna tarea no prioritaria desde allí, lo cual no es una pena abandonar y volver al soporte recién aparecido. Esto suele suceder. Y no hace esto por más de una semana, porque sería un camino directo a la frustración. Si durante la iteración completa de dos semanas solo está involucrado en el soporte de rastrillado, esto lo desmotivará enormemente. Usted repara, repara, repara, y no tiene fin. Por esta razón, cada semana transferimos el papel de un ingeniero de soporte a la siguiente persona.

Ingeniero de lanzamiento

Hay otra posición virtual que es muy conveniente para descargar el liderazgo del equipo: este es un ingeniero de lanzamiento. Prepara versiones para versiones de arreglos planificadas previamente, recopila ramas, prepara compilaciones, ejecuta todas las pruebas. Si las pruebas se ejecutan automáticamente, entonces simplemente controla el resultado. En su área de responsabilidad, elija cuán hermoso es rodar sin tiempo de inactividad y efectos especiales para los sistemas que dependen de nosotros.

Sucede que necesitamos comunicación con otros equipos antes del despliegue para advertirles de los cambios. Como resultado, el ingeniero de lanzamiento despliega todo y mira para ver si algo se ha desmoronado. Usamos para esto, Centinela , Prometeo , Icinga , mira Elastic, usando Kibana . El ingeniero de lanzamiento decide qué hacer si algo sale mal. Es decir, es su responsabilidad decidir si se necesita algún tipo de revisión, o si todos estamos en bancarrota, perdemos dinero y necesitamos hacer una reversión. La decisión de retroceder se toma solo como último recurso, pero esto también sucede.

Él (ingeniero de lanzamiento) registra los problemas que surgen. Si algo se rompiera, sería genial aprender de tus errores. Para hacer esto, indica la fecha de lanzamiento y los errores que llevaron al problema. Esto permite que el próximo ingeniero de versiones analice problemas comunes y los evite. Bueno, sí, no hace esto durante más de una semana consecutiva, porque recabar un comunicado es costoso.

Si el lanzamiento es grande, la mitad del día sale volando fácilmente y es muy difícil a tiempo romper a tiempo para cambiar a sus tareas. Por ejemplo, comenzó un ensamblaje que demora 20 minutos. Mientras la asamblea está en progreso, puedes fumar o pensar en la vida. Pero si regresó a la tarea y el ensamblaje fue exitoso, debe cambiar nuevamente. En general, este es un proceso bastante triste, que se retira del desarrollo normal y no permite ingresar a la corriente. Por esta razón, la próxima semana el ingeniero de lanzamiento es una persona diferente.

Tekhlid

Otra posición virtual más interesante es el líder técnico.

Un arquitecto (a veces llamado así) entra en la refriega cuando hay una gran tarea importante o se lanza un nuevo proyecto. Esto significa que él se responsabiliza del diseño, desarrollo y lanzamiento. Se le da el derecho de comunicarse con el líder del equipo y el gerente del equipo, tomar decisiones técnicas y la obligación de documentarlas se transfiere. Si se produce alguna basura al comienzo, registra todos los problemas que han ocurrido y sus causas de la misma manera que lo hace un ingeniero de lanzamiento o un ingeniero de soporte.

Conclusiones

¿Qué obtenemos como resultado?

La rotación de roles en un equipo durante mucho tiempo (al menos seis meses) hace posible que incluso un junior sin experiencia obtenga la habilidad para trabajar con una variedad de partes del sistema y tipos de tareas.

Al principio, hablé sobre el hecho de que la documentación y la experiencia real pueden ayudar a resolver problemas típicos. Después de aplicar las prácticas descritas, no es un hecho que resolverá el problema de la documentación, pero todos los participantes del equipo de desarrollo obtendrán experiencia variada y de alta calidad.Durante una larga rotación de roles virtuales, una persona logra tocar una variedad de partes del sistema como ingeniero de soporte. Como ingeniero de lanzamiento, aprende a desplegar, comunicarse, observar y tomar decisiones rápidamente. Si obtuvo el papel de experto técnico, entonces se está preparando para impulsar de forma independiente proyectos más grandes y más importantes.

A partir de este momento, el líder del equipo puede y debe delegar sus tareas a sus subordinados, porque, si lo recuerda, el líder del equipo tiene la tarea de no esforzarse y crecer en algún lugar.

Gracias a tales prácticas, es posible finalmente dar a alguien una parte de su trabajo. Por ejemplo, lanzamientos. Esto es de 4 a 8 horas a la semana, que se liberan repentinamente de vez en cuando. Ahora puede gastarlos en desarrollo, leer artículos, resolver otros problemas. Un gran error sería no incluirlo en el calendario y gastarlo en reuniones no tan útiles. Aunque, por regla general, esto sucede :) Ahora el líder del equipo puede alegrarse, ya que tiene la oportunidad de estar menos nervioso y confiar parte de su trabajo a sus empleados. Si algo le sucede, los proyectos no se levantarán.

Como resultado, aumentamos el factor de autobús del liderazgo del equipo. El equipo, a su vez, puede estar seguro de que si algo salió mal con el líder del equipo, cualquiera de ellos estará listo para asumir un trabajo y lidiar con él.

Por supuesto, hay limitaciones. Este enfoque no es posible si hace todo solo (persona-departamento). , . — .

5 , . , . , .

– . , , , . , . . , - “” , - . , , , , . , . , .

, : « , , , ” . , , , . . , . - .