El director técnico de ivi,
Evgeny Rossinsky (
eross ), conoce bien a los participantes en nuestras conferencias sobre informes sobre el
aspecto técnico de la transmisión. Pero hoy tiene la transcripción del informe de Eugene sobre
TeamLead Conf sobre cómo se refleja la transformación ágil en los líderes de equipo.
No hace mucho tiempo en ivi pasamos por la transformación ágil y obtuvimos un buen beneficio en términos de:
- negocio
- velocidad de desarrollo
- tiempo de comercialización;
- Otras métricas interesantes.
Pero las consecuencias de esta decisión creativa golpearon bastante seriamente a los líderes del equipo. El informe trata solo sobre cómo lidiar con esto y qué herramientas usar.
Antes de la transformación
Para entender de qué hablaré, necesitamos familiarizarnos un poco con nuestro producto. Luego analizaremos por qué tenemos ese formato de comandos y por qué elegimos este camino.
El desarrollo en ivi se desarrolla en
cinco plataformas principales :
- iOS
- Android
- Web
- TV inteligente
- Windows + Xbox.
Y, por supuesto, el backend, sin el cual en ninguna parte. Antes de decidir llevar a cabo la transformación, nuestros equipos estaban formados por competencias.
Chicos que saben, por ejemplo, Swift u Objective C:
- sentado en la misma habitación;
- recibir tareas de gerentes de producto;
- trabajar en ellos y producir un resultado.
Todo parece estar bien, pero hay un problema: las plataformas son muy diferentes en términos de consumo de contenido de producto y usuario.
Esto significa que
en cada equipo comenzó a aparecer su cartera de pedidos y sus prioridades. Por ejemplo, a los usuarios de una aplicación web no les gusta pagar, y el contenido se consume a través de un modelo publicitario. Las características que se necesitan para esta plataforma aparecen naturalmente en la cartera de pedidos. Los televisores inteligentes se caracterizan por el hecho de que están bien comprados y las características de un modelo pago se manifiestan.
Resulta la siguiente situación: a alguien se le ocurrió una idea brillante de cómo mejorar un producto; Escribí muchos tickets para los gerentes de producto, cada uno responsable de su plataforma. Los gerentes pasan las ideas a través del prisma de su percepción, tal vez modernizan algo y lo incorporan a su plan de trabajo. El problema aquí es que una característica se puede lanzar en todas las plataformas durante más de un año, porque "creo que no es en absoluto una prioridad para mi plataforma". Y en un año, seis meses o solo unos pocos meses, cualquier cosa puede sucederle al producto; por ejemplo, se produce un rediseño o un cambio de concepto, y esta característica ya debe implementarse, y es completamente diferente a todas las demás plataformas.
Como resultado, después de un tiempo resultó que
en diferentes plataformas tenemos productos completamente diferentes con diferentes mensajes de comunicación y lógica de negocios. El usuario en esta situación comienza a confundirse, porque no tiene un solo espacio en el que se sienta seguro. Además, es
muy difícil construir hipótesis , ya que no siempre está claro en qué plataforma se disparará mejor la funcionalidad. Todo depende del tamaño de la pantalla, de cómo las personas consumen contenido. Y todo se parecía a esto:
El ingenioso producto trae la idea, y los desarrolladores en diferentes plataformas la perciben como poco amigable, con la excepción del backend, que en general no importa qué escribir.
Entonces, dado que la compañía tenía suficientes competencias con respecto a las metodologías flexibles, acordamos con el negocio que necesitamos eliminar la barrera entre:
- producto
- negocio
- tecnología
interactuar productivamente y hacer una cosa común.
Después de la transformación
Esto dio como resultado una arquitectura con
Value Stream dedicado, en el que cada equipo participa en un área comercial específica.
Para formar una nueva estructura nosotros:
- condujo varios entrenamientos;
- Determinado cuáles son las áreas principales para nuestro negocio;
- voluntariamente obligaron a las personas a ingresar en la corriente de valor;
- comenzó a implementar.
Es cierto que antes de esto hicimos uno de esos equipos, en el ejemplo del cual realizamos
demostraciones , después de haber eliminado una característica en todas las plataformas con un excelente tiempo de comercialización.
Además, la función se eligió muy bien y tuvo éxito en todas las plataformas. Así que tuvimos un ejemplo que mostró que
todo se puede hacer más rápido y mejor . Esto permitió que todo el equipo de desarrollo de 130–140 personas entendiera que usted puede trabajar de manera diferente.
Cuando determinamos el flujo de valor, surgió la pregunta de qué hacer con los líderes de equipo. Anteriormente, eran la base de todo en su dirección, pero ahora hay una corriente de valor y una mayor influencia del negocio. Que hemos hecho Reunimos personas de diferentes competencias en cada flujo de valor, al menos uno cada uno:
- desarrollador iOS
- Desarrollador de Android
- Desarrollador JavaScript
- Especialista en Smart TV
- diseñador de maquetación,
- al probador.
Resultó ser un equipo independiente, pero
independiente en palabras y en hermosas diapositivas de un entrenador ágil. De hecho, todos olvidan que sigue habiendo algo en común entre las personas que pueden escribir en el mismo lenguaje de programación: este es su código de programa, a través del cual deben comunicarse de alguna manera. Por alguna razón, muchos guardan silencio al respecto, pero este es realmente un problema bastante grande que debe recordarse.
Supongamos que pones personas en diferentes pisos o habitaciones, y escriben el mismo código. Hay un ciclo de lanzamiento y características que no deberían interferir entre sí. Hay muchos problemas
Del concepto
Hemos adoptado varios conceptos básicos:
Tenemos
flujo de valor y
comandos de plataforma . En el flujo de valor, los chicos implementan una característica específica, y en las plataformas hay un líder de equipo: el centro de competencias. Dentro de las plataformas, también se pueden desarrollar algunas características, pero esta es más una vista arquitectónica sobre el desarrollo de software.
Introdujimos el concepto de "
Gremios ". Al colocar a los mismos desarrolladores de iOS en diferentes salas, necesitábamos darles una señal formal e incluso informal, de que seguían siendo los mismos desarrolladores de iOS, y no solo participantes en el flujo de valor del producto publicitario, por ejemplo. Y luego con este gremio necesitas hacer algo y de alguna manera enseñar a las personas a comunicarse dentro.
La siguiente pregunta fue
qué hacer con los ciclos de lanzamiento . En aquellas plataformas donde puede desplegarse cuando la función esté lista, no hay preguntas. Y en el caso de iOS o Android, cuando, debido a los detalles específicos de recibir la aprobación de Apple, es imposible enviar la aplicación dos veces al día para su lanzamiento, es necesario acumular algunos paquetes.
Decidimos que cada plataforma que no se pueda lanzar de inmediato se lanzará
una vez cada dos semanas . Pusieron a disposición de todos un calendario especial, donde el equipo publica la fecha de
congelación y la fecha de lanzamiento. Si, al estar en la cadena de valor, desea que su tarea esté disponible para un usuario real, debe estar a tiempo para congelar las funciones. Tuve tiempo, bueno, no tuve tiempo, está esperando el próximo tren.
Tímido en el nuevo esquema
¿Qué les pasó a los tímidos? Pasaron por el esquema clásico de conciencia de los problemas que no se pueden resolver.
Al principio nos encontramos con una
negación . Debido a que el líder del equipo había estado construyendo un equipo genial durante varios años, nutrió a cada empleado y atrajo a alguien de la competencia. Y estos especialistas ahora han sido asignados a un trabajo que no siempre cumple con sus expectativas.
Por supuesto, después de la negación hubo
ira .
Hubo muchos escándalos, después de los cuales comenzó la
negociación . A todos se les ocurrió una pregunta: "Dejen que todos tengan su propio camino, pero lo tendré como antes, pero tomaré un marcador, escribiré" Agile "en mi casa, iré en una camiseta con esta inscripción, pero todo será como antes". No funcionó.
Pero al final, lo que realmente esperaba sucedió: la gente entendió por qué estábamos haciendo esto. Espero que lo hayan entendido, aunque tal vez hayan mentido. El primer caso exitoso mostró una diferencia realmente sorprendente entre lo que era antes y cómo se puede hacer de manera diferente. El tiempo de comercialización reducido a la mitad nos permitió establecer un punto de referencia para todos. Se produjo el siguiente paso, que en el modelo clásico de psicología se llama
Síndrome de Estocolmo . Las personas que adoptaron las nuevas reglas aprendieron a existir en ellas y comenzaron a propagar lentamente esta "religión". No puedo decir para todos los Timlids, pero alrededor del 30% de ellos ahora son "predicadores" activos en esta dirección.
Problemas y dificultades
Ahora intentaré enumerar más estructuralmente las dificultades que encontramos:
Debido al hecho de que los empleados estaban sentados en diferentes oficinas, se perdió la comunicación verbal.
Se hizo muy difícil durante un mes , porque antes era posible preguntar rápidamente a un vecino, por ejemplo, de qué necesita heredar y luego obtener una respuesta. Y ahora está sentado en una habitación separada, hay personas a su alrededor cuya tecnología puede no gustarle y no hay nadie a quien consultar. Para hacerle una pregunta a alguien, debe escribir en un chat, y la persona que puede responder se ha ido; eso es todo, se le deja en sus propios dispositivos.
Inmediatamente comenzamos a
tener problemas con Code Review , lo que creo que no es un problema, sino un gran descubrimiento. Descubrimos que una
gran cantidad de empleados no son independientes . Supongamos que hay un empleado que, según las estadísticas, los problemas de revisión superaron el máximo la segunda vez, generalmente la primera vez, todo estuvo bien. Y cuando se fue a trabajar en la cadena de valor, por alguna razón se convirtió en 5-6 iteraciones.
Comenzaron a comprender, y resultó que la opinión autorizada de la figura icónica del líder del equipo, que controla, centraliza todos los flujos de información en relación con él, no afecta muy bien el desarrollo de los desarrolladores.
Las personas son flojas , piden ayuda en todos los temas y reciben respuestas competentes. Y así, la revisión es rápida y genial. Al estar a solas consigo mismos, muchos desarrolladores tuvieron que
crecer bastante por
encima de sí mismos para tomar las mismas decisiones arquitectónicas . A nadie le gusta escuchar cinco veces seguidas que su código no es muy bueno. Es frustrante, hace que te consideres un empleado insuficientemente calificado, incluso puede conducir a la depresión o la convicción de que tal vez el trabajo sea malo. Pero el punto es que necesitas mirarte a ti mismo, comprender que en el modo de operación anterior no pensabas en estas cosas, pero ahora estás
desarrollándote y debes comenzar a pensar en ellas .
Por otro lado, tuvimos algunas cosas muy interesantes que, en mi opinión, son redundantes con respecto a la Revisión de Código. Había una regla en uno de los equipos: para que la tarea sea aprobada, todos los miembros del equipo deben tomar su decisión. Cuando todos se sentaron juntos, tuvieron más o menos éxito, y ahora todos se sentaron, algunos tuvieron una reunión de pie todos los días, otros tuvieron otros asuntos, y las tareas de revisión se convirtieron en un estrecho cuello de botella. Una y otra vez en retrospectiva, aprendieron que algunas tareas estaban pendientes de revisión durante dos semanas y se vieron obligados a cambiar algo.
Entonces comenzó:
separatismo, discriminación y envidia .
Anteriormente, una persona pensaba que sabía lo que quería hacer. Y con la separación del flujo de valor y la plataforma, comenzó a surgir la sospecha de que "el vecino sabe mejor": las tareas son más interesantes y el crecimiento es más rápido. El segundo problema es que cuando todo se
centra en las
características , la
calidad del código se deteriora mucho. A su alrededor, hay personas que desean obtener rápidamente el resultado, y no es su tarea pensar que tendrá que ser apoyado, modernizado de ninguna manera, y nada debería alejar a los colegas de la nueva función.
Comenzaron a surgir situaciones en las que la alta velocidad de desarrollo tenía su lado opuesto:
un código de baja calidad , que comenzó a multiplicarse en cantidades inhumanas. Cuando el líder del equipo responsable asume la corrección de estos errores y refactoriza, resulta que su vida se convierte en basura para los empleados negligentes. Los desarrolladores se apresuran a obtener todo, todos están contentos y no se dan cuenta del trabajo titánico del líder del equipo, gracias a lo cual, de hecho, todo funciona. Después de aproximadamente dos meses, cada líder de equipo expresó su insatisfacción con la situación actual.
Para resolver estos problemas, mantuvimos varias reuniones primero con los Timlids, y luego con todos los gremios para explicar a la gente que es posible trabajar de manera diferente. Si quieres probar algo más, entonces con esto necesitas llegar al liderazgo del equipo, y puedes cambiar fácilmente de lugar. Lo principal es ponerse de acuerdo entre ellos.
La fortaleza de las metodologías flexibles es que no les importa a todos cómo sucede todo, lo principal es que las personas estén de acuerdo y estén satisfechas.
Esto es por un lado. Por otro lado, para que haya justicia con respecto a quién está involucrado en la refactorización y quién está haciendo nuevas funciones, los líderes de equipo comienzan a trabajar con retrasos, volveré sobre esto un poco más tarde.
Y luego comenzaron las
dificultades con Release Management . Hay probadores en el flujo de valor, probadores en las plataformas, algo está automatizado, algo no está automatizado, debe pensar en cómo hacer una regresión general. Y hay términos. Voluntariamente decidimos liberar una vez cada dos semanas, y ¿qué pasa si un socio llega junto con una solicitud de hacer todo para mañana (y una bolsa de dinero, por ejemplo), decirle que espere el próximo ciclo? Aún así, se
debe buscar un
compromiso . Y luego, un hermoso esquema con lanzamientos puede cambiar mucho.
Un buen ejemplo es la ley FZ-54, según la cual todas las compras en Internet deben ir acompañadas del envío de cheques electrónicos a los usuarios y al impuesto. Puede hablar en conferencias tanto como quiera y hablar sobre metodologías flexibles y sobre las regulaciones, etc., pero tan pronto como existe el riesgo de obtener una penalización del 70% de sus ingresos, cambia a un régimen completamente diferente y se asegura de que su empresa no sea multada. Tales casos son poco frecuentes, pero los hay. En particular, tuvimos que hacer el segundo nivel de comunicación en caso de cambios en el esquema. No es fácil, pero posible.
El siguiente problema que encontramos como resultado de la transformación está relacionado con los
nuevos empleados . En mi opinión, los principiantes deberían estar inmersos en un entorno lo más cercano posible al que él trabajará. Y allí, debido al medio ambiente, recibirá rápidamente los conocimientos necesarios. Pero arrastramos a los especialistas que conformaron este entorno a diferentes pisos y habitaciones. La vida de un principiante en una empresa se convierte en una tarea gerencial bastante seria, cuya solución debe ser pensada.
Las herramientas
Aquí están las herramientas que utilizamos.
Comenzaré la historia con un
mapa de ruta para un nuevo empleado. Desafortunadamente, esto es algo que aún no hemos aprendido cómo automatizar completamente y, de hecho, pensar en cada empleado por separado, dependiendo de lo que haga.
Hubo un ejemplo bastante interesante: necesitábamos hacer crecer un
probador universal , que pudiera probar absolutamente todos los productos para un flujo publicitario. Tienen mucho en común, pero también tienen sus propios detalles. No es ningún secreto que un probador que es bueno para probar una aplicación web se perderá por primera vez cuando trabaje con herramientas, por ejemplo, para iOS. Para este probador, nuestro director de control de calidad construyó un mapa de ruta especial. En esta tarjeta, un nuevo empleado en cada competencia adquirió conocimiento durante dos semanas, participó en regresiones y más. Con los desarrolladores, la situación con la implementación es aproximadamente la misma. Por lo tanto, incluso en la entrevista, descubrimos a qué se dirige Candida y qué le interesa, y tratamos de elegir en qué dirección enviarlo.
Por supuesto, la primera vez que un nuevo empleado bombea competencias, es decir, en nuestros términos, está en el equipo de la plataforma, y luego ya puede migrar al flujo de valor que necesitamos. Por cierto, los mapas de rutas son buenos, pero tampoco es necesario descartar su adaptabilidad.
Luego presentamos
Guild Sync - sincronización de acciones de gremio .
¿Por qué se necesita esto? Todos escucharon una conferencia sobre Scrum, que hablaba sobre la necesidad de una reunión diaria de pie para informarles lo que está sucediendo. Pero nuestro especialista, por ejemplo, es un desarrollador de Android, por un lado, y un miembro del equipo del producto, por otro lado. Si tiene que caminar y comunicarse dos veces al día, recibirá algún tipo de culto a Cargo. A este ritmo, puede pasar toda su vida en reuniones. Definitivamente, molestará a la gente.
Si decimos que estamos basados en un modelo centrado en características, entonces la reunión diaria de pie es más importante en su flujo de valor. Pero al mismo tiempo, puedes separarte de lo que sucede en el gremio. Para hacer esto, algunos gremios organizan reuniones una vez por semana, algunas, dos veces por semana. Y aquí el líder del equipo piensa metódicamente sobre lo que vale la pena hablar. Esto no debería traducirse en una conversación vacía, es una estrategia de desarrollo para el equipo de tecnología, que es el gremio. Se necesitan reuniones de Guild Sync para que todos comprendan qué tecnologías utilizará la empresa, qué decisiones estratégicas se toman con respecto a esta plataforma. En él, se realiza una revisión parcial de las soluciones arquitectónicas.
En algunos equipos tenemos más de un líder de equipo. En general, la definición de liderazgo del equipo es muy ambigua. Hay
líderes de opinión que pueden ser líderes de equipo y llevar la solución de algunos problemas organizacionales. Puede haber varios líderes de opinión con habilidades de gestión en un equipo. Y luego pueden organizarse, quién es responsable de qué. Por ejemplo, uno de los líderes de opinión puede ir al flujo de valor. En este caso, debe sincronizar sus decisiones arquitectónicas, que en el futuro determinarán la estrategia de desarrollo de toda la plataforma tecnológica.
Luego comenzamos a realizar
mitaps internos y externos en ciertas áreas. En general, este es un caso bastante estándar en parte de RRHH, en parte en equipo. Para las reuniones internas, a veces se realiza una votación sobre el tema que es más interesante, se buscan oradores dentro de la empresa o invitamos a alguien del exterior, alquilamos una sala especial y discutimos varios puntos importantes. En promedio, tenemos dos mitaps internos por mes, pero a veces cuatro. Las personas de otras competencias pueden venir a estos mitaps para escuchar cómo viven los vecinos y ver si quieren cambiar su especialización. Esto también pasa.
Ahora en el mercado laboral en materia de desarrolladores, no todo es muy simple. , , . , ,
, . , , .
. , , Agile- , Guild Sync .
, , , . , , Guild Sync , .
, , , ,
, . 10 .
—
. , , -. - , , , . - , , , . , - . , , , , , - .
. , . , , , , . , , , . , - , , , , , .. .
, « ». , , .
Guild , . - , , .
, product owner' value stream. , 10 , - , , . , product owner' . backlog' . , , . , ( , , , , ).
— , .
Teamlead —
, , -
.
,
. , , , , , , — .
, , , « ». , , , . , , , , value stream. , , .
, , .
24 25 . - Saint TeamLead Conf .
, 40 , — 10 .