Comment construire des processus et arrêter de se moquer d'une équipe

Bonjour à tous! Aujourd'hui, je voulais parler des processus de développement. Au fur et à mesure que l'entreprise grandit, non seulement l'entreprise elle-même se développe, mais aussi des problèmes s'accumulent à l'intérieur, en particulier pendant le processus de développement. Souvent, ils essaient de les résoudre en introduisant des pratiques et des méthodologies nouvelles. Hélas, cette réorganisation forcée du processus selon les livres et les formations conduit souvent à des problèmes encore plus importants - la moquerie des gens.

J'ai récemment parlé à la conférence Saint TeamLead Conf 2019 , dans un rapport, j'ai expliqué comment j'ai pu trouver un certain nombre de problèmes dans le flux de travail et les surmonter progressivement. Ici, je vais essayer de décrire les pratiques les plus précieuses qui m'ont aidé non seulement à établir un flux de travail, mais aussi à arrêter de se moquer des développeurs. Les employés ont changé d'attitude envers l'entreprise dans son ensemble et le processus de travail.

Défis du processus de développement

Alors, lorsque les approches toutes faites n'ont pas donné de résultat, et que nous étions proches du désespoir, j'ai commencé à analyser les processus et à tout analyser par les os. Le résultat est une liste de problèmes:

• Le tableau est surchargé de tâches - il y avait un vrai chaos dessus. En regardant le tableau, il était presque impossible de comprendre les processus.
• Il n'y a pas eu d'évaluations normales - nous ne savions pas comment évaluer correctement les tâches en fonction des délais, pour cette raison, les délais étaient constamment en cours, les chefs d'entreprise se sont lancés dans le développement.
• Nous respections constamment les délais - nous ne pouvions pas dire exactement quand la fonctionnalité entrerait en production, le plus souvent nous l'avons déployée beaucoup plus tard que prévu en raison de facteurs externes, par exemple, l'entreprise a recouru et a demandé de faire rapidement une fonctionnalité urgente en premier lieu.
• On ne comprenait pas comment accélérer le développement - l'embauche de nouvelles personnes et le chargement d'ingénieurs à 100% ne rendent pas toujours le processus plus rapide.
• Planification et tâches urgentes - si avec les tâches en cours, il était en quelque sorte possible de faire des plans et d'indiquer des dates approximatives, alors les tâches urgentes qui provenaient généralement de l'entreprise ont brisé tous les plans.
• Les réunions prennent du temps - notre erreur la plus courante: quelque chose ne fonctionne pas ou nous devons prioriser les tâches - et nous allons nous réunir et discuter. Ou des réunions régulières, où les développeurs se sont assis pendant une heure ou deux et n'ont pas compris ce qu'ils faisaient là-bas.
• Le problème de la motivation et de l'implication des équipes - souvent certaines innovations ont été simplement apportées par les autorités d'en haut, sans demander l'avis de l'équipe de développement, cela n'a pas dépeint l'atmosphère de l'équipe.

En fait, la tâche de tout leader, qu'il soit TL ou CTO, est qu'il devienne le lien entre le business et le développement.

Pour sortir de cette situation, nous nous sommes tournés vers la méthode Kanban. Que nous dit-il? Améliorons ce qui existe déjà. Eh bien, nous sommes allés améliorer notre processus de développement.

Mettre de l'ordre au tableau

Nous avons commencé à discuter: si les backenders ont terminé leur tâche et remis au front-end, commenceront-ils immédiatement? En regardant le tableau, c'est incompréhensible. Selon les principes de Kanban, nous avons divisé chaque direction de développement (nous en avions 5: backend, frontend, DevOps, QA et design) en deux colonnes: Do et Done. Le problème est immédiatement apparu: notre bande passante ne nous permet pas de faire autant de tâches qu’ils le souhaitent.



Kanban dit aussi: introduisons une limite WIP et limitons le nombre de tâches. Comment fixons-nous des limites? Empiriquement. Bien sûr, ils ont raté plusieurs fois, mais ensuite ils l'ont ramassé afin que nous n'ayons pas à accumuler des tâches dans l'endroit le plus étroit. Un bénéfice supplémentaire de WIP-limit est un déclencheur, qui dit que dès que la tâche est supprimée, nous pouvons prendre ce qui suit. C'est une sorte de système de traction.



