A veces parece que el tímido es alguien o algo así como Snark del poema de Lewis Carroll: ciertamente existe, es versátil y contradictorio descrito en sus manifestaciones cotidianas y comerciales, pero para todo eso es un misterio. Para comprender cuán importante es este rol (líder del equipo, no Snark) en los equipos de ingeniería, quién es mejor para ponerlo y qué obstáculos están ocultos en el liderazgo del equipo,
Saint TeamLead Conf 2018 promete ayudar, que se llevará a cabo del 24 al 25 de septiembre en San Petersburgo .
Un mes antes del evento, hablamos sin ninguna formalidad con el director técnico del proyecto Mos.ru
Roman Ivliev , quien encabeza el Comité del Programa Saint TeamLead Conf 2018. En la conversación: quiénes son los líderes del equipo, cómo prepararlos correctamente, para quién y para qué deben prepararse, qué deberían ser un círculo de sus responsabilidades y mucho más.
Ayuda
Roman Ivliev nació en 1982. En 2005, se graduó del Departamento de Cibernética, Instituto de Física de Ingeniería de Moscú. Más de 15 años en TI. Especialización: altas cargas de trabajo, gestión en equipos tecnológicos, formación.
Últimos lugares de trabajo:
• En 2009–2013, primero ingeniero senior, luego gerente de proyectos en Kaspersky Lab (fue responsable del soporte y desarrollo de sitios corporativos, tanto b2c como b2b).
• En 2014–2016 - Director de Tecnología de la Información Banki.ru
• Asumió el cargo de director de tecnología en el proyecto Mos.ru a finales de 2016.- Durante casi dos años, usted ha sido CTO en el proyecto Mos.ru, y antes de eso trabajó durante muchos años principalmente en organizaciones comerciales. ¿Cómo, en su experiencia, es trabajar como director técnico en una estructura gubernamental diferente de trabajar en el mismo puesto en los negocios?- Desde el punto de vista de los procesos de producción, considere que no hay una diferencia significativa. El sistema de configuración de tareas no es muy diferente de los adoptados en las oficinas comerciales. La diferencia de escala: por lo general, un proyecto gubernamental es un mecanismo enorme. Muchas personas están involucradas en su trabajo y tienen derecho a tomar y tomar decisiones. A modo de comparación: si en Banki.ru esculpimos unos cinco proyectos internos, en Mos.ru, unas veinte personas pueden participar en un proyecto comparable. En una organización gubernamental, el departamento de TI es un poco más difícil en términos de construcción de comunicaciones externas: sucede que intenta atrapar a la persona adecuada durante medio día, simplemente porque el personal es grande. Pero con aquellos con los que necesita interactuar regularmente, incluso a través de la integración de servicios, estamos en una etapa corta: nos conocimos.
En cada rincón del Departamento de Tecnologías de la Información de la ciudad de Moscú (DIT) y otras estructuras con las que tenemos que interactuar, nuestras propias reglas del juego y nuestros problemas, como en cualquier organización enorme, al menos en el mismo Sbertekh. Nuestro Mos.ru no es muy diferente del mercado de servicios b2c, excepto que no ganamos dinero.
Por supuesto, todavía dependemos de la ley. Y si traducimos un determinado servicio en forma electrónica o publicamos un nuevo servicio, solo si existe un marco regulatorio apropiado. Digamos igualar los derechos de aquellos que registran al dentista en Internet y a través del registro. Dentro del departamento, esta no es nuestra área de responsabilidad. A veces, pospusimos el lanzamiento debido a circunstancias similares, en las que no pudimos influir. Aunque el negocio ahora es el mismo desastre.
- ¿Qué hay detrás de la fachada de Mos.ru?- Mos.ru es la puerta. Un portal que reúne una gran cantidad de servicios. Debajo de él, hay una sala de redacción que escribe sobre eventos en la ciudad y mantiene un póster. Hay secciones que estamos obligados a tener de acuerdo con la ley, por ejemplo, que contienen información sobre actos legales regulatorios y la estructura del gobierno. Estas partes del recurso también están ocupadas por personas especialmente capacitadas. Los preparamos para la mecánica de la gestión de contenidos, lo usan.
Todavía en nuestra área de responsabilidad están los proyectos digitales especiales. De fresco - hecho esto para el parque Zaryadye.
Nosotros, relativamente hablando, tenemos un equipo de ciclo completo. Tomamos algo de un lado, aunque rara vez. Otros servicios que viven en el dominio
www.mos.ru , pero que no fueron desarrollados por nosotros, sino por otras divisiones de DIT, están disponibles en el sitio debido a integraciones internas. Se los ocultamos al usuario para que cualquier transición dentro del portal sea perfecta. Sentado en Mos.ru, puede estar fácilmente en otro sistema, sin embargo, si no ingresa al código de la página, no notará nada.
Los mismos
servicios del gobierno de la ciudad (se puede acceder a ellos a través de nuestro sitio web) participan en un equipo separado. Sus servicios, a su vez, se limitan a los sistemas de TI específicos de la industria: atención médica, social, etc.
- ¿Cuánto participa un gran equipo en el soporte técnico del portal bajo su supervisión?- Veinte personas en desarrollo. Con una docena de pruebas, incluidas las relacionadas con la automatización. Agregue aquí el equipo de explotación y DevOps. En total, hasta cincuenta, el número exacto y la composición dependen de las circunstancias actuales y la carga.
- ¿Cómo se construye su jerarquía de gestión técnica? ¿Cómo se dividen las áreas de responsabilidad?- Tenemos tres áreas principales: desarrollo, pruebas, operación. La operación, a su vez, se divide en operación limpia y DevOps. Además, los que interactúan con los centros de datos y los que se dedican a la automatización se distinguen, pero tienen muchas tareas comunes, por lo que no los crío en diferentes campos.
Las pruebas se implementan de acuerdo con el esquema de "pruebas como servicio". Hay un grupo de probadores y su jefe. Están nominalmente unidos a los equipos, pero de hecho no son sus miembros. Si es necesario, transferimos los probadores de tarea a tarea: estos tipos son multifuncionales. La excepción es móvil. Enviamos personas especiales para probar aplicaciones móviles y tratar de no sacarlas por nada: su trabajo tiene una especificidad pronunciada.
También tenemos DevOps como servicio: las tareas se configuran, priorizan y luego se ejecutan a través de los devops, que tampoco están muy ajustados a algunos equipos. Del mismo modo, la operación funciona.
Pero el desarrollo se divide en equipos en áreas funcionales. Tenemos dos tipos de equipos. El primero es altamente especializado. En particular, el que hace la búsqueda. No toca el frontend y la GUI: solo el backend. Aserrando sus propios algoritmos, estudiando el aprendizaje automático, creando brujos, pistas, estadísticas, analizadores, corrección de errores tipográficos. Están sentados en su pila de tecnología y se conectan con Mos.ru a través de la API. El servicio de búsqueda está conectado a cualquier parte del portal. Un equipo separado aterrizó en la dirección de aplicaciones móviles. Ella tiene su propio backend.
Ambos equipos interactúan con el "desarrollo central" de DevOps, pruebas y operación.
El segundo tipo de comandos son aquellos que crean y admiten módulos Mos.ru separados, incluida la GUI. Generalmente hay cinco en cada uno, con un máximo de seis empleados, dependiendo de la dirección. En estos mini-grupos, hay una división clara en front-end y back-end: en nuestro caso, ha demostrado ser efectivo. La mayoría de los backenders son desarrolladores completos, pero no los hago girar en dos pistas de baile a la vez. Cada equipo tiene un líder de equipo.
- Entonces esta palabra sonó. ¿Y qué hace un tímido?- En primer lugar, es un estratega en su sector del frente: supervisa el cumplimiento de las reglas del juego que hemos establecido. En él, entre otras cosas, descomposición de tareas, revisión de código, organización retrospectiva, educación de novatos.
Traducido a filas militares, se trata de alguien como un sargento: el líder del escuadrón. Está facultado y tiene derecho a tomar decisiones en el marco de las soluciones y estándares tecnológicos que hemos adoptado conjuntamente.
Además, los miembros de mi equipo son parte del equipo de arquitectura. Esta no es una estructura formalizada y que no opera constantemente: surge cuando se madura la necesidad de crear algo nuevo en términos de tecnología. Luego, todos los líderes de equipo, los jefes de los departamentos de pruebas y operaciones y todos los demás interesados en los cambios se reunirán conmigo. Especialistas con diferentes competencias, con diferentes puntos de vista sobre el panorama tecnológico, con diferentes posiciones se sientan en un círculo. Discuten temas controvertidos, arreglan acuerdos, proponen una arquitectura o solución, y no están de acuerdo.
Hasta hace poco, en Banki.ru y en Mos.ru, exclusivamente "espaldas" fueron eliminados de mis compañeros de equipo. Como regla general, un desarrollador de back-end senior asumió este rol. Pero en este momento ya tengo dos líderes de equipo de la interfaz.
Todo esta cambiando. Tuvimos que adaptarnos a las realidades tecnológicas actuales, y como resultado obtuvimos lo que llamamos gremios.
Aquí está la cosa: es difícil para el favorito llevar un registro de lo que está sucediendo en el mundo del backend en 2018, y viceversa. Nos dimos cuenta de que las personas necesitan cooperar a nivel horizontal, involucrarse en asociaciones informales sin subordinación directa, pero con estatus, como filas en sociedades secretas, algo así como un "maestro del orden de fondo". Los portadores de tales "títulos" son personas que de hecho toman decisiones gerenciales de naturaleza aplicada: ¿nos moveremos a PHP 7.2, se desarrollará Angular o es mejor apostar por React?
Los gremios se reúnen regularmente: front-end por separado, back-end por separado. Se reúnen y descubren quién es bueno y quién es malo, qué está de moda y genial ahora. Argumentan si Webpack es realmente un sombrero aburrido que recoge un montón de todo lo que es innecesario, o si simplemente necesita aprender a manejarlo. Simplemente no se desbordan de vacío a vacío, pero al final llegan a una solución práctica.
Finalmente, el equipo de arquitectura reemplaza a mi arquitecto de sistemas. Sí, no tengo un arquitecto de sistemas.
- ¿Qué lugar ocupa el líder del equipo en tu equipo? ¿Se reporta directamente al CTO o hay gerentes de nivel medio?- No tenemos un nivel intermedio, simplemente sucedió. Según la lógica de las cosas, entre los líderes del equipo y yo debería haber un gerente de desarrollo. De hecho, hay jefes en los departamentos de prueba y operación, y personalmente administro el desarrollo. Por lo tanto, los Timlids me informan directamente.
Un poco más complicado es el esquema de sumisión de los devops. Inicialmente, también los iba a separar en un grupo separado con mi jefe, pero los muchachos y yo reflexionamos y decidimos que este era un vínculo administrativo adicional. Trajeron DevOps en lugar del jefe Kanban, por lo que están extremadamente satisfechos.
- ¿Cuándo te encontraste con una entidad como líder de equipo en desarrollo? ¿Cuándo mi experiencia personal se convenció de que esta característica es útil?- En 2008, mis colegas y yo escribimos software astuto en una planta de defensa. Una vez que enterramos nuestras narices ante el hecho de que era ofensivamente simple: un equipo de diez desarrolladores no es capaz de producir nada, pero solo es capaz de estafar y maldecir. Luego, por primera vez en mi vida, surgió la frase "líder de grupo", una especie de prototipo de un líder de equipo.
El equipo de ingenieros se dividió en dos, habiendo asignado una persona responsable a cada uno de los dos grupos. Yo fui uno de ellos. El jefe de otro grupo y yo comenzamos a construir procesos de desarrollo interno y depurar la interacción entre las mitades de nuestro mini equipo. Juntos convertimos el colectivo "tipo rebaño" en dos unidades de combate efectivas. Comenzaron a distribuir tareas entre ellos y priorizar estas mismas tareas, planificar por períodos más largos y, al final, sincronizar el trabajo de los equipos para evitar el tiempo de inactividad.
En Banki.ru, la estructura del departamento técnico también era "celular": los equipos en él estaban controlados por líderes de equipo, y la mayoría de las veces con cinco de ellos contacté directamente, en ausencia de un gerente de desarrollo. Justo como ahora en Mos.ru.
Antes de eso, en Kaspersky Lab, donde era responsable del trabajo de los sitios corporativos, varios equipos operaban bajo mi dirección: multidisciplinarios, con diferentes conjuntos tecnológicos. Así que allí habría sido lastimado por mi mente sin los Timlids, los líderes de los grupos que me salvaron del tormento asociado con la construcción de un panorama tecnológico en todos los detalles. Interactué con ellos a nivel de ideología y coordinación general de procesos. Y construir las reglas del juego (cómo llevar a cabo una revisión del código, si ayudar a los más jóvenes, engañar a los más viejos, etc.) permaneció en su conciencia.
Y de nuevo más o menos lo mismo: ¿con quién más se compararon los Timlids, si no con los sargentos? En los Estados Unidos, todo el ejército se aferra a ellos. Tampoco puedo vivir sin mis "sargentos". Más bien puedo, pero con dolor y a través de una plataforma de tocones. Son mis ojos, oídos, manos. Son los primeros en llevar mis deseos, sugerencias e instrucciones "a las masas" y velar por que todo esto se implemente.
- En su opinión, ¿es un líder de equipo más bien una profesión o un papel situacional en la organización, por analogía con el scrum master?- Ahora tengo los dos en el equipo. Una cosa es cuando las tareas de un equipo son básicamente las mismas, y las personas se mueven en un solo ritmo. Otra es cuando en un equipo n los problemas se resuelven en paralelo, donde n puede exceder el número de ingenieros en un equipo. En el segundo caso, el líder del equipo tiene todas las posibilidades de convertirse, incluso temporalmente, en un administrador natural, que "enrutará" estas tareas. En cuanto a mí, este es un rol y una profesión.
Además, el mercado todavía discute sobre quién es el pájaro tímido en principio y cuáles son sus funciones básicas. A todos se les ocurre una configuración que más le convenga. Con mayor frecuencia, incluso provienen de las tareas que es necesario y apropiado resolver en un equipo en particular. Por ejemplo, en Banki.ru delegué la selección de personal a los líderes de mi equipo: estaban lo suficientemente "iluminados" para hacer las preguntas correctas durante la entrevista, no solo para determinar la calificación del candidato, sino también para evaluar sus habilidades blandas. Poco a poco, los muchachos bombearon y pasaron de ser líderes técnicos ordinarios del rango inicial a unidades de los siguientes niveles. En Mos.ru, gradualmente llegamos al mismo sistema. Los muchachos estudian el currículum, miran a los candidatos, realizan entrevistas técnicas. A menudo asisto a esta etapa como espectador.
¿Existe tímido como profesión, la pregunta es de relleno? ¿Es el líder del equipo una profesión? Absolutamente Solo en la ciencia espacial es uno, y en la programación de otro, desde el punto de vista de las funciones realizadas por su representante y el rango de tareas que realiza. En la empresa, donde hay cinco personas en desarrollo, una. En la oficina para 250 empleados - otro.
Lo mismo con el scrum master. Nadie lo molesta para ser un back-end, front-end, probador, o incluso un escritor técnico. Lo principal es la capacidad de reunir a las personas, establecerlas de la manera correcta y organizarse, reducir la entropía tanto como sea posible y alentar a los colegas a moverse en un solo ritmo y en una dirección.
- Vamos a visitar tu mundo perfecto. Cuando un equipo incluye un gerente de producto, un gerente de proyecto y, en general, ¿dónde está la responsabilidad del líder del equipo? ¿Timlid gravita hacia el "diseño" en lugar de la "productividad"?"Está más cerca del diseño, sí". Pero los negocios son negocios, y los procesos internos de ingeniería son procesos internos de ingeniería. Toda la sal es que su principal área de responsabilidad es la organización del trabajo en la "célula de la sociedad", que produce el producto final.
Más precisamente, el líder del equipo tiene dos puntos de enfoque. El primero es la organización misma del trabajo en el microcolectivo, desde la recopilación de datos de entrada hasta la entrega del resultado. El segundo es la provisión de interacciones sociales dentro del equipo y el establecimiento de su conexión con el más alto liderazgo de TI. Si hay un sesgo claro en una dirección u otra, es basura.
- ¿Qué tiene que controlar el Timlid?- En primer lugar, busca garantizar que las reglas del juego adoptadas a nivel de empresa, unidades, grupos de empleados se respeten en su compensación. Existen reglas para producir un código, mantener la documentación, realizar eventos generales, lo que significa que todos deben seguirlos.
En segundo lugar, proporciona orientación técnica: es responsable de la descomposición de las tareas, su implementación en el desarrollo con el objetivo de hacer que su implementación sea lo más fácil y comprensible posible, y realmente supervisar su implementación. Se adjunta a la función subestimada y extremadamente importante del líder del equipo, para garantizar la integridad de los datos de entrada para el equipo. Tengo a estos muchachos parados en la entrada de su mini grupo como filtro: si un equipo recibe una mierda explícita en lugar de TK, el líder de su equipo presiona sobre el proyecto o producto hasta que formula los requisitos correctos.
Cuando es necesario, el equipo lidera a través de recursos de explotación, como el acceso a la red. Y, por supuesto, comprende cómo se estructura esa parte del sistema en la que participan sus compañeros de equipo, incluso para él está claro cómo funciona la integración. De lo contrario, no podrá formular correctamente en nombre de su equipo las tareas para los departamentos de prueba y operación.
En tercer lugar, un líder de este tipo en caso de fallas de cualquier tipo, que él mismo no puede enfrentar, las señala de inmediato y las pone en conocimiento de las personas que pueden resolver el problema. Si el equipo no tiene tiempo a tiempo, él, apenas lo descubrió, da un paso hacia su jefe y, sin desolación, admite: "No tenemos tiempo, porque estamos" subestimados "", y le ofrece soluciones.
En Mos.ru, la muestra de 2018, el líder del equipo es responsable de garantizar que las tareas recibidas por el equipo se cierren a tiempo, dentro del presupuesto especificado, con la composición actual de especialistas. Esto es ideal Algo falla: inmediatamente saca a relucir un problema que no puede manejar con sus recursos disponibles y lo "aprieta" hasta que se resuelva dentro del equipo o uno o dos niveles más arriba. Al menos no deja el proceso problemático por sí solo.
Por lo tanto, el líder del equipo es un gerente técnico de pleno derecho, no una especie de apéndice de la categoría de "déjalo ser".
- ¿Qué otras responsabilidades se pueden, o se deben, dar al cuidado de un Timlid?- Los timbales realizan otra parte de sus funciones con bastante frecuencia, solo dependiendo de las circunstancias, les prestan más o menos atención desde la organización. Por ejemplo, un ajuste de la metodología de desarrollo: usted, como líder del equipo, ve lo mejor de todo si la metodología elegida para todos es adecuada específicamente para su sitio. A menudo resulta que no. Imagine que todos están aserrando una GUI, y usted es un componente de servicio. Obviamente, sus procesos no son los mismos que los de sus vecinos.
, «» : , , - «- ». HR-. , , , . . HR- .
, . , - . .
. - , , , . : , . , : «- , - ».
, — , , — . . , Mos.ru . , . - , . , «» , , , : , . , : , , .
— «», ?— , - . , . . — , , - . , code review, - , . , (, ). , Vue.js, PostgreSQL 10 «» . , , -, .
, . , , : , Sphinx Avito. .
, , — - , . . , , , .
- , . , , , .
— , ? , back-end front-end .— . , , , «», . «» , , , .
— — , — ? , ? «»?— , . . - , - — . . , , , . , IT — , . . : , .
CTO . — , ? , « — — » — , , , ? .
— , , , ?— , . , - . — . , . .
, , . . , : « PHP, Go, - -». , , .
, «», : , , .
. - , . - « ». , , .
— . . — . HR-. , . , ? , , . , , — - .
— . , . — .
, soft skills, , , , . , ? , . : .
— «» «-». , , . , ? ?— , . — — . , : « ». , . , — . .
Saint TeamLead Conf : , «», «».
, — — . , , , : « , — ». : , .
, , : : « , , — - ».
— ? ?— , , soft skills. , , , , , .
, , , , , . — , , .
— , , , ? ?— - . , . 7±2, , , , , ( ). -, — -.
— , ? ?— : , .
:
• . , , , , , .
• , , , , , , .
• , , .
— , IT , ?- no! . , «» IT-. , , : , «» .
TeamLead Conf, , «», , , , — , , — .
, , . , Mos.ru , . : . Banki.ru , , , , ; - .
— . , , , , review. .
, Saint TeamLead Conf, — . , , , , , .
— , TeamLead Conf , , ? ?— , , , - . , .
— , .
— IT , «» ? ?— . . , - - . , . - .
— ? « », , - ?— . , - : , , , IT-, . , « », .
«» —
HighLoad++ , ++, «» — Whale Rider Aletheia Business. « »: , , , .
, Saint TeamLead Conf . , ?
Los materiales del Spring TeamLead Conf se han publicado completamente en nuestro canal de YouTube . También aparecerá un video de la nueva conferencia, pero dentro de unos meses. Suscríbete si no quieres perderte.
Todas nuestras noticias sobre gestión y emprendimiento las recogemos en el boletín. Incluye: publicación de artículos y transcripciones, videos abiertos, oradores geniales y otras utilidades. Si está interesado, regístrese .