
Del 23 al 24 de septiembre, se
celebró Saint TeamLead Conf 2019 en San Petersburgo. Flant participó activamente en él: Igor Tsupko (nuestro director para lo desconocido) celebró una reunión en la que los participantes entendieron cómo encontrar y revelar conocimientos secretos dentro de la organización, y Sergey Goncharuk (gerente de proyecto) hizo una presentación "Gestión de un equipo distribuido en multiproyección ". Por tradición, publicamos una revisión del informe y
su video (~ 37 minutos).
"Equipo distribuido" y "multiproyecto"
Bajo un equipo distribuido, diferentes compañías entienden cosas muy diferentes, por ejemplo, una red de sucursales u oficina y trabajadores remotos ... Pero en nuestro caso no hay oficina en su sentido "real".

Ahora tenemos más de 80 empleados que viven en más de 20 ciudades de Rusia y más allá. La mayoría de nosotros nos vemos "en vivo" solo 2 días al año, en el cumpleaños de "Flanta".
El resto del tiempo que vivimos en Moscú, Samara, Tyumen, Nizhny Novgorod o cualquier otra ciudad, trabajamos con el canto de los pájaros o el olor a café. En lugar de alquilar un lugar, invertimos dinero en algo realmente útil. Y dado que todos trabajan de forma remota, no tenemos una división en "sucursales" o "castas".
Y lo más importante: contratamos a los mejores, a pesar de los límites. Eso es lo que significa "distribución" en nuestro entendimiento.

Ahora tratemos con el diseño múltiple, pero para empezar es importante sumergirse un poco en el dispositivo Flanta.
Somos una empresa de ingeniería, tenemos muchos ingenieros. De cinco a siete ingenieros, bajo la dirección del líder y gerente del equipo, forman el equipo. Hay varios equipos de este tipo, y cada equipo tiene su propio conjunto de proyectos.

Para nosotros, un proyecto es una infraestructura de cliente para un producto o un equipo de desarrollo. Es decir, el proyecto tiene límites claros, ¡pero no hay restricciones para el crecimiento y el desarrollo!

Cada proyecto tiene sus propias necesidades, que de alguna manera deben transmitir al equipo.
Esto lo hace el gerente. Estos son los conceptos básicos del "diseño múltiple".
Ahora que tenemos una comprensión común de los términos del título del informe, la pregunta es: ¿qué se necesita para garantizar que, en tales condiciones, todo no solo funcione, sino que funcione bien?
El gerente del equipo es responsable de resolver este problema. Ser un "traductor" del cliente a la ingeniería es una de sus competencias clave. El segundo es la organización de una comunicación constructiva dentro del equipo y con los clientes. Y la tercera competencia central es encontrar un equilibrio entre el flujo de trabajo y las capacidades reales de los ingenieros:

Analizaremos cada competencia con más detalle.
1. Expectativas de transmisión
Incluso el mismo cliente puede tener expectativas contradictorias. Por ejemplo, el negocio de un cliente requiere que la producción que genera dinero sea estable. Y además, se reponía constantemente con nuevas características que ayudan a aumentar los ingresos.
Bueno, si ocurre algún accidente (el negocio está listo para que ocurra el accidente), se eliminará lo antes posible. Eso suena muy predecible, ¿verdad?
Pero este cliente también tiene desarrolladores. ¡Y resulta que sus expectativas son completamente diferentes! Para los desarrolladores de desarrollo, la producción es más importante (después de todo, las empresas también los presionan), y también esperan que cualquiera de sus solicitudes se escuche y se haga en este momento (generalmente esto se describe con la frase "después de todo, hay 5 minutos de trabajo").
Lo único que une tanto a las empresas como a los desarrolladores en los requisitos es que ambos esperan que las tareas planificadas se realicen con precisión y a tiempo.

Miremos la imagen como un todo ... Sí, ¡está inmediatamente llena de párrafos mutuamente excluyentes!
- Agregar nuevas características siempre agrega nuevos puntos de falla. Babah! Y la producción es inestable después del lanzamiento del viernes.
- Nuestros ingenieros llevaron a cabo lo más rápido posible durante el día todo lo que los desarrolladores pidieron, y las tareas planificadas permanecieron intactas debido a esto.
- O aquí está la historia: ¿a qué entorno de estabilidad prestar más atención? ¡Estabilizamos el desarrollo al asignar recursos para esto, pero después de otro lanzamiento, la producción comenzó a caer!
- Un caso frecuente: la producción se interrumpió y todo el equipo fue a repararla. Al mismo tiempo, por supuesto, no hay progreso en las tareas planificadas, e incluso los desarrolladores de la India ya han cambiado al chat en ruso, porque no pueden esperar una respuesta.

