Le plus important est que les programmeurs ne comprennent pas comment communiquer avec le client et entre eux. Comment construire un processus de développement de produits de qualité continue. Comment planifier votre journée de travail et vos sprints.
Et tout cela se traduit finalement par des délais perturbés, des heures supplémentaires, des confrontations constantes pour savoir qui est à blâmer et l'insatisfaction des clients - où et comment tout se passe. Très souvent, tout cela entraîne 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 viens de monter sur un tel projet, où se trouvaient tous ces charmes.
Personne ne voulait assumer la responsabilité du projet (une grande place de marché de services), le chiffre d'affaires était terrible, le client a juste déchiré et battu. Le PDG est venu me voir et m'a dit que vous aviez l'expérience nécessaire, alors voici les cartes entre vos mains. Prenez le projet pour vous. Vous vous trompez, nous fermerons le projet et expulserons tout le monde. Cela s'avérera, ce sera cool, puis dirigez-le et développez-le comme bon vous semble. Du coup, je suis devenu chef d'équipe sur le projet et tout est tombé sur mes épaules.
La première chose que j'ai faite a été de concevoir 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. Ce n'était pas facile à mettre en œuvre. Mais en un mois, tout s'est calmé, les développeurs et le client s'y sont habitués, et tout s'est déroulé tranquillement et confortablement. Afin de montrer à l'équipe qu'il ne s'agit pas simplement d'une "tempête dans un verre", mais d'une véritable issue à la situation, j'ai pris 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 rat» et toutes sortes de stress. Quelqu'un dans l'ancienne équipe ne voulait pas travailler comme ça et est parti, quelqu'un, au contraire, tenait beaucoup à ce que des règles transparentes apparaissent. Mais en conséquence, tous les membres de l'équipe sont très motivés et connaissent l'énorme projet dans son intégralité, avec à la fois le front-end et le back-end. Y compris la base de code et toute la logique métier. Il en est même arrivé au point que nous ne sommes pas seulement des «rameurs», mais que nous proposons nous-mêmes de nombreux processus métier et de nouvelles fonctionnalités que l'entreprise a trouvé à son goût.
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, peut-être que cela peut aussi aider quelqu'un. Donc, le processus lui-même qui nous a aidés à sauver le projet:
Processus de travail d'équipe sur le projet "Mon projet préféré"
a) Processus d'équipe interne (entre développeurs)
- Toutes les tâches sont créées dans le système Jira
- Chaque tâche doit être décrite autant que possible et effectuer strictement une action
- Toute fonctionnalité, si elle est suffisamment complexe, est décomposée en de nombreux petits swaps
- L'équipe travaille sur des fonctionnalités comme une seule tâche. Tout d'abord, nous faisons tous ensemble 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 swaps et de bogues. Vous devez les indiquer correctement.
- Une fois la tâche terminée, elle est transférée au statut de révision de code (cela crée une pull request pour votre collègue)
- Celui qui a terminé la tâche suit immédiatement son temps pour cette tâche.
- , , , , , .
- , , ( ), , - . —
- ,
- ,
- , , . ,
- : To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
- , . , , .
- . , .
- .
- , .
- , , , , .
- , , , , . ( ) . , /.
- ( 12.00)
- , , , . . , . , , .
- , . .
- , , , , .
- . .
- . , , . . , , , .
- , . . .
- , , . .
- Chaque jour, le développeur doit écrire dans le chat du client sur les tâches sur lesquelles il a travaillé hier et sur les tâches sur lesquelles il travaillera aujourd'hui
- Le flux de travail est basé sur Scrum. Tout est décomposé en sprints. Chaque sprint dure deux semaines.
- Les sprints créent, remplissent et clôturent un chef d'équipe.
- Si le projet a des délais stricts, nous essayons d'estimer approximativement toutes les tâches. Et nous collectons un sprint d'eux. 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) Le processus de travail avec le client
- Chaque développeur peut et doit communiquer avec le client
- Le client ne doit pas être autorisé à imposer ses propres règles du jeu. Il est nécessaire de manière polie et amicale de faire comprendre au client que nous sommes des spécialistes dans notre domaine, et que nous devons seulement construire des processus de travail et y impliquer le client.
- , , - , - (). . , , , .. , , , , , , .
- /-/ .. /, .
- . , , -, /.
- , . , , . .
- , . . , .
- , , . , . , . , . .
- , , . , . , .
- Si le client commence à proposer différentes tâches de sa tête, commence à fantasmer et à expliquer sur les doigts, 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 de 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, alors nous devons définitivement évaluer cette fonctionnalité ((délai estimé + 30%) x 2) et indiquer au client que cela nous prendra tellement de temps, plus le délai est décalé par deux fois l'estimation. Rendons la tâche plus rapide - super, tout le monde en bénéficiera. Sinon, nous sommes assurés.
c) Ce que nous n'acceptons pas dans l'équipe:
- Optionnel, manque d'assemblage, oubli
- „ “. , , , .
- , . , , :)
- . , , . , , — . -, .
- .
- ! - - , .
Et un certain nombre d'autres questions / thèses que je demande parfois à mon client pour lever tous les malentendus:
- Quels sont vos critères de qualité?
- Comment déterminez-vous si un projet a des problèmes ou non?
- En violation de toutes nos recommandations et conseils sur le changement / l'amélioration du système, tous les risques ne sont supportés que par vous
- Toute modification majeure du projet (par exemple, toutes sortes de flux supplémentaires) entraînera l'apparition possible de bogues (que nous allons bien sûr corriger)
- Il est impossible pendant quelques minutes de comprendre quel type de problème est survenu sur le projet, et plus encore de le résoudre immédiatement
- Nous travaillons sur un produit de flux spécifique (Tâches en gros - Développement - Test - 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 ne sont que des programmeurs, pas des testeurs professionnels, et ne peuvent pas garantir la bonne qualité des tests de projets
- , , ( )
- ( ), ,
- — ,
- , , , ,
- , , , ,
- .
- , ( ),
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 manifestement pas.
En général, c'est tout. Je laisse dans les coulisses beaucoup de négociations et le débogage initial de tous les processus, mais en conséquence tout a fonctionné. Je peux dire que ce processus est devenu une sorte de "Silver Bullet" pour nous. Les nouveaux venus sur le projet ont pu s'habituer immédiatement au travail dès le premier jour, puisque tous les processus sont décrits, et la documentation et l'architecture sous forme de diagrammes ont immédiatement donné 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. Le projet est européen. Toutes les communications sont en anglais uniquement.
Bonne chance à tous sur les projets. Ne vous épuisez pas et essayez d'améliorer vos processus.
La source est sur mon blog .