Cuando un producto es grande, los desarrolladores llegan a extremos:
- el código es demasiado hermoso - lanzamientos lentos,
- demasiada atención a los procesos - poca atención al desarrollo,
- envío rápido de nuevas características en producción - código demasiado malo,
- demasiada atención a las pruebas automáticas - es difícil hacer cambios,
- preocupación por la velocidad de la interfaz - evitando nuevas características,
- Mejora de la interfaz de usuario: poca atención a la arquitectura del código.
En el informe, hablé sobre cómo evitar estos extremos y lograr un trabajo en equipo exitoso.
- Quiero hablar sobre cómo vivir en grandes equipos. Un equipo grande es cuando hay incluso más personas que en esta sala.
Y quiero que funcionen tan bien como estos chicos en el GIF:
No tengo un equipo muy grande, pero solo vi un poco lo que está sucediendo con los grandes equipos de la empresa en general, y solo quiero compartir esto con ustedes.
Para imaginar la escala, debes contar cosas bastante obvias. Que Yandex es un poco más que una página de búsqueda. Somos muchos, más de 10 mil.
Y entre estos "muchos", la mayoría son desarrolladores. Hacemos muchos productos diferentes, no solo para la web. Se trata de bienes, de automóviles, de comer, de todo tipo de piezas de hierro, de inteligencia artificial. Y los desarrolladores están involucrados en esto. Incluso si, al parecer, estamos hablando de automóviles o de comida.
Contamos con muchos servicios. No caben en el tobogán. Espero haberte convencido de que Yandex es muy grande. Las cosas grandes son difíciles de manejar.
Un punto importante Lo que continuaré diciendo es, en primer lugar, una simplificación muy fuerte; segundo, tengo fallas de memoria, así que interpretaré algo; en tercer lugar, algunas cosas con las que jugueteo deliberadamente un poco para la coherencia de la historia, etc. Fuertemente no objetan. Las ideas generales, mientras tanto, serán ciertas.
Comenzaré desde tiempos muy antiguos. Entonces acabo de llegar a Yandex. Luego se organizó de manera muy diferente a la actual. La división era por especialización, genial para los desarrolladores. Se veía algo así. La empresa estaba estructuralmente dividida en gerentes, hicieron algo entre ellos. Hubo otras especializaciones. De hecho, no había diseñadores en ese momento, pero transmite el significado. Y, por supuesto, había desarrolladores. Dentro de esta estructura, se cortó en fragmentos aún más pequeños.
Los desarrolladores fueron con sierras o con alicates. Había tipos con gorras con batidos, tipos con cascos eran más duros, diseñadores que no estaban allí en ese momento y gerentes que lo tenían para todos. Por lo tanto, fueron preparados.
Si profundizas en esta historia, entonces dentro de la jerarquía había algo como esto. Había un tipo en el casco más duro, que recibió todos los golpes. Tenía gerentes sutiles bajo su mando, luego otros menos severos. Exagero, pero la idea es clara. Y la misma jerarquía funcionó para cada especialización.
Los tipos con batidos en gorras funcionaron de la misma manera, y es divertido. Eres un desarrollador, obedeces a otro desarrollador, él entiende lo que estás haciendo, te elogia por algo que a él mismo le gusta. Genial
Pero supongamos que una idea llega a algún producto. Y solo tiene otros gerentes subordinados, esto es si tiene suerte y tiene al menos a alguien que está subordinado. Todo lo demás no lo obedece en absoluto, pero de alguna manera la idea debe realizarse.
Y él dice: "Camarada jefe de diseño, tengo una idea genial. Necesito un diseñador. Él responderá: “Bueno, en primer lugar, su idea es extraña y, en segundo lugar, todos los diseñadores están ocupados conmigo. Ven a la Q5 ".
Si el gerente le cree en este momento, no tendrá nada. Si es persistente, talentoso y está listo para superar todas las dificultades, tal vez convencerá a este diseñador jefe. Él dirá: está bien, en dos meses llevarás a este tipo, debe ser libre. Amigo, por supuesto, la fecha límite se completará y se lanzará en cuatro meses, pero al menos habrá una oportunidad para el desarrollo del proceso.
Luego, este gerente irá al desarrollador principal y le dirá: “Tengo un diseño genial, una idea increíble. Necesito un back-end ". Y todo esto continuará: "El defensor está ocupado, tienes una idea más o menos, el diseño es malo".
Al final, puede obtener un equipo de desarrollo y hacer algo. Por un lado, de esta manera solo sobrevive la idea más genial, por otro lado, es realmente difícil hacer algo.
Pero para el desarrollador, esto es genial. Los desarrolladores son evaluados por otros desarrolladores. Los desarrolladores, por supuesto, aman todo lo técnico. Y sobre el supermercado, deje que el gerente primero convenza de que esta es una idea genial. Y debido al hecho de que todos los desarrolladores en la misma estructura se comunican entre sí, todos tienen partes en común, el intercambio de experiencia técnica está muy bien establecido. Con experiencia en productos, las cosas no son muy buenas, pero ¿a quién le importa? Y mucha investigación, porque es para el fanático. Será evaluado por otros desarrolladores que también son fanáticos. Puedes inventar cosas de alta tecnología.
Obviamente, este enfoque tiene un problema. Los desarrolladores no están muy preocupados por lo que pasa con el producto, porque no obedecen a los gerentes. Los administradores de cascos se burlarán si algo sale mal, pero no tienen una influencia especial en los desarrolladores. Y el producto, a su vez, es bastante difícil de cambiar. De hecho, solo pueden persuadir, convencer y bailar de alguna manera para demostrar que su idea es genial. Entonces el desarrollador creerá en ello y, por supuesto, hará que todo duela.
Pero resulta que de esta gran fila de desarrolladores tienes que agarrar accidentalmente a alguien, todos hacen algo interesante, pero armar una cosa grande y compleja que interactúa constantemente es problemático.
Mientras tanto, todo esto sucede, la compañía toma y crece dos veces en un año. Y necesitas hacer algo. Como solía decir Arkady Volozh, administrar una empresa es como freír una albóndiga. Necesita ser entregado constantemente.
La estructura de la empresa está cambiando. En lugar de dividir a todos por especialización, dividir por producto. Y el gerente se está convirtiendo en un tipo mucho más importante.
Resulta aproximadamente un esquema de este tipo, si se simplifica y exagera enormemente. Tenemos una gran parte del producto, en su interior se divide en partes más pequeñas, y para cada parte se destaca un equipo totalmente equipado. Hay diseñadores, desarrolladores, gerentes, y todos hacen este producto.
Parece que el problema fue tratado, pero hay un nuevo problema. Los equipos pueden ser bastante pequeños y, naturalmente, habrá un front-end, un back-end, un diseñador, medio analista y otra persona. Están cursi con nadie para hablar sobre su área temática, y parece que esto no es obligatorio. Están aserrando su proyecto, pero todos los inventos que reciben en el proceso, no tienen a quién transmitir, no tienen a nadie a quien preguntar cómo hacerlo mejor. No saben lo que están haciendo detrás del muro adyacente, y tal vez están haciendo lo mismo. Además, directamente hacen lo mismo de forma natural.
El gerente parece tener más poder, pero no comprende tan bien todas las sutilezas del desarrollo. Un desarrollador talentoso, si lo desea, puede decirle que sin una reescritura completa del proyecto, en ninguna parte. ¿Y cuál es la próxima opción del gerente? O le creerá o le prohibirá que lo haga, todos estarán insatisfechos. En general, hay un problema.
Quiero equilibrar de alguna manera todo en términos del producto. Por ejemplo, un producto tiene un equipo y, por ejemplo, cree que un código hermoso es importante. Y aunque perfeccionan este código al ideal, está claro que los lanzamientos se posponen. No es genial O el equipo piensa: "Está bien, si solo hubiera procesos geniales, y el código sucedería de alguna manera". De hecho, no, no sucede. También es necesario que alguien lo vea.
O el equipo dice: "Necesitamos avanzar muy rápido, es importante para nosotros que desarrollemos funciones todos los días", pero en ese momento la calidad del código se está volviendo fuera de foco. O el equipo dice: “Está bien, la última vez que dimos la vuelta al rastrillo, nos dimos cuenta de que la calidad es importante. Cubramos todo con pruebas automáticas. Las pruebas automáticas se escriben para cada característica, pero ahora estas pruebas deben ejecutarse en cada solicitud de grupo, y tardan mucho tiempo en completarse, y todo se vuelve lento.
O: "Sabemos que nuestros usuarios, si la interfaz es lenta, se van. Hagamos que las interfaces sean rápidas ". Pero luego resulta que cada nueva característica es un código adicional que debe transmitirse a través de la red y ejecutarse, y ralentiza la interfaz. "Entonces no hagamos nuevas funciones, todo funcionará más rápido". O: “Al usuario le encanta cuando es bella. Hagámoslo maravillosamente. Pero no importa lo que haya dentro.
En busca de este equilibrio, resulta que algo necesita ser cambiado nuevamente. Mientras tanto, el equipo está creciendo dramáticamente de nuevo.
¿Cómo se suele resolver esto? Toma una palabra de moda. Nosotros también lo tomamos. Tenemos un scrum bastante común, pero con nuestros propios inventos. Que dice Dice que vamos a enfriar al personal de los equipos para que todos sean responsables del resultado final, hay toda la experiencia necesaria. Y deje que este equipo elija qué tareas hacer primero, elija qué procesos deben tener dentro. En general, un producto es más importante que los procesos. Eso es todo Suena bien Parece incluso resolver parte de los problemas.
Pero aún hay un problema. Por ejemplo, se supone que dichos equipos de scrum se adaptan constantemente a lo que sucede a su alrededor, cambian constantemente (su composición cambia, pueden formarse, disolverse constantemente) y, en principio, no hay un lugar común donde se agregue el historial de desarrollo del empleado.
Es decir, hay algún tipo de desarrollador y tiene algunas fortalezas, se está quemando en alguna parte. Y entonces entra en un nuevo equipo de scrum, y ellos no conocen estas fortalezas, y no comienzan a usarlas allí mismo. Y, por el contrario, tal vez él no aguante en algo, no hay nadie que lo sepa, se asegure de que esté motivado en esto y se asegure de que el proyecto no sufra el hecho de que no tiene experiencia allí.
Y hay soluciones que ahora estamos tratando de aplicar en una parte separada de la empresa y ver qué sucede. La idea es la siguiente. Hay una estructura bastante estable en la que hay vínculos entre el desarrollador y su líder, también el desarrollador. Todo es igual que al principio, cuando el líder entiende lo que estás haciendo, comparte intereses contigo, puede aconsejarte algo en términos de cómo trabajar de manera más eficiente y ayudarte en algún lado. Estos enlaces se han mantenido durante mucho tiempo durante varios años.
Para satisfacer las necesidades del producto, junto con una estructura estable constante, todavía se forman equipos de scrum virtuales rápidos para cada producto, e incluso para cada aspecto individual del producto. Ahora te contaré más al respecto.
Los equipos son temporales, rápidos, pueden centrarse en algunas de las cosas más críticas en este momento.
Se ve algo como esto. Aquí tenemos una pequeña pieza, por ejemplo, la web. Y dentro, si miras, un montón de personas que están aserrando esta web.
Así es como se lleva a cabo el equilibrio de toda la historia. Hay tipos verdes, son responsables de garantizar que las interfaces sean rápidas. Y todo lo que les interesa es que todo debería ser lo mejor posible según las métricas de velocidad. Deja que todo lo demás sea como quieras. Pero hay otros tipos que, en principio, la velocidad no es tan importante, pero es importante por un período de tiempo que logramos lanzar un montón de nuevas características interesantes para el usuario en producción. Y ahora la situación es imposible de que los tipos digan: “La velocidad es lo más importante. No corras nada. Porque para ese equipo esto es fundamentalmente inaceptable.
Pero, por el contrario, el equipo responsable de las funciones ya no puede lanzar un montón de código nuevo y decir: "Así que tuvimos que iniciar las funciones, todo se volvió más lento, pero comenzamos las funciones". Estarán de acuerdo el uno con el otro, de alguna manera se ayudarán, y al final todo estará bien. Los tipos azules escriben pruebas frenéticamente, constantemente. Y cubrieron todo con pruebas, y ahora hay muchas pruebas, y todas funcionan lentamente. Y a los tipos no les importa, porque solo son responsables de la cobertura.
Pero es genial que haya otros que digan: "Pero es importante para nosotros que el proceso de desarrollo en su conjunto sea rápido. Desde el momento en que establecemos la tarea hasta el momento en que nuestros usuarios comienzan a usarla, este período de tiempo debe reducirse ". Y estarán de acuerdo, y todo estará bien. Ayudarán a las personas que escriben pruebas para que estas pruebas se ejecuten más rápido.
Alguien solo es responsable de garantizar que todo sea arquitectónicamente genial. Además, es posible que ni siquiera tengan que pensar en lo que está sucediendo en este momento en el código. Pueden pensar en términos de: "¿Y a dónde debería ir todo en un año y medio?" - Y ahora concéntrate en este futuro. Pero al mismo tiempo habrá alguien que apriete las esquinas redondeadas, corrija las sombras y piense en la animación para que el usuario esté más feliz mañana. Y cuando existe tal distribución de responsabilidad, y cada equipo se complementa mutuamente, se obtiene un equilibrio.
Hay varios roles en todo esto. Ya dije algo sobre esto, pero, sin embargo, esto es algo importante. Cada uno tiene su supervisor inmediato, que sabe todo sobre él y se asegura de que una persona crezca profesionalmente, crezca personalmente y sea feliz. Al mismo tiempo, hay un líder de dicho equipo que dice que la cobertura de las pruebas debería crecer y que todo lo demás es menos importante. Y cuando estos dos roles ocurren simultáneamente, resulta más o menos bien.
Y hay cosas diferentes adicionales. En tal situación, resulta que para los desarrolladores involucrados en el mismo producto, ensamblados a partir de diferentes estructuras en un equipo tan virtual, se recibe mucha más atención de diferentes gerentes. Y en total, esta experiencia permite mejorar el producto ...
... y luego transferir a otros productos que los gerentes estructurales observan, algunos inventos que han surgido durante el trabajo de este gran equipo. O viceversa, es decir, estas flechas se pueden girar en la dirección opuesta, y esto también será cierto. Resulta desbordamiento y experiencia, y de alguna manera es conveniente volver a reunir a los equipos en el producto donde ahora es más importante. Por lo tanto, aumenta la atención a los diferentes productos de los camaradas más experimentados de la empresa.
OK, más o menos de acuerdo en cómo debería funcionar todo. Pero si tenemos un jefe estructural y un jefe sobre un producto, ¿cómo evaluar si todo salió bien? Sergey Berezhnoy habló sobre esto en detalle el año anterior al sábado pasado. Repetiré brevemente la idea general.
La decisión sobre si una persona en particular ha funcionado bien se toma, en primer lugar, en comparación con otros participantes en el proceso, y en segundo lugar, de manera colectiva por todos los interesados. Es decir, tanto su líder estructural, que monitorea cómo se desarrolla en el segmento a largo plazo, como la persona responsable de las tareas del producto a corto plazo y estima no en términos del hecho de que la persona se esforzó mucho y no durmió por la noche, sino en términos de cómo realmente logró sus objetivos. Y esta es una manera que por el momento nos parece la más justa. Si se destaca, incluso sin esforzarse especialmente: guapo, alabémoslo. Tal equilibrio nos parece funcionando, bien.
Beneficios adicionales Cuando acordamos que podemos reunir rápidamente equipos individuales, reagrupar personas para cada necesidad específica, se vuelve crítico que esta transición sea lo más simple posible. Y esto es posible solo si todo está bien descrito, documentado. Tal construcción en sí obliga a la necesidad de documentación. Y al escribir documentación, los productos mejoran automáticamente en general. Tal es el beneficio en dos direcciones.
Además de intercambiar experiencia, las transiciones de las personas hacen que los diferentes productos sean más similares entre sí, tanto en términos de cómo se ven como en términos de cómo están organizados en su interior. También puede beneficiarse de esto: los usuarios entienden cómo usar los sistemas, porque simplemente usaron algo similar en otro proyecto. Y, por supuesto, finalmente puede reutilizar las mejores prácticas.
Dichos equipos se centran en cada aspecto por separado: escriben exámenes o son responsables de la velocidad o de la belleza, pero aún no pueden calificar en lo que está sucediendo con los vecinos. El hecho es que su líder es responsable de los desarrolladores de otros equipos, y ellos mismos pronto pueden pasar a otro equipo.
Es obvio para ellos que, condicionalmente, mañana les afectará. Por lo tanto, cuando se enfoca, la responsabilidad de todo en su conjunto no se pierde. Como resultado, cambiar entre proyectos es bastante fácil.Al mismo tiempo, las personas tienen muchas oportunidades de crecimiento. Porque en una estructura donde todo está moldeado en granito y no se mezcla, las personas en algún momento llegan a la situación de que ya entienden todo. Intentaron todo en este proyecto y simplemente siguieron la corriente. no necesitan hacer esfuerzos repentinos sobre sí mismos cada vez. Y si constantemente tienen que cambiar el equipo, cambiar constantemente el ángulo de continuación de sus talentos, su experiencia crece automáticamente, todo esto fortalece el sistema en su conjunto. Y de todos modos, no es aburrido. Es poco probable que no esté de acuerdo con esto.
, : « , , ?». , . , , . , - , , .
, . , , . ? , , , , .
,
. , - , , . , . , , — , , , : «, , . ».
, — . , , , , , ? . . , , , . , , . . , — , , , . -, , .
: — , , , , . — . .