Y entendemos que los requisitos en sí mismos son contradictorios, lo que significa que es imposible transmitirlos directamente.
2. Comunicaciones
Realmente hay problemas en las expectativas de transmisión. Bueno, ¿tal vez al menos con las comunicaciones todo es más fácil?
Para comunicarnos entre nosotros y con los clientes, utilizamos Slack para mensajes de texto y Google Meet para reuniones y ocasiones en las que es más fácil decirlo que escribirlo. ¡Pero en un chat a menudo recibimos mensajes que no tienen un significado útil o contienen tantos errores que es difícil reconocer el significado!

¿Por qué prestamos atención a esto? El hecho es que, por ejemplo, solo en julio de 2019 recibimos solicitudes de clientes de 1993 en Slack, que requerían una respuesta obligatoria. Y, por supuesto, con el crecimiento en el número de clientes, hay una tendencia constante en el crecimiento del número de solicitudes de este tipo. En julio, pasamos unas 165 horas de ingeniería en la reacción a tales llamadas. Pero para cada apelación, ¡también era necesario hacer algo!
Lamentamos mucho que se desperdicie el tiempo de los ingenieros, que podrían invertirse en tareas planificadas, reacción a otras llamadas o incluso para reparar accidentes.
El problema con las salas de chat es obvio, pero ¿la videoconferencia probablemente no tiene problemas?
Dijimos anteriormente que usamos Google Meet para las reuniones diarias del equipo, y el resto del tiempo hacemos las tareas que resolvimos en el rally. Todos los días pasamos aproximadamente una hora en manifestaciones. Intentamos dedicar al menos siete horas al día al trabajo directo, es decir, quedan 6 horas para completar las tareas. Pero nuestras tareas son muy diferentes en duración.

Resulta que en una hora de la concentración podríamos completar varias tareas pequeñas, pero probablemente importantes para nuestros clientes. Y tenemos que entender si realmente se necesitan reuniones de vigilancia o si es mejor ir a trabajar esta vez.
Si intenta unir los problemas de comunicación, vemos que el chat genera interrupciones inútiles y las reuniones regulares "comen" el tiempo de trabajo.

Las comunicaciones efectivas no se alinean por sí mismas.
3. Planificación
Bueno, necesitamos resolver problemas en las comunicaciones y las expectativas de transmisión, pero en la planificación, probablemente, ¿no hay obstáculos? Vamos a resolverlo.
Todos los días se crean una gran cantidad de nuevas tareas. Me gustaría que cerremos las tareas tan rápido como crezcan. Pero en la vida, un ideal rara vez es alcanzable. En primer lugar, a veces algo se rompe en la infraestructura. En segundo lugar, siempre hay algunas pequeñas cosas que son más fáciles de hacer de inmediato. En tercer lugar, hay tareas que acordamos resolver en una reunión de equipo:

¡Y a veces sucede que debido a accidentes y tirones de bagatelas, no es posible llegar a los planeados! Al mismo tiempo, las nuevas tareas no dejan de llegar: se rompen todos los plazos prometidos.
Nuestra receta

Pero para todos los problemas con la traducción de las expectativas, con las comunicaciones y la planificación, el método de relleno de conos, logramos, como nos parece, la respuesta correcta.

Uno de los procesos comerciales clave que afectan las tres competencias centrales es una reunión de equipo. ¿Y asumimos que si hacemos que una reunión del equipo sea efectiva podemos lograr el 80% del resultado con el veinte por ciento del esfuerzo? Probamos esta teoría.
Como recordará, tenemos un equipo al servicio de nuestro conjunto de proyectos. Y ella tiene una cierta lista de requisitos de estos proyectos. Pero cada requisito, por regla general, es solo uno en una cadena de tareas interrelacionadas. ¡Y así en cada proyecto! ¿Y antes de asumir una nueva tarea, debemos entender si hemos completado la etapa anterior?

Ayer, la tarea A-1 fue realizada por Egor, la tarea B-1 - Semyon, y la tarea B-1 - Jeanne. Pero, ¿cómo podemos sumergir a todos los ingenieros en todos los proyectos tan profundamente que Yegor logre hacer frente a la tarea B, y Semyon con dos pequeñas tareas A y B. "¿Por qué todas estas dificultades?" - usted pregunta ¡Sí, el hecho es que Zhanna no cumplirá las tareas planificadas de vacaciones hoy!

