Pourquoi les «équipes» des services partagés ne fonctionnent pas avec agilité
0 0
Read Time:4 Minute, 25 Second


Tiré dans trop de directions Signes Anxiété de stress
Un de mes clients souhaite utiliser des «équipes» de services partagés pour amorcer sa transformation agile. Leurs développeurs travaillent sur un produit pendant des mois et des années à la fois.

Cependant, les testeurs et les utilisateurs de l’interface utilisateur font partie de groupes de personnes. L’organisation appelle ces testeurs et ces personnes de l’interface utilisateur des «services partagés».

La réflexion sur les services partagés nie la réalité d’un développement de produit efficace:

Une équipe interfonctionnelle apprend ensemble tout en développant le produit.

Sans cette équipe interfonctionnelle, les personnes, le produit et l’organisation souffrent de diverses manières:

  • Ni les testeurs ni les utilisateurs de l’interface utilisateur n’apprennent tout ce dont ils ont besoin sur un produit.
  • Les développeurs ne réalisent pas ce dont les testeurs ou les utilisateurs de l’interface utilisateur ont besoin pour être efficaces.
  • Tout le monde attend les autres. Les développeurs attendent les utilisateurs de l’interface utilisateur. Les testeurs, lorsqu’ils se mettent enfin au travail sur le produit, attendent que les développeurs répondent à leurs questions.
  • Les clients attendent quelque chose d’utile.
  • L’organisation se demande pourquoi personne ne peut «respecter» un délai.

L’organisation vit avec de nombreux retards lorsque les gestionnaires choisissent un modèle de services partagés. (C’est parce que les gestionnaires pensent que l’efficacité des ressources fonctionne. Ils ne réalisent pas à quel point l’efficacité des flux est plus efficace.)

Ils pensent économiser de l’argent avec un pool de testeurs et un pool de personnes UI. Ils perdent du temps, ce qui coûte beaucoup plus que les coûts salariaux.

Les approches agiles brisent l’idée d’un modèle de «service partagé» des personnes.

Avant de recommander des alternatives, permettez-moi d’examiner pourquoi les gestionnaires bien intentionnés pensaient que les «services partagés» fonctionnaient.

Pourquoi les gestionnaires pensaient que les services partagés fonctionnaient

Vous vous souvenez du cycle de vie en série, avec un seul livrable à la fin du projet?

Les gestionnaires pensaient que les cycles de vie en série fonctionnaient. Même si les gestionnaires avaient ces données:

  • De nombreux cycles de vie de phase-gate permettaient des phases glissantes. Une équipe peut passer de l’analyse à la conception et même au codage sans finition la phase précédente.
  • Même lorsque les développeurs ont dit qu’ils avaient «fini» avec le projet précédent, certains développeurs «sont restés en arrière» pour travailler avec les testeurs pour finir de résoudre les problèmes.
  • Les projets n’étaient pas «terminés» lorsque l’équipe a dit qu’ils étaient terminés. Parfois, il y avait tellement de problèmes que toute l’équipe – développeurs et testeurs et toute autre personne dont ils avaient besoin – a fini de résoudre les problèmes.

Les gestionnaires n’ont pas calculé leur coût du retard. Ils n’ont mesuré aucun élément ni aucune chaîne de valeur du projet.

Les gestionnaires n’ont examiné que les dépenses salariales.

Si vous regardez les coûts salariaux, les «services partagés» semblent être un excellent moyen d’économiser de l’argent. Les «services partagés» sont un exemple de réflexion sur l’efficacité des ressources qui semble permettre d’économiser de l’argent.

Cependant, parce que le flux de travail prend tellement de temps, nous sommes beaucoup moins efficaces et le développement de produit est beaucoup plus coûteux. Nous sommes moins efficaces – et moins efficients.

Je ne connais aucun moyen de conserver les «services partagés» et de passer à des approches agiles. Cependant, je connais plusieurs alternatives efficaces aux «services partagés».

Alternatives efficaces à la réflexion sur les «services partagés»

Mes options de réflexion sur les «services partagés»:

  • Créez des équipes interfonctionnelles qui travaillent sur un seul produit à la fois. Vous pourriez avoir besoin d’équipes plus importantes que je ne le recommande normalement (4 à 6 personnes). Quoi que vous fassiez, créez l’équipe du produit.
  • Gardez les équipes sur leur seul produit pendant trois mois au minimum. Pourquoi trois mois? Ainsi, les gens apprennent à travailler ensemble et ainsi tout le monde apprend l’intérieur du produit.
  • Réduisez le WIP (Work in Progress) de l’organisation en gérant le portefeuille de projets. (Voir Gérer votre portefeuille de projets.)

Lorsque vous effectuez ces actions, vous verrez plusieurs effets:

  • Les gens seront beaucoup plus engagés.
  • L’équipe pourra peut-être prédire quand elle pourra livrer.
  • Vous aurez plus de facilité à gérer le portefeuille de projets.
  • Vous ne verrez peut-être pas cela au premier trimestre, mais finalement, le coût de développement et de maintenance de vos produits diminuera.

Oui, lorsque vous modifiez votre gestion, vous constaterez une meilleure efficacité des flux.

Que faire si quelqu’un souhaite conserver les «services partagés»?

N’utilisez pas une approche agile.

Cependant, je ne recommande à personne d’utiliser une approche de «services partagés» pour tout développement de produit. Vous pourrez peut-être utiliser des «services partagés» dans un groupe de travail orienté services. Ne l’utilisez pas pour le développement de produits.

Que fait mon client potentiel? Pensée. Et mesurer leurs différentes chaînes de valeur. (Voir Créer du temps pour la collaboration pour une carte de flux de valeur qui pourrait être similaire à une carte de «services partagés».)

Les «services partagés» ne fonctionnent pour aucune approche agile. Cela ne fonctionne pas pour le développement de produits. Dans n’importe quelle culture ou cycle de vie.

Vous voulez en savoir plus sur les raisons pour lesquelles les «services partagés» ne font pas ce que vous voulez? Lisez les moyens pratiques de diriger une organisation innovante.

Average Rating

5 Star
0%
4 Star
0%
3 Star
0%
2 Star
0%
1 Star
0%

Laisser un commentaire