Comment puis-je combler le fossé entre les développeurs et les équipes de support en production ?

Question

Pour clarifier ma question, permettez-moi de définir les termes du titre--

Les équipes de support à la production sont les ressources qui maintiennent les applications logicielles actuellement en cours d'utilisation. Les développeurs sont les codeurs qui écrivent les applications logicielles à partir des exigences.

Souvent, du moins dans mon expérience professionnelle, ces deux équipes ne se rencontrent qu'une ou deux fois au maximum pour discuter de la prochaine version en production. On suppose que les équipes de support à la production vont comprendre les risques potentiels sans jamais consulter les exigences ou les documents de conception ou sans jamais rencontrer les clients ou les parties prenantes. On s'attend à ce qu'après seulement une ou deux réunions avec les équipes de développement, les équipes de support à la production comprennent, atténuent et résolvent les risques potentiels de cette version.

Ceci étant le problème, il me faut établir des lignes directrices pour combler le fossé entre les équipes de support à la production et les développeurs. Quelles sont vos idées? Quelles questions doivent être posées lorsque les deux équipes se réunissent?

Answer 1

Avoir deux équipes est une erreur dès le départ.

J'ai vu cela (deux équipes distinctes) dans d'autres entreprises et cela m'étonnait toujours que cela se fasse réellement dans le monde réel.

Je suggère seulement une équipe de développeurs - certains sont chargés du support, et d'autres travaillent sur de nouveaux développements - mais il n'y a pas de délimitation claire.

Pour commencer, il n'y a pas de boucle de rétroaction naturelle (positive ou négative) pour les développeurs de nouveaux codes afin de les rendre maintenables. Ils les envoient simplement aux mainteneurs sans se soucier.

J'ai également constaté que cela créait de la division au lieu d'une cohésion. Je ne vois rien de positif dans ce scénario, alors qu'une seule équipe produit comporte de nombreux avantages.

Je ne comprends pas.

Je suis d'accord avec les autres - soit tournez en rotation, soit faites UNE seule équipe.

EDIT:

Donc, pour ceux qui n'ont pas la possibilité de tourner au sein des équipes ou de créer une seule équipe :

• Il doit y avoir une visibilité des deux côtés sur les problèmes qui surviennent. C'est-à-dire que les retours de la production doivent parvenir aux équipes de développement.
• Comme vous le suggérez, impliquez l'équipe de production dès la conception initiale, la planification et la collecte des exigences.
• Les équipes doivent pouvoir facilement accéder les unes aux autres.

EDIT:

J'ai travaillé dans une société qui avait une petite équipe en prêt du reste de l'équipe de développement - ils l'appelaient l'équipe "swat". Ils développaient des fonctionnalités spécifiques pour certains gros clients ou moyennant des frais, et le code était mis sur une branche spécifique. Bien que similaire, ils provenaient finalement de l'ensemble des développeurs.

Answer 2

Faites tourner les gens entre les deux équipes pendant un court instant. De cette façon, lorsqu'ils retournent dans leur équipe d'origine, ils ont une meilleure compréhension des problèmes auxquels l'autre équipe est confrontée.

Answer 3

Je pousserais la suggestion d'Elie un peu plus loin et dirais toujours tourner les gens. Je ne connais aucun développeur qui soit heureux de faire uniquement du travail de maintenance sur du code écrit par d'autres personnes.

D'un autre côté, les développeurs qui n'écrivent que du nouveau code ne ressentiront jamais la douleur de la maintenance et ne sauront donc pas comment écrire un code maintenable.

Modifier :
Idéalement, je suis d'accord avec Tim - il ne devrait vraiment pas y avoir d'équipes séparées et c'est une pratique terrible. Je supposais que vous n'auriez pas le pouvoir de faire un changement aussi radical, mais peut-être que si :).

Answer 4

Quelques idées de départ :

1. L'équipe de production est concernée, elle doit donc être impliquée dès le premier jour. Votre système est-il maintenable ? Publie-t-il des alertes vers le système/de tableau de bord de support ? Des processus manuels (ex. redémarrage le week-end) sont-ils nécessaires ? En parlant au support dès le début du projet, vous aurez créé les prémices d'une relation de travail.
2. Dès que possible, impliquez autant que possible le support de production en 'productionisant' votre système. C'est-à-dire, essayez de gérer vos builds Smoke, QA et UAT comme s'ils étaient des systèmes de production. Ce n'est pas toujours possible pour les builds Smoke, mais cela devrait être possible (voire requis) pour QA/UAT.
3. Formation et documentation. Formez l'équipe de support de production et fournissez-leur une bonne documentation.
4. Assurez-vous d'avoir un processus de support de 2ème ou 3ème ligne en place - c'est-à-dire que l'équipe de support de production puisse entrer en contact avec un développeur quand ils en ont besoin.

Answer 5

L'intégration réelle ne peut venir que du travail en commun sur le même projet.

Le meilleur moyen est que l'équipe de support participe au développement, par exemple une équipe de 4 membres, chaque semaine une personne est principalement en charge du support pendant que les autres travaillent sur le développement. Cela signifie que le responsable du support peut se reposer pendant 3 semaines avant de reprendre le support.

Cela permet aux personnes de ressentir le projet comme leur propre, et d'éviter de devenir fou avec les questions stupides et les tâches sans réflexion dont le support peut parfois être composé.

N'oubliez pas que l'équipe de support connaît normalement beaucoup mieux les utilisateurs et la manière dont ils utilisent le système. Pour cette raison, elle est dans la meilleure position pour l'améliorer.

L'équipe de support de production devrait avoir accès aux exigences ou aux documents de conception et participer à leur mise à jour.