Les processus de mon équipe sont-ils hors de contrôle?

Je suis un chef d'équipe de développement logiciel (j'ai récemment pris le contrôle d'une nouvelle équipe) et, en fin de compte, responsable du maintien d'une productivité élevée, d'une bonne qualité et de priorités organisées.

J'ai 6 développeurs seniors dans mon équipe, mais les choses semblent être un gâchis ici. La situation est que je dois traiter les demandes JIRA d'environ 10 points de contact différents dans notre entreprise, et ils représentent tous des unités commerciales ou des clients différents.

Le problème que j'ai, c'est que mon travail consiste principalement à éteindre les incendies toute la journée et à veiller à ce que les problèmes de chacun soient résolus. Malheureusement, la culture de notre entreprise a été une productivité élevée (versions rapides) mais de faible qualité (bogues de production), et nos clients n'accepteront pas un retard soudain des résultats.

Quels sont les bons moyens de gérer cela? J'ai des tonnes de théories, mais je cherche une réponse de quelqu'un qui a réellement une expérience de travail dans une situation comme la mienne.

Voici une petite liste de la façon dont les choses fonctionnent:

• Chaque développeur est responsable d'une application et de services spécifiques interagissant avec lui;
• Les versions sont généralement testées par le client sur un serveur de production simulé, puis déployées sur le serveur en direct;
• Chaque application est utilisée par une moyenne de 50 à 80 personnes, avec 8 applications au total.

Merci

nos clients n'accepteront pas un retard soudain des résultats

Eh bien, ils doivent accepter la mauvaise qualité qu'ils obtiennent.

Qu'est - ce que vous avez à faire pour changer cela est d' obtenir vos clients d'accepter la réalité du développement de logiciels (ou toute autre production!): Que précipiter les choses affecte la qualité.

Créez une grande liste des choses qui ne vont pas - des choses qui sont cassées, des moments où ils ont eu à se plaindre. Expliquez-leur la raison de ces problèmes et dites-leur ce que vous aimeriez faire pour changer cela. Assurez-vous de leur expliquer le pourcentage de temps que votre équipe passe à soutenir et à réparer les applications en direct. Si vous ne collectez pas les données à ce sujet, il est maintenant temps de commencer (et de les collecter pendant un mois avant de présenter les informations aux clients).

Obtenez les principales parties prenantes dans une pièce et dites: "voulez-vous que X soit réparé, ou voulez-vous que Y soit livré? Nous n'avons le temps que pour l'un des deux." Rendez- les responsables de la définition des priorités et indiquez clairement que votre capacité est limitée. S'ils demandent quelque chose de nouveau, demandez-leur ce qu'ils sont prêts à sacrifier de leur feuille de route actuelle pour y parvenir.

Demandez à votre équipe le temps et les ressources dont elle a besoin pour "arranger les choses" (à la fois en termes de correction de bogues de base et en termes de résolution de problèmes plus importants en termes de qualité / architecture / etc.). Incluez ces éléments dans la liste des choses que vos parties prenantes doivent prioriser.

La meilleure chose que j'ai jamais faite dans mon travail actuel a été de réunir les 8 principaux intervenants dans une pièce en même temps et de disposer une pile de 16 fiches représentant les nouvelles fonctionnalités qui avaient été demandées. Je me suis éloigné de la table et j'ai dit: "nous pouvons en livrer un à la fois. Dans quel ordre les voulez-vous?" Laissez-les débattre mutuellement de la priorité commerciale au lieu de vous coincer au milieu.

Arrêter de tomber et rouler. Les incendies ont besoin de carburant et se présentent souvent sous forme de panique. Réservez du temps pour vous gérer et gérer votre équipe dans l'ordre. Évaluez vos développeurs et voyez si vous en avez qui ne sont pas suffisamment qualifiés et / ou ne travaillent pas assez dur pour produire les résultats que vous souhaitez. Décidez qui reste (et faites un effort pour les garder), qui a besoin d'un petit coup de pouce, le reste doit partir. Évaluez le support et les outils dont disposent vos programmeurs pour vous assurer qu'ils peuvent faire leur travail. Assurez-vous que les tests, la révision, le contrôle des sources et la documentation sont suivis. Les bonnes personnes avec de bons outils doivent être responsables pour faire du bon travail.

Il doit y avoir un système pour savoir ce que votre équipe doit faire, travaille actuellement et quand elle s'attend à ce qu'elle soit terminée. Beaucoup de méthodologies, de théories, de logiciels, de tableaux effaçables à sec et de notes autocollantes, de documents et de courriels pour y parvenir. Faire fonctionner quelque chose en obligeant tout le monde à s'y tenir. Si tout le monde a une certaine contribution au système, il y a plus d'incitation à le suivre.

