L’efficacité DevOps doit donner la priorité aux objectifs commerciaux

Voici une histoire rapide. En tant qu’analyste commercial, j’ai travaillé dans un éditeur à Oxford. Nous faisions des entretiens, des schémas de processus, etc. – ce n’est pas la partie intéressante. Parallèlement, ils ont fait appel à des consultants d’une petite entreprise de Birmingham, au Royaume-Uni. Deux ou trois personnes.

Le bâtiment dans lequel nous travaillions était long et mince et avait un étage supérieur vide. Ces types sont arrivés avec un énorme rouleau de papier brun de 7 pieds de haut. Ils ont tiré ce rouleau jusqu’au sol vide. Ils sont ensuite allés parler aux gens et leur ont demandé quels systèmes ils utilisaient, quels formulaires ils remplissaient, etc.

Ensuite, ils ont littéralement tout collé sur cette feuille de papier. Ils prenaient des impressions de leurs écrans ou des formulaires qu’ils remplissaient, les collaient et les joignaient avec du ruban adhésif noir pour que vous puissiez voir les liens.

Lorsqu’ils eurent fini, après quelques semaines, ils firent monter tout le monde dans l’entreprise et leur dirent : « Et voilà ! » Tout le monde était simplement impressionné : « Oh mon Dieu, je remplis ça, puis ça va là-bas, et puis rien ne lui arrive ? ou : « Ce morceau est exactement le même que celui-là, mais réalisé par deux personnes différentes ? et ainsi de suite.

C’était le plus beau cadeau que les consultants pouvaient offrir à l’entreprise. Est-ce que cela valait 20 000 $ (ou quel que soit le prix), juste pour coller quelques morceaux de papier sur une grande feuille de papier brun ? Oui absolument. 100%.

Le pouvoir de la visualisation est fantastique et je l’ai constaté à plusieurs reprises au fil des ans. J’ai récemment parlé à une start-up qui permet la cartographie des processus et les tableaux de bord DevOps. Ils m’ont demandé ce que je pensais de ce qu’ils faisaient, d’autant plus que (c’est ce qu’ils m’ont dit) que j’étais un peu sceptique.

Alors, je leur ai raconté l’histoire ci-dessus. D’après mon expérience, les processus de développement logiciel sont notoirement difficiles à verrouiller malgré tous les efforts déployés pour définir des méthodologies et des structures. On peut en expliquer les raisons autour d’un verre, mais le résultat est un manque persistant de visibilité. Comme le dit l’adage, si on ne peut pas mesurer, on ne peut pas gérer. Et le développement de logiciels est notoirement difficile à mesurer.

Alors, que dire aux fournisseurs de solutions qui tentent de déchiffrer le code de la visibilité des processus dans l’espace DevOps ? La question porte moins sur la nécessité, ni sur les révélations qui peuvent être obtenues avec un progiciel (ou des post-its sur un tableau blanc, ou un rouleau de papier kraft), que sur la façon de réussir alors que, historiquement, beaucoup ont essayé et est devenu, avec la meilleure volonté du monde, une solution ponctuelle.

Le défi est double. Premièrement, personne dans l’organisation (non technique) ne se soucie suffisamment des processus logiciels pour allouer un budget à de tels outils. Pour une raison quelconque, l’entreprise continue de penser que les logiciels fonctionnent tout seuls – cela ne peut pas être si difficile à écrire si vous avez de bonnes personnes, n’est-ce pas ? Tout le monde suppose que ce sont juste des gens intelligents qui créent les choses.

Cependant, quiconque a créé des logiciels à n’importe quelle échelle sait dans quel désordre épineux nous pouvons nous retrouver sans les bons contrôles. Etrange bonne nouvelle, nous sommes dans une période de serrement de ceinture, où les DSI sont invités à justifier combien coûte l’informatique – l’adage s’étend jusqu’à : « Si vous ne pouvez pas mesurer, vous ne pouvez pas avoir plus d’argent », ce qui focalise certainement l’esprit.

Donc, oui, la demande d’efficacité peut être satisfaite par des initiatives de dépenses pour économiser, ce qui à son tour alimente l’intérêt pour les outils de processus logiciels, classés dans la catégorie de la gestion de la chaîne de valeur, de l’analyse du développement logiciel ou similaire. Lorsque je regarde plusieurs fournisseurs cherchant à résoudre un problème complexe de la même manière, je fais souvent l’analogie avec plusieurs chemins gravissant la même montagne – et cet espace n’est pas différent.

Pour reprendre un peu cette analogie, je vois plusieurs fournisseurs, à différents stades de développement, emprunter différentes routes sur cette montagne. Cela nous amène au deuxième défi : aucune organisation n’a encore trouvé un chemin reproductible vers le sommet.

Tout le monde s’épuise au bout d’un moment et commence à ralentir. Dans le rapport VSM, nous voyons des leaders et des challengers, des acteurs historiques et de nouveaux entrants qui abordent tous le problème à leur manière. Les start-ups arrivent souvent dans l’espace par le biais d’une révélation personnelle, de leur moment « rouleau de papier brun », si vous préférez.

Ils arrivent, et gravissent la montagne, ils courent et courent, et ils commencent à ralentir… et finalement, au fil du temps, ils deviennent simplement une fonctionnalité de la plate-forme de quelqu’un d’autre. Je me souviens du coureur de montagne champion du monde espagnol Killian JornetLes exploits de – même si nous aspirons tous à ressembler à un tel athlète, il est une exception et non la norme.

Que faire à ce sujet ? Une réponse, bien sûr, est de ne pas trop s’en soucier. Un fournisseur peut reconnaître qu’il s’agira toujours d’un outil tactique, à utiliser lorsque les choses ne vont pas très bien. Pour le vendeur, cela se traduit par une certaine voie vers le marché : changer d’analogie, un outil pour les mécaniciens qui entretiennent l’avion, plutôt que la pièce maîtresse du cockpit.

Une deuxième option consiste à définir la portée en fonction de ce qui est faisable, verticalement plutôt qu’horizontalement : si vous devez être dans le cockpit, faites bien une chose plutôt que de chercher à contrôler l’ensemble de l’avion. Ainsi, le public peut être défini plus précisément et, par extension, la valeur apportée aux parties prenantes.

Ce qui nous amène à la troisième option. Considérer les cas d’utilisation dans lesquels l’outil peut apporter de la valeur. C’est très bien qu’un groupe plus restreint reconnaisse l’ampleur du problème, dans ce cas-ci ; le développement de logiciels est complexe et tend au chaos sans les bons freins et contrepoids. Mais il est fort probable que d’autres – les responsables du budget jusqu’au conseil d’administration – parviendront à la même conclusion sans un rouleau géant de papier kraft pour guider leur réflexion.

Alors, si le défi est que la majorité ne veut pas résoudre le problème, aussi clair qu’il paraisse pour la minorité, alors quels sont les scénarios dans lesquels la majorité le considère comme important ? Existe-t-il un autre besoin pour lequel la majorité est prête à mettre son portefeuille derrière ? Et partir de là, plutôt que du processus de développement et de la rentabilité ?

Dès le manifeste DevOps, le Projet Phénixlui-même basé sur Eli GoldrattDans les romanisations de Best Practices en matière de gestion de projet, il s’agissait toujours des défis commerciaux : attirer les clients sur le site Web, augmenter les ventes, améliorer les chaînes d’approvisionnement, etc. Cependant, trop d’outils et d’approches sont introspectifs et axés sur l’amélioration des moyens plutôt que sur la fin.

Nous savons tous à quel point il est difficile de créer des logiciels, mais voyez le premier point : personne en dehors du secteur informatique ne s’en soucie autant. Si nous ne parvenons pas à obtenir l’argent nécessaire pour apporter les améliorations nécessaires, c’est une chose. Et c’est absolument vrai que le problème existe. Mais supposer que les gens « comprendront » comme par magie que le problème doit être résolu en est une autre.

Alors, si les gens ne prennent pas la peine de le résoudre, quel scénario les pousserait à vouloir le résoudre ? Trop souvent, dans ce métier, nous sommes obligés d’attendre des situations où le problème se transforme en crise – juste après une faille de sécurité, à l’approche d’un audit de conformité ou lorsqu’un progiciel arrive en fin de vie.

Alternativement, j’adopterais une approche axée sur le design thinking, qui cartographie et hiérarchise les résultats commerciaux – cela s’applique aussi bien aux entreprises utilisatrices finales qu’aux fournisseurs de solutions. Pour les entreprises, quelles orientations commerciales spécifiques peuvent être modifiées grâce à l’amélioration des processus logiciels, et dans quelle mesure ? Et pour les fournisseurs, à quoi ressemble l’image composite de l’ensemble de la clientèle ?

Notez cependant que même si ces scénarios peuvent être des événements qui méritent d’être financés, ils ne constituent pas la fin du jeu, qui peut être décrite par la vision, la mission et la stratégie d’une entreprise. L’entreprise elle-même est la montagne – la vôtre ou celle des organisations dont vous êtes le fournisseur. Si vous vous dirigez vers le haut, demandez-vous d’abord à quoi ressemble le sommet ? Qu’aurez-vous réalisé une fois sur place ?

Si la réponse ne peut être décrite en termes commerciaux, il devient bien moins probable que vous y parveniez. Franchement, n’organisez la réunion de lancement de l’amélioration des processus logiciels qu’avec une image claire des trois principaux objectifs de votre entreprise pour la période à venir et de la manière dont l’amélioration des processus, les outils ou tout autre élément les réaliseront directement.

Et, en tant que vendeur, si vous cherchez uniquement à lever des capitaux auprès des investisseurs et à vous retirer rapidement, je dirais que c’est un faux sommet. À l’heure de la transformation numérique, le décalage entre la fourniture de technologies et les objectifs commerciaux est probablement la principale cause d’inefficacité des résultats. Préparez-vous à commencer le voyage avec une carte pour atteindre le sommet, si vous souhaitez vous rendre n’importe où.