Au sein des DSI, la fonction de Contract Manager a fait ses preuves au cours de ces dernières années.
Suite à la période particulière que nous avons traversé et les conséquences sans précédents observées durant ce printemps 2020, son importance s’est vue décuplée. Ce besoin croissant au sein des DSI peut s’expliquer notamment par certains des questionnements soulevés par Lahcen Elouahi, Senior Manager de Rhapsodies Conseil, lorsqu’il aborde l’impact du télétravail sur les contrats de Soucing IT.
Entre autres :
Comment modifier ses contrats de sourcing pour tenir compte du mode de travail à distance ?
Comment optimiser les coûts de support dans un contexte de travail mixte : sur site et à distance ?
Quels indicateurs de performance, modèle de gouvernance et outillages faut-il mettre en place ?
Comment auditer et faire évoluer ses Contrats IT ?
Partant de la pertinence de ces interrogations, et de la nécessité d’y apporter une réponse adéquate, il est légitime de se demander qui serait le mieux placé au sein de son organisation pour mener à bien les actions attendues ?
Au vu du sujet de cet article, la question est évidemment rhétorique. Cependant, apporter la réponse n’est pas si évident, et de nombreuses entreprises ne parviennent pas à tirer profit du Contract Management. Cette difficulté réside dans la transversalité des sujets concernés, impliquant de fait de nombreux métiers et acteurs de l’entreprise.
Dès lors, il me semble intéressant de comprendre l’origine de la complexité attachée au positionnement du Contract Manager, pour chercher ensuite comment l’intégrer intelligemment au sein d’une organisation.
Comprendre l’origine
Le rôle de la nomenclature des métiers du CIGREF est de rationaliser les métiers de l’IT. La version 2018 de ladite nomenclature a fait ressortir une nouvelle famille de métier, dénommée « Relations Fournisseurs », au sein de laquelle la fonction de Contract Manager (ou « Manager de Contrat » en français) a été déplacée aux côtés de celles de l’Acheteur IT, du Software Asset Manager et du Vendor Manager.
Toutefois, la réalité démontre qu’il est très compliqué de standardiser le rôle et les responsabilités du Contract Manager. Ceci étant dû tant à l’histoire de la fonction, qu’à sa terminologie et/ou à son positionnement. Initialement étranger au secteur informatique, le métier de Contract Manager trouve ses origines dans l’univers du BTP durant les années 1990. Il fait alors partie de ces postes « reflexes » créés en réaction à une action, une inaction ou un besoin inattendu. Dans ce cas précis, le Contract Manager devait répondre à l’émergence de Claims Managers. Ces derniers avaient pour objectifs de maximiser les gains financiers potentiels des contrats dont ils avaient la charge en usant de tous les leviers contractuels disponibles, et ce au détriment de la relation commerciale.
La mission du Contract Manager consista dès lors à s’approprier la gestion du contrat, en privilégiant l’équilibre contractuel et le dialogue nécessaire à une relation commerciale saine. Les Contract Managers sont parvenus à s’approprier le Cycle de Vie Contractuel en liant la théorie juridique, la pratique opérationnelle, l’aspect commercial et les impératifs du contrôleur de gestion.
La combinaison de l’ensemble de ces compétences en fit une fonction transverse. La gestion des risques contractuels fut ainsi simplifiée et entraina une maîtrise efficace et collaborative des cocontractants. Néanmoins, ce métier resté discret en France au cours des années 2000, souffre encore aujourd’hui de sa dénomination anglaise mal perçue par les sociétés et directions françaises. C’est ainsi que l’on retrouve couramment des « Gestionnaires de Contrats » (ou de bases de données contractuelles) dénommés « Contract Manager », chargés de la duplication de documents contractuels, ou de la référenciation massive des contrats. En réalité, leur rôle se rapproche davantage d’un poste de Paralégal ou d’Assistant Administratif. Dans la mesure du possible, cette situation doit être évitée au risque de ne pas rattacher le niveau de compétences adéquat à des missions essentielles.
Au-delà de la terminologie, le Contract Manager souffre également de son positionnement au sein des DSI françaises. Comme cela a été évoqué précédemment, le Contract Manager constitue la pierre angulaire entre quatre métiers essentiels : les juristes (Direction Juridique), les acheteurs (Direction des Achats), les opérationnels (Direction des Opérations) et les contrôleurs de gestion (Direction Financière). Les entreprises fonctionnant majoritairement en silo, la fonction transverse que représente le Contract Manager se voit régulièrement rattachée hiérarchiquement à l’une des quatre directions susmentionnées. Les conséquences ne sont pas anodines, et le profil des Contract Managers se retrouve forcément impacté.
Ainsi, certaines organisations vont faire valoir au Contract Managament une prédominance du métier d’Acheteur, tandis que d’autres organisations pourront décider de recourir majoritairement aux compétences juridiques, et d’autres encore préférer y rattacher les missions d’un Service Delivery Manager.
L’intégration d’une cellule de contract management
Lors de la construction d’une cellule de Contract Management au sein de votre DSI, c’est une réalité qu’il est impératif de prendre en compte. Il est pertinent de se demander en autre :
Quels sont les objectifs recherchés ?
Quelles sont les performances supplémentaires attendues ?
Quelle typologie de risques m’affecte le plus ?
Quels outils et processus peuvent-être adaptés, modifiés, optimisés ?
La réponse à ces questions stratégiques permet la création d’un RACI pertinent et adéquat dont il ressort généralement une typologie de « profil de Contract Manager ». Cette information est clef dans la construction, le rattachement et donc le positionnement du Contract Management. Chaque situation étant spécifique, il n’y a pas de mauvaise solution. En revanche, une cellule de Contract Management correctement positionnée, bénéficiant d’un maximum de rôles et responsabilités transverses, permettra non seulement d’éviter de nombreux travers et points de blocages, mais aussi d’assurer une gestion des risques et des fournisseurs performants.
Les autres articles qui peuvent vous intéresser
13 janvier 2025
Pilotage & Performance Opérationnelle et Contractuelle
Dans le contexte actuel, quelle organisation n’a pas pour objectif “d’être plus agile” ? Être plus agile, la clé du succès ? Oui, mais comment y parvenir ?
Agile … is an attitude, not a technique with boundaries. An attitude has no boundaries, so we wouldn’t ask “can I use agile here”, but rather “how would I act in the agile way here?” or “how agile can we be, here? »
Alistair Cockburn
En traduction synthétique « L’Agilité, c’est un état d’esprit pas seulement des pratiques ! ». D’expérience, nous savons qu’appliquer un framework agile ou utiliser des outils estampillés agiles (JIRA, Trello…) ne sont aucunement une garantie que vous allez évoluer vers un état d’esprit agile. La notion d’état d’esprit renvoie à la complexité humaine, une complexité qui se caractérise par un grand nombre d’éléments en relation d’interdépendance et sans coordination centrale. Pas facile de s’y retrouver… sauf si nous utilisons la pyramide de Dilts. C’est un modèle que je trouve très pertinent pour structurer ces éléments et mettre en évidence leur relation.
Mais avant d’utiliser ce très beau modèle (mini teasing, il va falloir patienter encore un peu), revenons-en à notre objectif, à cet état d’esprit agile que l’on vise. (car nous savons que « Tout objectif flou conduit irrémédiablement à une connerie précise. » Anonyme)
Pour clarifier notre objectif, commençons par le sens des mots :
1. Qu’est ce qu’un état d’esprit ?
C’est un état mental qui agit comme un filtre dans nos désirs et nos interprétations, nous prédisposant ainsi à penser, à parler et à agir d’une certaine manière.
Exemple : Avant le démarrage d’une compétition, le sportif se plonge souvent dans un état d’esprit de grande certitude. Les imprévus pendant la compétition généreront ainsi moins de doutes en lui, trop de doutes pouvant impacter négativement sa motivation ou lui faire perdre sa concentration.
Au contraire, entre chaque entraînement, le sportif pourrait adopter un état d’esprit de curiosité et de remise en question. Le doute sera dans ce cas-là une ressource positive pour le sportif, lui permettant d’envisager de meilleures solutions pour améliorer son entraînement.
Cet exemple souligne combien il est important d’adapter son état d’esprit en fonction de la situation et des objectifs que l’on poursuit. Si vous n’en êtes pas encore intimement persuadés, je vous suggère de regarder le TedX Change your mindset, change the game | Dr. Alia Crum.
Une seconde question nous vient alors tout naturellement
2. Qu’est-ce qu’un état d’esprit agile ?
Si nous associons l’Agilité au manifeste du développement agile de logiciels, nous pouvons dire que dans ce cas-là, l’état d’esprit agile recherché serait d’être prédisposé à penser, à parler et à agir en cohérence avec les 4 valeurs et 12 principes de ce manifeste.
On peut bien entendu étendre notre définition aux 5 valeurs et aux 3 piliers de Scrum (si l’on utilise ce framework)
ou au triptyque : build the right thing, build the thing right, build it fast
ou à quelque autre concept que l’on associe à de l’agilité. Il n’y a pas une seule bonne réponse de ce qu’est un état d’esprit agile.
La bonne question à se poser pour trouver la définition de l’état d’esprit agile que vous recherchez est :
3. Pourquoi développer cet état d’esprit agile ?
Effectivement, avant la question du « comment », posons-nous la question du « pourquoi » (<- j’ai Simon Sinek qui me le chuchote constamment à l’oreille depuis que j’ai vu son TedX Simon Sinek – Comment les grands leaders inspirent l’action )
Globalement, nous pouvons voir l’agilité comme une réponse au contexte VICA : Volatile, Incertain, Complexe, et Ambigu (VUCA en anglais), qui devient de plus en plus une norme dans le monde de l’entreprise.
Si nous voulons développer un état d’esprit agile, c’est parce nous voulons nous doter de la capacité de penser et d’agir de façon adaptée et performante dans ce contexte.
Prenons un exemple en utilisant comme guide de réflexion l’une des 4 valeurs du manifeste du développement agile de logiciels : “les individus et leurs interactions plus que les processus et les outils”. Si vous êtes dans un contexte changeant, alors les processus et les outils qui ont tendance à figer le système, sont une barrière à votre adaptation. Vous devez alors porter votre attention aux individus et aux interactions qui leur permettent de s’adapter au contexte. Dans ce cas, un état d’esprit agile est primordial.
Maintenant, si vous êtes dans un environnement avec une faible variabilité (pas VICA), il y a de fortes chances de gagner plus rapidement en performance en travaillant sur l’axe des processus et des outils plutôt qu’en travaillant sur l’axe des individus et interactions. Ce serait là un état d’esprit moins agile mais qui serait pertinent vis à vis du contexte.
A travers cet exemple quelque peu provocateur pour l’agiliste convaincu que je suis, je veux montrer qu’il vous faut adopter un état d’esprit plus ou moins agile selon le contexte. Tout comme pour notre sportif, un état d’esprit de grande certitude est bénéfique en phase de compétition mais est néfaste en phase d’entraînement.
Après avoir mûri notre réflexion sur l’état d’esprit que l’on recherche (un état d’esprit adapté à notre contexte), nous pouvons passer à :
4. Comment favoriser l’émergence de l’état d’esprit recherché ?
C’est le moment d’introduire la pyramide de Dilts. Ce modèle se compose de 6 niveaux qui se superposent avec une gradation des aspects les plus concrets en bas aux aspects les plus abstraits en haut.
Note : le « nous » dans les questions peut faire référence aussi bien à un individu qu’à une équipe ou une organisation (<- une pyramide multi usages, cool, non ?). Chaque niveau a une influence sur tous les autres mais il reste plus étroitement lié au niveau qui est juste en dessous et juste au-dessus de lui.
Pour mieux saisir les relations entre les niveaux successifs, prenons un exemple : Imaginons une équipe qui passe de la responsabilité de maintenir un produit en fin de vie à celle de développer un nouveau produit. Nous sommes dans le cas d’un changement au plus haut niveau de la pyramide, au niveau du sens (mission).
L’équipe va naturellement se poser la question de ce qu’elle doit modifier dans son mode de fonctionnement pour s’adapter à cette nouvelle mission.
Nous allons répondre à cet enjeu en utilisant la structure du modèle de Dilts par un questionnement à chaque niveau :
Etape 1 – niveau sens :
Quel est le changement au niveau du sens (mission) ? Quelle est votre nouvelle contribution à quels nouveaux clients / utilisateurs ? (pour notre exemple, l’équipe a une nouvelle mission qui est de développer un nouveau produit pour des utilisateurs X)
Etape 2 – au niveau identité :
Quels sont les aspects de votre rôle que vous aviez qui ne sont plus en phase avec votre nouvelle mission ?
Quel est le nouveau rôle que vous devez jouer pour apporter des résultats plus en phase avec votre nouvelle mission ?
Etape 3 – A partir du nouveau rôle qui a été identifié, nous procédons aux mêmes questions avec le niveau inférieur, le niveau des valeurs et croyances :
Quelles sont les valeurs et les croyances que vous aviez adoptées qui ne sont plus en phase avec ce nouveau rôle ?
Quelles sont les valeurs et les croyances que vous devez adopter pour être plus performant dans ce nouveau rôle ?
Et nous descendons ainsi de suite sur tous les niveaux jusqu’au niveau le plus bas qui est l’environnement.
Ce déroulé de questions par niveaux successifs va faire ressentir à l’équipe la nécessité d’un alignement, d’une cohérence, d’une « relation + / + » entre tous les niveaux pour obtenir la contribution la plus efficace au niveau de sa nouvelle mission.
Si nous n’avions pas utilisé ce questionnement structuré sur les niveaux de la pyramide, il est probable que l’équipe ait répondu sur des modifications à faire au niveau des capacités, des comportements et de l’environnement (par ex : passage de Kanban à Scrum et colocalisation avec l’équipe métier) mais pas au niveau des valeurs et croyances et de l’identité. On peut imaginer que l’équipe devra délaisser un état d’esprit orienté efficience et process (qu’elle avait adopté pour maintenir un produit en fin de vie) pour aller vers plus de souplesse et de priorité aux interactions dans le développement du produit avec l’équipe métier.
Une autre clé de compréhension de la pyramide de Dilts est que l’influence entre les niveaux est plus importante dans le sens descendant que dans le sens montant. De fait, il est souvent préférable de régler un problème qui se situe à un niveau par un changement au niveau supérieur. Par exemple, si vous observez que le Product Owner transforme les daily meeting en séance de reporting (problème au niveau des comportements), l’exclure du daily meeting (solution au niveau des comportements) va sûrement transférer le problème ailleurs (il viendra solliciter l’équipe pour du reporting à d’autres moments que le daily). La solution est peut-être à trouver sur les niveaux supérieurs, comme au niveau des capacités en renforçant le management visuel ou au niveau de l’identité (un product owner n’est pas la traduction de chef de projet en anglais !).
Je vous propose un dernier exemple qui montre l’importance de la cohérence entre les 6 niveaux logiques.
Avant ma bascule dans le domaine de l’Agilité, je travaillais dans une entreprise où les départements collaboraient peu efficacement entre eux. Une année, le PDG se décide à prioriser dans les objectifs l’amélioration de la collaboration entre départements (notamment évolution du rôle et des responsabilités et donc du niveau identité) au service d’une plus grande performance collective (niveau sens). Il fait une annonce à ce sujet et une formation est dispensée au plus grand nombre afin d’accompagner ce changement. C’est une formation qui met en avant des principes comme « nous sommes tous des clients internes », « les optimums locaux ne font pas un optimum global »,etc. Le but était de changer le niveau des croyances et des valeurs afin qu’elles soient plus en phase avec le changement désiré au niveau identité (collaboration) et au niveau sens (performance collective). Cette formation n’a aucun effet durable car les autres niveaux (environnement, comportements, capacités) ne sont pas alignés et propices à cette plus grande collaboration. Tous les collaborateurs de l’entreprise ont des objectifs individuels. Chaque département a ses propres objectifs qui peuvent être quasiment en conflit avec ceux des autres. Chaque équipe déjeune séparément des autres. Les éléments que je viens de citer ont une rétroaction beaucoup plus forte que l’action de la formation, le système revient à l’équilibre. Ce fut une belle démonstration des interactions fortes entre les niveaux de la pyramide de Dilts et du principe d’homéostasie.
Conclusion
En synthèse, voici l’articulation des réponses que je vous propose à notre problématique initiale “Comment être vraiment agile avec la pyramide de Dilts ?”
L’agilité n’est pas une finalité en soi. Analyser d’abord votre contexte (notamment sur son aspect VICA) et les objectifs poursuivis par votre organisation afin d’identifier quel est le niveau d’agilité le plus pertinent à mettre en place
On peut être vraiment agile à condition que notre état d’esprit soit agile. Préciser donc les caractéristiques de l’état d’esprit qu’il vous faut adopter (notamment en fonction du niveau d’agilité défini précédemment).
Analyser chacun des niveaux de la pyramide de Dilts afin de définir les incohérences et manques qui empêchent l’atteinte de cet état d’esprit et qui freinent votre performance dans votre mission (niveau du “sens”, niveau le plus haut de la pyramide)
Définissez les actions qui pourraient être entreprises pour commencer à faire évoluer chacun des niveaux dans la direction souhaitée et les prioriser
Mettez en oeuvre ses actions et vérifier leur efficacité dans la poursuite de ce nouvel état d’esprit
Observez les changements d’état d’esprit opérés et assurez vous qu’ils ont un impact positif sur vos performances
Bravo ! Félicitez-vous ! Vous avez accompli un beau chemin. Vous pouvez maintenant itérer en revenant à l’étape 4) ou challenger le tout et revenir à l’étape 1)
C’est un bravo sincère sur cette étape 7) car l’utilisation de la pyramide de Dilts nécessite de l’humilité et une vraie volonté de remise en cause (qui aime révéler ses incohérences ?) pour être pleinement performante. Ce travail sur les blocages et les incohérences entre les 6 niveaux du modèle va fluidifier et aligner l’état d’esprit et l’action sur la mission. C’est un chemin qui va libérer tous les potentiels de votre organisation !
Vous avez des APIs pour interconnecter les systèmes ? Parfait c’est une belle première étape. Asseyons-nous maintenant pour parler de résilience et de découplage… Une nouvelle étape s’ouvre : les APIs Asynchrones ? Mais quelle obscure clarté, quelle douce violence est-ce donc que cela ??
Un petit récap, pourquoi parler d’APIs asynchrones ?
Le sujet des APIs asynchrones résonne depuis quelques années dans la tête des architectes, et ces derniers en font de plus en plus un de leurs objectifs : une API, donc un contrat d’interface bien défini, qui s’affranchit des défauts des APIs. Comme disait le sage Bruno dans son article : “Favoriser l’asynchronisme est un bon principe de conception de flux”.
Ce besoin d’éviter un couplage fort et de créer des SAS de décompression entre les différentes applications / parcours est certainement cohérent, mais est à priori en contradiction avec la nature même des API et du protocole HTTP. Alors comment concilier le meilleur de ces deux mondes ?
Commençons par les bases, une API asynchrone, concrètement, c’est quoi ?
Une API asynchrone est une API recevant, par exemple, la commande d’un client, client qui n’attend pas la réponse de celle-ci dans l’immédiat. Le seul retour mis à disposition par l’API, dans un premier temps, est la prise en compte de la demande (un « acknowledgement » : vous avez bien votre ticket, merci d’attendre).
Le fournisseur d’API effectue les actions nécessaires pour satisfaire la requête, sans forcément être contraint par des timeouts, en gros il peut prendre son temps pour en garantir la bonne exécution.
Et dans la pratique ?
En pratique, cette architecture peut être garantie par le couple API qui poste dans une queue / topic assurés par un outil de type MOM.
L’API déverse les informations dans une queue (ou topic) du MOM, informations qui sont ensuite prises en compte suivant les disponibilités des applications en aval. L’application appelée devient un consommateur d’un flux asynchrone, ce qui permet de découpler les deux.
Pour notifier, ça passe crème
Ce type de comportement est facilement mis en place lorsque nous nous trouvons dans des cas de figure non critiques, dans lesquels par exemple on doit notifier un utilisateur LinkedIn de l’anniversaire d’un de ses contacts : en tant que client, tant pis si l’information n’arrive pas, nous pouvons accepter un manque de fiabilité.
Un peu moins quand l’objectif porte sur un échange critique
Tout change quand le demandeur s’attend à quelque-chose, soit une information soit une confirmation forte de la livraison de l’information , car cet aspect demeure crucial pour son bon fonctionnement. Dans une API synchrone, nous l’obtenons à la fin de la transaction.
Dans le cas asynchrone, comment garantir le même comportement lorsque la transaction se termine ?
C’est à ce niveau que les avantages de l’asynchronisme induisent une complication de gestion, complication dont souvent les équipes n’ont pas conscience. Une confirmation de réception (“acknowledgement”) est dans ces cas insuffisante (ex. votre transaction bancaire s’est bien passée, comme par exemple un virement).
Mais alors comment notifier le client du résultat ?
La mise en place d’une logique de réponse peut être construite de deux façons différentes.
En mode PULL
Le mode pull présuppose que l’action soit toujours à l’initiative du client.
L’API met à disposition le statut de l’action (sous forme de numéro de suivi), sans notifier le client. C’est au client de venir vérifier le statut de sa demande, en faisant des requêtes de suivi à des intervalles réguliers.
En mode PUSH
Le mode push suppose que le canal de communication soit ouvert dans les deux sens, et que le serveur ne soit pas forcément tenu d’attendre une requête du client pour “pousser” l’information.
Certaines technologies et patterns d’architecture, permettent de mettre en place ce mode de communication, pour citer les plus connus :
Le protocole websocket permettant l’ouverture de canaux pour établir une communication bidirectionnelle entre serveur et client,
Les mécanismes de CallBack et Webhooks,
Les constructions réalisées avec des MOMs, basées sur des queues / topics d’aller et d’autres de retour, qui se traduisent en patterns request / reply implémentés par certains de ces outils,
Basés sur des solutions similaires au précédent point, des patterns d’architecture custom permettant de gérer ces aller-retours entre applications.
Les patterns schématisés ci-dessous ne sont pas exhaustifs mais ont pour objectif de montrer des exemples réels de contraintes, en termes de flux, apportées par les trois modes : synchrone, asynchrone pull et asynchrone push.
Synchrone
Asynchrone Pull
Asynchrone Push
Mais alors, push ou pull ?
L’utilisation d’un pattern par rapport à l’autre doit être réfléchie, car donner un avis tranché sur la meilleure solution est assez compliqué sans connaître l’environnement et les contraintes. Les deux techniques sont fondamentalement faisables mais le choix dépendra du besoin réel, des patterns supportés par les socles déjà déployés et des applications difficilement intégrables en synchrone.
Notre avis est d’éviter au maximum les solutions pull, car ces méthodes impliquent des aller-retour inutiles entre les applications.
Comment mettre du liant entre aller et retour ?
La mise en place d’une API asynchrone présuppose donc une certaine attention à l’intégrité fonctionnelle entre la requête et la réponse, qui ne sont pas, dans le cas de l’asynchronisme, forcément liées par la même transaction.
Pour garantir l’intégrité fonctionnelle et le lien entre la requête et la réponse, surtout dans le cas d’une notification PUSH, un échange d’informations pour identifier et coupler les deux étapes est nécessaire. L’utilisation d’informations spécifiques dans l’entête des requêtes, comme dans le cas d’APIs synchrones, est une solution performante, tout en s’assurant d’avoir mis en place les bonnes pratiques de sécurité visant à éviter l’intrusion de tiers dans la communication. Sans vouloir réinventer la roue, les mécanismes déjà en place pour d’autres technologies peuvent être repris, comme par exemple les identifiants de corrélation, chers au MOMs, identifiants qui permettent de créer un lien entre les différentes communications.
Si on utilise des mécanismes non natifs aux API, pourquoi passer par une API et pas par un autre moyen asynchrone ?
Le choix de passer par une API a plusieurs raisons, suivant le cas d’usage :
c’est le standard actuel auquel la plupart des solutions ont adhéré, avec un fonctionnement API first même si le besoin est asynchrone
l’éventuelle gestion par API gateway, rendue possible sur une construction asynchrone par cette solution, demeure très pratique pour la gestion des échanges, avec des avantages que les protocoles / solutions asynchrones classiques ne sont pas prêts d’intégrer
Cela ne limite pas pour autant le spectre d’APIs asynchrones au seul HTTP. Bien que le standard OpenAPI soit fortement focalisé HTTP, d’autres standards ont été conçus expressément pour les cas d’usage asynchrone.
Exemple, la spécification AsyncAPI. Cette spécification se veut agnostique du protocole de communication avec le serveur, qui peut être du HTTP, mais également du AMQP, MQTT, Kafka, STOMP, etc. standards normalement employés par des MOMs.
Conclusion
En conclusion, notre conviction est que l’asynchronisme est vraiment la pièce manquante aux approches API. L’APIsation a été un formidable bond en termes de standardisation des interfaces mais reste jusque là coincée dans son carcan synchrone. L’heure de la pleine maturité a sonnée !
Nous le constatons encore aujourd’hui, certains projets n’aboutissent jamais, ou alors après des mois voire des années de mise en œuvre et sont boudés par les utilisateurs.
Malgré une gestion des changements, la plateforme n’est jamais utilisée et l’application meurt (on l’espère rapidement) sans jamais rencontrer ses utilisateurs.
Dans certains cas, le projet “stratégique” a été validé par la Direction, la technologie en haut à droite du cadran du Gartner a bien été déployée, mais au final les cas d’usage sont beaucoup trop compliqués à intégrer sur la plateforme. Ces projets finissent souvent en échec, les ressources ont été gaspillées et l’image de la DSI en pâtit.
Enfin, dans d’autres cas, l’étude s’éternise pour concevoir, et planifier l’architecture qui répondra à l’ensemble des cas d’usages et qui permettra de résorber la dette technologique. Ces cas de figure trop fréquents partent malheureusement de bonnes intentions. Il s’agissait de couvrir l’ensemble des besoins existants et d’absorber les besoins qui ne manqueront pas d’arriver à court et moyen terme.
Une approche frugale
La meilleure solution consiste à se concentrer sur quelques utilisateurs clés pour prendre en compte des fonctionnalités précises qui peuvent être implémentés sous forme de MVP en quelques sprints et le faire évoluer pour prendre en compte les nouveaux besoins.
L’architecture de la solution devra rester souple et prévoir “by design” de pouvoir intégrer de nouveaux composants et technologies qui répondront demain à des nouveaux besoins.
Pour réussir cette mise en œuvre, il faut donc réunir une équipe pluridisciplinaire qui sera en charge de :
Collecter et analyser les besoins des utilisateurs
Définir l’architecture fonctionnelle et de données
Définir l’architecture technique
Constituer et suivre la backlog
Concevoir et mettre en œuvre les développements
Déployer l’architecture technique
Au démarrage du projet il faudra donc :
un Product Owner
un architecte en charge des aspects fonctionnel, applicatifs et data
un architecte technique
un scrum master
un ou plusieurs développeurs spécialisés sur les stacks à mettre en oeuvre
un cloud-ops
Un Business Analyste
Une organisation efficiente
Cette organisation s’inspire des Pizza Teams (l’ensemble des membres d’une équipe doit pouvoir se nourrir sur une Pizza Américaine). Elle vise à simplifier la communication au sein d’une équipe. En effet, le nombre de liens entre les personnes d’une équipe peut être calculé avec la formule suivante (1) :
( N x (N -1 ) )/ 2
Où N est égale au nombre de personnes dans l’équipe.
Plus le nombre de personnes est important plus les échanges sont importants et les risques et le temps consacrés aux échanges sont importants.
La mobilisation de l’équipe permettra de produire au fil des sprints des versions de plus en plus abouties, revues régulièrement par les utilisateurs.
En quelques semaines, une première version pourra être déployée en production sur le périmètre jugé prioritaire par les utilisateurs.
L’adoption ne sera plus un problème, car les utilisateurs auront participé à la conception de leur outil et remonteront directement les fonctionnalités prioritaires.
Au fil des évolutions, l’équipe pourra être élargie pour prendre en compte des besoins impliquant des nouvelles briques d’architecture et de nouvelles technologies. Il faudra toutefois rester vigilant afin de ne pas dépasser le nombre critique de membres dans l’équipe.
Une dynamique dès le cadrage
Un cadrage initial est indispensable avant de lancer le projet. Certes l’organisation projet et le user-centrisme sont des facilitateurs, mais la clef dans le succès de la démarche se trouve en amont. Si au lieu de demander aux utilisateurs quels sont leurs besoins et de les hiérarchiser par priorités, nous leur demandions leurs envies ?
Les utilisateurs vont être concentrés sur ce qui est vraiment important dans leur travail et ce qui va leur simplifier la vie. Si l’application a de multiples utilisateurs, il faudra les amener à trouver un consensus et à présenter une liste commune. Cette liste sera la base de la backlog projet et devra être affinée afin de la rendre implémentable.
Faire adhérer les décideurs
Cette approche projet nécessite de rassurer les décideurs. En cela la méthode agile est insuffisante. Le burn out chart ou les autres indicateurs sont utiles au pilotage agile des projets, mais suffisent rarement à rassurer les décideurs sur les aspects coûts / délais / valeur ajoutée des projets.
Il faut donc trouver des indicateurs complémentaires, aptes à rendre compte de l’avancement des sprints, mais qui permettent aussi d’apporter de la visibilité aux décideurs qui n’ont que faire des points de complexités et autres idiomes agiles.
Revoir la méthode
La réussite des projets passe par une remise en question profonde de nos méthodes d’architecture. Le framework TOGAF nous donne de bonnes bases, mais elles sont loin d’être suffisantes pour aller vers de l’architecture SI agile.
Les évolutions de l’architecture découlant des besoins métiers et non plus d’une planification détaillée réalisée en début de projet et implémentée dans un cycle de plusieurs mois ou années, cela nous amène à adresser des problématiques qui remettent en cause nos méthodes de travail :
Les projets font de plus en plus souvent appel à de l’expérimentation. Les composants sont testés sur des calendriers resserrés et suivant l’adéquation par rapport au besoin, sont adoptés ou abandonnés.
Les schémas d’architecture initiaux sont vite obsolètes et ne seront maintenus qu’en contrepartie d’un investissement conséquent à faible valeur ajoutée pour l’utilisateur.
Les technologies évoluent (trop) vite, la maîtrise des technologies par les équipes de support et d’exploitation prend beaucoup plus de temps.
Les utilisateurs ne comprennent plus que l’informatique professionnelle soit décorrélées des technologies mises à dispositions par les GAFA.
Les projets sur plusieurs années sont obsolètes avant d’être ouverts aux utilisateurs.
Pourtant des méthodes et outils inspirés du design thinking, du Lean ou du manifeste agile sont là pour nous aider avec par exemple :
La méthode sprint pour l’expérimentation ;
Des outils de documentation automatique des architectures qui garantissent des schémas toujours à jour (2) ;
Une organisation devops et une automatisation du traitement des incidents ;
Une approche itérative des projets, pour apporter de la valeur aux utilisateurs de manière linéaire sans sacrifier la qualité.
Certains argumentent que ces transformations sont réalisables à l’échelle des startups ou de compagnies digital natives, mais c’est oublier que le dev-ops tire son origine du monde industriel, certes beaucoup moins souple que l’IT, mais où la transformation vers le lean a été une condition de survie. The phoenix project (3) illustre très bien les parallèles entre le monde industriel et l’agilité , plus proche de notre quotidien, la gestion des maintenances des TGV est opérée par la SNCF via des tableaux agiles où l’ensemble des bonnes pratiques sont respectées.
Se transformer pour survivre
Les architectes n’auront bientôt plus le choix, les projets planifiés à plusieurs années induisent trop de risques :
tant sur le budget (il est de plus en plus difficile d’obtenir un budget pluriannuel pour un projet qui délivrera dans un futur éloigné)
que sur l’adoption utilisateur : la solution prévue ne correspondra plus aux priorités du business lorsqu’elle aboutira.
L’architecte doit donc à la fois porter une vision à long terme permettant de respecter les règles de l’entreprise, garantissant l’exploitabilité de l’application et être capable de faire opérer des changements d’architecture pour répondre aux priorités métier à court terme.
Un changement de paradigme est nécessaire pour passer d’une organisation ou les technologies sont des capacités de soutien qui fournissent des services, des plates-formes ou des outils spécifiques au reste de l’organisation, tels que définis par les priorités, les ressources et le budget, à une organisation ou les technologies sont parfaitement intégrées et au cœur de tous les aspects de l’organisation en tant que moyen de libérer de la valeur et de permettre des réactions rapides aux besoins des entreprises et des parties prenantes (4).
Il nous faut nous habituer à la distribution de valeur dès le début du projet et nous préparer à prendre en compte les nouveaux besoins à chaque nouveaux sprints.
Les utilisateurs doivent se sentir impliqués, considérés. Leurs remarques doivent être valorisées afin de rentrer dans un cercle vertueux qui permettra de délivrer de l’expérience utilisateur de qualité en continu.
Le succès des projets dépend maintenant de la capacité des architectes à prendre en compte les besoins des utilisateurs, afin de toujours pouvoir s’adapter aux priorités métier et délivrer de la valeur au plus près des enjeux business. Ces changements bousculent certainement les habitudes ancrées dans la DSI, mais la valeur dispensée aux utilisateurs justifiera l’investissement à apporter dans ces changements.
La gestion de portefeuille des projets est une activité de mieux en mieux considérée au sein des organisations. Elles sont de plus en plus nombreuses à prendre conscience que le rendement de leurs investissements n’est pas seulement le fait des livraisons mais aussi de leurs capacités à engager les bonnes initiatives de changement au bon moment. La gestion de portefeuille de projets y contribue par ses processus mis en œuvre pour les prioriser, pour s’assurer de leur pertinence vis-à-vis des objectifs stratégiques, pour optimiser les ressources, pour anticiper les incertitudes et les risques, pour coordonner les adhérences, pour discipliner les pratiques et pour maximiser les bénéfices. C’est bien tout cela qu’apporte la gestion de portefeuille de projets.
Des capacités d’action et d’information à développer
Les bonnes pratiques de gestion de portefeuille de projets (instances, prise de décision, etc.), toutes ensembles, permettent de régler la bonne vitesse du changement, c’est à dire le plus efficace. À ce titre, la gestion de portefeuille aspire à fournir à sa Direction des données fiables qui lui permettent de prendre des décisions d’investissement plus éclairées, en fonction des ambitions et des moyens disponibles. Il revient donc à la direction de rattachement du dispositif PMO au sein de l’entreprise d’exprimer ses besoins vis-à-vis d’elle. Cela s’étend de la surveillance passive jusqu’à la gestion active de la composition et de l’exécution du portefeuille dans son ensemble, ainsi qu’à s’assurer que les équipes sont dynamisées, que la réalisation des bénéfices est optimisée et que les leçons de l’expérience sont tirées et appliquées à l’avenir (amélioration continue).
Connaître ses défis pour mieux les affronter
Parce que “charité bien ordonnée commence par soi-même”, les PMO doivent se prêter à un auto-examen pour connaître leur propre maturité au regard des besoins de gouvernance, de l’évolution de l’environnement et des technologies. En effet, la gestion des projets est soumise aux mêmes contraintes que les autres activités de l’entreprise : enjeux multiples, interdépendants et sur des horizons de temps toujours plus courts qui réclament toujours plus d’agilité. Pour ne citer que ceux-ci :
Positionnement dans l’organisation : où doit se situer ce centre névralgique, porteur de la vue panoramique des projets de l’entreprise, qui constituent rien de moins que le moteur des futures transformations ?
Posture de facilitateur : comment assumer le rôle de coordinateur du changement, comme gestionnaire des dépendances entre projets et entre programmes et des flux de données en temps réel qui s’y rattachent ?
Réduction des temps de réponse : comment accélérer ses propres procédés avec les nouveaux outils digitaux pour limiter au mieux l’inertie et la charge administrative appliquées aux projets ?
Intégration de l’agilité : quelles sont les nouvelles capacités de travail à développer (travail collaboratif, gestion des produits, etc.) pour gagner à la fois en flexibilité du travail et surtout être à même de plus de réactivité face aux attentes des usagers, et à toutes sortes de contingences externes ?
Ainsi, il incombe au PMO de veiller à ce que ses méthodes, compétences, indicateurs, et outils soient à jour et apte à optimiser la création de valeur ainsi que l’exécution de la stratégie.
L’évaluation des capacité est un impératif avant les actions de progrès
Pour y parvenir, l’évaluation apporte un regard objectivé sur le niveau de sophistication des fonctions et services réalisés sur tout ou partie des activités PMO d’une entreprise. La connaissance de la maturité PMO éclaire tout à la fois sur la capacité de ses services et moyens à répondre aux besoins des parties prenantes et sur la valeur qu’ils sont aptes à générer.
Cet exercice d’introspection est possible depuis que les éditeurs de référentiels de bonnes pratiques de gestion de projets proposent chacun leurs modèles d’évaluation de la maturité des pratiques PPM. Le plus ancien est OPM3 (du PMI éditeur du PMbok) le plus connu. L’autre modèle notoire est P3M3 (de l’OGC éditeur des référentiels P3O et Prince 2) qui reste le plus accessible dans sa mise en œuvre.
OPM3 & P3M3 pour évaluer la maturité: les limites
Le référentiel OPM3 construit autour de 3 groupes de processus (projets, programmes, portefeuilles), 5 domaines de connaissances, 16 processus de gestion de portefeuille et 18 Facilitateurs organisationnels, est aligné sur les principaux standards de son éditeur. Ce modèle, très exhaustif, met l’accent sur la valeur de la gestion de projet organisationnelle dans l’exécution des stratégies organisationnelles pour identifier les domaines d’amélioration.
Le modèle de maturité P3M3 examine la façon dont une organisation exécute ses 3 champs d’activités projets, programmes et portefeuilles. Il est unique en ce sens qu’il examine l’ensemble du système et pas seulement les processus. L’évaluation P3M3 peut être adaptée aux besoins de l’organisation et être déployée de multiples façons. Il propose d’évaluer tous les domaines de l’organisation au travers de 7 perspectives de processus (le contrôle de gestion, la gestion des gains, la gestion financière, la gestion des parties prenantes, la gouvernance organisationnelle, la gestion des risques, la gestion des ressources).
Cependant, pour un usage récurrent, effectuer une évaluation de la maturité PMO avec ces deux modèles devient rapidement difficile car nécessitent de faire appel à un évaluateur certifié sans faire de distinction entre les processus pour servir l’organisation et ceux internes exécutés en fonction de la localisation du PMO dans l’organisation. Enfin, le relevé des forces et faiblesses de maturité qui résulte de leur évaluation est établie entre l’existant de l’organisation et une référence standard maintenue par l’éditeur.
Rhapsodies Conseil a élaboré un outil d’évaluation de la maturité PPM
C’est en cherchant à disposer d’un outil à la fois facile à mettre en œuvre et proposant un rendu plus visuel de l’évaluation de la maturité PPM des organisations, que Rhapsodies Conseil en est venu à développer son outil. Après plusieurs versions et mises à l’épreuve, le CUBe de la maturité PMO est une création issue d’une forte inspiration du concept du CUBe® (collectif Americo Pinto, Marcelo F De Matheus Cota, et Dr. Ginger Levin – 2010) et des modèles OPM3, P3M3.
A partir d’un référentiel de 27 services adaptés des fonctions les plus communes en PMO (travaux de Hobbs and Aubry – 2007) et des 18 facilitateurs organisationnels du modèle OPM3, le CUBe est structuré par ses trois dimensions en 9 cadrans et 3 niveaux de maturité. La première dimension, la Portée s’attache aux niveaux de l’activité PMO dans l’organisation (Entreprise, Direction, Projet/programme). La seconde, l’Approche, représente les niveaux d’action (Stratégique, Tactique, Opérationnelle) de ses services comme l’évoque le modèle P3O. Enfin les niveaux de maturité se déclinent en Basic, Intermédiaire et Avancé.
Aux croisements des niveaux de Portée et d’Approches, il en résulte le questionnaire de l’évaluation. Pour limiter les biais de réponses aux questions celles-ci sont proposées en choix limité à 3. Autre caractéristique de simplification, la détermination des services à améliorer peut se faire par comparaison de la maturité existante du dispositif avec celle des capacités de ses activités en cible. Cette cible est déterminée en parallèle avec le responsable de rattachement du PMO. Car les exigences et attentes entre les différentes Portées et vis à vis de chacune des Approches de l’activité PMO sont propre aux ambitions et rythme d’évolution de chaque PMO.
Enfin, la restitution se fait selon deux formats possibles, un score en % des cadrans du CUBe à destination des décideurs et sur une carte « Heatmap » des différents services évalués plus adaptée aux opérationnels pour construire le plan de développement de la maturité PMO PPM où cela est nécessaire dans l’organisation. C’est ainsi que l’outil permet de dresser un bilan des pratiques et des besoins d’évolution à traiter et d’en relever les progrès plus facilement au fil du temps.
Si après cette lecture vous êtes curieux de découvrir ou d’essayer cet outil, vous trouverez ci-dessous le lien de téléchargement. Si vous souhaitez en savoir plus ou pour obtenir des réponses à vos questions, nous sommes à votre disposition. N’hésitez pas à nous contacter.
¹ Organizational Project Management Maturity Model (PMI) ² P3M3 : Programme, Project, Management Maturity Model (OGC) ³ P3O : Portfolio, programme and Project Offices
Gartner estime que les budgets des DSI vont baisser de 8% en 2020 par rapport à 2019.
Dans ce contexte, c’est toujours la même sempiternelle question qui revient : comment faire plus quand on a moins d’argent ?
Il n’y a pas de solution miracle
Si la réponse à cette question était si simple, quelqu’un en aurait fait une méthode et serait devenu probablement très riche en très peu de temps.
Pas de solution miracle donc, mais peut-être des pistes de solutions à chercher dans les modes de fonctionnement de certaines équipes.
Première piste : dépenser moins.
Maigrir : lean, lean, lean…
Il s’agit ici d’optimiser les processus, de standardiser et d’automatiser au maximum pour réduire les coûts. L’approche Lean et ses dérivés dans l’industrie, l’IT ou le Management contient tout un tas de méthodes pour arriver à cet objectif. Cet article à ce sujet est très intéressant : “Sorry, But Lean Is About Cost Reduction…” et identifie certaines pistes :
Eliminer les gaspillages (c’est ce qui est le plus connu dans Lean et parfois on s’arrête là).
Analyser et catégoriser les coûts et s’attaquer aux coûts non justifiés
Rationaliser les activités
Supprimer des postes (mais pas les personnes que l’on emploiera à travailler sur le système)
… Oui mais pas n’importe comment !
Vous noterez que cet article au titre provocateur insiste finalement sur le fait que l’approche Lean n’a pas pour seul but de réduire les coûts, mais permet de le faire si on l’adresse de manière globale et intelligente.
Sur ce point, considérer qu’il est possible de réduire les coûts en supprimant des postes et en demandant toujours plus aux employés a peu de chance d’être rentable. Les coûts cachés ne sont pas loin : augmentation du turnover, de l’absentéisme, désengagement.
Par exemple, cette étude montre qu’une implémentation d’une approche Lean qui ne serait centrée que sur les aspects méthodologiques au détriment des aspects humains peut conduire à une augmentation de 82% du nombre d’arrêts maladie et de 62% de leur fréquence moyenne. En effet, une culture du process à outrance peut conduire à une diminution de l’autonomie et du contenu cognitif du travail, deux facteurs jouant sur la motivation intrinsèque du travailleur comme nous le rappelle Dan Pink dans cette vidéo “la vérité sur ce qui nous motive”.
Simplifier
Vous connaissez les 4 valeurs du Manifeste Agile ? Normalement oui.
Vous connaissez les 12 principes sous-jacents ? Moins sûr n’est-ce pas ?
Je les relisais récemment et l’un d’entre eux me semble totalement aligné avec le thème de cet article : La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
Apprendre à faire simple pour travailler moins et donc dépenser moins, vous en avez forcément entendu parler.
Innovation frugale vous connaissez ? Allez lire cet article où Navi Radjou nous dit :
“L’objectif est également de faire des produits simples, robustes et durables. Et d’aller vite.”
Qu’est-ce qui nous empêche de faire pareil dans la DSI ?
Planifier juste à temps et pas tout le temps : roadmap produit, sprint planning, et basta !
Estimer par comparaison plutôt que chiffrer : j’ai réussi un jour à réduire à 45 minutes une session d’estimation d’une équipe de 8 personnes qui durait d’habitude 1 journée entière, et qu’ils réalisaient une fois par mois. Je vous laisse faire le calcul des économies réalisées. De mon côté les remerciements des participants de ne plus avoir à subir cette journée infernale m’ont suffit.
CoProj, coPil, CoStrat, ComInvest, etc… Privilégiez la transparence et la visibilité à froid (emails, supports de communication) et ne participez à des comités que si des décisions importantes sont à prendre. Sinon traitez les petites décisions en point à point.
Développeurs, écoutez Uncle Bob et codez proprement avec Clean Code : Keep it simply stupid !
Antoine de Saint-Exupéry annonçait d’ailleurs le Lean et l’Agilité avant l’heure :
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
Investir
Comment ? Dépenser moins en investissant ? Mais qu’est-ce qu’il raconte ?
Et pourtant : investir au début et régulièrement permet d’économiser sur la durée.
Pas le temps d’industrialiser les tests, il faut qu’on produise de la valeur, c’est notre PO qui l’a dit.
Expliquez donc à votre PO que produire du code sans automatiser les tests aujourd’hui est plus rapide et moins coûteux, mais qu’il est probable qu’il devra repayer une toute nouvelle application dans 3 ans quand celle-ci sera impossible à maintenir.
Nous pouvons regrouper toutes ces pratiques d’automatisation (des tests, des déploiements, de l’infrastructure) sous le terme chapeau de DevOps (je préfère parler de BizDevOps). Ces pratiques et outils nous servent à faire des économies :
moins d’évaluation et de gestion des risques en amont car on teste plus tôt et on obtient rapidement les feedback des utilisateurs
moins de charges de recette manuelle qui ont tendance à augmenter de manière exponentielle avec le temps
moins de temps perdu à bricoler parce qu’on n’a pas à disposition les bonnes données ou l’environnement pour les tests de performances (coucou Infrastructure as code)
Sans oublier que BizDevOps, c’est avant tout un mode de fonctionnement qui favorise les interactions et la collaboration. Qui n’a jamais entendu une phrase du type : « Mon job c’est développeur, …peu importe ce qui arrive …je développe » ? Phrase qui annonce de bien mauvaises nouvelles dans quelques sprints…
Deuxième piste : produire plus de valeur
Prioriser
Cela fait plus de 10 ans que je travaille autour de l’agilité. Ce qui m’avait passionné dès le début, au-delà de l’amélioration des interactions et des relations humaines qui en découlent, c’est la priorisation par la valeur. Je ne sais pas combien j’ai fait d’ateliers avec des Product Owners (PO) pour les aider à appliquer ce principe si simple à énoncer, si difficile à mettre en œuvre.
Évidemment, aujourd’hui tout le monde est d’accord sur le principe de faire d’abord ce qui a le plus de valeur. Il y a 10 ou 20 ans, ce n’était pas si naturel, puisque de toute façon il fallait tout faire, alors pourquoi ne pas commencer par le plus facile, ou le plus difficile…
Avec mon équipe de coachs agiles, nous avons créé une école pour les PO d’une grande entreprise leader du e-commerce. Nous avons dédié un module entier d’½ journée à la valeur. Pas à la priorisation, mais à la représentation de la valeur. Car c’est un travail qui peut être extrêmement complexe. Il consiste à identifier les drivers ayant un impact sur la valeur et à les catégoriser : risques, valeur intrinsèque, valeur d’investissement, technologies…
En travaillant sur la priorisation du backlog, le processus de développement en agile permet donc, pour un coût constant, de livrer en premier des fonctionnalités qui génèrent plus de valeur.
Alistair Cockburn nous propose d’ailleurs la définition suivante :
“Agile is early delivery of Value and less bureaucracy”
Comprendre et mesurer
Pour produire plus de valeur, il faut probablement développer sa compréhension des utilisateurs et des clients.
Et pour aller plus loin que cette simple phrase, j’aime beaucoup la combinaison des 3 approches Design Thinking + Lean Startup + Agile :
Design Thinking ou l’approche centrée utilisateur vise à se mettre à la place du client/utilisateur pour bien comprendre quels sont ses problèmes.
Lean Startup permet de poser des hypothèses sur les solutions à mettre en oeuvre en face de ses problèmes, et de boucler très vite pour savoir si nos hypothèses sont bonnes, ou pas.
Le développement Agile permet d’organiser le processus de livraison des fonctionnalités de sorte que ce soit régulier (itératif) et incrémental en priorisant par la valeur (comme vu précédemment).
Si même le Gartner le dit…
La combinaison de ces 3 approches est pour moi indispensable dans la réussite d’un produit car on peut très facilement en arriver à développer vite et bien des fonctionnalités parfaitement inutiles. J’intègre tout cela dans tous mes accompagnements pour product owners et product managers.
Au final : lean et agile, la solution ?
Ce qui définit l’Agilité, c’est cette importance donnée à l’apport de valeur plus qu’à la réduction des coûts. Il y a bien sûr une recherche d’efficacité, mais surtout d’efficience.
Avec plusieurs années d’expérience derrière moi, une combinaison des 2 est probablement une bonne approche : optimiser au maximum ce qui va être répétitif (tests, déploiements…) et accélérer au maximum le processus de création de valeur (priorisation, less is more…).
Comme dans un bon cocktail, tout est question de dosage et de vision globale : pour avoir un système efficient, il se peut que certaines parties du système ne soient pas optimisées au maximum, générant de fait une capacité à innover et à créer plus de valeur.
Pour arriver à trouver ce bon dosage permettant de produire plus de valeur, plus vite et avec moins d’argent, vous avez probablement besoin d’une bonne équipe produit qui :
Comprend les problèmes réels de ses clients (avec un profil UX par exemple dans l’équipe)
Expérimente fréquemment des morceaux de solutions pour mieux comprendre son écosystème et valider ses hypothèses (avec le Lean Startup). Cela implique de systématiquement mesurer a posteriori de la livraison les indicateurs liés à ces hypothèses, chose qu’on a parfois tendance à oublier de faire
Développe son produit avec des principes agiles : en favorisant les interactions, en livrant fréquemment des fonctionnalités en production, en documentant le nécessaire et en étant ouvert à des changements fréquents (vous avez reconnu les 4 valeurs du Manifeste Agile ?)
Met en place un système de mesure de la performance et s’organise pour l’améliorer en continu (avec le Lean). Je me permets d’insister sur ce dernier point : la mise en place d’une véritable démarche d’amélioration continue est la base de l’optimisation d’un système. C’est également ce qui fait trop souvent défaut dans les implémentations Agiles qui prennent insuffisamment en compte le changement de mindset nécessaire
J’ai observé personnellement une équipe de 6 personnes (PO, UX, devs) produire en 6 semaines ce qu’une équipe de 12 n’avait pas réussi à finaliser en 6 mois.
Leur différence ? Probablement un peu plus d’expérience (et donc un TJM plus élevé coucou les fausses économies) et surtout une capacité à se poser les bonnes questions.
Rappelez-vous A. Einstein qui disait :
“Si j’avais une heure pour sauver le monde, je passerais 55 minutes à définir le problème et cinq minutes à trouver la solution.”
Attention je le répète : ceci n’est pas une solution miracle. Ca ne fonctionnera pas si votre organisation n’est pas collaborative, si vos métiers et vos IT ne savent pas se parler, si votre management met des bâtons dans les roues plutôt que d’aider les équipes de dev. Mais si vous prenez maintenant ce chemin, ce sera toujours mieux que la situation actuelle. C’est dans les situations de crise que l’Homme est le plus innovant.