Nuestro enfoque es muchas tareas similares. En promedio, recibimos alrededor de 25 nuevas tareas para cada equipo cada día hábil. Y dado que hay muchas tareas, las conexiones entre ellas son confusas y no se comprende si se han completado todas las tareas del día anterior. Para desentrañar todo esto, necesitamos una reunión de equipo, y todos los días hábiles, de lo contrario no podremos gestionar este flujo.
Dado el volumen del flujo, vale la pena prepararse para el rally por adelantado. En la capacitación, sin ingenieros, no podremos entender qué tareas se han completado por completo y cuáles no. Y, por supuesto, no podremos transferir conocimientos de ingeniero a ingeniero. Pero somos inequívocamente capaces de determinar las prioridades para llevar a cabo nuevas tareas.
Priorización de tareas
¿En qué nos basamos para priorizar tareas? En primer lugar, tenemos acuerdos estratégicos con el cliente sobre los objetivos que deben alcanzarse. En segundo lugar, una vez por semana actualizamos los planes tácticos para una reunión en línea con el cliente. El gerente confirma las necesidades de preparación del cliente, y la necesidad técnica y el procedimiento para completar una u otra tarea es el líder del equipo. Así es, sobre la base de la
paridad de las opiniones del líder y gerente del equipo , se forma una lista de tareas para el día.

Cultura de las reuniones de equipo.
Tan pronto como hayamos determinado la lista de tareas para el día con el fin de aclarar lo que se ha hecho y sumergir a nuestros colegas en los detalles, comenzamos una reunión de equipo en la que cada ingeniero debe contar en detalle lo que hizo ayer, y todo el equipo debe escuchar y, lo más importante, comprender los cambios que han tenido lugar. Pero esto es más fácil decirlo que hacerlo.
Introdujimos una serie de características culturales de la manifestación, que nos permitieron lograr el resultado deseado:

Al comienzo de la manifestación, mientras todos se reúnen, pasamos 10-15 minutos hablando de la vida. Sobre noticias y eventos no relacionados con el trabajo, sobre pasatiempos de colegas. Entonces, los ingenieros que están en diferentes ciudades y casi nunca se ven se hacen amigos o incluso amigos. Y
estos 10-15 minutos al día ayudan al equipo a estar más unido .
Después de la conversación de trabajo en equipo, procedemos a la parte sustantiva. Volvamos un poco.

¿Recuerdas esta ilustración? El hecho es que ni Semyon ni Yegor saben qué tareas y proyectos llevarán a cabo hoy antes de que comience la concentración. Por varias razones: vacaciones, viajes de negocios, enfermedad, deber, etc. - la tarea puede cambiar a los artistas todos los días hasta que se resuelva por completo. Y cada ingeniero comprende que hoy se le puede asignar una tarea, es decir, todos los ingenieros ya están inicialmente
interesados en profundizar en los detalles de cada tarea .
En el mitin, analizamos los bloqueos que han surgido por todo el equipo. Insistimos en que todo el equipo participe en la resolución del problema del orador. Así que nos
motivamos a sumergirnos en tareas y resolverlas juntos .
Si el equipo trabaja en la oficina, la comunicación informal a menudo se produce "en el refrigerador". Pero en un equipo distribuido, existe la necesidad de dicha comunicación. Es por eso que, durante una discusión de tareas, la conversación a menudo se filtra en algún lugar en la dirección equivocada. Pero detenemos cualquier distracción. Como exactamente Logramos hacerlo con bastante facilidad: después de todo, hay un tiempo especialmente asignado para conversaciones abstractas, y ahora es tiempo de trabajo. Por lo tanto, incluso el habitual "vamos al grano" oral es suficiente para que todos regresen a la agenda de negocios. Al detener las distracciones en el proceso de analizar las tareas,
configuramos el equipo para trabajar .
Intentamos controlar el tiempo de informe de cada ingeniero. A veces, para sumergirnos en los detalles, necesitamos una historia larga y detallada sobre la tarea. Sin embargo, en la mayoría de los casos,
tratamos de no estirar el rally .
Manifestaciones efectivas: ¿una bala de plata?
Gracias a la preparación para el rally sobre la base de la paridad de las opiniones del líder del equipo y el gerente y nuestras características culturales del rally, realmente los hicimos efectivos. ¿Pero lograste cerrar el 80% de todas las competencias? En realidad no

