Bonjour les amis. Très souvent, surtout dans le domaine de l'externalisation, je vois la même situation. Manque de flux de travail clair dans les équipes sur divers projets.
Le plus important est que les programmeurs ne comprennent pas comment communiquer avec le client et entre eux. Comment construire un processus continu de développement d'un produit de qualité. Comment planifier votre journée de travail et vos sprints.
Et tout cela aboutit finalement à des délais non respectés, à des heures supplémentaires, à des confrontations constantes pour savoir qui est à blâmer et à l'insatisfaction des clients quant à l'endroit et à la manière dont tout se déroule. Bien souvent, tout cela conduit à un changement de programmeurs, voire d'équipes entières. Perte d'un client, détérioration de la réputation, etc.
À un moment donné, je me retrouvais sur un tel projet, où il y avait tous ces délices.
Personne ne voulait assumer la responsabilité du projet (un grand marché de services), le chiffre d'affaires était terrible, le client était tout simplement déchiré et frustré. Le PDG est venu me voir un jour et m'a dit que vous aviez l'expérience nécessaire, voici donc les cartes entre vos mains. Prenez le projet pour vous. Si vous vous trompez, nous fermerons le projet et expulserons tout le monde. Cela fonctionnera, ce sera cool, puis dirigez-le et développez-le comme bon vous semble. En conséquence, je suis devenu le chef d’équipe du projet et tout est tombé sur mes épaules.
La première chose que j'ai faite a été de développer un flux de travail à partir de zéro qui correspondait à ma vision de l'époque et de rédiger une description de poste pour l'équipe. Sa mise en œuvre n’a pas été facile. Mais au bout d'un mois environ, tout s'est calmé, les développeurs et le client s'y sont habitués, et tout s'est déroulé dans le calme et le confort. Afin de montrer à l'équipe qu'il ne s'agissait pas seulement d'une « tempête dans une tasse de thé », mais d'un véritable moyen de sortir de la situation, j'ai assumé le maximum de responsabilités, supprimant la routine désagréable de l'équipe.
Un an et demi s'est déjà écoulé et le projet se développe sans heures supplémentaires, sans « courses de rats » et sans stress de toutes sortes. Certains membres de l’ancienne équipe ne voulaient pas travailler ainsi et sont partis ; d’autres, au contraire, étaient très heureux que des règles transparentes soient apparues. Mais au final, tous les membres de l’équipe sont très motivés et connaissent parfaitement l’énorme projet, tant en front-end qu’en back-end. Y compris à la fois la base de code et toute la logique métier. Nous en sommes même arrivés au point où nous ne sommes pas seulement des « rameurs », mais nous inventons nous-mêmes de nombreux processus commerciaux et de nouvelles fonctionnalités qui plaisent à l'entreprise.
Grâce à cette démarche de notre part, le client a décidé de commander une autre marketplace auprès de notre société, ce qui est une bonne nouvelle.
Puisque cela fonctionne sur mon projet, cela aidera peut-être aussi quelqu'un. Ainsi, le processus lui-même qui nous a aidé à sauver le projet :
Le processus de travail d'équipe sur le projet « Mon projet préféré »
a) Processus d'équipe interne (entre développeurs)
- Tous les tickets sont créés dans le système Jira
- Chaque tâche doit être décrite autant que possible et effectuer strictement une seule action
- Toute fonctionnalité, si elle est suffisamment complexe, se décompose en de nombreuses petites tâches
- L'équipe travaille sur les fonctionnalités comme une seule tâche. Tout d’abord, nous travaillons tous ensemble sur une fonctionnalité, l’envoyons pour test, puis passons à la suivante.
- Chaque tâche est marquée, pour le backend ou le frontend
- Il existe des types de tâches et de bugs. Vous devez les indiquer correctement.
- Après avoir terminé une tâche, elle est transférée en statut de révision de code (dans ce cas, une pull request est créée pour un collègue)
- La personne qui a terminé la tâche suit immédiatement son temps pour cette tâche.
- Après avoir vérifié le code, le PR approuvera et après cela, celui qui a effectué cette tâche le fusionnera indépendamment dans la branche principale, après quoi il changera son statut en prêt à être déployé sur le serveur de développement.
- Toutes les tâches prêtes à être déployées sur le serveur de développement sont déployées par le chef d'équipe (son domaine 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 à être déployées vers le développement sont transférées au statut - prêtes à être testées sur le développement.
- Toutes les tâches sont testées par le client
- Lorsque le client a testé la tâche sur le dev, il la transfère au statut prêt à être déployé en production
- Pour le déploiement en production, nous avons une branche distincte, où nous fusionnons le maître uniquement avant le déploiement
- Si lors des tests le client trouve des bogues, il renvoie la tâche pour révision, définissant son statut comme renvoyé pour révision. De cette façon, nous séparons les nouvelles tâches de celles qui n’ont pas réussi les tests.
- En conséquence, toutes les tâches vont de la création à l'achèvement : À faire → En développement → Révision du code → Prêt à déployer sur le développement → QA en développement → (Retour au développement) → Prêt à déployer en production → QA en production → Terminé
- Chaque développeur teste son code de manière indépendante, y compris en tant qu'utilisateur du site. Il n'est pas permis de fusionner une branche avec la branche principale à moins d'être certain que le code fonctionne.
- Chaque tâche a des priorités. Les priorités sont définies soit par le client, soit par le chef d'équipe.
- Les développeurs effectuent les tâches prioritaires en premier.
- Les développeurs peuvent s'attribuer des tâches les uns aux autres si différents bogues ont été trouvés dans le système ou si une tâche consiste en 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 au client de les modifier ou les assigne à l'un des membres de l'équipe.
- Toutes les tâches prêtes à être déployées en développement ou en production sont également confiées au chef d'équipe, qui détermine de manière indépendante quand et comment effectuer le déploiement. Après chaque déploiement, le chef d'équipe (ou membre de l'équipe) doit en informer le client. Et modifiez également les statuts des tâches pour qu'ils soient prêts à être testés pour dev/cont.
- Chaque jour à la même heure (pour nous c'est à 12.00hXNUMX) nous organisons une réunion entre tous les membres de l'équipe
- Toutes les personnes présentes à la réunion rendent compte, y compris le chef d'équipe, de ce qu'elles ont fait hier et de ce qu'elles prévoient de faire aujourd'hui. Qu'est-ce qui ne fonctionne pas et pourquoi. De cette façon, toute l’équipe sait qui fait quoi et à quel stade se trouve le projet. Cela nous donne la possibilité de prévoir et d’ajuster, si nécessaire, nos estimations et délais.
- Lors de la réunion, le chef d'équipe parle également de tous les changements intervenus dans le projet et du niveau de bugs actuels qui n'ont pas été trouvés par le client. Tous les bugs sont triés et attribués à chaque membre de l'équipe pour les résoudre.
- Lors de la réunion, le chef d'équipe attribue des tâches à chaque personne, en tenant compte de la charge de travail actuelle des développeurs, de leur niveau de formation professionnelle, et en tenant également compte de la proximité d'une tâche particulière avec ce que fait actuellement le développeur.
- Lors de la réunion, le chef d'équipe élabore une stratégie générale pour l'architecture et la logique métier. Après quoi toute l’équipe en discute et décide de faire des ajustements ou d’adopter cette stratégie.
- Chaque développeur écrit du code et construit des algorithmes de manière indépendante dans le cadre d'une architecture et d'une logique métier uniques. Chacun peut exprimer sa vision de la mise en œuvre, mais personne n’oblige personne à le faire de cette manière et pas autrement. Chaque décision est justifiée. S'il existe une meilleure solution, mais que nous n'avons pas le temps pour cela maintenant, alors une tâche est créée en gras pour la future refactorisation d'une certaine partie du code.
- Lorsqu'un développeur assume une tâche, il la transfère au statut de développement. Toute communication concernant la clarification de la tâche avec le client incombe au développeur. Des questions techniques peuvent être posées au chef d’équipe ou à des collègues.
- Si le développeur ne comprend pas l'essence de la tâche et que le client n'est pas en mesure de l'expliquer clairement, il passe alors à la tâche suivante. Et le chef d'équipe prend celui actuel et en discute avec le client.
- Chaque jour, le développeur doit écrire dans le chat du client les tâches sur lesquelles il a travaillé hier et les tâches sur lesquelles il travaillera aujourd'hui.
- Le processus de travail se déroule selon Scrum. Tout est divisé en sprints. Chaque sprint dure deux semaines.
- Les sprints sont créés, remplis et clôturés par le chef d'équipe.
- Si le projet a des délais stricts, nous essayons alors d'estimer approximativement toutes les tâches. Et nous les avons rassemblés dans un sprint. Si le client essaie d'ajouter plus de tâches au sprint, nous définissons des priorités et transférons d'autres tâches au sprint suivant.
b) Processus de travail avec le client
- Chaque développeur peut et doit communiquer avec le client
- Le client ne peut être autorisé à imposer ses propres règles du jeu. Il est nécessaire de faire comprendre au client de manière polie et amicale que nous sommes des spécialistes dans notre domaine et que nous sommes les seuls à construire des processus de travail et à y impliquer le client.
- Il est nécessaire, idéalement, avant de commencer à implémenter une fonctionnalité, de créer un organigramme de l'ensemble du processus logique de la fonctionnalité (workflow). Et envoyez-le au client pour confirmation. Cela ne s'applique qu'aux fonctionnalités complexes et peu évidentes, par exemple un système de paiement, un système de notification, etc. Cela nous permettra de comprendre plus précisément ce dont le client a exactement besoin, de sauvegarder la documentation sur la fonctionnalité et également de nous assurer contre le fait que le client puisse dire à l'avenir que nous n'avons pas fait ce qu'il a demandé.
- Tous les diagrammes/organigrammes/logiques, etc. Nous l'enregistrons dans Confluence/Fat, où nous demandons au client de confirmer l'exactitude de la future implémentation dans les commentaires.
- Nous essayons de ne pas surcharger le client avec des détails techniques. Si nous avons besoin de comprendre ce que le client souhaite, nous dessinons des algorithmes primitifs sous la forme d'un organigramme que le client peut comprendre et tout corriger/modifier lui-même.
- Si le client découvre un bug dans le projet, nous vous demandons de le décrire de manière très détaillée dans Zhira. Dans quelles circonstances cela s'est-il produit, quand, quelle séquence d'actions a été effectuée par le client lors des tests. Veuillez joindre des captures d'écran.
- Nous essayons tous les jours, tous les deux jours au maximum, de déployer sur le serveur de développement. Le client commence alors à tester la fonctionnalité et le projet ne reste pas inactif. En même temps, c'est un signe pour le client que le projet est en plein développement et que personne ne lui raconte des contes de fées.
- Il arrive souvent que le client ne comprenne pas parfaitement ce dont il a besoin. Parce qu’il se crée une nouvelle entreprise, avec des processus qui ne sont pas encore établis. Par conséquent, une situation très courante est celle où nous jetons des morceaux de code entiers à la poubelle et reconcevons la logique de l'application. Il s'ensuit qu'il ne faut pas absolument tout couvrir avec des tests. Il est logique de couvrir uniquement les fonctionnalités critiques avec des tests, et ensuite uniquement avec des réserves.
- Il y a des situations où l'équipe se rend compte que nous ne respectons pas les délais. Nous effectuons ensuite un audit rapide des tâches et en informons immédiatement le client. Pour sortir de cette situation, nous suggérons de lancer les fonctionnalités importantes et critiques à temps et de laisser le reste après la publication.
- Si le client commence à imaginer différentes tâches de sa tête, commence à fantasmer et à expliquer avec ses doigts, alors nous lui demandons de nous fournir une mise en page et un flux avec une logique qui devrait décrire pleinement le comportement de l'ensemble de la mise en page et ses éléments.
- Avant d'entreprendre une tâche, nous devons nous assurer que cette fonctionnalité a été incluse dans les termes de notre accord/contrat. S'il s'agit d'une nouvelle fonctionnalité qui va au-delà de nos accords initiaux, nous devons alors tarifer cette fonctionnalité ((délai de réalisation estimé + 30 %) x 2) et indiquer au client qu'il nous faudra autant de temps pour la réaliser, plus le le délai est décalé du délai d’estimation multiplié par deux. Faisons la tâche plus rapidement - super, tout le monde en bénéficiera. Si ce n'est pas le cas, nous avons ce qu'il vous faut.
c) Ce qu’on n’accepte pas dans une équipe :
- Désengagement, manque de sang-froid, oubli
- "Nourrir le petit-déjeuner." Si vous ne pouvez pas accomplir une tâche et ne savez pas comment, vous devez en informer immédiatement le chef d'équipe et ne pas attendre la dernière minute.
- Sourcils et vantardises d'une personne qui n'a pas encore prouvé ses capacités et son professionnalisme. Si c’est prouvé, alors c’est possible, dans les limites de la décence :)
- La tromperie sous toutes ses formes. Si une tâche n'est pas terminée, vous ne devez pas changer son statut en terminé et écrire dans le chat client qu'elle est prête. L'ordinateur est tombé en panne, le système est tombé en panne, le chien a mâché l'ordinateur portable - tout cela est inacceptable. Si un événement réel de force majeure survient, le chef d’équipe doit en être immédiatement informé.
- Lorsqu'un spécialiste est tout le temps hors ligne et qu'il est difficile de le joindre pendant les heures de travail.
- La toxicité dans l'équipe n'est pas autorisée ! Si quelqu'un n'est pas d'accord avec quelque chose, alors tout le monde se rassemble pour un rassemblement, en discute et prend une décision.
Et un certain nombre de questions/thèses que je pose parfois à mon client pour dissiper tout malentendu :
- Quels sont vos critères de qualité ?
- Comment déterminer si un projet présente des problèmes ou non ?
- En violant toutes nos recommandations et conseils sur la modification/amélioration du système, tous les risques sont supportés uniquement par vous.
- Toute modification majeure apportée au projet (par exemple, toutes sortes de flux supplémentaires) entraînera l'apparition possible de bugs (que nous corrigerons bien entendu)
- Il est impossible de comprendre en quelques minutes quel type de problème s'est produit sur le projet, et encore moins de le résoudre immédiatement.
- Nous travaillons sur un flux de produits spécifique (Tâches dans Zhira - Développement - Tests - Déploiement). Cela signifie que nous ne pouvons pas répondre à l'ensemble du flux de demandes et de plaintes dans le chat.
- Les programmeurs sont des programmeurs, pas des testeurs professionnels, et ne peuvent pas garantir la bonne qualité des tests du projet.
- La responsabilité des tests finaux et de l'acceptation des tâches de production vous incombe entièrement
- Si nous avons déjà accepté une tâche, nous ne pouvons pas passer immédiatement à d'autres jusqu'à ce que nous ayons terminé celle en cours (sinon cela entraîne encore plus de bugs et une augmentation du temps de développement)
- Il y a moins de personnes dans l'équipe (à cause des vacances ou des maladies), mais il y a plus de travail et nous n'aurons physiquement pas le temps de répondre à tout ce que vous voulez
- Nous vous demandons d'effectuer un déploiement en production sans tâches testées sur le développement - ce n'est que votre risque, pas celui des développeurs
- Lorsque vous définissez des tâches peu claires, sans flux correct, sans schémas de conception, cela nous demande beaucoup plus d'efforts et de temps de mise en œuvre, car nous devons effectuer une quantité de travail supplémentaire à votre place.
- Toute tâche sur les bugs, sans description détaillée de leur apparition et captures d'écran, ne nous donne pas la possibilité de comprendre ce qui n'a pas fonctionné et comment nous pouvons corriger ce bug.
- Le projet nécessite un perfectionnement et des améliorations constants pour améliorer les performances et la sécurité. L’équipe consacre donc une partie de son temps à ces améliorations
- Etant donné que nous avons des heures supplémentaires à l'heure (dépannages urgents), nous devons les compenser les autres jours.
En règle générale, le client comprend immédiatement que tout n'est pas si simple dans le développement de logiciels et que le désir seul ne suffit clairement pas.
En général, c'est tout. Je laisse en coulisses de nombreuses négociations et le débogage initial de tous les processus, mais en fin de compte, tout s'est bien passé. Je peux dire que ce processus est devenu pour nous une sorte de « solution miracle ». Les nouvelles personnes qui venaient au projet pouvaient immédiatement s'impliquer dans le travail dès le premier jour, puisque tous les processus étaient décrits, et la documentation et l'architecture sous forme de diagrammes donnaient immédiatement une idée de ce que nous faisions tous ici.
PS Je tiens à préciser qu'il n'y a pas de chef de projet de notre côté. C'est du côté du client. Pas du tout un technicien. Projet européen. Toutes les communications se font uniquement en anglais.
Bonne chance à tous pour les projets. Ne vous épuisez pas et essayez d'améliorer vos processus.
Source dans la mienne .
Source: habr.com