À quoi cela a-t-il conduit? Les ingénieurs ont commencé à être plus attentifs aux tâches, car lorsqu'ils ne peuvent pas résoudre un problème, un bloqueur est mis dessus. Plus aucune tâche ne peut être effectuée, car il existe une limite WIP, les ingénieurs doivent attendre qu’elle les aide à la résoudre. Il y a une chance de rester sans tâches.

Lorsque nous avons commencé à analyser en détail le problème du retour des tâches, il s'est avéré que tout le monde les faisait différemment, par exemple, quelqu'un écrit des tests, et quelqu'un non. Il y avait des règles à cet égard, mais celles qui ont été abandonnées par les autorités. Ils n'ont pas résolu le problème des développeurs. Nous avons introduit de nouvelles règles ( Définition de Terminé ), qui sont intégrées au tableau. Ils pouvaient agir à la fois sur une colonne et sur le type de carte. Par exemple, pour une API, vous avez besoin du backend pour documenter toutes les méthodes et tout. Les règles étaient accessibles à tous et visibles sur la carte, et surtout, elles provenaient des ingénieurs eux-mêmes et ont résolu leurs problèmes. Si quelque chose n'a pas été fait, l'ingénieur l'a vu et est allé le faire.

Tâches de notation

Nous ne savions pas comment évaluer les tâches par délais, et Kanban nous dit: «Pas d'estimation». Que faire Nous avons accumulé des statistiques et construit un tel calendrier. Il s'agit d'un diagramme spectral, la dépendance du nombre de tâches dans le temps.



Nous avons commencé à l'étudier, vu sur le graphique 3 pics qui correspondent à trois types de travaux. Sur la base de ces types, une classification et des critères pour ces travaux ont été élaborés. Nous avons introduit ces types sur le tableau des tâches, puis pour chacun dans le processus, nous avons ajouté des règles supplémentaires. Nous avons obtenu ce qui suit:



Nous avons convenu avec le client, c'est-à-dire avec l'entreprise, d'un contrat de qualité de service (SLA). Un manager vient vers nous et demande: "Et combien allez-vous faire cette fonctionnalité?" Nous ne pouvons pas dire combien nous ferons avec certitude, mais nous pouvons dire combien de temps sera consacré à un lot entier de telles tâches. Il n'y avait pas besoin de Scrum Poker, et nous avons cessé de torturer les gens avec des questions de timing. Nous avons juste regardé les statistiques et appelé les dates pour les affaires.



Bien entendu, cette approche présente également des inconvénients. Par exemple, cela ne fonctionnait pas avec des tâches d'un nouveau type, pour lesquelles nous n'avions tout simplement pas de statistiques. Ils ont fait semblant d'être à l'ancienne, mais ils ont ensuite accumulé une quantité suffisante de données et ce problème n'a pas abouti.



Ensuite, nous avons été confrontés au fait que certaines tâches ont commencé à tomber dans d'autres types de travail. Nous avons effectué quelques recherches et découvert que certaines tâches étaient effectuées beaucoup plus rapidement, car l'entreprise a promis aux partenaires quelque chose et a demandé aux développeurs de les faire de toute urgence. Et certaines tâches au contraire n'étaient pas si importantes, elles ont été reportées. Nous avons donc eu des priorités, c'est-à-dire des accords sur les classes de services de services (CoS), nous les avons placés au conseil d'administration. Et pour que l'entreprise n'en abuse pas et ne fixe pas une urgence accrue pour toutes les tâches, des limites WIP horizontales ont été introduites.

Comment accélérer le développement

Passons à nouveau aux statistiques du traqueur de tâches. Nous avons constaté que de nombreuses tâches sont suspendues en prévision d'améliorations, de vérifications ou de données supplémentaires, c'est-à-dire qu'elles ont réalisé que le développement peut être accéléré. Ils ont commencé à regarder combien de tâches s'accumulent, combien elles sont inactives et ont constaté que certaines fonctionnalités étaient moins développées que prévu. Nous avons décidé de fixer un jour pour l'acceptation des fonctionnalités, et le délai d'émission des tâches a été réduit. Et puis nous avons attaché le CD (livraison continue) et commencé à envoyer des notifications.