Hicimos un buen trabajo con las expectativas de transmisión, pero todavía había problemas con mensajes de chat poco informativos en las comunicaciones, y hubo interrupciones en la planificación que nos impidieron realizar tareas programadas de manera efectiva.
Sí, pero los mensajes de chat no informativos también son interrupciones. Y necesitamos encontrar un mecanismo que nos ayude a manejar eficientemente las interrupciones de todo tipo.
Interrupciones de lucha
Pensamos, ¿y si tenemos una persona separada que "cubrirá" con nosotros mismos un equipo que trabaje en tareas planificadas desde el flujo de interrupción?

La idea no es nueva y generalmente buena, pero ¿quién lo hará exactamente? Consideramos dos opciones: encontrar y contratar dicho servicio o usar ingenieros existentes. La búsqueda de nuevas personas requirió tiempo y recursos financieros, y los ingenieros existentes ya fueron "probados en la batalla" e inmersos en todos los proyectos del equipo. Por lo tanto, la opción de contratar nuevas personas fue rechazada.
Queda por decidir sobre la cuestión de cómo organizar dicho servicio de los ingenieros actuales. Aquí la solución estaba en la superficie: simplemente aplicaban el servicio en un horario, con una rotación de ingenieros del equipo. Mantenemos el cronograma de servicio en Google Calendar, además de configurar notificaciones en Slack sobre quién está en servicio hoy.

Parece que todo debería estar bien ahora? Hurra? No, en realidad el problema persiste. Recuerde, un poco antes dijimos que solo en Slack recibimos casi 2,000 visitas al mes, lo que equivale a 16 visitas diarias para cada equipo. Pero además de Slack, el asistente tendrá que procesar los mensajes de los sistemas de monitoreo y el día que:
- 112 - de Prometeo;
- 16 - de okmeter;
- 25 - de sistemas externos de monitoreo de caja negra;
- 14 - de varios scripts personalizados;
- e incluso 2 llamadas telefónicas de clientes.
¡Esto es 198 interrupciones diarias de diferentes fuentes! Pero, de hecho, hay aún más fuentes:
- Casi todos los clientes tienen un Prometeo;
- y Okmeter está instalado en cada cliente;
- pero scripts personalizados, incluso un cliente puede tener tantos como desee ...

Para que cualquier ingeniero del equipo pueda hacer frente a esto sin magia y superpoderes, recopilamos alertas de todas las fuentes de interrupción en un solo lugar. Llamamos a esta herramienta Madison, y cada mensaje que contiene es un Incidente.
Pero Madison solo recolecta incidentes y mantiene una fortuna sobre ellos. Pero necesitamos entender qué tipo de incidente se debe tomar primero, es decir, realizar una clasificación, tener un orden claro de procesamiento y escalamiento, de modo que pueda realizarse fácilmente en una situación estresante.
También creamos dicho instrumento, lo llamamos Polk:

Polk es el lugar de trabajo del ingeniero de servicio. Permite al asistente concentrarse solo en incidentes, sin distraerse con las tareas planificadas, recibir incidentes de todas las fuentes en un solo lugar, ayuda a determinar la importancia de un incidente de acuerdo con una gravedad predefinida, tiene un conjunto de estados claramente definidos y un algoritmo de procesamiento que determina el movimiento de estos estados.
Características técnicas y culturales del chat.
Excelente: ahora el asistente, equipado con una herramienta tan poderosa, realmente cierra el equipo de las interrupciones. Pero incluso con tales herramientas, el reloj es agotador, y las interrupciones inútiles solo agregan combustible al fuego.

Para combatir las interrupciones de chat inútiles, podemos usar un pequeño conjunto de herramientas técnicas, pero la solución principal a este problema definitivamente radica en el plano cultural.
Desde un punto de vista técnico, en Slack compartimos información sobre proyectos, creando un canal separado para la comunicación con representantes de los clientes, y para cada proyecto, un canal para que los ingenieros discutan el trabajo en él. También escribimos el bot
@flant
, cuando Polk accede a él, se crea automáticamente un incidente que procesa el oficial de servicio.

Además, recomendamos a los clientes que utilicen
@flant
y
@channel
(un evento que notifica a todos los miembros del canal) y
@here
(un evento que notifica a todos los miembros del canal en línea) para usar solo en esos casos raros y excepcionales en los que realmente no puede prescindir de ellos (por ejemplo, cuando el
@flant
bot no
@flant
disponible).
El primer día de nuestra cooperación con el cliente, publicamos instrucciones detalladas sobre la interacción en el canal. Y en la primera reunión regular, definitivamente discutiremos la interacción, incluida la diferencia entre
@channel
,
@here
y
@flant
.
En particular, nos enfocamos en el hecho de que la llamada a
@flant
para nosotros, en primer lugar, es una acción con una reacción obligatoria, y
@channel
y
@here
para la mayoría del equipo es solo una interrupción, que también no tiene dirección y puede ignorarse mientras distrae a todo el equipo de resolver tareas planificadas, incluso para este proyecto.

