Nous accélérons le processus de développement de projets complexes. Sans chaos ni nerfs

Dans la pratique, nous rencontrons souvent le fait que le chef de projet souhaite accélérer le processus de développement - il n'est pas satisfait de la rapidité de livraison des nouvelles fonctionnalités. En règle générale, ces clients ont besoin de produits complexes tels qu'un système de gestion d'hôpital, un système d'échange de devises, des systèmes bancaires et des services bancaires.

Dans de tels cas, vous pouvez connecter une nouvelle équipe de spécialistes, établir des processus dans un processus existant ou combiner les deux. Considérez les avantages et les inconvénients de chaque approche. Faites immédiatement une réserve que l'article discute du développement de projets grands et complexes (plus de 10 000 heures).

Pourquoi vous ne pouvez pas connecter immédiatement de nouveaux spécialistes

Souvent, l'option la plus simple et la plus évidente pour augmenter la vitesse de développement est de connecter de nouveaux spécialistes ou une équipe. Il semble au chef de projet que cela peut accélérer la vitesse de livraison de la valeur commerciale aux utilisateurs finaux. En pratique, ce n'est pas toujours le cas, surtout lorsque les processus du projet nécessitent un traitement. Nous donnons un exemple de notre pratique.

Il était nécessaire de connecter deux équipes à un projet en développement existant. Le projet est développé depuis plus de 4 ans et contient un grand nombre de sous-systèmes (plus de 20) avec leurs mécanismes et services communs. Une régression complète a nécessité la participation de 5-7 ingénieurs QA et environ 4-6 jours ouvrables. En entrant dans le projet et en laissant les équipes au niveau requis de résolution de problèmes, elles ont rencontré les difficultés suivantes:

• Une partie du code source du système était sous le contrôle du système de contrôle de version svn, l'autre git. SVN était auparavant très populaire, cependant, pour les grands projets d'équipe et les changements simultanés fréquents, il ne convient pas. Par conséquent, avant de passer à git, une partie du temps a été consacrée aux fusions, à la modification des conflits et à d'autres opérations liées au branchement dans svn.
• Il y avait une instruction obsolète pour le déploiement de l'environnement, de sorte que les équipes ont collecté toutes sortes d'embûches de ce système et n'ont pu commencer les premières tâches qu'après 3 à 4 jours.
• Les analystes clés, les experts techniques étaient occupés à préparer la publication, il était donc impossible d'obtenir rapidement des informations de clarification sur les nouvelles tâches. Le réglage des tâches était de très haut niveau. Cela a considérablement ralenti la mise en œuvre des tâches.
• Le déroulement des tâches était difficile, au début, les équipes ont «trébuché» sur la façon de gérer la tâche tout au long de son cycle de vie.
• Au début, le client ne voulait se débrouiller qu'avec les efforts de ses ingénieurs QA, mais il n'a pas réussi à vérifier pleinement et rapidement les nouvelles fonctionnalités des équipes de développement connectées, en raison de la lourde charge. J'ai donc dû travailler avec des heures supplémentaires.
• L'examen du code a été effectué conformément aux principes et critères établis par le projet. Les critères n'ont pas été documentés. Par conséquent, du temps supplémentaire a été consacré à la correction des commentaires.

Le résultat des nuances ci-dessus sont:

• Coûts de temps supplémentaires qui pourraient être consacrés à la résolution de problèmes commerciaux
• développement lent de l'ensemble du système
• ou des heures supplémentaires.

Considérez comment éviter cette situation.

Analyse de processus

Avant de connecter de nouveaux spécialistes, il est utile de comprendre comment le travail de l'équipe est organisé - il est nécessaire de trouver et d'éliminer les goulots d'étranglement. En règle générale, PM s'occupe de ce problème, car il est responsable du projet et souhaite dépenser moins d'énergie pour suivre les processus.

L'élimination des goulots d'étranglement fait avancer le projet. Par exemple, le temps requis pour entrer un nouveau spécialiste ou une équipe de spécialistes est réduit, l'implication de l'équipe dans le projet est augmentée, le coût d'une heure est réduit en raison de la bonne mise en œuvre des tâches la première fois. Si tous les goulots d'étranglement sont supprimés, le chef de projet recevra une augmentation rapide de la vitesse de développement comme le permettent la pratique actuelle et le contexte du projet. En général, c'est bon pour tout le monde.

L'analyse des goulots d'étranglement est possible de deux côtés: de la direction / expert et de l'équipe. Nous analyserons chaque option séparément.



Experts externes. Dans cette approche, le processus de travail est analysé soit par une équipe externe d'experts externes, soit par le chef de projet avec le chef d'équipe. Avec ce dernier, ce n’est pas le fait qu’il s’avérera - il est important qu’ils puissent rejeter toutes les nuances du projet, sinon l’analyse sera dénuée de sens.

