Bonjour, Habr! Je suis Maxim, analyste commercial chez Tinkoff. Dans cet article, je partagerai l'expérience de notre équipe: comment effectuer deux fois plus de tâches, réécrire un projet hérité à partir de zéro et ne pas mourir.







Notre équipe développe des produits de crédit et de garantie pour les personnes morales. La direction est jeune, les premiers numéros ont commencé en 2018. Nous nous sommes enregistrés et avons étudié le marché, lancé un découvert, un prêt pour augmenter le chiffre d'affaires et des garanties bancaires. Les plans étaient de lancer un prêt contre un contrat, des prêts garantis et d'autres produits.

Symptômes

Notre processus de démarrage rapide de la mécanique d'épicerie a accumulé des béquilles. Nous les avons supportés et, comme vous pouvez le deviner, nous avons remarqué une fois que les tâches des processus ont commencé à être développées trop longtemps. Cela se reflétait dans le transfert constant des versions, les tâches n'étaient pas terminées à temps. Les bogues s'accumulaient affectant un petit segment spécifique de clients.



Il y a eu des situations où la libération pour la tâche suivante, qui avait déjà été déplacée depuis deux mois, a de nouveau été reportée indéfiniment. Dans le même temps, la libération de la fonction de découvert a rompu les garanties bancaires. Il y a eu une désynchronisation de la compréhension du produit. Les développeurs ont considéré des choses importantes auxquelles l'équipe commerciale n'a même pas prêté attention. Les principales caractéristiques des produits, en revanche, sont restées inconnues.



Pour sortir de la situation de crise, un groupe de travail a été créé, qui a été confronté à la tâche de faire «vite et bien» de «mal et longtemps». Pour nous-mêmes, nous nous fixons des objectifs pour améliorer les performances et réduire le nombre de bogues.

Problèmes

Après avoir approfondi les processus de l'équipe, nous avons trouvé un enchevêtrement de problèmes qui ne pouvaient pas être résolus séparément, ils nécessitaient une approche intégrée:

• ancienne pile technologique;
• processus kanban long et tordu;
• les affaires ont grimpé dans les affaires internes du développement;
• l'équipe de développement se désintéressait du projet;
• toxicité générale.

Je vais vous dire plus en détail comment cela a été exprimé.