Il est devenu clair que nous avions besoin d'un outil pour évaluer nos améliorations. Nous avons décidé d'utiliser le diagramme de flux cumulatif. En bref, comment il est construit: nous attribuons une couleur à chaque poste de travail (colonnes sur le tableau), prenons des statistiques sur le nombre d'éléments (tâches) dans une unité de temps dans une colonne, et les traçons sur le graphique, en les plaçant l'un sous l'autre. Sur le graphique, l'axe X est le temps, l'axe Y est le nombre de tâches.



Qu'avons-nous obtenu d'ici? Ici, il est facile de voir le délai d'exécution (temps de production) - la ligne horizontale (la largeur du flux le long de l'axe X) commence par l'énoncé du problème et atteint le stade de préparation. Ainsi, ici, vous pouvez voir comment la tâche traverse toutes les étapes du développement - la ligne croise toutes les couleurs, chacune correspondant à sa phase. Et aussi la limite WIP totale de la carte - la hauteur d'écoulement le long de l'axe Y. Comment augmenter la vitesse de développement? Vous pouvez réduire la limite WIP (c'est-à-dire rendre le flux sur le graphique plus étroit), ou vous pouvez rendre notre flux, qui est dirigé de l'origine vers le coin supérieur droit du graphique, a tendance à augmenter encore plus (c'est-à-dire à augmenter la direction du flux encore plus haut, réduire son angle par rapport à l'axe Y). Pour diriger le flux vers le haut, vous pouvez introduire une nouvelle pratique, par exemple, implémenter Docker ou créer une base de connaissances pratique. Il ne s'agit pas nécessairement d'une innovation technique; une nouvelle approche de la gestion peut également donner un tel effet.


Ainsi, nous avons obtenu un outil qui montrait clairement quelles améliorations fonctionnaient et lesquelles ne fonctionnaient pas.

Planification d'entreprise, tâches urgentes et inutiles

La planification du développement des affaires a été la plus grande difficulté. Qu'avons-nous fait? Après avoir reçu la tâche de l'entreprise, une réunion a eu lieu entre l'analyste et le développeur, où ils l'ont décomposée, et le développeur a proposé des solutions. En conséquence, nous avons compris combien et quelles ressources la tâche nécessitait. Et ce n'est qu'alors que l'entreprise sans notre participation a fait ses plans et a considéré combien nous pouvons publier des fonctionnalités. Dans Kanban, cela s'appelle la cadence de réapprovisionnement .

Relativement parlant, nous allouons des emplacements d'une certaine taille, conformément aux limites WIP, où vous pouvez placer des tâches. Chaque emplacement ne contient qu'un nombre limité de tâches. D'une autre manière, cette méthode est appelée «planification de coupe».



Nous avons créé un outil simple pour les entreprises (un tableau dans Excel), dans lequel il pouvait planifier visuellement. Les managers se sont battus entre eux, ont discuté de la tâche la plus importante, puis ils sont venus vers nous et ont confié les tâches au développement.

Comme nous avions déjà des limites, l'entreprise était plus attentive au choix des tâches, choisissait les plus importantes et ne nous submergeait d'aucun non-sens. Et un autre gros plus: ils ont sélectionné les tâches eux-mêmes sans notre participation, sans distraire les développeurs pour les réunions, ils ont travaillé tranquillement et n'ont pas passé de temps sur les réunions.

Nous avons également porté notre attention sur le problème des tâches urgentes. Ils ont commencé à analyser les statistiques à leur sujet et ont réalisé que ces tâches n'étaient pas si urgentes. Par exemple, nous avons besoin d'une promotion pour le changement saisonnier des roues des automobilistes. Nous savons que cela se produit toujours 2 fois par an. Une fois qu'ils sont répétés, réservons à l'avance des emplacements pour ces tâches sur le tableau. Il n'y aura rien d'urgence - nous prendrons une autre tâche de la file d'attente, nous ne resterons pas sans travail. En conséquence, nous avons découvert que 60% des tâches urgentes ne sont en fait pas urgentes.