Une condition importante est le soutien à la gestion de projet et la préparation au changement.

En conséquence, l'expert se plonge dans le projet et analyse en détail la documentation, le code source, la structure de la base de données, le processus de production (de l'analyse à la publication). Le travail échelonné ressemble à ceci:

1. L'ensemble de la chaîne de travail sur le projet est considéré du début à la fin. Le temps de chaque processus est mesuré.
2. Un diagramme de Gantt est construit. L'expert examine les processus qui s'exécutent en parallèle, les uns après les autres.
3. Un expert pense comment rendre chaque processus plus productif et moins coûteux. En règle générale, un expert comprend intuitivement les endroits où se posent les plus grandes difficultés et commence à les faire tourner pour une éventuelle modernisation.

Les avantages de cette approche:

• Le travail est analysé par une personne non impliquée dans le projet. Il a une vision simple des processus, par conséquent, il peut trouver les problèmes qui ne sont pas visibles pour les membres de l'équipe.
• Un expert, en tant qu'autorité, est capable de convaincre une équipe d'accepter des changements de processus. Les équipes qui travaillent depuis longtemps sur un projet ne recherchent pas l'innovation. Pour eux, c'est beaucoup de stress, car ils devront réapprendre. De plus, une telle réaction va même aux changements qui aideront à travailler plus efficacement.
• Mise en œuvre rapide des solutions - de 2 à 15 jours. Tout dépend du changement global et de la bureaucratie au sein de l'organisation.
• L'équipe du projet s'appuie sur l'expérience d'experts tiers. À l'avenir, cela aidera à configurer indépendamment les processus.

Inconvénients:

• Les experts doivent consacrer beaucoup de temps à comprendre les subtilités. L'équipe peut étudier l'historique du projet en une journée, tandis que l'expert a besoin d'au moins une semaine et demie.
  Que faire : définir les objectifs de l'analyse avec le chef de projet / chef d'équipe. Donnez à l'expert tous les projets «d'introduction», ne cachez pas les détails.
  
  Si le client est si fidèle qu'il est prêt à analyser itérativement le projet, vous devez saisir l'opportunité et accepter ces conditions. Par la suite, il sera possible d'ajuster le sens de l'analyse après chaque itération, en se concentrant uniquement sur celle souhaitée.
• Certains membres de l'équipe peuvent ne pas être d'accord avec la décision. Par la suite, ils peuvent saboter le projet, mal mettre en œuvre l'accord, ce qui affecte l'humeur générale de l'équipe.
  
  Que faire à ce sujet: discutez de chaque décision avec l'équipe et ne les mettez pas juste avant le fait.
  
  Option idéale: l'expert analyse les processus de manière indépendante, puis en discute avec les personnes clés du projet. S'il y a des contradictions, ils en discutent. Cela accumulera beaucoup de gens fidèles aux changements qui affecteront les autres membres de l'équipe. Il sera possible de convaincre les sceptiques les plus ardents.

De l'équipe . Cette approche peut être qualifiée de rétrospective, qui fait partie intégrante de la mêlée. Le processus ressemble à ceci:

• Toute l'équipe du projet va
• Un des participants assume le rôle de facilitateur (scrum-master). Il s'assure que la conversation se déroule de manière constructive.
• L'équipe discute de leurs approches de travail. Tous les aspects sont pris en compte: processus, codage, fixation d'objectifs, etc. Ensuite, les avantages et les inconvénients sont mis en évidence.
• Lors d'un vote général, ils s'accordent sur des changements: les avantages doivent être fixés, les inconvénients supprimés.
• Après 3-4 semaines, le processus se répète. L'équipe regarde les résultats et si tout le monde est satisfait de tout, alors le travail continue.

Termes importants:

1. Support de gestion pour tout changement et innovation.
2. Cohésion d'équipe et concentration sur l'amélioration.

Si la culture de l'entreprise n'encourage pas l'initiative, l'innovation, la rétrospective n'est pas la meilleure façon de repenser les processus. Les membres de l'équipe ne dépasseront pas leur «marais».

Avantages de l'approche:

• Implication de chaque participant dans la discussion du projet.
• La capacité d'identifier tous les aspects positifs du projet et, si nécessaire, de les intégrer dans un certain modèle (meilleure pratique).
• Les membres de l'équipe partagent leurs expériences.
• Résolution progressive des problèmes, en commençant par ceux qui ralentissent le plus l'équipe et le projet, pour finir par de petites améliorations.

Inconvénients:

• Il existe un risque que seuls des problèmes mineurs soient résolus et que tous les problèmes clés restent intacts.
  Que faire : le PM, le chef d'équipe et le facilitateur doivent influencer leur opinion sur l'équipe par le biais de l'autorité. Leur tâche est d'attirer l'attention sur des problèmes importants au stade de la discussion.