Pero nuevos colegas acuden al chat de clientes que no conocen el bot. Otros simplemente lo olvidan. Si esto sucede, recordamos suavemente su existencia.

Para la comunicación entre ingenieros, utilizamos las mismas reglas para
@channel
y
@here
: no los use a menos que sea absolutamente necesario. Y, sin embargo, insistimos en adherirnos a la regla "No solo diga" hola "en el chat, formule inmediatamente un pensamiento". Esta regla es una lectura obligada para todos los principiantes. A aquellos que lo olvidaron se les recordará esto, si es necesario, desplegados.
Total: con la introducción de turnos y la corrección de problemas de comunicación en el chat, enfrentamos la mayoría de las interrupciones inútiles y la influencia de las interrupciones en el desempeño de las tareas planificadas.

Dilación y bloqueo
Luego de eso, verificamos cómo mejoraron nuestros indicadores: de hecho, se volvieron claramente mejores, pero aún había un problema en la planificación.
Cuando termina la concentración del equipo, es hora de trabajar. Pero a menudo, los ingenieros, especialmente aquellos que trabajan remotamente, tienden a postergar. O, durante el trabajo, encuentre un problema y camine en círculos en un intento de resolverlo.

Tratemos de lidiar con la dilación. ¿Cómo superarlo? Hay demasiadas tareas en Redmine (nuestro rastreador de tareas): necesita centrarse en las que estarán en el trabajo hoy. E incluso entre ellos, debe comprender qué tareas hacer primero, es decir, determinar las prioridades. E idealmente, si planea aproximadamente el tiempo que estamos listos para gastar en cada tarea ...

Creamos una herramienta que ayuda a resolver todo esto, y lo llamamos Ford:

Es en él que el ingeniero recibe una tarea para la jornada laboral en forma de tarjetas dispuestas en orden de prioridad. Para todas las tareas planificadas, establecemos el tiempo aproximado que el ingeniero debe cumplir al resolverlas. El ingeniero tiene en cuenta el tiempo que dedicó a resolver el problema. Y si el tiempo es aproximadamente el mismo, pero el problema no se resuelve, este es un marcador de que el ingeniero ha llegado a un callejón sin salida.

¿Qué se puede hacer con esto? Además de la prioridad en la que se encuentran las tarjetas,
También presentamos categorías prioritarias, las resaltamos con colores:
- El cuadro gris se usa para tareas ordinarias y programadas;
- Campo verde: para tareas que deben iniciarse en el día actual solo si las tareas en todos los demás campos han terminado;
- El campo amarillo es para tareas que repentinamente ocurrieron no planificadas durante el día;
- Campo rojo: para tareas que deben resolverse antes del final de la jornada laboral actual.
Si un ingeniero es bloqueado por una tarea en los campos gris y verde, entonces solo tiene que comenzar la siguiente tarea y desmantelar la cerradura en la próxima reunión del equipo.

Pero es obvio que si un ingeniero está bloqueado por tareas en las zonas amarilla o roja, entonces no debe esperar a la próxima reunión: debe solicitar ayuda del equipo en el canal apropiado para que los ingenieros se comuniquen sobre el proyecto en el que se establece la tarea. Y, de acuerdo con nuestra cultura, los ingenieros del equipo o los líderes del equipo definitivamente vendrán al rescate.

Vale la pena mencionar que las capacidades de Ford son mucho más amplias y hemos tocado solo la "punta del iceberg", que puede implementar utilizando otras herramientas abiertas.
Resumen
Resulta que para combatir la dilación y el bloqueo, usamos Ford como una solución técnica y reglas simples en la cultura del equipo.

¿Nos ayudaron estas herramientas? Si! Pero por alguna razón, no 100%?
El hecho es que el mundo está cambiando y avanzando. Y también estamos cambiando en estas condiciones, luchando por el ideal, pero, como saben, es inalcanzable.
Sobre el logro de los ideales y el papel del gerente
Todas las grandes cosas que la humanidad ha creado durante todo el período de su existencia han sido realizadas por equipos de profesionales que tenían gerentes geniales.


Nosotros, Flant, también somos un equipo de profesionales. Y sería genial si hubiera más gerentes geniales en nuestro equipo. Acérquese a nosotros para trabajar y ayudar a mejorar nuestros procesos:

Videos y diapositivas
Video de la actuación (~ 38 minutos):
Presentación del informe:
PS
Lea también en nuestro blog: