Voir la source de Changez votre façon de construire

[[Category: Marty Cagan]]
[[Category: Accelerate]]
[[Catégorie:Portail Product Owner]]
Auteurs : Jon Moore et Marty Cagan<br />
Source : [https://www.svpg.com/changing-how-you-build/ Changing How You Build]<br />
Date : 16/09/2022<br />
----
Traducteur : Fabrice Aimetti<br />
Date : 16/11/2022<br />
----
Traduction :<br />
<br/>
__NOTOC__
Nous avons récemment publié [https://www.svpg.com/transformation-defined/ un article définissant ce que nous entendons par une véritable transformation], dans lequel nous décrivions trois éléments permettant de devenir une entreprise forte, axée sur les produits.

Dans les trois prochains articles, nous allons approfondir chacun de ces trois éléments et décrire pourquoi ces changements sont si importants pour les entreprises de produits fortes.

Bien qu'il s'agisse de concepts quelque peu techniques, une connaissance approfondie de la technologie n'est pas nécessaire pour comprendre l'importance et la valeur de ces éléments pour votre entreprise et vos clients.

Votre investissement technologique a pour but de créer de la valeur pour vos clients et votre entreprise.  

La création de cette valeur comporte plusieurs aspects importants, mais en fin de compte, les ingénieurs sont la principale compétence dont vous dépendez pour construire vos produits.  Pour la plupart des entreprises axées sur la technologie, les ingénieurs représentent le coût le plus important.

Pourtant, il existe un large éventail d'outils, de méthodes et de processus que vos ingénieurs peuvent utiliser pour construire, tester et déployer leurs produits.

Mais bien plus importants que les outils, méthodes ou processus spécifiques, il y a trois principes fondamentaux qui sont à la base de la façon dont les entreprises de produits fortes construisent leurs produits :

==1. PROTÉGEZ LES CLIENTS, LES REVENUS, LA MARQUE, LES COLLÈGUES==
Avant tout, lorsque nous construisons et déployons nos produits, nous devons le faire de manière à protéger nos clients, nos revenus, notre réputation et nos collègues.

Dans les produits et services modernes basés sur la technologie, la rupture du produit peut avoir des conséquences immédiates et dommageables pour nos utilisateurs et nos clients, nos revenus, la réputation de notre marque et nos collègues (en particulier le personnel chargé des ventes et du succès auprès des clients). 

Si nous provoquons un problème grave, cela peut entraîner une indisponibilité pour tous les clients et utilisateurs qui utilisent et dépendent de ce service.  Cela fait partie du prix à payer pour les nombreux avantages du cloud computing pour les clients.

C'est pourquoi, si un service d'infrastructure de base tel que AWS d'Amazon connaît un problème grave, une grande partie des produits dont nous dépendons dans notre vie personnelle et professionnelle sont immédiatement touchés et souvent rendus inopérants.  Cette situation est très similaire à une panne de courant de grande ampleur.

Bien qu'il soit impossible de se prémunir contre tous les problèmes possibles, nous avons l'obligation de nous efforcer constamment de protéger nos clients contre les problèmes que nous causons lorsque nous construisons et déployons.

==2. RÉPONDEZ AUX BESOINS DU MARCHÉ==
Deuxièmement, il est important de souligner que cela ne sert pas uniquement à doter nos clients de nouvelles capacités.  

Dans chaque entreprise, il y a des moments où quelque chose change sur le marché, dans le paysage concurrentiel ou dans l'environnement qui fait que les choses cessent de fonctionner, se comportent de manière incorrecte, ou peut-être en raison de changements réglementaires ou de conformité, exigent un changement de nos produits, ou vos clients rencontrent un problème grave nécessitant une action immédiate. 

Lorsque des problèmes graves ont un impact sur nos clients, nous devons être en mesure de diagnostiquer rapidement le problème, de créer une solution, de tester cette solution, puis de la déployer.

Attendre des semaines ou des mois n'est plus acceptable pour la plupart des entreprises aujourd'hui.  Les entreprises de produits solides doivent être capables de répondre rapidement et avec compétence aux besoins du marché.

==3. MÉRITEZ LA CONFIANCE DE VOS CLIENTS==
Enfin, les clients comprennent généralement que des problèmes surviendront occasionnellement, mais ils nous jugent davantage par notre capacité à réagir rapidement et avec compétence lorsque ces problèmes surviennent.

De même, il y a toujours des situations où les équipes produit doivent être capables de prendre ce que l'on appelle [https://www.svpg.com/managing-commitments-in-an-agile-team/ un engagement de haute fidélité].  C'est le cas lorsque nos clients ou partenaires dépendent de nous pour un produit spécifique, et qu'ils doivent savoir qu'ils peuvent compter sur ce produit pour fournir la valeur nécessaire, et qu'il sera livré dans les délais promis.

Ce n'est pas un secret dans notre domaine que de nombreuses entreprises ont un bilan terrible en termes de respect de ce type de promesses.  Mais les entreprises de produits fortes savent combien cela est important pour établir et maintenir la confiance avec nos clients.

===PETITES VERSIONS, FRÉQUENTES, FIABLES===
La technique de base utilisée pour répondre à chacun de ces principes est la notion de versions petites, fréquentes et fiables.

Cela signifie, au minimum, que chaque équipe produit publie une version toutes les deux semaines.  Pour les entreprises de produits les plus fortes, cela signifie qu'elles publient plusieurs fois par jour.

La raison pour laquelle vous ne savez probablement pas que cela se passe avec vos produits préférés est précisément parce qu'ils publient un flux quasi constant de petites versions.

Et afin de proposer constamment de petites versions, fréquentes et fiables, nous devons prendre très au sérieux notre obligation de tester, connue plus officiellement sous le nom d'assurance qualité.  

Mais les tests sont plus compliqués qu'il n'y paraît.  En général, nous travaillons pour tester deux aspects principaux de ce que nous construisons, le premier est simple, le second l'est moins.  

Le premier est que lorsque nous construisons une nouvelle capacité, nous devons tester que cette nouvelle capacité fonctionnera comme prévu.  C'est simple, mais comme nous devrons probablement tester et retester cette nouvelle capacité des milliers de fois au cours des mois et des années à venir, nous investissons généralement dans un certain niveau d'automatisation des tests.

La seconde consiste à s'assurer que les changements apportés pour activer la nouvelle capacité ne cassent pas autre chose de manière involontaire ou par inadvertance.  C'est ce que l'on appelle le test de non-régression, et lorsque l'on sait que de nombreux produits et services technologiques sont aujourd'hui le résultat du travail de centaines d'ingénieurs pendant de nombreuses années, créant des dizaines de milliers d'interactions, on comprend que s'assurer qu'un produit complexe ne régresse pas lorsqu'une nouvelle capacité est introduite peut être une affaire de taille.

La principale méthode utilisée par les équipes produit pour s'assurer que les nouvelles capacités fonctionnent comme prévu et n'introduisent pas de régressions, consiste à déployer une série de changements très fréquents et de très petite taille.  

Plus l'incrément de version est petit, plus vite nous pouvons garantir la qualité de la nouvelle fonctionnalité et plus vite nous pouvons être sûrs que nous n'introduisons pas de régressions.  Et avec ces versions petites et fréquentes, si un problème est introduit, il est beaucoup plus facile et rapide d'en identifier la cause (puisque nous n'avons changé qu'un petit nombre de choses).

Si cela vous semble contre-intuitif et si vous continuez à croire que pour garantir la qualité, il faut publier lentement et rarement, vous vous devez, pour vous-même et votre entreprise, d'examiner à la fois la théorie et les preuves qui expliquent pourquoi des versions fréquentes et plus petites permettent d'augmenter le débit et d'améliorer la qualité des entreprises de produits fortes.  Nous vous recommandons l'excellent livre [https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339 Accelerate].

Malheureusement, de nombreuses entreprises n'ont pas encore atteint la capacité de réaliser ces petites versions fréquentes.

Au lieu de cela, elles effectuent des centaines, voire des milliers de changements, puis, une fois par mois, par trimestre ou même par an, elles s'efforcent d'intégrer tous ces changements ensemble, puis elles essaient de tester que toutes ces nouvelles capacités fonctionnent comme prévu, et enfin elles commencent à identifier et à supprimer toutes les conséquences involontaires (régressions).

Comme vous commencez, je l'espère, à le comprendre, c'est la raison pour laquelle les grandes versions comme celle-ci (connues sous le nom de "big bang") sont connues pour leurs retards de plusieurs semaines, voire de plusieurs mois, pour essayer de tout remettre dans un état fiable et publiable.

En fait, de nombreux produits construits de cette manière n'atteignent jamais un niveau de qualité élevé, et le client est obligé de faire face à un flux constant de défauts et de problèmes, ou bien de chercher un autre fournisseur de solutions.

De plus, même si la nouvelle version fonctionne comme prévu (ce qui est loin d'être le cas), le client est contraint d'absorber des centaines, voire des milliers de changements de produit qui le frappent d'un seul coup, nécessitant probablement une nouvelle formation, une recertification, une réintégration et une interruption importante de son travail pour s'adapter à tous les changements que l'entreprise lui a imposés.  

Dans ce cas, il arrive trop souvent que le client fasse pression sur votre entreprise pour qu'elle publie moins souvent, car il n'a tout simplement pas le temps de faire face à un tel degré de changement.  Comme vous pouvez le voir maintenant, bien qu'il soit tout à fait compréhensible que le client demande cela, agir ainsi serait bien pire pour le client et pour votre entreprise.

Si l'on ajoute à cela l'incapacité de l'entreprise à répondre rapidement et de manière compétente aux problèmes critiques, on comprendra que les clients perdent confiance dans votre capacité à leur fournir le service dont ils ont besoin.

===UNE REMARQUE SUR LES MÉTHODES AGILES===
Vous avez presque certainement entendu parler des méthodes agiles.  La raison principale pour laquelle tant d'entreprises ont adopté les méthodes agiles au cours des vingt dernières années est que ces méthodes peuvent fournir la force nécessaire pour amener les équipes de produits à réaliser ces petites versions régulières et fréquentes.

Il est vrai que le passage à des versions petites et fréquentes peut nécessiter un investissement important, principalement dans l'automatisation des tests et du déploiement.  Mais pour les entreprises qui ont utilisé les méthodes Agile pour parvenir à des versions au moins toutes les deux semaines, cela leur a apporté, ainsi qu'à leurs clients, une réelle valeur ajoutée.

Cela dit, il est important de comprendre qu'il n'est pas nécessaire de recourir aux méthodes agiles pour obtenir des versions régulières, petites et fréquentes.

En fait, beaucoup des meilleures équipes produits du monde ont maîtrisé la capacité de déployer systématiquement ces petites versions (appelées intégration continue et déploiement continue ou "CICD"), sans pour autant suivre un processus ou des méthodes agiles formels.

Comparez cela aux organisations qui investissent tant de temps et d'argent dans l'adoption de rituels, de rôles, de méthodes et de processus Agile, mais qui, au bout du compte, continuent de publier des versions trimestrielles et de pénaliser leurs clients.

De même, [https://www.svpg.com/revenge-of-the-pmo/ une maladie se propage] dans le monde de la technologie, où des processus lourds [https://www.forbes.com/sites/stevedenning/2019/05/23/understanding-fake-agile/ se font passer pour Agile], mais ne sortent une version qu'une fois par trimestre.

Et pour être parfaitement clair sur ce point très critique : si votre entreprise continue à publier des versions annuelles, trimestrielles ou même mensuelles, peu importe le nombre de rituels agiles que vous suivez ou le nombre de soi-disant coachs agiles que vous employez, la vérité est que vous n'êtes pas Agile au sens propre, vous n'obtenez pas les bénéfices nécessaires et vous ne serez pas en mesure de servir vos clients ou votre entreprise comme il se doit.