Cuando en artículos e informes hablan sobre casos en la gestión de equipos, a menudo se limitan a decir qué estaba mal y cómo cambiaron la situación. Pero esta vez tenemos una oportunidad única para descubrir cómo el equipo vivió más y cómo terminó todo; de hecho, no terminó, sino que continuó.

Aquí hay una continuación de una historia titulada " Cómo sobrevivir a una escalada escalable y mantener el control de calidad del código " sobre la transformación ágil en ivi. En TeamLead Conf, el director técnico de la compañía, Evgeny Rossinsky ( eross ), explicó por qué podría ser necesario revertir toda la reorganización del equipo, cómo no discutir y ayudar a los desarrolladores, sino también para mantener y aumentar la eficiencia del negocio.

Contexto de la empresa

ivi: el cine de Internet legal más grande con una audiencia de 48 millones de usuarios, que colectivamente pasan 70 millones de horas mensualmente. Ivi tiene 62 mil unidades de contenido, que está disponible desde diferentes dispositivos y siempre en excelente calidad.

Dio la casualidad de que el mismo día en que Eugene habló en TeamLead Conf con este informe, era el cumpleaños de la compañía. Hace 9 años, tuvo lugar el primer lanzamiento de la versión web del proyecto, y después de 2 días, la fortaleza de Channel One atrajo a un gran número de usuarios a ivi. La compañía incluso pensó que era DDoS, pero pudo resistir con dignidad.

Este artículo trata sobre el lanzamiento de un nuevo producto: un reinicio completo de todas las aplicaciones.

Mire el video para escuchar la versión sin censura o lea la transcripción del informe en primera persona.



Primero, hablemos sobre las tecnologías y competencias utilizadas para comprender el alcance del daño.

Competencias:

• Backend (Python, Golang, Java);
• Web (JavaScript, Node.js);
• Android (Java)
• iOS (Objetivo-C, Swift);
• SmartTV (JavaScript);
• Windows / XBox (C #);
• Sony PS (JavaScript).

Para cada una de estas competencias en 2016, teníamos nuestro propio equipo, es decir equipo iOS, equipo Android, etc. También había un equipo de backend y, por separado, un equipo de gerentes de producto que idearon nuevas funciones.

El principal problema, debido al cual era necesario transformar, era que todas las plataformas son diferentes, incluso que tenían diferentes retrasos y prioridades. Y realmente queríamos construir un único espacio de información dentro de nuestras aplicaciones.

A menudo sucedió que apareció una característica compleja en todas las plataformas 4 meses después de su concepción. Al mismo tiempo, apareció en una plataforma después de 3 días, y luego, dependiendo de la priorización de los retrasos, se implementó en diferentes plataformas a diferentes velocidades. Resultó monstruoso por las siguientes razones:

• Durante 4 meses, la función ya podría adquirir un significado completamente diferente y la necesidad podría desaparecer.
• Debido a problemas de comunicación, que son obvios en este caso, las personas implementaron características de diferentes maneras.

Dado que el producto tiene tres modelos de monetización que funcionan con diferente eficiencia en diferentes plataformas, la priorización de la cartera de pedidos en cada plataforma fue diferente. Algunas características podrían, en principio, nunca implementarse en plataformas separadas.

Un breve recuento de la transformación.

En 2017, presentamos el concepto de Value Stream : estos son equipos multifuncionales que son responsables de tareas comerciales específicas. Para entender qué negocio específico es nuestro negocio, reunimos a unas 25-30 personas de toda la compañía, entrenadores invitados que participan en metodologías flexibles, y en 2 días formulamos cuál debería ser nuestro valor: direcciones de desarrollo.

Obtuve 5-6 secuencias de valor. Plantaron a estos tipos juntos, les dieron a cada uno un Propietario del producto, que se estaría ahogando por esta dirección en particular (más detalles aquí ).

Conocimos dolor, sangre, lágrimas y alegría y llegamos a muy buenos indicadores:

• Descarga sincrónica de características idénticas en diferentes plataformas .
• Una disminución múltiple en el tiempo de comercialización . El lanzamiento de muchas funciones se basó solo en el ciclo de administración de lanzamientos en cada plataforma, ya que, por ejemplo, Apple no permite descargar cada función por separado. Por lo tanto, las características están agrupadas y, en promedio, se lanzarán una vez cada dos semanas.
• Eliminación de "cuellos de botella" , que eran propietarios de productos y gerentes técnicos y líderes de equipo.
• Los desarrolladores comenzaron a entender por qué están "aserrando" una nueva funcionalidad.

Sobrevivimos muy bien el año: en 2017, los ingresos casi se duplicaron .

Pero esto no fue suficiente, y la vida a fines de 2017 - principios de 2018 nos dio una sorpresa.

¿Por qué necesitabas un nuevo producto?

El negocio ha establecido nuevas metas. La sorpresa fue que el desarrollo de cualquier software existe por el bien de algo. Pocos escriben código por razones altruistas. Para que la empresa justifique su existencia, sus propietarios y accionistas establecen ciertas metas que el equipo debe cumplir.

Nuestros accionistas no dicen cómo hacerlo, dicen lo que quieren lograr. Cómo: el equipo debe decidir.

El equipo enfrentó la tarea de idear cómo ganar más . Llevamos a cabo una lluvia de ideas, y el departamento de comestibles, junto con el técnico, llegó a la conclusión de que para alcanzar objetivos ambiciosos (condicionalmente, duplicar el tamaño de la audiencia que paga), en principio, deberíamos cambiar el énfasis de la visualización gratuita de la película a la paga.

Casi todas las hipótesis presentadas encajan muy mal en el concepto del producto anterior. Más precisamente, no encajaba en absoluto: cualquier flujo de motivación en las transiciones de los usuarios se basaba en el hecho de que se implementaba en algunas plataformas, en algunas no, hay algunas limitaciones, hay otras. Nuestro equipo tiene 9 años y hemos acumulado muchas cosas que nos arrastraron al fondo. En el buen sentido, era necesario reescribir todo.

Varios estudios cualitativos y cuantitativos han demostrado los problemas del antiguo producto . Resultó que estamos 2-3 años detrás de lo que la humanidad sabia ha pensado. Por ejemplo, si hace unos 5 años en dispositivos móviles estaba de moda y moderno poner un menú de hamburguesas en la esquina superior izquierda, entonces con el advenimiento de las pantallas grandes la gente dejó de llegar allí. Hasta 2018, realmente teníamos un menú de hamburguesas, y las personas de alguna manera lo enfrentaron.

El usuario pobre se acostumbra a todo, pero esto no significa que deba dejar todo como está.

Muchos marcos necesitaban refactorización. Encontramos fallas lógicas y, como en cualquier código de larga duración, teníamos muchos códigos viejos y no muy buenos. A los desarrolladores realmente no les gustó.

Por ejemplo, es muy difícil contratar desarrolladores que quieran escribir en Objective-C. Todos estamos influenciados por la moda e incluso perezosos: si hay alguna herramienta que le permita hacer lo mismo, pero de manera más rápida y eficiente, queremos usarla. Y la situación en el mercado laboral es tal que puedes escribir un resumen: "Quiero escribir en Swift", e incluso si no sabes cómo escribir en Swift, definitivamente llegarás a algún lado.

Algo tuvo que hacerse con esto, y este es uno de los problemas que impide el desarrollo. Por lo tanto, tuvimos que reescribir componentes obsoletos e implementar marcos modernos.

Objetivos

Queríamos:

• Crea un nuevo producto con un diseño único.
• Haga que nuestro buen sistema de recomendaciones sea responsable de emitir todos los bloques dentro de nuestro producto.
• Corrija los errores de la interfaz lógica.
• Limpia el código.
• Migrar a un nuevo sistema de estadísticas.
• Implementar un sistema de diseño.

Todos los desafíos son bastante ambiciosos, especialmente el sistema de diseño, porque hay muy pocos sistemas de diseño que funcionen multiplataforma y que estén divorciados del código del programa. Producen principalmente el motor JS, que se utiliza en diferentes plataformas. De hecho, el mecanismo para transmitir información sobre cómo debería verse el producto está dentro del código.

No podemos hacer esto muy bien, porque trabajamos con video, y trabajar con video requiere el uso de herramientas más o menos nativas. Además, si no utiliza herramientas nativas, siempre habrá una acumulación de 1-2 pasos de las versiones del sistema operativo. Todos los marcos universales como Xamarin todavía tienen que ponerse al día después de los lanzamientos. Y somos muy codiciosos antes de ser presentados, tanto Google como Apple nos recomiendan solo porque utilizamos herramientas nativas.

Las herramientas nativas ayudan a crear aplicaciones de calidad, buenas y rápidas. En el caso del video, esto es simplemente necesario.

Busque soluciones de gestión

Habiendo designado los objetivos, nos sintonizamos con su rápido logro. Permítame recordarle que estábamos divididos en Value Stream, diferentes desarrolladores estaban sentados en diferentes equipos y nos enfrentamos a la dura realidad: ¿qué hacer?

Parece que teníamos un sistema al que acostumbramos a las personas durante bastante tiempo, y ahora las reglas del juego han cambiado.

Por supuesto, al principio intentamos trabajar como antes, utilizando Value Stream, aceptando los siguientes cálculos lógicos: "Deje que Value Stream, que se dedica a esa dirección del negocio, refactorice todos los componentes asociados con estas áreas".

¡Oh, qué equivocados estábamos! Aproximadamente un mes después, resultó que para reescribir el núcleo de cada una de las aplicaciones, de hecho, debe entrar en todas las áreas de las reglas comerciales.

Fue muy difícil diferenciar el área de responsabilidad de Value Stream, que asume qué parte cuando las personas están sentadas en diferentes pisos, en diferentes habitaciones.

Lo que es más triste, debido a los diferentes lenguajes y características de las plataformas de desarrollo, el efecto de la colaboración ha desaparecido por completo.

En el marco de Value Stream, los desarrolladores de iOS y Android están viendo la misma característica, y tienen algo de qué hablar, están discutiendo la lógica de negocios. Y cuando cada uno de ellos corta un marco de bajo nivel, que se correlaciona débilmente con lo que luego estará en el producto final, la sincronización desaparece por completo.

Hubo personas que, en principio, rompieron con el significado de lo que estaba sucediendo. Los Timlids fueron los primeros en desanimarse, porque ellos, como personas responsables, necesitaban tropezar y no creer en los empleados de la humanidad para regresar al seno de la verdadera iglesia para poder escribir un código adecuado en la dirección correcta. Resultó muy mal.

Después de un mes y medio, me di cuenta de que Value Streams funciona muy bien para los productos terminados, pero generalmente no es efectivo cuando un producto necesita ser escrito desde cero.

Como todas las verdades simples, las comprende solo después de caminar descalzo por el rastrillo e incluso deja que la corriente atraviese el rastrillo.

Todo lo nuevo está bien olvidado de lo viejo.

Devolveremos todo como estaba

Después de la triunfante transformación Ágil, decidimos hacer todo como estaba en 2016, porque se debe ganar el derecho a la democracia.

Para que todos tengan derecho a votar, y este derecho es reclamado y utilizado, es necesario formar las reglas y el ecosistema en el que funcionará.

Cuando no hay ecosistema, hay que hacer algunas cosas de forma autoritaria para que las reglas se formen de alguna manera.

Hizo lo siguiente:

• Trajeron a las personas nuevamente bajo el ala de los timbales, los reorientaron de la programación orientada a funciones a la programación normal.
• Los gerentes de producto fueron asignados a usuarios de flujo. En nuestro caso, esto es descarga, autorización, etc.
• Intentamos formalizar todos los requisitos para un nuevo producto, que acordamos al comienzo del desarrollo.

Todo parece ser lógico, pero hace dos años nos encontramos con los mismos problemas.

No funcionará, nuevamente problemas en la organización

Los principales problemas hace dos años fueron: centralización y toma de decisiones.

El autoritarismo conduce a la aparición de "cuellos de botella": líderes de equipo, gerentes técnicos y gerentes de producto que no tienen tiempo para transmitir características al desarrollo. Un producto que ha sido aserrado durante 8 años antes es difícil de repensar en unos pocos meses. No es genial cuando el 80% del concepto está listo, y el 20% (justo donde está la pulpa) todavía no está allí. Esto molestó mucho y molestó al equipo.

Cuando los desarrolladores volvieron formalmente a la gestión de los líderes de los equipos, había mucha menos comunicación en vivo con los gerentes de productos y era necesario formalizar los conocimientos tradicionales. Lo que fue reemplazado perfectamente por la comunicación verbal volvió a convertirse en formalismo: regresó, nadie lo devolvió. Pero los ingenieros están organizados de esta manera, se les enseña en el instituto: hay un enunciado del problema: debe resolverse, no hay un enunciado del problema: el mundo se está bloqueando, el algoritmo no funcionará.

En el proceso, se descubrieron errores y errores de cálculo, tanto lógicos como arquitectónicos. Imagínese haciendo código durante varios años, y todo este tiempo desea refactorizarlo, y cuando surge la oportunidad, resulta que todas las ideas y conceptos no son muy buenos o no funcionan en absoluto. El sueño resulta ser falso.

Al mismo tiempo, como suele ser el caso al evaluar plazos, una empresa escucha una cosa, el desarrollo escucha otra. Además, el negocio todavía se divide en dos, y luego comienza a presionar los plazos y quiere obtener un nuevo producto ayer. En la hora X, resulta que el desarrollo cree que todavía hay 3-4 meses, y el negocio estaba esperando el lanzamiento ayer. Todos están molestos, el equipo comienza a romper.

Que has hecho

Llevamos a cabo una retrospectiva a gran escala sobre cómo vivimos y revelamos lo que más preocupa a los desarrolladores y líderes de equipo.

La necesidad de rehacer la funcionalidad , y a menudo 3 veces. Para ser honesto, exactamente la mitad de los problemas estaban del lado de la declaración del problema, la segunda mitad estaba del lado de la implementación. Sin embargo, los desarrolladores, por supuesto, estaban firmemente convencidos de que todo el problema estaba en la formulación del problema. Del lado de la tarea, los directores eran lo mismo. Nadie quiere considerarse incorrecto o culpable, todos dicen que el problema está del otro lado.

Soporte para la aplicación anterior . Un servicio con una audiencia multimillonaria no puede simplemente abandonarse. Paralelamente a la escritura de un nuevo producto, se debe hacer algo con el anterior. ¡Esto es terriblemente molesto!

Implementación de un sistema de diseño. Estamos muy orgullosos de esta dirección: realmente le permite hacer rápidamente cosas muy complejas y el producto se ve uniforme. Pero tuve que capacitar a los diseñadores sobre lo que es JSON, y los diseñadores tuvieron que transmitir a los desarrolladores que la apariencia también es muy importante. Se rompieron muchas copias sobre esto.

Falta de información y respuestas a la pregunta "¿Por qué?". Sin Value Stream, algunos desarrolladores ya no entienden por qué están haciendo algo. Hubo una interrupción en la transmisión de información y la relación causa-efecto desapareció parcialmente. Los que encontraron la fuerza para preguntar por qué estábamos haciendo esto fueron felices. Las personas poco comunicativas pensaban que los idiotas estaban sentados arriba, inventando cosas que no se pueden diseñar.

Falta de documentación sobre nuevas reglas de negocio. Debido a la falta de información, faltaba documentación en la que se explicara cómo debería funcionar correctamente la aplicación.

Todos probaron el papel de un arquitecto, y no a todos les gustó. Para mí fue el mayor descubrimiento. Por primera vez, los líderes del equipo estimaron los plazos para procesar las solicitudes en aproximadamente un año y medio, lo que no tiene valor. Esto sucedió porque cada líder de equipo quería dejar pasar todas las partes del sistema por sí mismo, es decir, realmente no quería delegar y descomponer la arquitectura de la aplicación, sino que quería quedarse con todo para sí mismo.

Con este enfoque, realmente necesita un año y medio para reelaborar la arquitectura. Pero con tales términos en este mundo no hay nada que hacer. Por lo tanto, después de largas discusiones, llegamos a la conclusión de que las funciones arquitectónicas del líder del equipo deberían delegarse a ciertos luchadores experimentados del desarrollo en ciertas áreas clave, quienes, entre otras cosas, querían participar y sentirse arquitectos.

Resultó un hecho interesante: resulta que asumir la responsabilidad es desagradable.

Llamar a sí mismo arquitecto o líder de equipo y ser líder de equipo son dos grandes diferencias. No todo el mundo resultó estar listo para aceptar que si cuidas y malgastas una conversión, esto será solo tu responsabilidad.

Era ingenuo y por alguna razón pensé que todos en nuestro equipo poseían tal coraje. Olvidé que antes de Timlid necesitas madurar y crecer un poco. Durante el año, muchos de nosotros pasamos por esta dirección, y algunos se dieron cuenta de que no querían crecer, pero en general, y no querían ser líderes de equipo.

Cómo arreglar la situación.

Además de la descomposición y diferenciación de los roles de los tímidos en diversas áreas arquitectónicas, formamos las llamadas Unidades de represalia voladoras (VOC) y atrajimos a especialistas en control de calidad (QA). En primer lugar, eran más libres que todos: todavía no hay un producto nuevo y ahora puede escribir un caso de prueba y un conjunto de pruebas para regresiones posteriores.

Luego resultó que las reglas de negocio aún no están completamente formuladas, y la compañía no tiene mucha gente que sepa cómo debería funcionar la nueva aplicación.

Hemos establecido las siguientes tareas para el control de calidad:

• Necesitamos documentación actualizada sobre las reglas comerciales y la lógica en la que funciona la aplicación.
• Se necesitan adherentes a la nueva lógica de negocios, y no solo gerentes y gerentes técnicos.

Dado que tenemos una nueva aplicación, y tenemos que volver a hacerlo, necesitamos personas que puedan formular preguntas como: cómo manejar dicho error, cómo debe comportarse la aplicación en tal situación. Repito, se describieron los casos principales, pero el diablo está en los detalles: ese mismo 20% necesitaba ser cerrado.

Comenzamos a crear microcomandos dinámicos. A pesar del hecho de que las personas no fueron trasplantadas en ningún lugar, sino que se unieron a un producto de una dirección específica, una persona de QA que metódicamente se involucró en el trabajo del proyecto, es decir, fue responsable de:

• recolectando preguntas de desarrolladores, creando cuestionarios;
• organización y grabación de reuniones;
• formalización de documentación;
• escribir casos de prueba y suites de prueba por adelantado.

Cuando llegamos a la línea de meta, esto nos permitió conectar proveedores externos, personal externo para realizar pruebas a fin de aumentar la velocidad de preparación para el lanzamiento. Tenemos una gran cantidad de plataformas, lo que he enumerado son solo las herramientas con las que trabajamos. Por ejemplo, en SmartTV hay 6-7 plataformas, para cada una de las cuales necesita lanzar por separado, realizar una regresión separada, etc. Si tiene casos comerciales prerregistrados, puede conectar fácilmente proveedores externos y personal externo aquí.

La introducción de los VOC alivió enormemente a los Timlids. Tuvieron la oportunidad de no distraerse con tareas administrativas, sino de tomar decisiones estratégicas con respecto al desarrollo del código basado en el material desarrollado.

El proyecto "Los escuadrones voladores de la retribución" cumplió con las expectativas, y entramos en la línea de lanzamiento sin matarnos.

Que sigue

2018 , — , , . . , , . «, ,» — .

, , 2016 Value Stream. , . , , . .

, , .

, , . , , , 2018 4 . , , , .

.

.

— . , , , , , . -, , .

: , , , . . .

TeamLead Conf . , , , . 23 24 .