Construire des processus à partir de zéro: du chaos à l'ordre

Dans cet article, je vais parler de la création de workflows dans un petit département de développement web. Le département a été créé à partir de zéro et a immédiatement commencé un travail autonome, nous avons donc dû construire nous-mêmes les processus de production, marcher sur toutes sortes de râteaux et en tirer les conclusions nécessaires. Dans l'espoir que cela aidera quelqu'un à gagner du temps, de l'argent et des nerfs, je décrirai les problèmes auxquels nous sommes confrontés et nos options pour les résoudre.

Il est important de noter que ce n'est pas une méthodologie universelle qui peut être mise en œuvre dans n'importe quelle équipe de développement, et tout sera merveilleux tout de suite. Il s'agit simplement d'un mélange de techniques bien connues et d'expérience pratique, que nous avons pu ajuster efficacement à nos fonctionnalités de développement. Il n'y a pas de solution unique et simple à ce problème. Vous devez toujours vous appuyer sur la taille et l'expérience de l'équipe elle-même, les caractéristiques de l'entreprise, les spécificités des projets, etc.

Les données initiales de notre département: une petite équipe produit (5-10 personnes), partiellement répartie (certains employés travaillent à distance, d'autres au bureau) avec des clients internes à l'entreprise. Projets Web. Il n'y a pas de spécialistes de l'administration du système au sein du département, mais il existe des départements impliqués dans l'entreprise.

Communication d'équipe

Commençons par établir une communication efficace au sein du département. Dans toute équipe, il est important de créer des canaux et des moyens de communication efficaces, mais lorsque l'équipe se répartit, ce besoin s'intensifie. Il a atteint sa netteté maximale ici parce que l'équipe n'était que partiellement répartie. Nous avons dû apprendre à fusionner les mondes des employés de bureau et à distance.

Le problème le plus important que nous ayons rencontré est celui des discussions verbales. Le personnel du bureau a toujours la tentation d'emballer rapidement une tasse de café et de discuter de l'état d'avancement du projet. Cependant, dans ce cas, les travailleurs à distance ne pourront pas participer à cette discussion, par conséquent, ils ne pourront pas apporter leurs idées, et en effet ils ne sauront pas que quelque chose se passe. En règle générale, cela se traduit par une désynchronisation des actions de l'équipe, des discussions répétées en raison de l'émergence de nouvelles pensées et suggestions de la part distribuée de l'équipe et juste un arrière-goût désagréable.

Il est devenu clair que certaines choses communes importantes devraient être discutées par écrit dans les discussions générales ou lors de certains appels de groupe.

Cela donne lieu à un autre problème très courant qui apparaît dans les équipes où vous devez beaucoup écrire - le problème de la culture de l'écriture. Vous ne pouvez pas simplement aller voir un collègue, tirer votre manche, dessiner quelque chose sur une serviette et ajouter des gestes à votre histoire. D'une part, cela complique le travail, et d'autre part, les gens développent la capacité d'écrire leurs pensées d'une manière compréhensible et structurée. À la suite de cette approche, la documentation a commencé à être mieux formalisée, les tâches ont commencé à être formulées plus clairement, tout le monde a commencé à réfléchir à la façon de présenter leurs pensées de manière à ce qu'elles soient compréhensibles pour les autres dès la première lecture.

Tout cela ne signifie pas que nous avons complètement abandonné les communications personnelles, les appels vocaux et vidéo. Cependant, nous avons fait une règle selon laquelle les résultats de ces discussions devraient être enregistrés par écrit, comme une sorte d'artefact de connaissances, toujours accessible à tous.
Regardez brièvement la liste banale des outils avec lesquels nous avons résolu nos tâches de communication au sein de l'équipe.

Tout d'abord, nous avons commencé une discussion sur Telegram. Mais ensuite, en lien avec la croissance de l'équipe, nous avons réalisé que dans une conversation, nous étions déjà proches, et nous sommes passés à Slack. Nous avons divisé le flux général en canaux thématiques et établi des règles claires - pour quelles raisons écrire sur quel canal. Cela a permis d'éviter de mélanger les informations utiles et les inondations.

De plus, le passage à Slack nous a offert de belles opportunités d'automatisation et d'intégration avec d'autres services, tels qu'un système de gestion de référentiel ou un traqueur de bogues.

• Appels audio et vidéo - Skype Entreprise.
• Nous effectuons des tâches à Jira.
• La base de connaissances est stockée dans Confluence.

Planification, exécution et contrôle des tâches

Lorsque nous avons construit les communications, le problème de la définition, du contrôle et de l'achèvement des tâches au sein de l'équipe est devenu pertinent (je parlerai de travailler avec le client à cet égard un peu plus tard).
Nous n'avions pas une seule liste de tâches, leurs priorités, l'état de préparation, etc. Au lieu d'un plan clair, transparent et traçable, une planification et une exécution spontanées à court terme étaient présentes.

Pour faire face à cette situation, nous avons commencé à utiliser un bugtracker (en fait, nous en avons essayé cinq). Des contours de la direction générale du projet ont commencé à apparaître, une compréhension de l'état dans lequel certaines tâches et la vue d'ensemble dans son ensemble sont apparues. Cependant, nous avons été confrontés au problème du manque de discipline lors de l'utilisation du bugtracker, qui a commencé à dévaluer bon nombre de nos efforts. Toutes les tâches n'ont pas été démarrées dans le bugtracker, celles existantes n'ont pas toujours été mises à jour, etc. En termes simples, l'image de l'état du projet a cessé d'être pertinente et fiable.

Pour lutter contre cela, nous avons développé et implémenté notre propre culture de gestion des tâches:

• Le travail ne doit pas être effectué avant le démarrage de la tâche correspondante. Cela permet de tenir à jour l'historique du projet et le travail de l'équipe.
• Lorsque vous travaillez avec une tâche, il est nécessaire de changer son statut en temps opportun. Dans notre cas, quatre statuts suffisent: «À faire» - l'état de début de la tâche, «En cours» - la tâche en cours, «En attente» - la tâche qu'ils ont commencé à exécuter, mais le travail est suspendu (nous attendons quelques informations supplémentaires ), "Terminé" - la tâche est prête. La préparation de la tâche doit en quelque sorte être confirmée par le client ou le responsable de l'équipe.
• Au fil du temps, le nombre de tâches et de projets a considérablement augmenté, nous avons donc divisé la liste générale des travaux en sous-projets distincts, et la tâche doit être lancée en fonction de cette liste de sous-projets.
• La tâche doit avoir la priorité. Cela permet de comprendre quelles tâches dans quel ordre doivent être exécutées pour apporter le maximum d'avantages au projet.
• Tâches revues périodiquement et leurs priorités. Étant donné que les projets vivent et se développent, et que les plans d'affaires changent parfois, au fil du temps, certaines tâches deviennent de plus en plus pertinentes ou nécessitent même leur suppression.
• Certaines discussions clés sur les tâches qui ont été effectuées verbalement ou par écrit dans le chat nécessitent de fixer la solution finale dans la tâche elle-même, de sorte que lorsque nous la terminons, nous voyons toujours les informations les plus pertinentes à son sujet et son historique. Il arrive souvent que l'énoncé initial du problème après une série de discussions se transforme en quelque chose de complètement différent, et nous devons surveiller cela.
• Si une tâche est transférée d'un groupe de spécialistes à un autre au sein d'une équipe, le groupe transférant doit y fixer tous les artefacts de connaissances nécessaires qui doivent être transférés au groupe suivant. Par exemple, une équipe de conception doit joindre des maquettes et toute la documentation nécessaire au développement avant de transférer la tâche à l'équipe de développement. Cela évite les questions inutiles, les distractions et les changements de contexte.
• Attacher des validations aux tâches. En utilisant certaines règles pour nommer les validations, nous attachons automatiquement des liens aux validations aux tâches GitLab. Cela aide grandement dans le développement à comprendre qui, quoi, comment et quand cette tâche. Et dans la direction opposée, par des validations correctement nommées, vous pouvez toujours trouver une tâche contenant la raison des modifications apportées.

Communication client

La prochaine catégorie de difficultés que nous devions résoudre était de travailler avec les clients. La première chose que nous avons dû éradiquer était de mettre des mots dans les mots. Si nous avons introduit la culture de l'écriture au sein du département, le moment est venu de l'étendre aux contacts externes.

Ce n'est un secret pour personne qu'un autre manager aime approcher le développeur, lui dire en mots ce qui doit être fait, mettre des doigts sur l'écran pour se persuader et partir, en espérant que tout se fera bien et à temps. Dans cette situation, le manager et le développeur peuvent être remplacés par un chef de produit et un certain manager de l'équipe de développement qui dirige toutes ces tâches. Le résultat de cela ne changera pas.

Il y a plusieurs problèmes avec cette approche:

• Ce qui est dit en mots et en gestes sera oublié (au moins partiellement) pour demain, au mieux, après-demain. Il ne s’agit pas tant de petites choses, mais du danger d’oublier complètement la tâche. En même temps, il est impossible de confirmer de quelque façon que ce soit à quelqu'un ou que quelqu'un vous a promis de faire au moins quelque chose.
• Habituellement, une telle déclaration du problème est plutôt chaotique et ne contient aucun détail détaillé. Par conséquent, il est très difficile de clarifier les informations manquantes.
• Comme nous l'avons vu précédemment, l'énoncé du problème en mots laisse libre cours à la réticence des corrompus à apprendre à formuler leurs pensées par écrit afin que les autres comprennent.

Lorsque vous avez de nombreux clients et que chacun a ses propres caractéristiques, il est difficile de construire un seul ordre de travail avec tout le monde. Idéalement, nous aimerions amener tous les clients à un traqueur de bogues, où ils pourraient définir des tâches, définir des priorités, discuter des détails, accepter du travail. Mais cela reste une tâche impossible. Cependant, nous avons pu trouver un compromis dans lequel les tâches se déroulent ensemble dans un flux strictement écrit vers notre service de messagerie d'entreprise, et de notre côté le gestionnaire les démarre et les mène plus loin dans le bug tracker selon les règles qui ont déjà été établies dans notre pays. Les tâches ont cessé d'être perdues, oubliées, stockées dans l'esprit de personnes spécifiques, discutées par la composition incomplète des spécialistes requis, etc.

Ensuite, nous avons été confrontés à un autre problème important: il est difficile pour le client de formuler une tâche. Le client n'est pas toujours suffisamment compétent (ou plutôt, presque toujours insuffisamment compétent) dans la formulation des spécifications techniques pour l'équipe technique. Et c'est normal. Le facteur humain ne peut être ignoré: il peut être banal pour le client d'être gêné et mal à l'aise de venir à l'équipe avec une demande alors que lui-même n'a pas encore pu la formuler complètement. L'un des critères d'une équipe professionnelle mature est la capacité d'aider le client à identifier ses problèmes, ses exigences et ses solutions.

Il arrive souvent que le client, au lieu de venir avec un problème, vienne avec une demande de mise en œuvre d'une solution qu'il a déjà inventée. Afin de ne pas surprendre ni nous-mêmes ni le client avec les résultats des travaux sur les TdR élaborés «sur une serviette», nous avons créé une liste de contrôle de base des questions pour le client. Déjà à partir de ces réponses, il est plus facile à la fois pour le client de comprendre ce qu'il veut vraiment et pour l'équipe de développement ce qui lui est demandé. Et puis c'est au tour de poser des questions suggestives pour clarifier ou identifier les exigences.

Ainsi, avant la première rencontre avec le client, nous vous demandons de pré-remplir (autant que possible) et de nous envoyer cette check-list afin que vous n'ayez plus à perdre du temps sur les mêmes questions, mais à entamer immédiatement un dialogue fructueux. Il convient de noter que lors de l'interaction avec le client, il est important non seulement de clarifier les réponses qu'il a fournies, mais également en fonction de son problème déclaré pour l'aider à identifier les exigences auxquelles il n'aurait peut-être pas pensé.

Liste de questions pour le client:

• Quel est le but du projet? Quel problème cela résout-il? Quelle valeur commerciale porte-t-il?
• Est-ce la seule solution possible à ce problème? Sinon, quelles sont les autres options?
• Y a-t-il des exigences générales qui s'appliquent à l'ensemble du projet? Par exemple, s'il s'agit d'une boutique en ligne, elle doit se conformer pleinement à la législation régissant le commerce en ligne.
• Y a-t-il des exigences fonctionnelles? Que doit faire une section (page, projet)? Par exemple, la section devrait fournir des informations sur les produits de l'entreprise et, par le biais du formulaire sur la page, rassembler ceux qui souhaitent poser des questions sur ce produit ou l'acquérir.
• Y a-t-il des exigences non fonctionnelles? Dans quelle mesure devrait-il faire cela? Par exemple, le temps d'ouverture de la page ne doit pas dépasser 5 secondes.
• Exigences supplémentaires. Format gratuit dans lequel vous pouvez déverser votre âme.

Autre problème auquel nous avons dû faire face: des tâches venant de tous les côtés simultanément. Quand il y a beaucoup de clients sur différents projets, tout le monde veut donner à sa tâche la plus haute priorité. Dans le cas idéal général, un tel problème ne peut probablement pas être résolu à 100%. Comment vivons-nous avec ça? Avec l'introduction de la discipline dans la formulation et la gestion des tâches, ainsi que certains éléments des méthodologies Agiles, notre pool de tâches est devenu plus rationalisé, transparent pour un observateur externe et, surtout, prévisible. Nous avons établi l'ordre et les plans au sein de notre équipe, et nous avons seulement besoin de renforcer les commentaires des clients. En discutant des priorités, des délais et des plans, nous avons appris à construire un dialogue argumentatif, plutôt que de nous lancer aveuglément dans des tâches et d'éteindre constamment des feux enflammés (qui ne sont en fait pas toujours pertinents et pas toujours des feux).

Nous avons également essayé d'éradiquer l'anti-modèle classique de «gestion des mouettes» dans le cadre de ce paragraphe, lorsqu'un client ou un gestionnaire arrivait, «fixait» des tâches - et s'envolait en toute confiance qu'une fois qu'il s'était fixé une tâche, il obtiendrait certainement un excellent résultat. Comme l'a montré la pratique, le résultat de cette approche n'a pas été le plus impressionnant. Comment y faire face? Ici aussi, il n'y a pas de conseil universel, pas de phrase magique qui change le comportement des gens. Pour ce faire, vous devez parler, éduquer, expliquer, montrer, vous pouvez dire éduquer. Seuls des travaux éducatifs et des exemples positifs et négatifs très visuels ou très mesurables (et de préférence les deux) aideront à surmonter suffisamment la «gestion des mouettes».

Dev vs Ops

Et notre dernier enjeu important est le problème de communication entre les départements Dev et Ops.
Nous sommes confrontés à une situation classique où les développeurs ne comprennent pas très bien le fonctionnement du serveur, et une équipe d'administration tierce ne comprend pas vraiment le fonctionnement de l'application. Chaque difficulté à la jonction de ces deux sphères nous a été donnée avec douleur et beaucoup de temps. Il était même difficile de diagnostiquer de quel côté du problème:

• Vous l'avez programmé là-bas!
• Non, là vous avez quelque chose avec le serveur là-bas!

Dans ce cas, cela nous a aidés qu'un développeur apparaisse dans l'équipe qui était bien versé dans l'administration. Il a pu parler avec chaque groupe dans sa langue et diagnostiquer chaque problème des deux côtés. Les écarts ont commencé à diminuer, mais nous sommes restés liés à cet homme. Pour détacher tous ces problèmes de lui-même, il a commencé à aider les administrateurs à comprendre le fonctionnement de l'application et les programmeurs - ce qui se passe sur le serveur. Nous ajoutons à l'explication de la documentation d'écriture vocale et obtenons non seulement la connaissance de toute l'équipe, mais aussi le travail plus coordonné des départements Dev et Ops. Oui, dans de grandes sections de l'entreprise sanglante, il y a des équipes spéciales et des personnes qualifiées qui mettront tout en place pour que les développeurs ne sachent même pas comment et où leur travail fonctionne sur le serveur. Cependant, dans de petites équipes, il serait bon de développer ce niveau de compétence chez les personnes, ainsi que d'avoir au moins un employé qui est déjà bien développé à cet égard.

Développement

Parallèlement à tout cela, nous avons repris le développement d'une culture du développement.
Je ne me concentrerai pas sur la partie technique, et maintenant c'est déjà une norme de facto et presque tout le monde ne comprend pas la nécessité d'un système de contrôle de version, d'un CI / CD et d'autres outils de développement, d'assemblage et de déploiement. Je ne m'attarderai que sur les doux moments de développement.

• Codestyle Il est très important de développer et d'approuver explicitement les règles de conception du code. Tout d'abord, il est esthétiquement agréable de voir un seul look harmonieux dans le projet, plutôt qu'un zoo de styles et de normes différents. Deuxièmement, cela augmente la lisibilité du code et, comme nous le savons, la plupart du temps, le programmeur n'écrit pas son code, mais lit celui de quelqu'un d'autre.
• La nomination est validée . Nous avons introduit certaines règles pour nommer les commits, de sorte que par le nom du commit, il était clair quelles modifications avaient été apportées, par qui et dans quelle tâche.
• Révision du code . Les spécificités de nos projets et de l'équipe sont telles que nous n'avons pas de révision de code obligatoire, sans laquelle il est impossible de mettre notre code en production. Cependant, nous avons établi comme règle qu'au moins une personne regarde le code qu'un collègue pousse. Cela aide à la fois à remarquer les lacunes, à introduire des idées alternatives et à se tenir au courant de toutes les parties du système. La révision du code est devenue particulièrement pertinente avec le nombre et la complexité croissants des projets, c'est pourquoi chaque développeur n'a plus le temps de travailler sur tous les projets suffisamment pour comprendre tous leurs détails.
• Aligner l'architecture au sein de l'équipe dès le début . Il arrive souvent que dans un effort pour créer une fonctionnalité plus rapidement, le frontend commence à faire quelque chose de lui-même, le backend démarre rapidement le sien, puis il s'avère qu'il s'intègre très difficilement ou ne s'intègre pas du tout. Dans le développement de grandes fonctionnalités, nous discutons conjointement à l'avance de l'architecture, des formats d'échange de données, etc. En conséquence, l'intégration a cessé d'être longue et douloureuse.
• Développement piloté par CV . Il s'agit d'un problème dans lequel les développeurs font glisser de nouvelles technologies (fraîches, à la mode et très payantes) dans le projet non pas pour le bien du projet, mais pour le plaisir d'une coche dans le CV. Nous sommes ouverts aux nouvelles technologies et essayons de développer nos projets sur le plan technologique, cependant, il est important de maintenir un équilibre dans lequel il y aura des progrès technologiques et des projets achevés avec succès dans un délai raisonnable. Deux choses sont importantes dans ce sujet glissant: que le client ne repousse pas les délais afin que les développeurs n'aient pas de pause, et que l'équipe de développement (ou, du moins, le chef d'équipe compétent ou l'équipe technique) se soucie non seulement de développer son profil LinkedIn, mais aussi du bien-être du projet en général.

Refactoring, dette technique et principe d'amélioration continue

Notre département a commencé à se constituer autour d'un parc existant de projets réalisés par des donneurs d'ordre. Naturellement, il n'y avait aucune documentation là-bas, personne n'a suivi la pertinence et la qualité du code. Puisque nous avons compris que nous devons encore travailler, maintenir et développer cela pendant longtemps, il a été décidé de consacrer une partie du temps à mettre les choses en ordre dans le projet - refactorisation, suppression de code non pertinent, etc.

Comme le projet était important, le niveau d'entropie y était également élevé. Nous avons réalisé qu’en une seule séance, il est impossible de tout surmonter physiquement et d’abandonner moralement la perspective d’un travail aussi colossal. Nous avons décidé d'appliquer le principe japonais d'amélioration continue "kaizen". Nous avons divisé la dette technique en plusieurs petites pièces et petit à petit, mais avons régulièrement fermé ces petites pièces, modifiant et améliorant continuellement les projets et le travail de l'équipe elle-même.Moralement, cela n'a pas causé d'inconvénients, mais en même temps, cela n'a pas eu d'impact significatif sur le développement de nouvelles fonctionnalités et la couverture des besoins de l'entreprise. Après un an et demi, nous avons constaté que l'ancienne dette technique était entièrement remboursée, ce qui nous a permis de développer la fonctionnalité d'un niveau fondamentalement nouveau de complexité et d'importance.

Bien sûr, cela ne signifie pas que nous n'avons plus de dette technique. Au fur et à mesure que les projets vivent, évoluent, grandissent et se développent, ils s'accumulent certainement. Cependant, nous le surveillons attentivement, le reportons dans un ensemble spécial de tâches et consacrons régulièrement du temps à le rembourser. Un tel travail continu avec une dette technique nous permet de trouver un équilibre entre le développement de nouvelles fonctionnalités et un support de haute qualité pour les anciens.

Dans notre cas, nous, les développeurs, avons pu expliquer et montrer aux entreprises l'importance de rembourser la dette technique. Comment avons-nous fait cela? En pratique, nous avons démontré des situations dans lesquelles, si vous ne refactorisez pas ou n'apportez pas d'autres modifications structurelles au projet actuel, le développement de nouvelles fonctionnalités ou la modification de l'ancienne sera en principe impossible (ou possible, mais plusieurs fois plus lent).

Mettre en œuvre des méthodologies agiles

La mise en œuvre de certaines idées de méthodologies Agile nous a permis d'augmenter la transparence de notre travail au sein de l'équipe et pour l'entreprise, de rendre le développement plus prévisible et flexible, et le résultat plus stable.

La première chose que nous avons faite a été d'organiser des stand-ups quotidiens au sein de l'équipe. Étant donné que l'équipe est répartie, Slack a attribué un canal distinct pour cela, dans lequel chaque employé écrit trois points chaque matin: sur quelles tâches il a travaillé hier, sur quoi il prévoit de travailler aujourd'hui, y a-t-il des problèmes qui entravent son travail. Inonder ce canal, discuter des tâches ou des problèmes de quelqu'un est interdit. Ce canal est strictement destiné à l'agrégation d'informations sur la situation. Les discussions restantes devraient être menées dans les canaux thématiques appropriés. Cela a permis à chaque membre de l'équipe de comprendre ce que font ses collègues, ce qui se passe avec le projet en général, qui peut et doit être aidé. Si sans stand-up les problèmes ont été étouffés, et après un long moment, il s'est avéré soudain que la tâche n'était pas encore prête, maintenant il est clair qui a besoin d'aide,ce qui doit être fait pour rendre l'équipe plus efficace.

Ensuite, nous avons décidé de développer des sprints. Chaque vendredi à la fin de la journée, nous menons une rétrospective de sprint, regardons quelles tâches étaient prévues, ce qui est prêt, ce qui n'est pas prêt, et si quelque chose n'est pas prêt, pourquoi cela s'est-il produit. Nous réfléchissons aux problèmes que nous avons rencontrés et à ce que nous pourrions faire pour éviter des difficultés similaires à l'avenir. Ensuite, nous prévoyons un sprint pour la semaine prochaine en fonction de la charge de travail des différents domaines au sein de l'équipe et des priorités de l'entreprise. En conséquence, au début de la semaine, tous les développeurs savent quoi faire et dans quel ordre, et l'entreprise sait ce que ses besoins seront couverts dans un proche avenir, et peut déjà former sa propre «liste de souhaits» pour les prochains sprints. Il vaut la peine de dire que nous ne sommes pas épargnés par des tâches soudaines qui peuvent perturber nos plans de sprint.Dans ce cas, vous devez agir en fonction de la nature spécifique du travail: à quelle fréquence ces tâches surviennent-elles? Combien? Peut-on le prévoir? Dans notre cas spécifique en développement, nous avons calculé expérimentalement combien de temps en moyenne tombe sur des tâches imprévues et essayons de mettre cette marge dans le sprint. Séparément, il convient de noter qu'après avoir commencé à travailler sur des sprints, nous avons pu spécifiquement déterminer la quantité de travail qui nous est livrée sur une entrée imprévue, analyser et réduire ce montant, discuter soigneusement des priorités avec le client et montrer clairement comment le désir momentané d'obtenir la fonctionnalité la plus nécessaire affecte maintenant sur la productivité globale de toute l'équipe.quel est le temps moyen pour les tâches imprévues et essayez de mettre cette marge dans le sprint. Séparément, il convient de noter qu'après avoir commencé à travailler sur des sprints, nous avons pu spécifiquement déterminer la quantité de travail qui nous est livrée sur une entrée imprévue, analyser et réduire ce montant, discuter soigneusement des priorités avec le client et montrer clairement comment le désir momentané d'obtenir la fonctionnalité la plus nécessaire affecte maintenant sur la productivité globale de toute l'équipe.quel est le temps moyen pour les tâches imprévues et essayez de mettre cette marge dans le sprint. Séparément, il convient de noter qu'après avoir commencé à travailler sur des sprints, nous avons pu spécifiquement déterminer la quantité de travail qui nous est livrée sur une entrée imprévue, analyser et réduire ce montant, discuter soigneusement des priorités avec le client et montrer clairement comment le désir momentané d'obtenir la fonctionnalité la plus nécessaire affecte maintenant sur la productivité globale de toute l'équipe.comment un désir momentané d'obtenir une fonctionnalité inutile affecte actuellement la productivité globale de toute l'équipe.comment un désir momentané d'obtenir une fonctionnalité inutile affecte actuellement la productivité globale de toute l'équipe.

Nous sommes également passés de versions longues à courtes. Auparavant, nous recevions des savoirs traditionnels, des semaines ou des mois faisaient un ensemble complet de fonctionnalités, et seulement ensuite nous le montrions au client. En conséquence, il s'est souvent avéré que le client avait changé d'avis ou ne s'attendait pas à cela, et nous avons commencé à refaire tout ou partie de ce que nous avions déjà fait. Et apporter des modifications à un large éventail de fonctionnalités prêtes à l'emploi est un plaisir douteux. Maintenant, nous montrons toutes les fonctionnalités le plus tôt possible afin que le client prenne une décision - que ce soit ce qu'il voulait vraiment ou que quelque chose doive être changé. Plus rapidement il l'approuve ou l'envoie pour révision, moins nous investirons de main-d'oeuvre, donc, plus la fonctionnalité entrera en production rapidement. En conséquence, les fonctionnalités ont commencé à arriver plus rapidement en production, les hypothèses ont été testées plus rapidement et le projet est allé plus vite.

Facteur de bus

Notre équipe étant petite, nous avons immédiatement commencé à réfléchir aux problèmes que nous pourrions rencontrer lors de la rotation du personnel. Des personnes spécifiques sont devenues les seules gardiennes de certaines connaissances, les projets se sont suffisamment développés et nous avons donc commencé à développer une culture de stockage et de gestion des connaissances.

L'éradication de ce problème a été facilitée par l'accumulation d'artefacts de connaissances qui sont passés de la tête de personnes spécifiques au monde écrit physique. À savoir:

• Tout le travail n'est effectué que s'il y a une tâche dans le bugtracker. Cela vous permet de faire un historique complet des modifications dans le projet.
• Si quelque part dans le chat ou lors du rallye nous avons discuté des changements dans la tâche, nous devons refléter dans la tâche elle-même le résultat de cette discussion.
• . , Gitlab. , .
• Confluence , - , .
• - postmortem « — — — ».

Il existe toujours une bonne pratique, dans laquelle, bien sûr, vous devez connaître la mesure et non la porter à l'absolu: si vous êtes interrogé sur une partie du système que vous seul connaissez, il est conseillé d'écrire de la documentation à ce sujet et d'y répondre avec un lien. Vous n'aurez donc plus jamais à répondre à cette question et à demander à d'autres personnes.

Cette méthode de conservation des artefacts de connaissances nous a aidé à plusieurs reprises à trouver des informations sur les parties du projet qui autrement seraient nécessairement perdues. Et il a également considérablement réduit les risques pour le projet et l'équipe lors de la rotation du personnel. Dernier exemple: nous avons récupéré rapidement et facilement des informations sur la logique métier, le principe de fonctionnement et la méthode de déploiement de l'outil, ce qui a été fait par l'employé qui a quitté il y a deux ans.

Si nous appliquons le travail avec des stand-ups et des sprints à cette technique, le facteur de bus est encore plus réduit. Il n'y a pas si longtemps, nous avons mené une expérience: un développeur était en vacances et un autre développeur a travaillé. A ce moment, lorsque le premier est parti en vacances, le second est parti en vacances. L'essence de l'expérience n'était pas d'écrire des lettres explicatives, des messages, de ne pas remettre le cas et de voir à quel point il serait difficile pour une personne après de longues vacances de comprendre ce qui se passait en son absence, ce qui a changé, exactement comment et quels plans pour l'avenir. Comme le montre la pratique, la visualisation du bugtracker, des commits, de la documentation, des stand-ups et des sprints a permis à l'employé d'entrer assez facilement dans le cours des affaires et de poursuivre son travail de manière autonome.

Conclusion

En conclusion, je voudrais noter qu'aucun des problèmes ci-dessus n'a été résolu immédiatement et sans problème. Le changement organisationnel est toujours un travail long et méthodique. Vous ne pouvez pas simplement dire "maintenant nous faisons cela" et espérer que maintenant tout sera différent. Toutes les décisions que vous prenez, tous les événements que vous organisez, nécessitent le contrôle, la formation et l'illumination des personnes, du temps pour adapter à la fois l'équipe aux nouvelles méthodes et les méthodes elles-mêmes à une situation spécifique. Je note également que l'imposition d'une méthodologie aux personnes est un processus très laborieux et inefficace. Les gens se reposeront, oublieront, peut-être même saboteront.

Pour que les changements requis commencent dans l'équipe, l'équipe elle-même doit vouloir effectuer ces changements. Il est nécessaire de surveiller comment elle se porte, d'identifier les zones problématiques, d'être conscient de ces problèmes, de trouver des solutions, puis de les mettre en œuvre. Bien sûr, tous les membres de l'équipe ne devraient pas et ne veulent pas le faire, mais s'il y a quelqu'un qui a vu ces problèmes et qui a trouvé leurs solutions, alors il éclairera d'abord l'équipe.

Partagez vos connaissances, vos observations, votre expérience, discutez, montrez et prouvez où se trouvent les problèmes et quelles mesures peuvent être prises pour les résoudre. Ce n'est que de cette manière que les transformations organisationnelles majeures pourront être réalisées aussi efficacement que possible. Même si vous êtes un leader et que vous souhaitez pousser votre position et votre décision - essayez de le faire de manière aussi convaincante et convaincante que possible, économisant ainsi du temps sur la mise en œuvre et sauvant l'équipe de la négativité indésirable.

Publié par Evgeny Antonov, chef du groupe de développement des technologies positives