Pensez produit, pensez Vertical !

L'informatique, dans une entreprise ou une structure d'activité(s) dont le cœur de métier n'est, justement, pas l'informatique, joue traditionnellement un rôle de support.
Bien qu'en constante augmentation, la place de l'IT dans l'entreprise se limite souvent à la réalisation de projets, ceux-ci n’affectant pas l’organisation en place puisqu'étant par essence ponctuels.
Cependant, les méthodes de gestion de projet, la culture projet, n'ont cessés d'évoluer, à tel point qu'il devient stratégique d'avoir une entité dédiée au sein de l'entreprise, et donc un fonctionnement plus adéquat.

Dans cet article, je vais présenter les principes verticaux permettant de fluidifier l'activité d'un SI.

Projet? Produit? On fait quoi chef ?

Bon déjà, commençons par définir ces 2 notions, cela permettra d'y voir un peu plus clair et d'avoir une base solide.

A ma gauche : le projet…

Un projet est un ensemble finalisé d’activités et d’actions, réalisées par une équipe dédiée sur une plage de temps définie, se traduisant par un ou des livrables.
ITIL4 définit les projets comme l’un des moyens d’introduire des changements significatifs au sein de l’organisation. Ils peuvent être définis comme structures temporaires créées dans le but de livrer un ou plusieurs livrables (ou produits) selon le dossier business convenu.
Un projet se caractérise donc par un début et une fin, est par essence unique et doit aboutir à un résultat tangible, mesurable et appréciable.
Je ne m'attarde pas sur la constitution des équipes, la nécessité d'avoir une équipe dédiée (parfois plusieurs) à chaque projet et l'organisation autour d'un chef de projet, ce n'est pas le propos de cet article.

… Et tout autour, le produit

Sur le plan marketing, un produit est un bien ou un service vendu par une organisation afin de satisfaire un besoin. Un produit peut être physique ou immatériel.
ITIL4 définit un produit comme la configuration des ressources d'une organisation conçue pour offrir de la valeur à un consommateur.
Un produit ne possède ainsi pas de notion de temporalité mais repose sur la notion de valeur ajoutée, son utilité est sa raison d'être.

Et où tout cela nous mène ?

En gros, le monde de l'IT est assez traditionnellement orienté projets, c'en est presque devenu un gros mot.
Le développement logiciel est souvent un acte ponctuel, avec un début et une fin ainsi qu'un livrable.
Ok ! Cela colle avec les caractéristiques précédemment définies d'un projet, sauf que …
Une fois livré on arrête tout ? On fait quoi des équipes ? On laisse notre code vivre sa vie tout seul dans son espace dédié, un genre de retour à la nature en somme ?
Ah ça y est je l'ai : on lance un projet pour le maintenir et le faire évoluer ou - attendez c'est génial ! - plusieurs projets chainés pour le faire évoluer et le maintenir entre 2 - on tient un truc c'est sûr -.
En fait, c'est plus simple.

Attends, toi là bas, qui a dit d'un air narquois mais très confiant, on laisse le support et les opérationnels se débrouiller, tu sors.