Obtenez une meilleure compréhension de ce que les clients attendent. Cela peut ne pas faire partie de votre travail. Il peut y avoir d'autres personnes qui prétendent que leurs cheveux sont en feu, que leurs clients sont mécontents et que le ciel tombe. C'est ce qu'ils font et certains sont vraiment bons dans ce domaine. Si tout est une urgence, rien n'est une urgence car tout ne sera pas fait. Offrez de participer occasionnellement aux discussions avec les clients. Vous constaterez que beaucoup de `` gentils à avoir '' se transforment en `` rupteurs d'accord '' lorsqu'ils arrivent dans l'équipe de développement. Soyez le liason technique ou une autre excuse pour vous aider. Faire des promesses que vous ne pouvez pas tenir est pire que de leur dire ce qu'ils ne veulent pas entendre en premier lieu. Nous voulons faire du bon travail, nous avons donc besoin de 8 semaines et non de 5. Ils seront plus heureux à long terme.

En fin de compte, vous devez éduquer vos clients sur le développement de logiciels et les impliquer autant que possible dans le processus. Ce qu'ils voient maintenant, c'est la livraison rapide de nouvelles fonctionnalités mais aussi des bugs dans le logiciel. Bien qu'ils soient satisfaits de la première, ils ne seront pas (ou ne devraient pas) être satisfaits de la seconde.

Vous devez leur expliquer qu'avec de meilleurs processus alors que la livraison de nouveaux logiciels sera retardée d'un court montant, il y aura moins de bugs (il n'y en aura jamais zéro). Si vous pouvez vous mettre d'accord sur le fait que c'est la voie à suivre, vous pourrez commencer à introduire les processus dont vous avez besoin pour reprendre le contrôle de votre développement.

L'utilisation du processus Agile peut aider ici car ils suggèrent (et dans certains mandats de mise en œuvre) que le client soit inclus dans l'équipe. Si vous impliquez les clients de très près, ils verront ce qui fonctionne et ce que vous pouvez produire de première main.

Mon opinion (expérience limitée): Je pense qu'il y a deux problèmes à résoudre. Tout d'abord, le processus qualité. Utilisez-vous une mêlée / une cascade / quelque chose entre les deux? Dans Scrum, vous pouvez ajouter des tâches supplémentaires pour chaque histoire: 1 pour créer un script / plan de test, une autre pour l'exécuter, une autre pour une révision du code, etc. En cascade, pouvez-vous simplement ajouter ces étapes?

L'autre problème est l'énorme problème principal qui existe partout dans les logiciels. Gérer les attentes. C'est-à-dire de plus en plus de temps de quelqu'un criant qu'il a besoin d'un bouton pour faire X pour le faire livrer.

Si vous pouvez ajouter des étapes supplémentaires au processus et faire une grande annonce à ce sujet [nous mettons maintenant en œuvre ce processus de qualité: ce qui signifie moins de temps pour corriger les bogues! et des résultats de meilleure qualité! gros e-mails / réunions, etc. pour les informer] et fournir des résultats régulièrement (ala scrum), l'idée est que ceux à qui vous livrez en apprendront et verront la valeur dans les étapes de processus supplémentaires, et ils y adhéreront. Moins de temps pour corriger les bogues = plus de temps pour mettre en œuvre et tester les fonctionnalités.

Les clients n'accepteront pas un retard soudain des résultats? Ils doivent à peu près. Il est clair que cela ne peut pas continuer tel quel. Peut-être pouvez-vous ajouter les étapes supplémentaires d'AQ et ensuite, si besoin est, ajouter d'autres membres de l'équipe? Mais les étapes de qualité sont absolument nécessaires.

Encore une fois, si vous utilisez Scrum ou similaire, vous pouvez viser un sprint d'une semaine afin qu'il y ait des livraisons régulières de résultats. Cela apaisera les gens tout autant qu'un redressement rapide.

J'espère que cela aide dans une certaine mesure ... j'espère que je n'ai pas raté le point.

Ce que vous avez décrit semble très normal et pas vraiment alarmant du tout.

• Les clients ont généralement un état d'esprit différent de ce qui est important que les ingénieurs. Nous aimons que les choses soient correctes, mais les clients sont confrontés à une réalité qui récompense la ponctualité sur la pureté. Ils ont besoin que leurs problèmes soient résolus rapidement pour être compétitifs, et c'est exactement ce pour quoi ils vous paient.
• La définition des priorités est trop grande et trop complexe pour qu'une seule personne puisse gérer seule, ayant un arriéré de problèmes importants (vous utilisez donc JIRA), avec des lieutenants gérant chaque domaine d'intérêt est la meilleure option que nous avons pour garder le travail impuissant à l'avant l'horaire.

Aucune raison de s'inquiéter. Cela dit, vous pouvez vous épargner beaucoup de douleur en transférant autant de tâches de gestion que possible au client payant, en l'impliquant dans le processus de développement de la définition des priorités, et vers la technologie, en automatisant autant la routine que possible.