Lorsque dans des articles et des rapports, ils parlent de cas dans la gestion d'équipe, ils se limitent souvent à dire ce qui n'allait pas et comment ils ont changé la situation. Mais cette fois, nous avons une occasion unique de découvrir comment l'équipe a vécu plus loin et comment tout s'est terminé - en fait, cela n'a pas pris fin, mais a continué.

Voici une suite de l'histoire intitulée " Comment survivre à un cuir chevelu dans une scram évolutive et maintenir un contrôle sur la qualité du code " sur la transformation Agile dans ivi. Chez TeamLead Conf, le directeur technique de la société, Evgeny Rossinsky ( eross ), a expliqué pourquoi il pourrait être nécessaire d' annuler la réorganisation complète de l'équipe, comment ne pas se quereller et aider les développeurs, mais aussi pour maintenir et augmenter l'efficacité commerciale.

Contexte de l'entreprise

ivi - le plus grand cinéma Internet légal avec une audience de 48 millions d'utilisateurs, qui passent collectivement 70 millions d'heures par mois. Ivi a 62 000 unités de contenu, qui sont disponibles à partir de différents appareils et toujours d'excellente qualité.

Il se trouve que le jour même où Eugene a parlé à TeamLead Conf avec ce rapport, c'était l'anniversaire de l'entreprise. Il y a 9 ans, la première version de la version Web du projet a eu lieu, et après 2 jours, la force de Channel One a amené un grand nombre d'utilisateurs sur ivi. L'entreprise a même pensé qu'il s'agissait de DDoS, mais a pu résister avec dignité.

Cet article concerne le lancement d'un nouveau produit - un redémarrage complet de toutes les applications.

Regardez la vidéo pour entendre la version non censurée ou lisez la transcription du rapport à la première personne.



Parlons d'abord des technologies et des compétences utilisées pour comprendre l'étendue des dégâts.

Compétences:

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

Pour chacune de ces compétences en 2016, nous avions notre propre équipe, à savoir Équipe iOS, équipe Android, etc. Il y avait aussi une équipe de backend et séparément, une équipe de chefs de produits qui ont proposé de nouvelles fonctionnalités.

Le principal problème, en raison duquel il était nécessaire de transformer, était que toutes les plates-formes sont différentes, y compris qu'elles avaient des retards et des priorités différents. Et nous voulions vraiment créer un espace d'information unique au sein de nos applications.

Il arrivait souvent qu'une fonctionnalité complexe apparaisse sur toutes les plateformes 4 mois après sa conception. Dans le même temps, il est apparu sur une plate-forme après 3 jours, puis, en fonction de la priorité des backlogs, il s'est déployé sur différentes plates-formes à différentes vitesses. Cela s'est avéré monstrueux pour les raisons suivantes:

• Pendant 4 mois, la fonctionnalité pourrait déjà acquérir un sens complètement différent et le besoin pourrait disparaître.
• En raison de problèmes de communication, qui sont évidents dans ce cas, les utilisateurs ont implémenté les fonctionnalités de différentes manières.

Étant donné que le produit possède trois modèles de monétisation qui fonctionnent avec une efficacité différente sur différentes plates-formes, la priorité du backlog sur chaque plate-forme était différente. Certaines fonctionnalités ne pourraient en principe jamais être implémentées sur des plateformes distinctes.

Un bref récit de la transformation

En 2017, nous avons introduit le concept de Value Stream - ce sont des équipes interfonctionnelles qui sont responsables de tâches commerciales spécifiques. Pour comprendre ce que notre entreprise a des tâches spécifiques, nous avons rassemblé environ 25-30 personnes de toute l'entreprise, des coachs invités qui sont engagés dans des méthodologies flexibles, et en 2 jours, nous avons formulé le type de valeur que nous devrions avoir - les directions de développement.

Vous avez 5-6 flux de valeur. Ils ont planté ces gars-là ensemble, ont donné à chacun un Product Owner, qui se noierait pour cette direction particulière (plus de détails ici ).

Nous avons connu la douleur, le sang, les larmes et la joie et avons atteint de très bons indicateurs:

• Déchargement synchrone de fonctionnalités identiques sur différentes plateformes .
• Une diminution multiple du délai de mise sur le marché . La publication de nombreuses fonctionnalités ne reposait que sur le cycle de gestion des versions sur chaque plate-forme, car, par exemple, Apple ne permet pas de décharger chaque fonctionnalité séparément. Par conséquent, les fonctionnalités sont regroupées et, en moyenne, nous sortirons une fois toutes les deux semaines.
• Élimination des "goulots d'étranglement" , qui étaient à la fois propriétaires de produits et responsables techniques et chefs d'équipe.
• Les développeurs ont commencé à comprendre pourquoi ils "scient" de nouvelles fonctionnalités.

Nous avons très bien survécu à l'année - en 2017, les revenus ont presque doublé .

Mais cela ne suffisait pas et la vie fin 2017 - début 2018 nous a surpris.

Pourquoi aviez-vous besoin d'un nouveau produit

Les entreprises se sont fixé de nouveaux objectifs. La surprise a été que le développement de tout logiciel existe pour le bien de quelque chose. Peu écrivent du code pour des raisons altruistes. Pour que l'entreprise justifie son existence, ses propriétaires et actionnaires se fixent certains objectifs que l'équipe doit atteindre.

Nos actionnaires ne disent pas comment faire, ils disent ce qu'ils veulent réaliser. Comment - l'équipe doit décider.