A la base, les organisations développent des softs dans un but précis il me semble : satisfaire un besoin, et accessoirement en tirer un usufruit (gagner de l'argent plus trivialement).
On y arrive, un logiciel PEUT donc être considéré comme un produit à part entière, il possède certes un cycle de vie mais peut aussi être considéré comme un élément intemporel puisque sa durée d'exploitation est très difficilement appréciable.

Ceci étant dit, on arrive doucement vers le principal problème induit par une organisation projet : le cas par cas.

Horizontal Limit

En effet, nous avons précédemment vu qu'un projet suppose une équipe dédiée, comme il s'agit d'un processus ponctuel, il est logique de monter une équipe pour ce besoin.
Cette équipe sera d'ailleurs présente durant toute la phase de création de la solution et sera reventilée la plupart du temps une fois la solution livrée.
Au cours d'une étude publiée sur researchgate, l'IEEE Computer Society précise que les méthodes logicielles traditionnelles encouragent la division horizontale des membres du projet en équipes fonctionnellement séparées.
Cette division engendre la création d'équipes de développement, d'assurance qualité et d'opérationnels, parfois d'équipes prenant en charge les spécifications.
Cette séparation augmente la durée du cycle de développement en raison des transitions nécessaires entre les différentes équipes.
Le bon vieux principe de silotage.

En résumé : on va monter une équipe pour concevoir et confectionner une solution technique répondant à un besoin, on peut donc parler de produit. On va sûrement devoir monter d'autres équipes pour valider les livrables et gérer l'exploitation. Pour que le projet réussisse, toutes les étapes doivent être complémentaires et apporter une valeur ajoutée.

Plusieurs problèmes apparaissent d'emblée :

• Chaque équipe aura forcément son mode de fonctionnement, spécifique à son cadre de compétences, et donc ses outils et processus dédiés;
• Chaque équipe limite sa responsabilité et réalise ses tâches en fonction de son cadre technique;
• La communication entre les équipes devient complexe;
• Il devient difficile de gérer le transfert de connaissances fonctionnelles et la montée en compétences techniques.

Bref, il va falloir fournir beaucoup d'efforts pour assurer une coordination efficace et cela aura forcément un coût, en plus du fait qu'on aura tendance à se couper d'une forme de fluidité.

Levons un doute : je ne prétends pas que l'organisation projet est à jeter à la poubelle, elle s'avère toujours efficace et pertinente lorsque le sujet répond aux critères précédemment énoncés d'un projet.

Il est temps de voir quels seraient les avantages d'une organisation orientée produit, ou même catalogue de produits.

C'est là que tout se produit

Commençons par une maxime de l'armée US, les 6 p : Une Préparation Parfaite Préalable Permet de Parer aux Piètres Performances.

En adoptant une approche orientée produit, notre organisation va mettre en place et coordonner plusieurs choses afin de préparer un lancement réussi : la qualité du produit, l'écosystème technique, les outils favorisant la vélocité, préparer le delivery et l'intégrer dans le cycle de développement, définir la norme technique, et au final, rentrer dans un cercle vertueux permettant de s'améliorer continuellement.
L'équipe projet devient une équipe organisée verticalement: terminée la succession de rôles, en reposant sur les principes de DevOps, permettant justement de casser les frontières, notre équipe produit va couvrir de multiples compétences, on parle de Crossfunctional Team.

Stream-aligned teams

Dans leur ouvrage intitulé Team Topologies, Matthew Skelton et Manuel Pais définissent ce type d'équipe en tant que Stream-Aligned Teams et l'expliquent comme suit :
Il s'agit d'une équipe alignée sur un flux de travail unique et précieux ; il peut s'agir d'un seul produit ou service, d'un seul ensemble de fonctionnalités, d'un seul parcours utilisateur ou d'un seul utilisateur. De plus, l'équipe est habilitée à créer et à fournir une valeur client ou utilisateur aussi rapidement, en toute sécurité et de manière indépendante que possible, sans nécessiter de transfert à d'autres équipes pour effectuer certaines parties du travail.

Architecture en continue et construction d'équipes

Pour aller plus loin, le 1er principe de l'architecture en continue est explicite : Architecturer des produits : l'architecture des produits est plus efficace que la simple conception de solutions ponctuelles aux projets et concentre l'équipe sur ses clients.
Il s'agit donc d'évoluer depuis une gestion de projets vers une gestion de produits.
D'ailleurs, cela va paraitre contre intuitif, mais le 6ème principe de l'architecture en continue suppose de modéliser l'organisation des équipes après la conception du système à mettre en place.

En effet, une fois la phase d'idéation du produit finie, c'est à dire le moment où on réfléchit et conçoit l'idée même du produit, la phase de définition du produit va permettre de déterminer les exigences fonctionnelles et les exigences non fonctionnelles, en architecture continue on parle de Quality attributes.
Les attributs de qualité sont :

• Adéquation fonctionnelle;
• Efficacité des performances;
• Compatibilité;
• Fiabilité;
• Convivialité;
• Sécurité;
• Maintenabilité;
• Portabilité;
• Robustesse;

J'en oublie forcément …

Ces derniers, une fois triés et priorisés vont driver la conception du système, c'est à partir de là qu'on pourra définir les équipes puisqu'on sera désormais capable de cartographier le spectre de compétences nécessaires à la confection de notre produit.

Valeur ajoutée d'une équipe produit

De fait, on va avoir tendance à créer des synergies dans l'équipe, avoir une méthode de travail fluide et sans à coups.
Cela aura pour effet de concentrer les efforts vers un but commun, compris de la même manière par tous les membres de l'équipe, et non pas orienté compétences et objectifs individuels.
Plus pragmatiquement, ce changement de paradigme va permettre de nous rapprocher de ce qui produit la valeur, de considérer les éléments à construire dans leur intégralité et non pas simplement comme des features ou des fonctions à développer.

On intègre ainsi le concept de Value Stream Mapping provenant de Lean, permettant d'effectuer une cartographie de toutes les étapes à valeur ajoutée et sans valeur ajoutée qui amènent un produit d'un état initial à un état final, et donc de prioriser l'effort.

De même, on a tendance à mettre en place des outils prenant en charge le fonctionnement de manière plus globale et permettant d'éviter la dispersion.
En termes de résultat, cette organisation favorise la vélocité car la livraison et la validation de contenu se font au plus tôt et en continue, les boucles de rétroaction sont plus efficaces et l'automatisation des process (build, test, provisioning d'environnement, configuration, déploiement, monitoring, ...) est rendue possible car intégrée directement dans la conception du produit.

Une précision pour ce dernier point : les environnements mis en place font partie intégrante du produit et doivent être pensés, développés et mis à disposition par l'équipe elle-même le plus tôt possible.

Sur le long terme, on pourra même orienter notre organisation vers des pratiques type ProductOps, mettant le client au cœur des débats et permettant de collecter des informations utiles au plus tôt et de manière continue.

Finalement, ce qui nous intéresse est la mise en place de processus concrets favorisant :

• la détermination, la priorisation et le développement des "flux de valeur" fournissant un service maximisé à l'utilisateur, et donc une augmentation de la qualité perçue;
• la diminution de la charge cognitive pour l'équipe en place car les spécifications ont tendance à être exprimées de manière plus claire et plus directe et sont englobées dans un tout cohérent;
• un gain en modularité, flexibilité et indépendance, en effet l'équipe se concentre sur la production de valeurs et l'architecture est totalement tournée vers le produit plutôt que le reflet d'une organisation, comme prédit par la loi de Conway;
• une forte capacité à revenir sur les éléments pauvres en valeur ajoutée ou sur les erreurs (principe de fail fast), ou intégrer au plus tôt les retours utilisateurs;
• la suppression des silos de compétences et la promotion d'un travail plus collaboratif;
• une accélération du Time-To-Market significative.

J'ai glissé chef

Comme il faut bien conclure, je dirais simplement que le sujet est loin d'être nouveau, Marty Cagan en parle d'ailleurs dans ses deux livres Inspired et Empowered.
Evidemment, ces principes ne sont pas applicables systématiquement, il est important de bien comprendre les enjeux et les apports sous-jacents ainsi que les modifications structurelles qu'ils supposent, autant que le changement de culture induit.
Vu l'intérêt stratégique que peuvent avoir les principes de verticalité, des articles plus spécifiques pourraient bien suivre celui-ci, très généraliste, alors stay tuned !