• Pour les changements majeurs qui nécessitent beaucoup de travail, un temps supplémentaire est nécessaire pour la coordination avec la direction. Cependant, ce n'est pas un fait que la direction sera d'accord avec les innovations.
  Que faire : défendre votre point de vue devant le leadership est la seule solution.
• Si l'équipe n'a pas de formation continue (conférences, échange d'expérience, formations), alors les décisions prises seront probablement dépassées et moins efficaces.
  Que faire avec : échanger constamment des expériences. Participer aux conférences, réunions et formations internes pertinentes. Si nous parlons d'une grande entreprise, une bonne option serait les jours de démonstration. Lors de tels événements, les équipes montrent les résultats qu'elles ont obtenus dans leur travail.

Dans la plupart des cas, vous pouvez obtenir en adaptant et en améliorant les processus décrits ci-dessus. Même s'il est clair au départ qu'il est vraiment possible de terminer le projet à temps uniquement en attirant de nouveaux spécialistes / équipes, nous vous recommandons fortement d'essayer les étapes ci-dessus.

Si, après avoir éliminé les goulots d'étranglement, le chef de projet estime que la capacité n'a pas atteint le niveau souhaité, vous pouvez connecter de nouvelles équipes.

Préparer l'infrastructure pour les nouvelles équipes

À ce stade, il vaut la peine d'effectuer des travaux préparatoires qui réduiront la durée et le coût du développement, aideront à sauver les cellules nerveuses des développeurs. Voyons quelles conditions devraient être:

1. Les tâches de la nouvelle équipe doivent être détaillées en détail. Vous pouvez démarrer chacun d'eux sans attendre - il n'y a aucune dépendance sur les tâches actuelles ou futures. Les domaines de responsabilité de chaque équipe sont décrits.
   Si ce n'est pas le cas , alors la plupart de la nouvelle équipe restera inactive ou s'engagera dans des tâches secondaires qui auront le moins d'impact sur la valeur du produit.
2. L'architecture du projet est «correcte», c'est-à-dire décomposé en modules, sous-systèmes, composants communs.
   
   Si cela ne se produit pas , la connexion d'une nouvelle commande échouera. Les développeurs travailleront sous le contrôle du chef d'équipe actuel, mais une personne ne peut gérer efficacement que 7 à 9 personnes. Timlid sera déchiré et certains membres de l'équipe attendront au ralenti jusqu'à ce qu'on leur confie des tâches.
   
   S'il n'est pas possible d'isoler des sections isolées du code de projet, mais que vous devez avancer, vous pouvez essayer de contourner cette limitation. Il est nécessaire de diviser le projet en plusieurs parties par refactoring.
   
   Une autre option - après avoir plongé deux ou trois personnes dans le projet, pour donner à la nouvelle équipe de plus en plus de fonctions commerciales importantes. Ainsi, les équipes développeront le projet isolément les unes des autres, et en raison du nouveau chef d'équipe (une personne qui est plongée dans les subtilités) réduira la charge sur le chef d'équipe principal.
3. Les processus de travail du projet sont décrits en détail. Par exemple, il existe une tâche de workflow, la tâche est montrée comme étant exécutée dans le système de contrôle de version (la pratique montre que tout le monde n'a pas un GitFlow standard), l'interaction entre les participants au projet est décrite.
   Si cela ne se produit pas , le chaos sera créé sur le projet. Dans ce cas, le chef de projet ne s'occupe que de la gestion «manuelle» des urgences.
4. Les composants et modules communs disposent d'une documentation pertinente et compréhensible. Il existe des tests unitaires et d'intégration des pièces principales. Il y a une description claire de l'architecture de l'ensemble du projet, des mécanismes généraux, ainsi que des instructions sur la façon de les appliquer. Si ce qui précède n'existe pas encore, il est nécessaire d'ajouter des tâches similaires au pool technique de la dette pour corriger la situation.
   
   Si ce n'est pas le cas , le risque de double travail augmente. Un code source médiocre ou dupliqué sera écrit. À l'avenir, cela entraînera un soutien de projet plus coûteux. En règle générale, la connexion d'une nouvelle équipe implique la connexion possible de plusieurs autres équipes. En conséquence, les coûts de temps seront échelonnés par un multiple du nombre d'équipes.
5. Il existe des règles fixes pour l'écriture de code - code de convention, scripts pour mettre à jour la structure de la base de données - migration, principes généraux de révision obligatoire du code. Malgré la forte similitude, chaque projet a bien sûr ses propres caractéristiques.
   Si ce n'est pas le cas , la complexité et le coût de la poursuite du soutien au projet augmenteront de nombreuses fois.

Les conditions ci-dessus vous permettent de connecter plus efficacement de nouvelles équipes. Le temps nécessaire à une équipe pour entrer dans un projet est considérablement réduit. La même chose se produit avec les coûts de main-d'œuvre pour soutenir et développer le projet.

Comment nous avons connecté une équipe supplémentaire au projet

Nous avons eu un cas où le projet devait urgemment accélérer le processus de développement. 2-3 mois ont été laissés jusqu'à ce que la prochaine version majeure soit mise en service commercial. Le projet lui-même était un système complexe développé par une équipe pendant 3 à 4 ans.
Tout d'abord, nous avons plongé dans le contexte du projet lui-même. Le résultat est l'image suivante des goulots d'étranglement du projet:

1. Il n'y a pas d'informations précises sur la façon dont les fonctionnalités doivent être implémentées. La liste des tâches, bugs, améliorations est obsolète.
2. Il n'y a pas d'intégration continue et le développement s'effectue dans deux branches.
3. Le processus de test du produit n'est pas débogué. Par exemple, les ingénieurs QA peuvent trouver des bogues qui ont déjà été corrigés, ce qui entraîne des coûts de main-d'œuvre supplémentaires.
4. La base des cas de test en était à ses balbutiements. Les ingénieurs d'assurance qualité individuels ont commencé à écrire des cas pour eux-mêmes. Pour cette raison, personne ne pouvait donner une certaine évaluation de la qualité du produit et des risques possibles lors de la sortie d'une nouvelle version.
5. Le processus de travail, de la production à l'approbation du client, n'est pas documenté. Il était impossible de prédire la composition exacte des fonctions de libération, ainsi que d'autres points moins significatifs.

Après analyse, nous avons créé un plan pour éliminer les points ci-dessus. Bien sûr, l'équipe n'a pas immédiatement accepté les changements, mais avec le soutien de la direction et le développement de délais clairs, nous avons réussi à convaincre chaque membre de l'équipe.

Nous avons coordonné nos actions avec les personnes clés du projet: PM, chef d'équipe, analyste principal. Ensemble, ces trois personnes constituent un centre d'équipe de gestion client unique. Ils encouragent en outre les solutions et contrôlent leur mise en œuvre dans la pratique. Sans une telle équipe de gestion, il est impossible de coordonner les actions de plus de trois équipes.

En conséquence, les processus suivants ont été mis en œuvre \ optimisés:

1. Nous avons établi des communications entre tous les membres de l'équipe produit - développeurs, analystes et spécialistes des tests.
2. Ils ont documenté des fonctions critiques et complexes pour des tests plus transparents, l'élimination des défauts, la résolution des litiges et la planification des travaux ultérieurs.
3. Processus de développement optimisés. Adopté par WorkFlow et le projet GitFlow. Ils ont aidé à configurer l'intégration continue et à exécuter des tests automatiques en mode automatique.
4. Nous avons doublé la vitesse d'assemblage des bancs d'essai.
5. Organisé le processus de tests appropriés. Implémentation de tests de régression à la fin de chaque itération.
6. Présentation du processus de planification des itérations.
7. Test de charge conduite.

Sur la base des résultats de la première itération, nous avons préparé l'infrastructure pour connecter une nouvelle équipe. Parallèlement à cela, deux de nos développeurs ont rejoint l'équipe actuelle pour plonger dans la base de code. Puis l'un d'eux est devenu le chef d'équipe de la nouvelle équipe. Lors de la deuxième itération, les deux équipes ont obtenu les résultats suivants:

• Mise en service après 3 mois.
• Correction de 70% des bugs
• Quatre fonctionnalités sérieuses mises en œuvre
• Optimisé et augmenté de 8 fois la vitesse de chargement de certaines pages
• Reçu des informations précises sur la qualité de l'ensemble du produit
• Itérations RoadMap intégrées

Je crois que l'une des réalisations les plus importantes de ce projet est la joie du client. Il a représenté de manière transparente l'état du projet à tout moment, et les obligations envers l'entreprise ont été remplies intégralement et dans les délais.

Conclusion

Il existe deux façons principales d'accélérer le développement d'un projet: éliminer les goulots d'étranglement et augmenter les capacités de production. Dans le premier cas, vous pouvez obtenir une augmentation de 30 à 40% de la vitesse de développement, dans le second 70 à 80%. Les commandes supplémentaires ne donnent pas une double augmentation de la productivité, car plus de temps est consacré à l'interaction entre plusieurs équipes.

Les facteurs clés de succès de l'expansion des équipes de développement sont:

• travaux préparatoires
• processus établis
• un chef ou un membre d'une équipe de projet qui ferait la promotion et superviserait les activités des équipes,
• centre de contrôle à commande unique.

Trois équipes travaillent actuellement sur le projet que nous avons décrit précédemment (une ancienne et deux nouvelles). Le nombre de tâches effectuées a augmenté de 1,9 fois .