Il y avait un autre problème. Nous avons souvent scié des fonctionnalités, qui ont finalement refusé l'activité, car elles se sont révélées inutiles d'un point de vue commercial. Nous avons suggéré que les entreprises utilisent des fonctionnalités MVP qui nécessitent plusieurs fois moins de temps que le développement conventionnel. Les commentaires ont commencé à être supprimés beaucoup plus rapidement et les ingénieurs ont commencé à réaliser qu'il s'agissait d'expériences. Auparavant, lorsque des semaines de travail étaient jetées à la poubelle, ils s'inquiétaient, cela empoisonnait leur vie.

Nous avons commencé à tester 85% des fonctionnalités de telle manière qu'au final nous avons dégagé beaucoup de temps, que nous avons ensuite consacré à des hypothèses testées en pratique. Ils ont déjà apporté de l'argent à l'entreprise. De plus, en cas de problème dans le processus, le client de la fonctionnalité de l'entreprise peut apporter des corrections à un stade précoce, et non tout au long du cycle de développement.

En conséquence, un tel fait a été découvert que toutes les idées ne fonctionnent pas. Et puisqu'ils ne fonctionnent pas, alors ne les faites pas. Depuis lors, les développeurs ont cessé de travailler avec des singes et ont fait exactement ce que l'entreprise rapporte.

Réunions

Les améliorations que nous avons apportées à cette époque avaient déjà tué un certain nombre de réunions inutiles. Les discussions de priorisation n'étaient plus, puisque nous avons donné cela à l'entreprise, nous avons également planifié sans ingénieurs. Nous avons également abandonné les raids de cinq minutes des managers avec une demande "d'aide rapide". Il n'y avait que des réunions vraiment nécessaires. Nous avons également introduit la règle selon laquelle les réunions sont désormais planifiées à une heure précise afin que chacun puisse planifier son horaire.

En conséquence, toutes les réunions sur la boltologie ont été transformées en types de réunions suivants:

• lorsqu'un analyste souhaite discuter d'un problème spécifique avec un ingénieur, par exemple, pour trouver la solution ou la décomposition optimale;
• quand quelque chose est coincé sur la planche. Dans ces cas, nous nous sommes rassemblés et avons marché le long de la planche de droite à gauche, demandant aux ingénieurs ce qui s'était passé, qui pouvait aider. Il est important que nous passions de tâches et n'essayions pas de calculer ce que les gens faisaient;
  
• quand ils ont planifié des tâches pour le sprint (cadence pour la reconstitution);
• quand ils ont pris des traits;
• Réunions entre équipes de développement, par exemple, pour discuter du format de l'API ou décider des événements à envoyer.

Point clé: nous avons invité à des réunions uniquement les personnes directement impliquées dans le sujet de discussion et qui n'ont pas appelé d'auditeurs nominés, comme auparavant. Les ingénieurs ont fondamentalement changé d'attitude vis-à-vis des réunions, avant de ne pas les aimer, mais maintenant c'est l'inverse, ils semblent leur être nécessaires et utiles.

Motivation et implication de l'équipe

Tout ce que nous avons mis en place: limites WIP, évaluation des tâches sur la base de statistiques, refus des tâches inutiles, etc. décrites ci-dessus, a permis de libérer du temps pour les ingénieurs. Que vont-ils faire maintenant? La plus grande idée fausse est que personne ne fera rien. J'ai moi-même entendu à plusieurs reprises les gars: "J'aurais refactorisé ce code, sinon la jambe du diable se briserait". Oui, au début, l'ingénieur dort vraiment et se repose pendant 2-3 semaines, puis quoi? Il s'assoit sans tâches, commence à approcher ses collègues avec une proposition d'aide, aide à accomplir les tâches, puis les deux sont déjà assis sans tâches. «Envoyons les bugs corrigés» - la colonne contenant les bogues était vide. «Envoyez le code que nous allons refactoriser» - le code est devenu plus rapide à écrire, la limite WIP peut être augmentée. Ensuite, ils commencent à mettre en œuvre CD / CI, écrire une base de connaissances. Qu'est-il arrivé? Les ingénieurs commencent à faire beaucoup de choses utiles, auxquelles leurs mains n'atteignent pas. C'est la vitesse que l'entreprise souhaite, mais pour une raison quelconque, elle ne peut l'obtenir de personne. Auparavant, l'ingénieur était en colère, il voulait que tout le monde soit derrière lui, et maintenant le paradigme humain a changé en: "Maintenant, comment puis-je vous aider?" Le nombre d'initiatives a augmenté et elles sont toutes venues d'en bas, pas d'en haut. Et finalement, cela s'est avéré beaucoup plus utile.