Ancienne pile de technologie. Notre processus a été écrit dans IBM ODM, un système avec un certain nombre de fonctionnalités qui ont gêné l'équipe. Ils ont été décrits en détail par notre architecte Denis Kotskindans le cas d'un projet voisin (bien qu'il y avait IBM BPM, mais en général tout est juste). Par ailleurs, je note qu'il n'y a pas de spécialistes sur le marché ayant une expérience dans ce système.



Long processus de livraison. Officiellement, nous nous sommes positionnés comme une équipe kanban, mais les processus ressemblaient à un croisement entre cascade et mêlée. L'héritage du développement en cascade est que les affaires, le développement et les tests ne communiquent que dans la carte Jira. Tout le monde avait une pensée claire: "J'ai fait ma part du travail, ma hutte est sur le bord."



Nous ne sommes pas venus au kanban tout de suite. Au tout début, nous avons utilisé Scrum avec des sprints, ce qui se montre mieux sur les jeunes projets. Puis ils ont réalisé qu'il était moralement difficile pour l'équipe de transférer les tâches du sprint au sprint et sont passés au kanban. Puis il est devenu clair que personne ne sait comment travailler avec le flux d'entrée, le cycle de développement a commencé à apparaître. Cela s'est manifesté par le fait que les tâches de l'entreprise étaient reçues une fois par semaine, puis l'équipe les a évaluées, il est devenu clair que rien n'était clair et la tâche a été envoyée pour la semaine suivante. En même temps, en mots, nous avons fait des kanban et recherché les goulots d'étranglement.



Je comprends que les idées de Kanban et Scrum ne se contredisent pas et il existe des exemples où une combinaison de méthodologies donne de bons résultats. Mais je tiens à souligner qu'il y avait une position radicale du pur kanban. Le grand nombre de retours du test au développement a également fortement ralenti, ce qui signalait la faible qualité de la tâche aux premiers stades.



Violation du modèle de rôle. Les analystes commerciaux étaient engagés dans l'architecture - ils ont proposé une solution technique au problème. Cela a conduit au fait qu'ils ont souvent abandonné la découverte profonde au profit de l'élaboration et de la spécification de la solution, et ce hack, couplé à une architecture faible, a ralenti le développement à plusieurs reprises.



Perte d'intérêt de l'équipe pour le projet.Une équipe jeune et talentueuse. Démarrage pur. Après le lancement et la mise à l'échelle, des douleurs de croissance ont commencé. La pression constante de l'entreprise, la complexité du développement due au manque de refactoring, l'accumulation de problèmes internes, l'arriéré des mois à venir ont conduit à une fatigue banale et un burn-out.



À cause de tout ce qui précède, l'atmosphère de l'équipe s'est dégradée. Les problèmes ont été résolus sur rétro, mais pas résolus, et ont erré de semaine en semaine. La toxicité générale se déplaçait, tout dialogue sur le travail se transformait en reproches mutuels.

Qu'avons-nous fait

Franchement, au début, nous avons seulement compris qu'il fallait réécrire le processus à partir de zéro pour se débarrasser des béquilles et renforcer l'équipe avec des développeurs expérimentés. Six mois plus tard, je peux citer deux autres choses qui nous ont aidés:

• Reconstruction du processus kanban. Grâce au centre de livraison Tinkoff Biznesa, qui a rapidement approfondi nos problématiques et aidé à adapter Jira.
• Synchronisation métier et informatique. Ici, nous étions motivés par la conviction que l'équipe devrait avoir une bonne compréhension du produit, et pas seulement effectuer les tâches qui l'amèneront.

En fin de compte, la réécriture du processus a résolu le problème de la pile technologique et aidé à se débarrasser des béquilles. La refonte du processus Kanban a permis de reconstruire le modèle de rôle et de réduire le nombre de retours, c'est-à-dire d'augmenter la vitesse de livraison des tâches au produit. Un certain nombre d'activités de synchronisation et de repenser les formats actuels ont redresser l'atmosphère générale.

Partie 1. Réécriture du processus

Nous avons donc commencé à réécrire le processus d'IBM ODM vers Camunda. Les raisons du choix de Camunda sont décrites dans l'article de Nikolay nshipyakov...



Dans les processus de candidature, nous utilisons un tel terme comme étape - une partie logiquement fermée du processus, avec une signification claire pour le client, par exemple «Collecte de documents» ou «Signature d'un accord de prêt». La première tâche pour nous a été de lancer un contrat de prêt. Nous nous sommes rendu compte que la logique des trois étapes lui est propre et que les autres ne sont pas différentes des étapes analogues d'un prêt en circulation. En fait, nous avons écrit trois étapes d'un nouveau produit sur Camunda. À l'avenir, toute la scène a été réécrite lorsqu'une tâche commerciale est apparue pour son changement sérieux.



Une question naturelle se pose: comment avons-nous négocié avec l'entreprise? Il est clair que la réécriture d'une fonctionnalité déjà opérationnelle prend plus de temps que sa modification sur l'ancien moteur. Tout s'est avéré très simple: les collègues étaient prêts à investir dans un nouveau processus, car ils ont vu à quel point cela fonctionnait sur un projet voisin (et bonjour encore, DenisKotskin). Dans le même temps, le temps de développement sur le nouveau moteur n'était pas beaucoup plus long, puisque nous avons commencé la rotation: les gars épuisés sont passés à d'autres projets, ont embauché des employés expérimentés dans le développement et la conception de processus métier pour les remplacer.

Partie 2. Modification de l'ordre d'exécution des tâches

Lors de la modification du processus de développement, nous nous sommes appuyés sur les directives suivantes:

• Il ne devrait y avoir aucune étape qui ne soit pas reflétée sur le tableau.
• Une expertise technique doit être donnée à l'équipe.
• L'équipe doit comprendre comment la tâche affecte l'entreprise.

En changeant le processus Kanban, nous avons identifié de nouvelles étapes qui passaient auparavant implicitement par l'étape de développement: c'est l'architecture et la rencontre de trois amigos. Naturellement, l'architecture n'est pas réalisée selon des changements mineurs, mais nous essayons de tenir une réunion de trois amigos pour n'importe quelle tâche. Nastya a un article sur la méthode "Three Amigo"Travieso... Je tiens à remercier tout particulièrement Nastya: sa formation aux tests Agile nous a inspiré à faire de nombreux changements au sein de l'équipe.



L'équipe reçoit des données sur la valeur du produit sous la forme d'une user story et une évaluation de l'impact de la tâche sur le produit. Il peut être difficile de repérer le bluff des clients commerciaux avisés. Par exemple, la note «Cette règle est importante, sera vérifiée sur toutes les candidatures» est beaucoup moins informative que «Nous avons effectué une analyse, la règle refusera 10 candidatures supplémentaires par semaine». Par conséquent, avant de soumettre une tâche au développement, je valide la qualité de la valeur écrite, en tant que représentant de l'équipe commerciale qui partage les valeurs des développeurs.



Nous avons également abandonné des pratiques qui ne fonctionnaient pas pour nous. Par exemple, maintenant, nous faisons rarement du rétro, uniquement lorsque cela est nécessaire - lorsque le besoin de discuter de quelque chose s'accumule. Cela se produit environ une fois par mois. Il est impératif que nous résolvions les problèmes indiqués en rétro, car il est important que chaque membre de l'équipe voit des changements positifs sur les questions qui le pèsent.



Nous avons cessé d'utiliser les points de stockage et l'évaluation en équipe d'une tâche - nous travaillons avec les dates d'échéance que nous recevons de l'entreprise et, en fonction d'eux, nous gérons le flux d'entrée. Sur des tâches importantes qui se font pendant quelques mois, nous effectuons une décomposition: cela permet de faire une sorte de points de contrôle et d'augmenter la précision des échéances. Pour suivre les progrès, nous nous réunissons périodiquement et discutons si nous sommes à l'heure. Si nous voyons que ce n'est pas le cas, nous ajustons le flux d'entrée et prenons moins de petites tâches. Quant à la précision du respect de la date limite, je peux seulement dire que pour notre tâche principale actuelle, nous sommes en bonne et due forme.



Concernant la redistribution des rôles, nous avons renforcé l'équipe avec un architecte et un deuxième analyste système. L'équipe commerciale essaie d'expliquer clairement ce qui est nécessaire dans la tâche, quelle valeur elle porte, mais pas pour conseiller ou entrer dans le fonctionnement interne du développement. Je m'occupe également de l'équipe commerciale.

Partie 3. Synchronisation des équipes informatiques et commerciales

Nous utilisons plusieurs formats pour synchroniser les entreprises et les développeurs.



Démo par tâche. Il s'agit d'une réunion de tous les intéressés - analystes de portefeuille, département des risques, spécialistes du marketing et spécialistes de l'informatique - avec une discussion sur la valeur, le problème problématique et la solution technique.



Une réunion importante où vous pouvez trouver les erreurs manquées au stade de la découverte et avoir le temps de les corriger. De plus, le responsable qui dirige la tâche ne sait pas avec certitude quels processus de l'entreprise seront affectés par la publication. Chez nous, une telle publicité nous permet d'éviter des situations où des changements dans le processus interrompent, par exemple des rapports analytiques.



Rétro sur tâche.Lors de cette réunion, nous discutons des problèmes des développeurs et des clients qu'ils ont rencontrés lors du développement du problème. Nous le conduisons après l'analyse post-publication - lorsque les passions se sont calmées et que tout le monde est prêt pour un dialogue constructif. Après avoir découvert les raisons, nous formons des points de croissance et un nuage d'idées, que nous essayerons à l'avenir.



Nous organisons des conférences sur les produits sous la forme d'un programme éducatif et des discussions ultérieures. Leur objectif est d'immerger les informaticiens dans le contexte commercial. Selon les commentaires recueillis sous la forme d'une enquête avec la formulation la plus générale «Évaluer la conférence d'aujourd'hui», la note moyenne est de 8,5 sur 10.

Résultat

Six mois plus tard, nous avons réécrit plus de 80% des processus, lancé un prêt contre un contrat en utilisant un tout nouveau moteur. L'atmosphère d'équipe s'est améliorée et nous sommes devenus plus efficaces. Pour vérifier cela, nous avons mené une enquête auprès de l'équipe et pris des statistiques auprès de Jira.



L'enquête a posé des questions sur l'ambiance dans l'équipe, la qualité des spécifications, le développement et l'architecture, la qualité de la communication avec l'entreprise. Selon les résultats de l'enquête, le score moyen des gars qui sont dans le projet depuis plus de six mois est passé de 6 à 8 points sur 10. Malheureusement, l'enquête n'est pas tout à fait honnête, puisqu'elle a été menée après les changements. Les chiffres indiqués concernent le début de l'année et le début de juillet. Il est donc juste de dire que la situation dans l'équipe s'est améliorée, mais on ne peut pas dire à quel point.



Les performances (nombre de tâches par jour) ont doublé pendant cette période. Naturellement, pas au détriment de la décomposition: nous nous sommes mis d'accord à l'avance sur certaines normes auxquelles nous adhérons.



Le nombre de retours du test au développement a légèrement diminué. Autrement dit, avec une augmentation multiple du nombre de tâches affichées pour la production, le nombre de retours n'a pas augmenté. Cela indique une amélioration de la qualité du développement des tâches aux stades de la découverte et de l'architecture. Le nombre de bogues détectés en production n'a pas changé.

Qu'avons-nous appris

Je vais maintenant formuler quelques idées que l'équipe et moi avons apprises de notre expérience. Si vous rencontrez des problèmes similaires dans vos équipes, j'espère qu'ils vous aideront également.

• , . — . , — , . — .
• , , , , , . , .
• — , , . , , discovery .
• . one-one-, , . Shoom3301, .
• : — , IT — . , .