Salut les amis. Dans le domaine de l'externalisation, je constate souvent le même problème. L'absence d'un processus de travail clair dans les équipes sur divers projets.
Le plus important, c'est que les programmeurs ne comprennent pas comment communiquer avec le client et entre eux. Comment créer un processus de développement continu d'un produit de qualité. Comment planifier sa journée de travail et ses sprints.
Tout cela se traduit finalement par des délais non respectés, des heures supplémentaires, des disputes constantes sur les responsabilités, et l'insatisfaction des clients concernant l'état et l'évolution du projet. Cela conduit souvent au changement de programmeurs, voire de toute une équipe. À la perte de clients, à une détérioration de la réputation, etc.
J'ai personnellement été impliqué dans un tel projet à l'époque, où toutes ces problématiques existaient.
Personne ne voulait prendre la responsabilité du projet (un grand marché de services), la rotation du personnel était alarmante, et le client était très mécontent. Le PDG est venu me voir et m'a dit que j'avais l'expérience nécessaire, donc voici les clés du projet. Si tu échoues, nous fermerons le projet et licencierons tout le monde. Si cela fonctionne, tant mieux, alors prends-le et développe-le comme bon te semble. Au final, je suis devenu le leader de l'équipe sur le projet et tout a reposé sur mes épaules.
La première chose que j'ai faite a été de développer un processus de travail à partir de zéro, qui correspondait à ma vision à l'époque, et j'ai rédigé une description de poste pour l'équipe. L'implémentation a été complexe. Mais après environ un mois, tout s'est stabilisé, les développeurs et le client se sont habitués, et tout a commencé à se dérouler de manière calme et agréable. Pour montrer à l'équipe qu'il ne s'agissait pas simplement d'un "orage dans un verre d'eau", mais d'une véritable solution, j'ai pris sur moi le maximum de responsabilités, en allégeant l'équipe des tâches pénibles.
Un an et demi se sont écoulés, et le projet se développe sans heures supplémentaires, sans "courses de rats" et sans divers stress. Certains membres de l'ancienne équipe n'ont pas voulu travailler ainsi et sont partis, tandis que d'autres ont trouvé que les règles transparentes étaient un plus. Au final, tous ceux qui restent dans l'équipe sont très motivés et connaissent le projet en profondeur, tant au niveau frontend que backend. Y compris la base de code et toute la logique commerciale. Nous en sommes même arrivés au point où nous ne sommes pas seulement des "rameurs", mais nous proposons nous-mêmes de nombreux processus commerciaux et de nouvelles fonctionnalités qui ont plu au business.
Grâce à cette approche de notre part, le client a décidé de commander un autre marketplace à notre entreprise, ce qui est réjouissant.
Puisque cela fonctionne pour mon projet, cela peut également aider quelqu'un d'autre. Voici donc le processus qui nous a aidés à sauver le projet :
Processus de travail de l'équipe sur le projet « Mon projet préféré »
a) Processus interne de l'équipe (entre les développeurs)
- Toutes les tâches sont créées dans le système Jira.
- Chaque tâche doit être décrite le plus précisément possible et exécuter une seule action.
- Toute fonctionnalité, si elle est suffisamment complexe, est divisée en plusieurs petites tâches.
- L'équipe travaille sur les fonctionnalités comme une seule tâche. D'abord, nous faisons ensemble une fonctionnalité, la soumettons pour test, puis prenons la suivante.
- Chaque tâche est marquée, qu'elle soit pour le back-end ou le front-end.
- Il existe des types de tâches et de bugs. Il est important de les indiquer correctement.
- Après l'exécution d'une tâche, elle est transférée à l'état de revue de code (un pull request est créé pour un collègue).
- Celui qui a exécuté la tâche suit immédiatement son temps pour cette tâche.
- Après vérification du code, le PR est approuvé, puis celui qui a effectué cette tâche fusionne la branche dans labranche principale, après quoi il change son statut en prêt pour déploiement sur dev. serveur.
- Toutes les tâches prêtes pour le déploiement sur le serveur dev sont déployées par le lead (sa zone de responsabilité), parfois par un membre de l'équipe si quelque chose est urgent. Après le déploiement, toutes les tâches prêtes pour le déploiement sur dev sont transférées au statut — prêtes pour les tests sur dev.
- Toutes les tâches sont testées par le client.
- Lorsque le client a testé la tâche sur dev, il la transfère au statut prêt pour le déploiement en production.
- Pour le déploiement en production, nous avons une branche distincte dans laquelle nous fusionnons la branche principale juste avant le déploiement.
- Si pendant les tests le client trouve des bugs, il renvoie la tâche pour retravail, lui attribuant le statut renvoyée pour retravail. Ainsi, nous séparons les nouvelles tâches de celles qui n'ont pas passé les tests.
- Ainsi, toutes les tâches suivent le chemin de la création à l'achèvement : To Do → En développement → Revue de code → Prêt à déployer sur dev → QA sur dev → (Retour à dev) → Prêt à déployer en prod → QA sur prod → Terminé.
- Chaque développeur teste son code lui-même, y compris en tant qu'utilisateur du site. La fusion d'une branche avec la principale n'est pas autorisée si l'on n'est pas certain que le code fonctionne.
- Chaque tâche a ses priorités. Les priorités sont définies soit par le client, soit par le chef d'équipe.
- Les développeurs s'attaquent en priorité aux tâches prioritaires.
- Les développeurs peuvent se désigner des tâches les uns aux autres si des bogues différents ont été trouvés dans le système ou si une tâche implique le travail de plusieurs spécialistes.
- Toutes les tâches créées par le client sont transmises au chef d'équipe, qui les évalue et demande soit au client d'apporter des modifications, soit les assigne à l'un des membres de l'équipe.
- Toutes les tâches prêtes à être déployées sur dev ou prod sont également transmises au chef d'équipe, qui détermine quand et comment procéder au déploiement. Après chaque déploiement, le chef d'équipe (ou un membre de l'équipe) doit informer le client à ce sujet et changer les statuts des tâches en prêts à être testées sur dev/prod.
- Nous avons une réunion tous les jours à la même heure (chez nous, c'est à 12h00) entre tous les membres de l'équipe.
- Lors de la réunion, chacun fait le point, y compris le chef d'équipe, sur ce qu'il a fait hier et ce qu'il prévoit de faire aujourd'hui. Il explique ce qui ne fonctionne pas et pourquoi. Ainsi, toute l'équipe est au courant de ce que chacun fait et à quel stade se trouve le projet. Cela nous permet de prévoir et d'ajuster, si nécessaire, nos estimations et délais.
- Lors de la réunion, le chef d'équipe informe également de tous les changements dans le projet et du niveau des bogues actuels découverts hors du client. Tous les bogues sont examinés et assignés à chaque membre de l'équipe pour qu'ils soient résolus.
- Lors de la réunion, le chef d'équipe assigne des tâches à chacun, en tenant compte de la charge actuelle des développeurs, de leur niveau de compétence, ainsi que de la proximité de chaque tâche par rapport à ce sur quoi travaille le développeur en ce moment.
- Lors de la réunion, le chef d'équipe élabore une stratégie générale concernant l'architecture et la logique d'affaires. Après quoi, toute l'équipe en discute et prend une décision concernant les ajustements ou l'adoption de cette stratégie.
- Chaque développeur écrit du code et construit des algorithmes de manière indépendante, en s'inscrivant dans une architecture et une logique commerciale communes. Chacun peut exprimer sa vision de la mise en œuvre, mais personne n'est contraint de procéder d'une manière particulière. Chaque décision est justifiée. S'il existe une meilleure solution mais qu'il n'y a pas de temps pour l'implémenter maintenant, une tâche est créée dans le JIRA pour un futur refactoring d'une certaine partie du code.
- Lorsqu'un développeur prend en charge une tâche, il la transfère au statut développement. Toute communication concernant des clarifications de la tâche avec le client incombe au développeur. Les questions techniques peuvent être posées au team lead ou à des collègues.
- Si le développeur ne comprend pas bien la nature de la tâche et que le client n'a pas réussi à l'expliquer clairement, il passe à la tâche suivante. Le team lead prend alors la tâche en cours et en discute directement avec le client.
- Chaque jour, le développeur doit informer le client dans le chat des tâches sur lesquelles il a travaillé la veille et celles sur lesquelles il travaillera aujourd'hui.
- Le processus de travail se déroule selon des principes Scrum. Tout est divisé en sprints. Chaque sprint dure deux semaines.
- Les sprints sont créés, remplis et fermés par le team lead.
- Si le projet a des délais stricts, nous essayons d'estimer toutes les tâches. Et nous les rassemblons en sprint. Si le client essaie d'ajouter d'autres tâches au sprint, nous établissons alors des priorités et reportons certaines autres tâches au prochain sprint.
b) Processus de travail avec le client
- Chaque développeur peut et doit communiquer avec le client.
- Il ne faut pas permettre au client d'imposer ses propres règles. Il est important de faire comprendre avec politesse et amitié au client que nous sommes des spécialistes dans notre domaine et que c'est à nous d'organiser les processus de travail tout en impliquant le client.
- Idéalement, avant de commencer à réaliser une fonctionnalité quelconque, il faut créer un schéma de flux logique pour la fonctionnalité (workflow) et l'envoyer au client pour validation. Cela ne concerne que les fonctionnalités complexes et non évidentes, par exemple un système de paiement, un système de notifications, etc. Cela permettra de mieux comprendre ce dont le client a réellement besoin, de conserver la documentation de la fonctionnalité et de se prémunir contre d'éventuelles réclamations du client disant que nous n'avons pas fait ce qu'il avait demandé.
- Nous conservons tous les diagrammes / organigrammes / logiques, etc. dans Confluence / Jira, où nous demandons au client de confirmer dans les commentaires l'exactitude de la mise en œuvre future.
- Nous essayons de ne pas surcharger le client avec des détails techniques. S'il est nécessaire de comprendre ce que veut le client, nous dessinons des algorithmes primitifs sous forme d'organigrammes que le client peut comprendre et corriger / améliorer lui-même.
- Si le client trouve un bug dans le projet, nous lui demandons de le décrire très en détail dans Jira. Quelles circonstances ont conduit à ce bug, quand cela s'est-il produit, quelle séquence d'actions le client a-t-il effectuée lors des tests ? Nous demandons également des captures d'écran.
- Nous essayons de déployer sur le serveur de développement chaque jour, au maximum tous les deux jours. Cela permet au client de commencer à tester les fonctionnalités et le projet ne reste pas inactif. Cela sert également de marqueur pour le client, indiquant que le projet est en cours de développement et que personne ne lui raconte des histoires.
- Il arrive très souvent que le client ne comprenne pas complètement ce qu'il veut. Étant donné qu'il crée une nouvelle entreprise avec des processus encore non établis. Par conséquent, il est fréquent que nous devions jeter des morceaux de code à la poubelle et retravailler la logique de l'application. Cela signifie qu'il n'est pas nécessaire de couvrir toutes les fonctionnalités par des tests. Il est logique de tester seulement les fonctionnalités critiques, et cela avec des réserves.
- Il arrive que l'équipe réalise qu'elle ne respecte pas les délais. Dans ce cas, nous faisons un audit rapide des tâches et informons immédiatement le client. Comme solution, nous proposons de livrer à temps les fonctionnalités importantes et critiques, et de repousser le reste au post-lancement.
- Si le client commence à inventer différentes tâches de son propre chef, à fantasmer et à expliquer de manière abstraite, nous lui demandons de nous fournir un modèle de page et un flux logique qui décrivent complètement le comportement de l'ensemble du modèle et de ses éléments.
- Avant de prendre en charge toute tâche, nous devons nous assurer que cette fonctionnalité est incluse dans les conditions de notre contrat. Si c'est une nouvelle fonctionnalité qui dépasse nos accords initiaux, nous devons absolument estimer cette fonctionnalité ((temps d'exécution estimé + 30%) x 2) et informer le client que cela prendra tant de temps, et que la date limite sera décalée de l'estimation multipliée par deux. Si nous sommes en mesure d'exécuter la tâche plus rapidement — c'est fantastique, tout le monde en bénéficiera. Sinon, nous serons couverts.
b) Ce que nous n'acceptons pas dans l'équipe :
- Nonchalance, désorganisation, oublis.
- « Faire traîner les choses ». Si vous ne pouvez pas exécuter une tâche, si vous ne savez pas comment faire, il faut en informer immédiatement le leader de l'équipe, et non pas attendre jusqu'à la dernière minute.
- Fanfaronnades et vantardises de la part d'une personne qui n'a pas encore prouvé ses compétences et son professionnalisme par ses actes. Si cela a été prouvé, alors ça peut aller, dans les limites du raisonnable 🙂.
- Toute forme de tromperie. Si une tâche n'est pas achevée, il ne faut pas changer son statut en 'terminée' et écrire dans le chat du client qu'elle est prête. Mon ordinateur est en panne, le système a planté, le chien a mâché le portable — tout cela est inacceptable. Si un véritable cas de force majeure se produit, le leader de l'équipe doit être immédiatement informé.
- Lorsque le spécialiste est toujours hors ligne et qu'il est difficile de le joindre pendant les heures de travail.
- La toxicité dans l'équipe n'est pas tolérée ! Si quelqu'un n'est pas d'accord, tout le monde se réunit en réunion pour en discuter et trouver une solution.
Et encore une série de questions/thèses que je pose parfois à mon client pour dissiper tout malentendu :
- Quels sont vos critères de qualité ?
- Comment déterminez-vous s'il y a des problèmes dans le projet ou non ?
- En enfreignant toutes nos recommandations et conseils concernant les modifications/améliorations du système, tous les risques sont à votre charge.
- Tout changement majeur dans le projet (par exemple, tout flux supplémentaire) peut entraîner l'apparition de bugs (que nous corrigerons, bien entendu).
- Il est impossible de comprendre en quelques minutes ce qui pose problème dans le projet, et encore moins de le corriger immédiatement.
- Nous travaillons selon un flux produit spécifique (Tâches dans Jira — Développement — Tests — Déploiement). Par conséquent, nous ne pouvons pas réagir à tout le flot de demandes et de plaintes dans le chat.
- Les programmeurs sont des programmeurs, pas des testeurs professionnels, et ne peuvent pas garantir la qualité appropriée des tests du projet.
- La responsabilité des tests finaux et de l'acceptation des tâches en production repose entièrement sur vous.
- Si nous avons déjà commencé à travailler sur une tâche, nous ne pouvons pas immédiatement nous tourner vers d'autres tant que nous n'avons pas terminé la tâche en cours (sinon cela entraîne encore plus de bogues et un allongement des délais de développement).
- Le nombre de personnes dans l'équipe a diminué (en raison de congés ou de maladies), tandis que le volume de travail a augmenté et nous ne pouvons physiquement pas répondre à tout ce que vous souhaitez.
- Votre demande de déploiement en production sans tâches testées en développement représente uniquement vos risques, pas ceux des développeurs.
- Lorsque vous définissez des tâches floues, sans flux correct, sans maquettes de design, cela exige de notre part beaucoup plus d'efforts et de délais de réalisation, car nous devons faire une nouvelle charge de travail à votre place.
- Toute tâche concernant des bogues, sans description détaillée de leur apparition et sans captures d'écran, ne nous permet pas de comprendre ce qui ne va pas et comment reproduire ce bogue.
- Le projet nécessite des améliorations et des ajustements constants pour augmenter les performances et la sécurité. C'est pourquoi l'équipe consacre une partie de son temps à ces améliorations.
- En raison de nos heures supplémentaires (fixations urgentes), nous devons les compenser à d'autres jours.
En général, le client comprend immédiatement que le développement de logiciels n'est pas si simple et qu'un simple désir ne suffit clairement pas.
En résumé, c'est tout. Je laisse de côté de nombreuses négociations et le débogage initial de tous les processus, mais en fin de compte, tout s'est bien organisé. Je peux dire que ce processus est devenu pour nous une sorte de « balle d'argent ». Les nouvelles personnes qui rejoignaient le projet pouvaient immédiatement s'y engager dès le premier jour, car tous les processus étaient décrits et la documentation ainsi que l'architecture sous forme de diagrammes donnaient immédiatement une idée de ce que nous faisons ici.
P. S. Je tiens à préciser qu'il n'y a pas de chef de projet de notre côté. Il est côté client. Pas du tout technique. Le projet est européen. Toute la communication est uniquement en anglais.
Bonne chance à tous dans vos projets. Ne vous laissez pas submerger et essayez d'améliorer vos processus.
Le code source est entre mes mains. .
Source : habr.com