Résumé des résultats

• Nous avons pu trouver un goulot d'étranglement dans le système et comprendre que nous ne pouvons pas faire plus que ce que nous pouvons.
• Ils ont cessé de jeter aux développeurs un travail inutile et ont libéré du temps pour des tâches plus utiles.
• Lorsque les ingénieurs n'avaient rien à faire, ils ont commencé à mieux évaluer les tâches, à ratisser les bogues, à automatiser les processus et une base de connaissances est apparue.
  
• Les ingénieurs ont cessé d'être stressés et sont devenus plus gentils.
• Nous avons pu accélérer 4 fois la sortie de nouvelles fonctionnalités grâce à des améliorations, à l'optimisation du travail (augmentation des limites WIP grâce à l'automatisation et aux améliorations).
• Nous avons obtenu des statistiques sur les entreprises et une compréhension claire de ce qui se passe et de la façon dont le développement se déroule.
• Nous avons appris à gagner du temps (rejet des tâches inutiles, commencé à réfléchir à l'avance aux tâches afin d'éviter des facteurs supplémentaires, etc.).
• Les réunions et les réunions ont eu lieu quand elles sont vraiment nécessaires (devenir plus flexibles).
• Tout le monde a commencé à réfléchir davantage, le nombre d'initiatives a augmenté. Les initiatives qui naissent en équipes sont toujours meilleures que celles qui viennent d'en haut. Le processus s'est poursuivi en permanence et tout le monde s'y est impliqué.

Conclusions

Dans cet article et ce rapport, je voulais attirer l'attention non seulement sur les outils et les approches que j'ai appliqués, mais plutôt sur l'aspect le plus important, qui passe souvent inaperçu, mais, à mon avis, il n'en est pas moins important. Nous avons commencé toute cette perestroïka, car nous avions des douleurs et nous voulions nous en débarrasser.

Vous pouvez mettre en œuvre quelque chose «sur le front» en lisant des livres intelligents ou en écoutant un rapport sur des méthodologies flexibles, de sorte qu'il est même possible d'accélérer le développement ou les produits fonctionneront mieux. Mais nous oublions souvent que les gens fabriquent ces produits, et mieux nous améliorons leur vie, mieux ils fabriqueront des produits. Par exemple, je vais voir les gars et je leur demande: «Et quelles sont vos douleurs? Qu'est-ce qui ne va pas? », Avant de commencer à mettre en œuvre quelque chose. Et c'est uniquement grâce à cette approche que j'ai réussi à faire ce que l'entreprise veut: rapidité et qualité de développement.

PS On m'a parlé d'une entreprise en Europe, quand vous venez au bureau, il peut sembler que l'anarchie complète règne: les développeurs, comme le fromage au beurre, jouent aux consoles, personne ne travaille. Mais ce n'est qu'à première vue, il y a une atmosphère spécialement créée pour les gens afin qu'ils puissent créer et s'améliorer. Dans l'intervalle entre les tâches de divertissement, un genou a écrit une solution qui a ensuite été mise en œuvre, et elle a commencé à apporter des bénéfices à l'entreprise. J'espère que notre direction russe ira dans cette direction dans un avenir proche. Et si pour une raison quelconque vous avez quelque chose de mal, pensez à ce que vous faites. Eh bien, ou lancez cet article au patron, mais si cela aide :)