On construit souvent les équipes en fonctions des projets et des applications qu’elles doivent piloter ; l’organisation choisie reflète ainsi les “activités” que doivent réaliser ses équipes.
Qui ne s’est ainsi pas retrouvé dans une équipe mélangeant des activités de maintenance (RUN), d’évolutions (BUILD) et d’assistance utilisateur diverses avec des plannings, des urgences et des cycle de vie complètement différents et parfois contradictoires ?
Un bonus est que parfois s’ajoute un besoin de suivre chaque activité de manière bien dissociée lors du pointage provoquant une saisie des temps complexe répartie sur de nombreuses lignes, sans compter les contributions ou interventions sur d’autres sujets…
Les projets se font alors concurrence pour les ressources et vampirise la maintenance ou inversement, les incidents de production dictent l’avancement des travaux.
S’organiser = construire le système
Cela pose deux principaux problèmes, le premier touche à la structuration du système d’information. Il faut pour cela connaître la Loi de Conway : « les organisations qui conçoivent des systèmes […] tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation. ».
Ainsi en séparant ou regroupant des outils, projets sans y intégrer une logique de construction visant à produire de la valeur pour l’entreprise, vous allez complexifier votre SI et aller à l’encontre d’une efficacité future. Si vous séparer le passage de commande, de la gestion des stocks et la relation client vous aller inévitablement créer des silos qui implémenteront des interfaces de communications de plus en plus complexes et tout cela sans vision de bout en bout pour les acteurs : chacun optimisera son près carré.
Pour mieux servir vos clients il faut penser à une vision de bout en bout et identifier les chaînes de valeur que vous voulez piloter, indépendamment des “directions” ou “services”. Cela ne les supprimera pas mais vos indicateurs devront aller vers un pilotage des bons objectifs (par exemple via la méthode OKR).
Définir sa notion de “produit”
Le deuxième enjeu est de définir un périmètre de responsabilité aux équipes qui soit cohérent avec la stratégie de l’entreprise. En IT le mode produit doit donc fixer comment vos équipes vont se structurer et qui sera responsable de quoi (périmètre fonctionnel). Un produit sera ainsi souvent constitué d’une équipe pluridisciplinaire (avec des compétences informatique et fonctionnelle).
Un produit IT ce N’est PAS une application ou une technologie : un produit regroupe des fonctionnalités cohérentes, plusieurs applications ou modules d’application (souvent très dépendantes) pour apporter un service à l’utilisateur cible (ou client), il peut ainsi comporter diverses technologies nécessaires au bon fonctionnement de ce service.
Un produit ce N’est PAS une organisation hiérarchique ou un projet : un produit n’a pas de périmètre ou de délai fixes, il évolue avec la marché pour apporter de la valeur à l’entreprise.
Par exemple : Pour obtenir un nouveau serveur il faut parfois faire des demandes à 4 ou 5 services différents (stockage, ouverture de flux, base de données, sécurité, etc..) qui eux-mêmes vont se faire des demandes entre eux, s’attendre mutuellement de sorte à ce que vous ne saurez pas forcément quand vous aurez l’ensemble des éléments pour commencer à travailler. L’idée pourrait être de regrouper ce besoin dans un produit en charge de fournir un service de bout en bout d’approvisionnement en serveur pour les équipes de développement.
Il faut être vigilant à ce que le produit IT rende un service spécifique et autonome, afin que si il évolue, les impacts sur les autres composants du système soit réduit et maîtrisé.
Vous pouvez à terme parvenir à identifier des progiciels qui couvrent plusieurs produits, mais cela n’est pas un problème, au moins vous éviterez de le voir comme un “bloc monolithique” et vous pourrez évaluer la qualité de service selon des critères cohérent avec les enjeux de votre entreprise.
Animer son produit IT agile
Vous pourrez ensuite constituer la liste des travaux à exécuter en menant un découpage et une priorisation par la valeur des fonctionnalités et tâches demandées. Le fil conducteur devant toujours être la valeur produite pour optimiser le ROI et savoir renoncer à des besoins ou demandes si d’autres sujets sont plus pertinents.
Dans un cas on suit le triptyque “cout-qualité-délai” (comme 3 indicateurs basiques de résultat) dans l’autre on se focalise sur “valeur-qualité-contraintes” : mesure de la valeur produite selon la qualité attendue avec des contraintes pour arbitrer et prioriser.
La participation des équipes métiers et des utilisateurs est comme toujours en agilité un facteur clé de réussite.
Si vous souhaitez en savoir plus comment mener votre transformation, n’hésitez pas à nous contacter.