Gestion de projet : Dans l’usine de composants

Moi.

Publicité

Parfois, les gens me demandent ce qu’il y a de si mauvais dans le développement de fonctionnalités. Il n’y a rien de mal à cela s’il y a quelqu’un qui veut et a besoin de ces fonctionnalités. Mais est-ce réellement le cas dans votre propre travail ? Ceci est à peine perceptible dans la proverbiale fabrique de fonctionnalités. Pour beaucoup de gens, cela ne semble pas normal de produire des billets que des tiers jugent utiles. Évaluer la valeur de votre travail peut être difficile pour de nombreuses raisons. Une raison : vous ne travaillez pas sur un produit, mais sur un composant d’un produit.

J’aime utiliser le développement (vision simpliste) d’une voiture comme exemple. Supposons que le développement se déroule en trois équipes : une pour le moteur, une pour la carrosserie et une pour le châssis. Si chaque équipe fait juste son propre travail et que la voiture complète n’est visible nulle part, il ne s’agit pas réellement de développement automobile. Dans chacune des trois revues, seuls des composants individuels sont visibles et ils ne résolvent pas le problème initial (« Amener les gens de A à B »). Vous ne pouvez pas non plus demander aux acheteurs (de voitures) comment ils trouvent le statut de la voiture.

Pour les parties prenantes internes de l’entreprise intéressées par la voiture, cela signifie qu’elles doivent passer par trois examens et faire preuve d’un peu d’imagination pour intégrer mentalement les composants.

Je trouve cette façon de travailler tellement absurde que je pense toujours que les entreprises ont dépassé ce stade depuis longtemps. Dans le contexte agile, les frameworks de mise à l’échelle s’entraident pour éviter, entre autres, le scénario décrit. Cependant, je rencontre encore des équipes de composants isolées. La question se pose alors : que puis-je faire en tant que membre d’une telle équipe pour sortir du silo ?

Voici quelques suggestions éprouvées :

D’abord. Accédez aux revues ou réunions similaires des autres équipes composantes. Si vous devez franchir des limites de silos soigneusement construites (c’est-à-dire les limites de département/équipe), votre sensibilité est requise. Il peut arriver que d’autres personnes soient irritées. Dans un tel cas, je demande d’abord poliment si je peux écouter. C’est plutôt bien. Je ne rencontre que très rarement un rejet.

Il est également bon de prêter attention à la manière dont les équipes ont été coordonnées jusqu’à présent. Qui transporte l’information d’un côté à l’autre ? Qui découpe les tâches en tickets composants ? De nombreux rôles sont ici remis en question. Peut-être que le propriétaire du produit ou un architecte logiciel le fait ? Parlez à cette personne pour éviter de lui marcher sur les pieds !

Dans un deuxième temps, vous pouvez inviter des collègues des autres équipes du composant à votre révision. Cela peut alors provoquer une irritation parmi votre propre peuple. Là aussi, il est utile de préparer le terrain en amont. Dites à vos coéquipiers que vous aimeriez avoir des retours des équipes voisines lors de l’examen.

Une fois les deux comportements acceptés, l’étape suivante consiste à essayer d’organiser ou d’être invité à une réunion où vous pourrez admirer le produit complet et intégré. Dans de nombreux cas, cela existe déjà car, après tout, quelqu’un doit faire l’intégration. S’il existe un service d’assurance qualité, un service de test ou similaire, c’est une bonne idée de se renseigner sur leur travail. C’est peut-être là que se produit l’intégration.

Dans de rares cas, j’ai constaté qu’il n’y avait pas d’intégration appropriée pendant le développement. Le plan était que l’intégration n’aurait lieu que lorsque tous les composants seraient prêts. L’accent a été mis sur le travail sur les interfaces et les équipes de composants ont testé exclusivement sur des interfaces simulées pendant très longtemps. J’espère que c’est l’exception.

Conclusion

Avec un peu de chance, cet article de blog n’intéressera personne. Cependant, je suis étonné de voir qu’il existe encore des entreprises dans lesquelles plusieurs équipes travaillent sur un produit ou un service sans que les membres de l’équipe puissent avoir leur propre (!) expérience de l’ensemble du produit sur lequel ils travaillent. Mais personne ne doit attendre la prochaine réorganisation de l’entreprise.

Ne restez pas seul dans votre équipe, construisez votre réseau interne d’entreprise et échangez avec les autres équipes ! Ce n’est pas seulement le développement de produits qui en bénéficiera. Vous vous sentez également beaucoup mieux lorsque vous faites l’expérience de votre propre contribution dans le contexte du produit intégré.

(moi)