Lorsqu'un produit est volumineux, les développeurs vont à l'extrême:
- le code est trop beau - les versions lentes,
- trop d'attention aux processus - peu d'attention au développement,
- envoi rapide de nouvelles fonctionnalités en production - trop mauvais code,
- trop d'attention aux autotests - il est difficile d'apporter des modifications,
- souci de la vitesse de l'interface - éviter les nouvelles fonctionnalités,
- Amélioration de l'interface utilisateur - peu d'attention à l'architecture de code.
Dans le rapport, j'ai expliqué comment éviter ces extrêmes et parvenir à un travail d'équipe réussi.
- Je veux parler de la façon de vivre en grandes équipes. Une grande équipe, c'est quand il y a encore plus de monde que dans cette salle.
Et je veux qu'ils fonctionnent aussi bien que ces gars sur le GIF:
Je n'ai pas de très grande équipe, mais je viens de voir un peu ce qui se passe avec les grandes équipes de l'entreprise dans son ensemble, et je veux juste partager cela avec vous.
Pour imaginer l'échelle, il faut dire des choses assez évidentes. Ce Yandex est un peu plus qu'une page de recherche. Nous sommes nombreux, plus de 10 000
Et parmi ces «nombreux», la plupart sont des développeurs. Nous fabriquons de nombreux produits différents, pas seulement pour le Web. Il y a tout sur les marchandises, sur les voitures, sur la nourriture, toutes sortes de morceaux de fer, l'intelligence artificielle. Et les développeurs y participent. Même si, semble-t-il, nous parlons de voitures ou de nourriture.
Nous avons de nombreux services. Ils ne tiennent pas sur la diapositive. J'espère que je vous ai convaincu que Yandex est très grand. Les grandes choses sont difficiles à gérer.
Un point important. Ce que je continuerai de dire est, premièrement, une très forte simplification; deuxièmement, j'ai des pertes de mémoire, donc je vais interpréter quelque chose; troisièmement, certaines choses que je joue délibérément avec un peu pour la cohérence de l'histoire, etc. Les idées générales, quant à elles, seront vraies.
Je vais partir de très vieux temps. Je suis ensuite venu à Yandex. Ensuite, cela a été arrangé très différemment que maintenant. La division était par spécialisation - cool pour les développeurs. Cela ressemblait à quelque chose comme ça. L'entreprise était structurellement divisée en managers, ils ont fait quelque chose entre eux. Il y avait d'autres spécialisations. En fait, il n'y avait pas de designers à cette époque, mais cela en donne le sens. Et, bien sûr, il y avait des développeurs. À l'intérieur de cette structure, il a ensuite été coupé en fragments encore plus petits.
Les développeurs étaient avec des scies ou des pinces. Il y avait des mecs dans des casquettes avec des smoothies, des mecs dans des casques étaient plus hardcore, des designers qui n'étaient pas là à l'époque, et des managers qui l'avaient pour tout le monde. Ils se sont donc préparés.
Si vous plongez dans cette histoire, alors à l'intérieur de la hiérarchie se trouvait quelque chose comme ça. Il y avait un mec dans le casque le plus dur, qui a eu toutes les bosses. Il avait sous ses ordres des managers subtils, puis des managers moins sévères. J'exagère, mais l'idée est claire. Et la même hiérarchie a fonctionné pour chaque spécialisation.
Les gars avec des smoothies en casquettes ont fonctionné de la même manière, et c'est amusant. Vous êtes développeur, vous obéissez à un autre développeur, il comprend ce que vous faites, il vous loue pour quelque chose qu'il aime lui-même. Super.
Mais supposons qu'une idée vienne à un produit. Et il n'a que d'autres managers subordonnés - c'est s'il a de la chance et qu'il a au moins quelqu'un qui est subordonné. Tous les autres ne lui obéissent pas du tout, mais l'idée doit en quelque sorte être réalisée.
Et il dit: «Camarade designer en chef, j'ai une bonne idée. J'ai besoin d'un designer. " Il répondra: «Eh bien, premièrement, votre idée est étrange, et deuxièmement, tous les designers sont occupés avec moi. Venez à Q5. "
Si le manager le croit en ce moment, il n'aura rien. S'il est persévérant, talentueux et prêt à surmonter toutes les difficultés, il convaincra peut-être ce chef designer. Il dira - d'accord, dans deux mois tu prendras ce mec, il doit être libre. Mec, bien sûr, le délai se remplira et sera publié dans quatre mois, mais au moins il y aura une chance pour le développement du processus.
Ensuite, ce gestionnaire ira au développeur principal, en disant: «J'ai un design cool, une idée géniale. J'ai besoin d'un back-end. " Et tout cela va continuer: "Le backender est occupé, vous avez une idée comme ça, le design est mauvais."
En fin de compte, il peut se constituer une équipe de développement et faire quelque chose. D'une part, de cette façon, seule l'idée la plus cool survit, d'autre part, il est vraiment difficile de faire quelque chose.
Mais pour le développeur, c'est cool. Les développeurs sont évalués par d'autres développeurs. Les développeurs, bien sûr, aiment tout ce qui est technique. Et à propos de l'épicerie, laissez le gestionnaire d'abord convaincre que c'est une bonne idée. Et du fait que tous les développeurs d'une même structure communiquent entre eux, tout le monde a des parties communes, l'échange d'expertise technique est très bien établi. Avec l'expertise produit, les choses ne sont pas très cool, mais qui s'en soucie? Et beaucoup de recherches, car c'est pour le fan. Sera évalué par d'autres développeurs qui sont également fans. Vous pouvez inventer des trucs de haute technologie.
De toute évidence, cette approche a un problème. Les développeurs ne sont pas très préoccupés par le contenu du produit, car ils n'obéissent pas aux gestionnaires. Les gestionnaires de casques seront raillés en cas de problème, mais ils n'ont aucune influence particulière sur les développeurs. Et le produit, à son tour, est assez difficile à changer. En fait, ils ne peuvent que persuader, convaincre et danser pour prouver que leur idée est cool. Ensuite, le développeur y croira et, bien sûr, fera tout blesser.
Mais il s'avère que parmi cette grande rangée de développeurs, vous devez saisir quelqu'un par hasard, tout le monde fait quelque chose d'intéressant - mais assembler une chose grande et complexe, en interaction constante, est problématique.
En attendant, tout cela arrive, l'entreprise prend et grandit deux fois par an. Et tu dois faire quelque chose. Comme disait Arkady Volozh, gérer une entreprise, c'est comme faire frire une boulette de viande. Il doit être constamment retourné.
La structure de l'entreprise évolue. Au lieu de diviser tout le monde par spécialisation, diviser par produit. Et le manager devient un mec beaucoup plus important.
Il se révèle approximativement un tel schéma, s'il est grandement simplifié et fortement exagéré. Nous avons un gros morceau du produit, à l'intérieur il se décompose en plus petites pièces, et pour chaque partie une équipe entièrement équipée se démarque. Il y a des concepteurs, des développeurs, des gestionnaires et ils fabriquent tous ce produit.
Il semblerait que le problème ait été traité, mais il y a un nouveau problème. Les équipes peuvent être assez petites et il y aura naturellement un front-end, un back-end, un concepteur, la moitié d'un analyste et quelqu'un d'autre. Ils sont ringards avec personne pour parler de leur sujet, et il semble que ce ne soit pas obligatoire. Ils voient leur projet, mais toutes les inventions qu'ils reçoivent dans le processus, ils n'ont personne à transmettre, ils n'ont personne pour demander comment faire mieux. Ils ne savent pas ce qu'ils font derrière le mur adjacent, et peut-être font-ils de même. De plus, ils font directement la même chose naturellement.
Le manager semble avoir plus de pouvoir, mais il ne comprend pas si bien toutes les subtilités du développement. Un développeur talentueux, s'il le souhaite, peut lui dire que sans une réécriture complète du projet, nulle part du tout. Et quel est le prochain choix du manager? Soit il le croira, soit il lui interdira de le faire, tout le monde sera insatisfait. En général, il y a un problème.
Je veux en quelque sorte tout équilibrer en termes de produit. Par exemple, un produit a une équipe et, par exemple, il croit qu'un beau code est important. Et bien qu'ils affinent ce code à l'idéal, il est clair que les versions sont reportées. Pas cool. Ou l'équipe pense: "D'accord, si seulement il y avait des processus sympas, et le code arriverait d'une manière ou d'une autre". En fait, non, cela ne se produit pas. Il est également nécessaire que cela soit surveillé par quelqu'un.
Ou l'équipe dit: «Nous devons avancer très rapidement, il est important pour nous que nous roulions des fonctionnalités tous les jours», mais à ce moment-là, la qualité du code est en train de perdre de sa netteté. Ou l'équipe dit: «D'accord, la dernière fois que nous avons fait le tour du râteau, nous avons réalisé que la qualité était importante. Couvrons le tout avec des autotests. » Les autotests sont écrits pour chaque fonctionnalité, mais maintenant ces tests doivent être exécutés sur chaque demande de pool, et ils prennent beaucoup de temps à se terminer, et tout devient lent.
Ou: «Nous savons que nos utilisateurs, si l'interface est lente, s'en vont. Rendons les interfaces rapides. » Mais il s'avère que chaque nouvelle fonctionnalité est un code supplémentaire qui doit être transmis sur le réseau et exécuté, et cela ralentit l'interface. "Alors ne créons pas de nouvelles fonctionnalités - tout fonctionnera plus rapidement." Ou: «L'utilisateur aime quand il est beau. Faisons-le magnifiquement. " Mais peu importe ce qu'il y a à l'intérieur.
A la recherche de cet équilibre, il s'avère que quelque chose doit encore être changé. Pendant ce temps, l'équipe s'agrandit de nouveau de façon spectaculaire.
Comment cela est-il généralement résolu? Prenez un mot à la mode. Nous l'avons aussi pris. Nous avons une mêlée assez commune, mais avec nos propres inventions. Qu'est-ce que ça dit? Il dit que refroidissons le personnel des équipes pour que tout le monde soit responsable du résultat final, il y a toute l'expertise nécessaire. Et laissez cette équipe choisir les tâches à effectuer en premier, choisir les processus qu'elle doit avoir à l'intérieur. En général, un produit est plus important que les processus. C’est tout. Ça sonne bien. Il semble même résoudre une partie des problèmes.
Mais il y a toujours un problème. Par exemple, on suppose que ces équipes Scrum s'adaptent constamment à ce qui se passe autour d'elles, changent constamment (leur composition change, elles peuvent constamment se former, se dissoudre) et, en principe, il n'y a pas de lieu commun où l'historique de développement de l'employé est agrégé.
Autrement dit, il y a une sorte de développeur et il a des forces, il brûle quelque part. Et donc il entre dans une nouvelle équipe de mêlée, et ils ne connaissent pas ces points forts, et ils ne commencent pas à les utiliser tout de suite. Et au contraire, peut-être qu'il ne résiste pas à quelque chose, il n'y a personne qui le sait, s'assure qu'il y est pompé, et s'assure que le projet ne souffre pas du fait qu'il n'y a pas d'expertise.
Et il y a des solutions que nous essayons maintenant d'appliquer dans une pièce distincte de l'entreprise et de voir ce qui se passe. L'idée est la suivante. Il existe une structure assez stable dans laquelle il existe des liens entre le développeur et son leader, également le développeur. Tout est comme au tout début, lorsque le leader comprend ce que vous faites, partage des intérêts avec vous, il peut vous conseiller sur la façon de travailler plus efficacement et vous aider quelque part. Ces liens sont maintenus depuis longtemps sur plusieurs années.
Pour répondre aux besoins du produit, avec une structure stable et constante, des équipes de mêlée virtuelle rapide sont toujours formées pour chaque produit, et même pour chaque aspect individuel du produit. Je vais maintenant vous en dire plus.
Les équipes sont temporaires, rapides, elles peuvent se concentrer sur certaines des choses les plus critiques du moment.
Cela ressemble à ceci. Ici, nous avons un petit morceau, par exemple le web. Et à l'intérieur, si vous regardez, tout un tas de gens qui scient cette toile.
C'est ainsi que l'équilibre de toute l'histoire se déroule. Il y a des mecs verts, ils sont responsables de s'assurer que les interfaces sont rapides. Et tout ce qui les intéresse, c'est que tout soit aussi cool que possible selon les métriques de vitesse. Laissez tout le reste être comme vous le souhaitez. Mais il y a d'autres mecs qui en principe la vitesse n'est pas si importante, mais il est important que nous réussissions pendant un certain temps à lancer un tas de nouvelles fonctionnalités intéressantes pour l'utilisateur en production. Et maintenant, la situation est impossible que les mecs diront: «La vitesse est le plus important. Ne dirigez rien. " Parce que pour cette équipe, c'est fondamentalement inacceptable.
Mais au contraire, l'équipe qui est responsable des fonctionnalités ne peut plus lancer un tas de nouveau code et dire: "Nous avons donc dû démarrer les fonctionnalités, tout est devenu plus lent, mais nous avons commencé les fonctionnalités". Ils seront d'accord les uns avec les autres, s'entraideront en quelque sorte, et à la fin tout ira bien. Les mecs bleus écrivent des tests frénétiquement, constamment. Et ils ont tout couvert avec des tests, et maintenant il y a beaucoup de tests, et ils fonctionnent tous lentement. Et les mecs s'en moquent, car ils ne sont responsables que de la couverture.
Mais c’est formidable qu’il y en ait d’autres qui disent: «Mais il est important pour nous que le processus de développement dans son ensemble soit rapide. À partir du moment où nous avons défini la tâche jusqu'au moment où nos utilisateurs commencent à l'utiliser, ce délai devrait être réduit. » Et ils seront d'accord, et tout ira bien. Ils aideront les personnes qui écrivent des tests à exécuter ces tests plus rapidement.
Quelqu'un est uniquement responsable de s'assurer que tout est architecturalement cool. De plus, ils peuvent même ne pas avoir à penser à ce qui se passe en ce moment dans le code. Ils peuvent penser en termes de: "Et où tout devrait-il aller dans un an et demi?" - et maintenant concentrez-vous sur cet avenir. Mais en même temps, il y aura quelqu'un qui resserre les coins arrondis, corrige les ombres et pense à l'animation pour que l'utilisateur soit plus heureux demain. Et quand il y a une telle répartition des responsabilités, et que chaque équipe se complète mutuellement, un équilibre est obtenu.
Il y a plusieurs rôles à tout cela. J'ai déjà dit quelque chose à ce sujet, mais, néanmoins, c'est une chose importante. Chacun a son supérieur immédiat, qui sait tout de lui et s'assure qu'une personne grandit professionnellement, grandit personnellement et est heureuse. Dans le même temps, il y a un leader d'une telle équipe qui dit que la couverture des tests devrait augmenter, et tout le reste est moins important. Et lorsque ces deux rôles se produisent simultanément, cela se passe plus ou moins bien.
Et il y a d'autres choses différentes. Dans une telle situation, il s'avère que pour les développeurs impliqués dans le même produit, assemblés à partir de différentes structures en une telle équipe virtuelle, beaucoup plus d'attention est reçue de différents gestionnaires. Et au total, cette expérience permet d'améliorer le produit ...
... puis transférer vers d'autres produits que les gestionnaires structurels regardent, certaines inventions qui ont vu le jour au cours du travail de cette grande équipe. Ou vice versa, c'est-à-dire que ces flèches peuvent être tournées dans la direction opposée, et cela sera également vrai. Cela transforme le débordement et l'expertise, et la méthode est en quelque sorte pratique pour réassembler les équipes dans le produit où il est plus important maintenant. Ainsi, l'attention portée aux différents produits par les camarades les plus expérimentés de l'entreprise augmente.
OK, en quelque sorte convenu comment tout devrait fonctionner. Mais si nous avons un patron structurel et un patron sur un produit, comment alors évaluer si tout s'est bien passé? Sergey Berezhnoy en a parlé en détail l'année précédente, samedi dernier. Je vais répéter brièvement l'idée générale.
La décision de savoir si une personne en particulier a bien fonctionné est prise, premièrement, en comparaison avec les autres participants au processus, et deuxièmement, collectivement par toutes les parties concernées. C'est-à-dire à la fois son leader structurel, qui surveille la façon dont il se développe sur le segment à long terme, et la personne qui est responsable des tâches de produit à court terme et estime non pas en termes du fait que la personne a fait des efforts et n'a pas dormi la nuit, mais en termes de la façon dont il a vraiment atteint ses objectifs. Et c'est ainsi que pour le moment nous semble le plus juste. Si vous vous démarquez, même sans forcer particulièrement - beau, félicitons-nous. Un tel équilibre nous semble bien fonctionner.
Avantages supplémentaires. Lorsque nous avons convenu que nous pouvons rapidement constituer des équipes individuelles, regrouper des personnes pour chaque besoin spécifique, il devient essentiel que cette transition soit aussi simple que possible. Et cela n'est possible que si tout est bien décrit, documenté. Une telle construction elle-même impose le besoin de documentation. Et lors de la rédaction de la documentation, les produits s'améliorent automatiquement dans l'ensemble. Tel est l'avantage dans deux directions.
Outre l'échange d'expertise, les transitions des personnes rendent les différents produits plus similaires les uns aux autres - à la fois en termes d'apparence et de disposition à l'intérieur. Vous pouvez également en bénéficier - les utilisateurs comprennent comment utiliser les systèmes, car ils ont simplement utilisé une chose similaire sur un autre projet. Et bien sûr, vous pouvez enfin réutiliser les meilleures pratiques.
Ces équipes se concentrent sur chaque aspect séparément: soit écrivent des tests, soit sont responsables de la vitesse, ou de la beauté - mais elles ne peuvent toujours pas marquer ce qui se passe avec les voisins. Le fait est que leur chef est responsable des développeurs dans d'autres équipes, et ils peuvent eux-mêmes bientôt passer à une autre équipe. Il leur est évident que, conditionnellement, demain, cela les affectera. Par conséquent, lors de la concentration, la responsabilité de tout dans son ensemble n'est pas perdue. En conséquence, le passage d'un projet à l'autre est assez facile.
Dans ce cas, les gens ont de nombreuses opportunités de croissance. Parce que dans une structure où tout est moulé en granit et ne se mélange pas, les gens arrivent à un moment donné à comprendre qu'ils comprennent déjà tout. Ils ont tout essayé sur ce projet et suivent le rythme. ils n'ont pas besoin de faire des efforts soudains sur eux-mêmes à chaque fois. Et s'ils doivent constamment changer d'équipe, changer constamment l'angle de continuation de leurs talents, leur expertise grandit automatiquement, tout cela renforce le système dans son ensemble. Et de toute façon, ce n'est pas ennuyeux. Il est peu probable que vous ne soyez pas d'accord avec cela.
, : « , , ?». , . , , . , - , , .
, . , , . ? , , , , .
,
. , - , , . , . , , — , , , : «, , . ».
, — . , , , , , ? . . , , , . , , . . , — , , , . -, , .
: — , , , , . — . .