L'équipe a été confrontée à la tâche de trouver comment gagner plus . Nous avons mené un remue-méninges, et le service d'épicerie, avec le service technique, est arrivé à la conclusion que pour atteindre des objectifs ambitieux (conditionnellement, doubler la taille de l'audience payante), en principe, nous devrions déplacer l'accent de la visualisation gratuite du film vers le payant.

Presque toutes les hypothèses avancées cadrent très mal avec le concept de l'ancien produit. Plus précisément, cela ne convenait pas du tout - tout flux de motivation sur les transitions des utilisateurs reposait sur le fait que sur certaines plates-formes, cela était implémenté, sur certains non, il y avait certaines limitations, d'autres là-bas. Notre équipe a 9 ans et nous avons accumulé beaucoup de choses qui nous ont entraînés au fond. Dans le bon sens, il fallait tout réécrire.

Plusieurs études qualitatives et quantitatives ont montré les problèmes de l'ancien produit . Il s'est avéré que nous avons 2-3 ans derrière ce à quoi l'humanité sage a pensé. Par exemple, s'il y a environ 5 ans sur les appareils mobiles, il était à la mode et moderne de mettre un menu de hamburger dans le coin supérieur gauche, puis avec l'avènement des grands écrans, les gens ont cessé de s'y rendre. Jusqu'en 2018, nous avions vraiment un menu de hamburgers, et les gens s'en sortaient en quelque sorte.

Le pauvre utilisateur s'habitue à tout, mais cela ne signifie pas que vous devez tout laisser tel quel.

De nombreux cadres devaient être refactorisés. Nous avons trouvé des défauts logiques et, comme dans tout code à longue durée de vie, nous avions beaucoup de vieux codes pas très bons. Les développeurs n’ont vraiment pas aimé.

Par exemple, il est très difficile d'embaucher des développeurs qui souhaitent écrire en Objective-C. Nous sommes tous influencés par la mode, et même paresseux - s'il existe un outil qui vous permet de faire la même chose, mais plus rapidement et plus efficacement, nous voulons l'utiliser. Et la situation sur le marché du travail est telle que vous pouvez écrire dans un résumé: "Je veux écrire en Swift", et même si vous ne savez pas écrire en Swift, vous arriverez certainement quelque part.

Il fallait faire quelque chose avec cela, et c'est l'un des problèmes qui entravent le développement. Par conséquent, nous avons dû réécrire des composants obsolètes et implémenter des cadres modernes.

Buts

Nous voulions:

• Créez un nouveau produit avec un design unique.
• Faites en sorte que notre bon système de recommandation devienne responsable de l'émission de tous les blocs de notre produit.
• Corrigez les erreurs d'interface logique.
• Nettoyez le code.
• Migrez vers un nouveau système de statistiques.
• Mettre en œuvre un système de conception.

Tous les défis sont assez ambitieux, en particulier le système de conception, car il y a très peu de systèmes de conception qui fonctionnent sur plusieurs plates-formes et sont séparés du code du programme. Ils produisent principalement le moteur JS, qui est utilisé sur différentes plateformes. En fait, le mécanisme de transmission des informations sur l'apparence du produit se trouve dans le code.

Nous ne pouvons pas très bien le faire, car nous travaillons avec la vidéo, et travailler avec la vidéo nécessite l'utilisation d'outils plus ou moins natifs. De plus, si vous n'utilisez pas d'outils natifs, il y aura toujours un retard de 1 à 2 étapes des versions du système d'exploitation. Tous les frameworks universels comme Xamarin doivent encore être rattrapés après les versions. Et nous sommes très gourmands avant d'être présentés - Google et Apple nous recommandent simplement parce que nous utilisons des outils natifs.

Les outils natifs aident à créer des applications de qualité, bonnes et rapides. Dans le cas de la vidéo, cela est simplement nécessaire.

Recherche de solutions de gestion

Après avoir désigné les objectifs, nous avons réglé leur réalisation rapide. Permettez-moi de vous rappeler que nous étions divisés en Value Stream, différents développeurs étaient assis dans différentes équipes et nous étions confrontés à la dure réalité - que faire?

Il semble que nous avions un système auquel nous habituions les gens depuis un certain temps, et maintenant les règles du jeu ont changé.

Bien sûr, au début, nous avons essayé de travailler comme avant, en utilisant Value Stream, en acceptant les calculs logiques suivants: «Laissez Value Stream, qui est engagé dans une telle direction de l'entreprise, refactoriser tous les composants associés à ces domaines.»

Oh comme nous avions tort! Environ un mois plus tard, il s'est avéré que pour réécrire le cœur de chacune des applications, en fait, vous devez entrer dans tous les domaines des règles métier.

Il était très difficile de différencier le domaine de responsabilité de Value Stream, qui joue quel rôle lorsque les gens sont assis à différents étages, dans différentes pièces.

Ce qui est le plus triste, en raison des différents langages et fonctionnalités des plateformes de développement, l'effet de la collaboration a complètement disparu.

Dans le cadre de Value Stream, les développeurs iOS et Android voient la même fonctionnalité, et ils ont quelque chose à dire, ils discutent de la logique métier. Et lorsque chacun d'eux voit un cadre de bas niveau, qui est faiblement corrélé avec ce qui sera plus tard dans le produit final, la synchronisation disparaît complètement.

Il y avait des gens qui, en principe, ont rompu avec le sens de ce qui se passait. Les Timlides ont été les premiers à se décourager, car en tant que personnes responsables, ils devaient trébucher et ne pas croire aux employés de l'humanité pour retourner au sein de la véritable église afin d'écrire un code adéquat dans la bonne direction. Cela s'est très mal passé.

Après un mois et demi, nous avons réalisé que les Value Streams fonctionnent très bien pour les produits finis, mais sont généralement inefficaces lorsqu'un produit doit être écrit à partir de zéro.

Comme toutes les vérités simples, vous ne les comprenez qu'après avoir traversé le râteau pieds nus, et même laissé le courant traverser le râteau.

Tout ce qui est nouveau est bien oublié.

Nous retournerons tout comme il était

Après la transformation agile triomphante, nous avons décidé de tout faire comme en 2016, car le droit à la démocratie doit être mérité.

Pour que chacun ait le droit de voter, et ce droit est revendiqué et utilisé, il est nécessaire de définir les règles et l'écosystème dans lequel il fonctionnera.

Lorsqu'il n'y a pas d'écosystème, certaines choses doivent être faites de manière autoritaire afin que les règles soient en quelque sorte formées.

A fait ce qui suit:

• Ils ont ramené les gens sous l'aile des timlids, les ont recentrés de la programmation axée sur les fonctionnalités à la programmation juste normale.
• Des chefs de produit ont été affectés aux utilisateurs de flux. Dans notre cas, il s'agit de téléchargement, d'autorisation, etc.
• Nous avons essayé de formaliser toutes les exigences pour un nouveau produit, ce que nous avons convenu au début du développement.

Tout semble logique, mais comme il y a deux ans, nous avons rencontré les mêmes problèmes.

Ça ne marchera pas, encore des problèmes dans l'organisation

Il y a deux ans, les principaux problèmes étaient: la centralisation et la prise de décision.

L'autoritarisme conduit à l'émergence de «goulots d'étranglement» - chefs d'équipe, responsables techniques et chefs de produit qui n'ont pas le temps de transmettre des fonctionnalités au développement. Un produit scié depuis 8 ans est difficile à repenser en quelques mois. Ce n'est pas cool quand 80% du concept est prêt, et 20% (juste là où est la pulpe) n'est pas encore là. Cela a énormément contrarié et bouleversé l'équipe.

Lorsque les développeurs ont officiellement repris la gestion des chefs d'équipe, la communication en direct avec les chefs de produit était beaucoup moins importante et il était nécessaire de formaliser les savoirs traditionnels. Ce qui a été parfaitement remplacé par la communication verbale est redevenu un formalisme - il est revenu, personne ne l'a rendu. Mais les ingénieurs sont disposés de cette façon, ils sont enseignés à l'institut: il y a une déclaration de problème - elle doit être résolue, il n'y a pas de déclaration de problème - le monde s'écroule, l'algorithme ne fonctionnera pas.

Au cours du processus, des erreurs et des erreurs de calcul ont été découvertes, à la fois logiques et architecturales. Imaginez faire du code pendant plusieurs années, et pendant tout ce temps vous voulez le refactoriser, et quand l'occasion se présente, il s'avère que toutes les idées et concepts ne sont pas très bons ou ne fonctionnent pas du tout. Le rêve s'avère faux.

Dans le même temps, comme c'est généralement le cas lors de l'évaluation des délais, une entreprise entend une chose, le développement en entend une autre. De plus, l'entreprise se divise toujours en deux, puis elle commence à faire pression sur les délais et veut obtenir un nouveau produit hier. À l'heure X, il s'avère que le développement pense qu'il reste encore 3-4 mois, et que l'entreprise attendait la sortie hier. Tout le monde est bouleversé, l'équipe commence à se déchirer.

Qu'as tu fait

Nous avons mené une rétrospective à grande échelle sur notre mode de vie et révélé ce qui inquiète le plus les développeurs et les chefs d'équipe.

La nécessité de refaire la fonctionnalité , et souvent 3 fois. Pour être honnête, exactement la moitié des problèmes étaient du côté de l'énoncé du problème, la seconde moitié était du côté de la mise en œuvre. Cependant, les développeurs, bien sûr, étaient fermement convaincus que tout le problème était dans la formulation du problème. Du côté de la tâche, les directeurs étaient les mêmes. Personne ne veut se considérer mal ou coupable, tout le monde dit que le problème est de l'autre côté.

Prise en charge de l'ancienne application . Un service avec une audience de plusieurs millions de dollars ne peut pas être abandonné. Parallèlement à l'écriture d'un nouveau produit, quelque chose doit être fait avec l'ancien. C'est terriblement ennuyeux!

Mise en place d'un système de conception. Nous sommes très fiers de cette direction: cela vous permet vraiment de faire rapidement des choses très complexes, et le produit semble uniforme. Mais j'ai dû former des concepteurs sur ce qu'est JSON, et les concepteurs ont dû communiquer aux développeurs que l'apparence est également très importante. Beaucoup d'exemplaires ont été cassés à ce sujet.

Manque d'informations et de réponses à la question «Pourquoi?». Sans Value Stream, certains développeurs ne comprennent plus pourquoi ils font quelque chose. Il y a eu une interruption de la transmission des informations et la relation de cause à effet a en partie disparu. Ceux qui ont trouvé la force de demander pourquoi nous faisions cela étaient heureux. Les gens peu communicatifs pensaient que les idiots étaient assis quelque part à l'étage et inventaient des choses qui ne peuvent pas être conçues.

Manque de documentation sur les nouvelles règles métier. En raison du manque d'informations, il y avait un manque de documentation dans laquelle il serait précisé comment l'application devrait fonctionner correctement.

Tout le monde a essayé le rôle d'un architecte, et tout le monde n'a pas aimé. Pour moi, c'était la plus grande découverte. Pour la première fois, les chefs d'équipe ont estimé les délais de traitement des demandes à environ un an et demi, ce qui ne vaut rien. Cela s'est produit parce que chaque chef d'équipe voulait laisser passer toutes les pièces du système à travers lui-même, c'est-à-dire qu'il ne voulait vraiment pas déléguer et décomposer l'architecture de l'application, mais voulait tout garder pour lui.

Avec cette approche, il faut vraiment un an et demi pour retravailler l'architecture. Mais avec de tels termes dans ce monde, il n'y a rien à faire. Par conséquent, après de longues discussions, nous sommes arrivés à la conclusion que les fonctions architecturales du chef d'équipe devaient être déléguées à des combattants expérimentés du développement, qui, entre autres, voulaient participer et se sentir comme un architecte, dans certains domaines clés.

Il s'est avéré un fait intéressant - il s'avère que la prise de responsabilité est désagréable.

Vous appeler architecte ou chef d'équipe et être chef d'équipe sont deux grandes différences. Tout le monde ne s'est pas montré prêt à accepter que si vous prenez soin et gaspillez une conversion, cela ne sera que votre responsabilité.

J'étais naïf et pour une raison quelconque, je pensais que tout le monde dans notre équipe possédait un tel courage. J'oubliais qu'avant Timlid, il fallait mûrir et grandir un peu. Au cours de l'année, beaucoup d'entre nous sont allés dans cette direction, et certains ont réalisé qu'ils ne voulaient pas grandir, mais en largeur, et ne voulaient pas être des chefs d'équipe.

Comment régler la situation

En plus de la décomposition et de la différenciation des rôles de timlid dans diverses directions architecturales, nous avons formé les soi-disant unités de représailles volantes (COV) et y avons attiré des spécialistes du contrôle de la qualité (AQ). Premièrement, ils étaient plus libres que tout le monde - il n'y a pas encore de nouveau produit, et vous pouvez maintenant écrire un scénario de test et une suite de tests pour les régressions suivantes.

Il s'est ensuite avéré que les règles commerciales n'étaient pas encore entièrement formulées et que la société ne comptait pas beaucoup de personnes qui savent comment la nouvelle application devrait fonctionner.

Nous avons défini les tâches suivantes pour le contrôle qualité:

• Nous avons besoin d'une documentation à jour sur les règles métier et la logique de fonctionnement de l'application.
• Les adhérents de la nouvelle logique métier sont nécessaires, et pas seulement les managers et les responsables techniques.

Étant donné que nous avons une nouvelle application et que nous devons tout recommencer, nous avons besoin de personnes capables de poser des questions telles que: comment gérer une telle erreur, comment l'application devrait se comporter dans une telle situation. Je le répète, les principaux cas ont été décrits, mais le diable est dans les détails - ces mêmes 20% devaient être fermés.

Nous avons commencé à créer des microcommandes dynamiques. Malgré le fait que les gens n'ont été transplantés nulle part, mais attachés à un produit d'une direction spécifique, une personne de QA qui a été méthodiquement engagée dans le travail de projet, à savoir, était responsable de:

• recueillir les questions des développeurs, créer des questionnaires;
• organisation et enregistrement des réunions;
• formalisation de la documentation;
• rédiger des cas de test et des suites de tests à l'avance.

Lorsque nous avons atteint la ligne d'arrivée, cela nous a permis de connecter des sous-traitants, des employés pour les tests afin d'augmenter la vitesse de préparation de la sortie. Nous avons un grand nombre de plates-formes, ce que j'ai énuméré ne sont que les outils avec lesquels nous travaillons. Par exemple, dans SmartTV, il existe 6-7 plates-formes, pour chacune desquelles vous devez publier séparément, effectuer une régression distincte, etc. Si vous avez des analyses de rentabilisation prédéfinies, vous pouvez facilement connecter des sous-traitants et des employés externes ici.

L'introduction des COV a grandement soulagé les Timlids. Ils ont eu l'opportunité de ne pas se laisser distraire par les tâches de gestion, mais de prendre des décisions stratégiques concernant le développement du code sur la base du matériel développé.

Le projet «The Flying Squads of Retribution» a répondu aux attentes, et nous sommes entrés dans la ligne de sortie sans nous tuer.

Et ensuite?

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

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

, , .

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

.

.

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

: , , , . . .

TeamLead Conf . , , , . 23 24 .