En toute franchise, lorsque le produit phare de votre entreprise est un logiciel, on s'y connaît forcément un peu en développement logiciel. Dans cet article, je vais vous faire part de la révélation que j'ai eue : comment le processus de développement logiciel peut s'appliquer à tous les autres aspects de votre entreprise (et de votre vie) — quel que soit votre secteur d'activité, votre poste ou votre service. [Attention, spoiler : un livre incontournable — « The Phoenix Project » — vous attend !]
Nous avons choisi« The Phoenix Project »pour notre club de lecture interne. Je n’avais pas prévu d’écrire une critique, mais cet ouvrage de management atypique regorge de révélations trop précieuses pour être gardées pour nous. Bien que je ne sois pas développeur (même si je travaille avec d’excellents développeurs), j’ai découvert leur approche du travail et des outils géniaux tels que [Kanban] pour la visualisation et la gestion des flux de travail. Des outils qui peuvent convenir à tout le monde et qui fonctionneront à coup sûr !
« Le Projet Phoenix : un roman sur l'informatique, le DevOps et comment aider votre entreprise à réussir »
Par Gene Kim, Kevin Behr et George Spafford
Imaginez un roman fictif dans lequel un groupe de personnages très différents s'unissent pour vaincre un dragon et sauver un village, sauf que dans cette histoire, les « guerriers » sont des professionnels du monde des affaires, le village est une entreprise industrielle en difficulté (intégrée verticalement avec des composantes de commerce électronique et de vente au détail), et le dragon représente les problèmes auxquels l'entreprise est confrontée, en particulier la myriade de défis liés aux opérations informatiques (qui, comme nous le découvrons, sont étroitement liées à tous les autres services !).
Toute entreprise — ou toute personne — qui travaille avec, au sein, pour ou en lien avec le « DevOps » devrait lire ce roman à la fois humoristique et souvent terrifiant. Compte tenu de la réalité de notre environnement professionnel actuel, et plus particulièrement du monde du travail à l'échelle mondiale, ce livre s'adresse à TOUT LE MONDE.
Presque toutes les entreprises, littéralement, fonctionnent grâce au DevOps — et sont gérées par celui-ci. C'est un élément central du système nerveux de l'organisation. À moins que vous ne soyez un enfant tenant un stand de limonade dans son jardin, où l'on ne paie qu'en espèces.
Qu'est-ce que le DevOps ?
Dans le domaine des technologies de l'information, le terme « DevOps » est un mot-valise formé à partir des termes « développement » (Dev) et « exploitation » (Ops). Loin des « silos » d’autrefois, la culture logicielle actuelle réunit ces professionnels au sein d’une seule et même équipe, qui intervient tout au long du cycle de vie de l’application, du développement aux tests, en passant par le déploiement, l’exploitation, l’assurance qualité et la sécurité. L’expérience nous enseigne que travailler en silo, c’est-à-dire ne pas partager d’informations ni de connaissances avec les autres, crée plus de problèmes qu’il n’en résout.
L'histoire du « projet Phoenix » et l'importance du DevOps
Le DevOps est la « révolution industrielle » de notre époque. À travers l’exemple fictif de l’entreprise technologique Parts Unlimited (PU), les auteurs illustrent le fonctionnement typique (dysfonctionnel !) de nombreux environnements d’entreprise et montrent comment tout changement – ou toute absence de changement – peut être source de transformation, le DevOps en étant le pilier central. Les logiciels font partie intégrante de toute entreprise, à tous les niveaux. Ce récit offre des perspectives très enrichissantes sous tous les angles, et ne s’adresse pas uniquement aux techniciens.
Notre histoire « PU » (jeu de mots intentionnel) s’ouvre sur une catastrophe annoncée. Un directeur informatique de niveau intermédiaire (Bill), dont les supérieurs ont mystérieusement « démissionné », est promu au poste de vice-président des opérations informatiques, une fonction qu’il ne convoite pas et qu’il ne souhaite pas accepter. Sa mission (à la « Mission : Impossible ») — confiée directement par le PDG, charmant au premier abord — consiste à rétablir les opérations critiques de l’entreprise et à éviter que celle-ci ne fasse la une des journaux… tout cela alors que le « Projet Phoenix », un nouveau produit en retard de plusieurs années et dont la portée a été surestimée, est en cours de développement, et que la confiance financière du public envers l’entreprise vacille.
La lettre de Bill semble vouée à l'échec ; le projet Phoenix est le « tout ou rien » de PU. Des intrigues internes tourbillonnent autour du projet, et Sarah, la responsable marketing (et héritière présomptive du PDG), en est la principale adversaire, dotée d'un talent incroyable pour rejeter la faute de ses propres erreurs sur les autres, du moins selon le service informatique.
C'est alors que surgit le premier problème… les systèmes de gestion de la paie sont complètement foireux (FUBAR, pour « Fouled Up Beyond All Recognition »). La consigne de Bill est claire : sauver l'entreprise d'elle-même.
La rupture
Au départ, notre équipe fictive présente toutes les caractéristiques de personnes qui ne font ni confiance à leurs coéquipiers ni ne leur accordent la moindre considération. Le manque de communication est le moindre de leurs soucis — et, en fin de compte, le plus grave. Plutôt que de s’unir pour résoudre les problèmes, ils se rejettent la faute et tirent des conclusions hâtives et injustifiées les uns sur les autres. Les personnalités prennent le pas sur le professionnalisme. La condescendance et le « théâtre » d’entreprise règnent en maître.
Les tensions entre les services sont flagrantes. Les auteurs nous donnent un aperçu de ce que pensent les collaborateurs des opérations informatiques du reste de l'entreprise :
- Les professionnels du marketing sont « des diplômés en arts ou en musique, et non des personnes ayant une formation en stratégies technologiques ».
- Les commerciaux promettent l'impossible aux clients et s'attendent à ce que le service informatique trouve une solution et tienne ses promesses ; on ne peut pas leur faire confiance : « Vous connaissez le dicton, n'est-ce pas ? On sait qu'un fournisseur ment dès que ses lèvres bougent. »
- En gros, les vice-présidents passent leur journée à se faire des présentations PowerPoint — entre eux.
- Les développeurs « jettent de l'huile sur le feu » ; ils provoquent sans cesse des pannes de système ; ils sont déconnectés mentalement ou en vacances ; ils causent souvent des problèmes, puis disparaissent, laissant aux équipes informatiques le soin de réparer les dégâts.
- La sécurité de l'information dans la salle est le meilleur moyen de s'assurer que quelque chose ne sera PAS fait.
Un membre du personnel fait remarquer que la célèbre série télévisée britannique « The IT Crowd » (l’une de mes préférées !) reflète bien le quotidien des équipes informatiques. L’équipe informatique — qui interprète l’acronyme CIO comme « Career Is Over » (ma carrière est finie) plutôt que comme Chief Information Officer (directeur des systèmes d’information) — estime qu’une promotion n’est pas forcément une bonne chose. Faire profil bas permet d’échapper à la bureaucratie de l’entreprise. Cela m’a fait penser aux « floaters » (personnages sans rôle précis) que l’on voit dans certaines émissions de téléréalité.
Au fur et à mesure que l'affaire PU prend de l'ampleur, les soupçons s'intensifient et des théories du complot voient le jour quant à la manière dont les concurrents parviennent sans cesse à prendre de l'avance sur eux. Y aurait-il des fuites ?
Et ce n'est pas tout. Les cahiers des charges ne sont pas rédigés. Malgré les besoins du service marketing en matière de haute technologie, les services informatiques et opérationnels ne sont absolument pas consultés, et le service marketing externalise souvent les achats informatiques, contournant ainsi complètement ce département.
Les transferts de responsabilité, en particulier entre le développement et l'exploitation informatique, ne sont jamais bien gérés. Il y a ces projets « ROUND-TUIT » qui reviennent sans cesse : les mises à niveau et la maintenance informatiques sont constamment reportées, car des urgences imprévues et d'autres priorités prennent le pas. C'est une véritable guerre de clans.
L'évaluation — Le système est défaillant
Bill prend sa promotion — ainsi que toutes les situations d'urgence à régler — avec sérénité. Son style de management, qui consiste à se déplacer au sein de l'entreprise (et à poser les questions qui fâchent), l'aide à replacer les problèmes de l'entreprise dans une perspective globale, en les replaçant dans le contexte de l'activité elle-même.
Il sait que les équipes opérationnelles ne devraient pas avoir à jouer le rôle de pompiers, et bien que PU, en tant que grande entreprise, dispose de plus de personnel pour faire face aux « exercices d'incendie » quotidiens au rythme effréné que les petites entreprises, les problèmes restent les mêmes. Tout est considéré comme urgent. Pourtant, si tout est urgent, peut-on vraiment traiter quoi que ce soit en urgence ?
Des processus, des procédures et des systèmes de gestion du changement sont en place, mais rarement respectés. L'absence de planification adéquate, où « tout le monde se retrouve autour d'une même table », est la norme. Les environnements de test nécessaires font défaut, soi-disant par manque de budget. Des dates de mise en production arbitraires sont fixées, sans tenir compte le moins du monde de ce qui doit réellement être mis en œuvre avant le déploiement.
Le soutien ne vient pas des échelons supérieurs de la hiérarchie de l'entreprise. La modernisation du matériel et la formation sont des luxes que l'entreprise ne peut se permettre. L'entreprise avance pour ainsi dire à l'aveuglette. Il n'y a aucune vision d'ensemble de la situation. La main gauche ne sait pas ce que fait la main droite.
La proactivité n'est qu'une réflexion après coup. La transparence est absolument indispensable.
La réalisation des projets est dictée par des échéances arbitraires — mais toujours urgentes —, imposées par des engagements externes pris par la direction sans une compréhension complète des problèmes internes. L’équipe de développement se voit alors contrainte de recourir à des raccourcis scandaleux et inacceptables pour respecter les délais. Le produit sera presque à coup sûr inutilisable, et ceux qui l’ont réclamé à grands cris seront gravement déçus. L’expérience client sera si mauvaise qu’elle poussera les clients vers la concurrence. Les équipes informatiques devront faire tout leur possible pour que le produit fonctionne – et dissimuler ce qui se passe en coulisses.
L'équipe met tout en œuvre pour éviter que la perfection ne soit l'ennemie du bien. Cependant, les répercussions sur l'activité seront dévastatrices ; l'entreprise ne fonctionne pas à l'échelle d'une grande entreprise.
Le logiciel Phoenix, qui vient de sortir, fait un tabac.
Point de défaillance unique — Qui est votre « Brent » ?
Et puis il y a le « point de défaillance unique » : cet employé indispensable qui est au cœur de tous les projets importants et qui est tiraillé dans mille directions différentes. Il semble que rien ne puisse se faire sans son intervention. Il est impossible de le remplacer ou de le reproduire. Dans « The Phoenix Project », il s'appelle Brent.
Il est impossible de gérer la production sans disposer d'une liste centralisée des projets : le service des achats ne connaît pas ses priorités en matière de demande ni ses engagements, ni l'état d'avancement des travaux en cours, ni la disponibilité des ressources. Le service des opérations informatiques se retrouve au cœur de tous les flux de travail, ce qui crée un goulot d'étranglement au niveau des travaux en cours, des livrables des projets, des pannes et de la conformité.
Chez PU, consacrer du temps à définir les priorités était considéré comme une perte de temps. L’entreprise ne suit pas la règle générale selon laquelle, lorsqu’une tâche devient plus urgente, une autre doit être reléguée au second plan. Elle n’a pas encore trouvé le moyen de réduire le volume des interventions correctives afin de pouvoir se consacrer à des projets générateurs de chiffre d’affaires.
Comment remédier au point de défaillance unique de votre entreprise ? Le livre commence par expliquer la théorie des contraintes.
Qu'est-ce que la théorie des contraintes ?
La théorie des contraintes (TOC) est un concept de gestion selon lequel seules quelques contraintes (ce point de défaillance unique au niveau des effectifs, ou ce goulot d’étranglement, par exemple sur une chaîne de production) vous empêchent d’atteindre vos objectifs. En concentrant vos efforts, vous pouvez identifier la nature de cette contrainte et trouver des solutions pour la contourner. Pensez à l’expression « une chaîne n’est pas plus solide que son maillon le plus faible ».
Mais si vous apportez une amélioration ailleurs, que ce soit en amont ou en aval du goulot d'étranglement, cette contrainte persiste. Dans notre scénario de production, le travail s'accumule en amont, tandis qu'en aval du goulot d'étranglement, les stocks de produits en cours de fabrication (WIP) sont insuffisants.
La gestion des processus dans le cadre du DevOps n'est pas si différente de celle de la production industrielle ou de la gestion d'une usine, et inversement. Chaque service peut tirer des enseignements des autres. Les mêmes outils et techniques peuvent être utilisés pour documenter les processus, identifier les gaspillages en temps et/ou en matériaux, et améliorer l'ensemble du système.
L'un des membres du conseil d'administration de PU a encadré Bill. Sa personnalité a permis de mieux cibler la tâche à accomplir en définissant les « quatre types de travail » et les « trois méthodes ».
Comprendre les trois voies
Les « Trois Principes » décrivent les valeurs et les philosophies qui sous-tendent les processus, les procédures et les pratiques de chaque système. L'objectif de toute entreprise, de chaque service et de chaque collaborateur est de comprendre véritablement — et d'apprécier — le système afin d'améliorer son travail et de fournir de meilleurs produits et services :
- Pensée systémique— Maîtriser les contraintes et accélérer le flux de travail, en procédant de gauche à droite (pour obtenir des résultats plus rapidement)
- Renforcer le retour d'information — Raccourcir la boucle de retour d'information, en procédant de droite à gauche (pour offrir une meilleure qualité)
- Culture de l'expérimentation et de l'apprentissage— Favoriser et encourager les essais afin de mettre plus rapidement en pratique les enseignements tirés des échecs (réduire les risques et assurer une amélioration continue)
Comprendre les quatre types de travail
Le fait de compartimenter nos activités et d'attribuer des indicateurs à chaque type de travail nous aide à mieux identifier les goulots d'étranglement, c'est-à-dire les contraintes :
- Projets commerciaux— Travailler sur des projets ayant un impact direct sur le résultat net, tels que le lancement de nouveaux produits ou de nouvelles fonctionnalités
- Projets informatiques et opérationnels internes — Travaux nécessaires pour soutenir les projets métier tels que la R&D (recherche et développement), les nouvelles architectures, les infrastructures ou l'ingénierie
- Changements— Modifications apportées aux travaux prévus dans le cadre des « projets internes » venant en appui aux « projets métier »
- Tâches imprévues— Bugs, défauts, retouches, gestion de crise, etc., qui détournent l'attention des « projets métier » générateurs de chiffre d'affaires
Il apparaît clairement que les projets internes, lorsqu'ils sont menés à bien, ont un effet positif sur les projets commerciaux et permettent également de réduire le volume de travail imprévu.
Sans dévoiler la fin du livre (Project Unicorn !), disons simplement que les tensions s'intensifient jusqu'à atteindre un niveau que nul chef d'entreprise, ni aucun salarié, qu'il soit cadre ou non, ne souhaite atteindre.
La solution est à votre portée
- Automatisez autant que possible les processus récurrents, contrôlez et consignez le travail effectué (en particulier les modifications), puis vérifiez, vérifiez et vérifiez encore.
- Identifier les problèmes plus tôt, décomposer le travail en étapes plus faciles à gérer, faire le point avec toutes les parties prenantes pour vérifier les résultats, apporter les modifications nécessaires et livrer les livrables plus rapidement
- Standardiser pour obtenir des résultats de meilleure qualité, plus reproductibles, plus précis et plus rapides
- Communiquer
« The Phoenix Project » m’a fait voir beaucoup de choses sous un nouvel angle. Par exemple, tout est un système : une entreprise, une usine de production, le plan de transport d’une ville, voire votre famille ou votre propre corps. Les solutions pour gérer tous ces « systèmes » se ressemblent de manière troublante. Je ne saurais trop vous recommander de lire ce livre.
Points à retenir
- Mieux connaître ses clients peut être ce qu'une entreprise a de plus précieux à faire.
- La bureaucratie fait partie intégrante de toute entreprise. À mesure que celle-ci se développe, de nouveaux mécanismes de sécurité deviennent nécessaires pour garantir une communication fluide. Même si votre entreprise est de petite taille et que le personnel change régulièrement, ces problèmes de communication propres aux grandes entreprises peuvent également se poser.
- Le processus de gestion du changement est une discipline: sa mise en place est difficile, mais son absence est bien pire. « On ne peut atteindre l'objectif stratégique tant qu'on n'a pas maîtrisé l'aspect tactique. »
- Si quelqu’un vous demande comment vous avez résolu un problème, il n’y a rien de pire que de répondre « Je ne sais pas ». Consignez tout par écrit ! La prochaine fois que cela se produira, nous aurons la réponse. Savoir, c’est pouvoir. Un savoir qui n’est pas partagé ne sert à rien, et pire encore : il sème le chaos.
- Si un service atteint un objectif clé, mais qu’un autre service de l’entreprise en subit les conséquences négatives, ne faites pas la fête et n’envoyez pas d’e-mail à tout le monde. Ce n’est tout simplement pas correct. Vous n’avez sans doute pas apprécié, quand vous étiez en CM2, que toute votre classe — sauf vous — soit invitée à la fête d’anniversaire du « gamin cool ». Et si c’était vous le « gamin cool », vous devriez avoir honte. N’oubliez pas : personne n’est une île. On se débrouille tous ensemble. Attendez que tout le monde puisse faire la fête ensemble avant d’organiser la célébration.
- Si vous avez des nouvelles à partager, n’hésitez pas. Peut-être que le nouveau processus de gestion du changement qui vient d’être mis en place vous a évité une catastrophe — faites-le savoir ! Insistez sur ce qui fonctionne. Les félicitations, les encouragements et les remerciements ne prennent que peu de temps et ont un impact considérable sur le moral et l’enthousiasme. « Mieux vaut prévenir que guérir », mais le problème avec la prévention, c’est que les gens en ont rarement connaissance. Communiquez sur les réussites !
- Si chacun comprend en quoi son travail peut compromettre les indicateurs clés de performance (KPI) de l'entreprise, c'est-à-dire les mesures de la performance globale de l'entreprise, loin de se sentir démoralisé, il aura davantage tendance à se sentir responsabilisé et à prendre de meilleures décisions professionnelles et opérationnelles.
- Il y a toujours des problèmes. Ne tirez pas de conclusions hâtives. N’agissez pas à la hâte au risque d’aggraver la situation. Ne poignardez pas les autres dans le dos, ne rejetez pas la responsabilité sur autrui et ne cherchez pas à rejeter la faute sur les autres. Assurez-vous que des procédures sont en place. Respectez ces procédures. Impliquez-vous de manière proactive pour trouver une solution et améliorez les procédures si nécessaire.
- Apprenez à vous connaître — et à vous comprendre — tant sur le plan personnel que professionnel. Cela permet de renforcer le respect, la confiance et d’améliorer les relations de travail. Lorsque je fais la connaissance de quelqu’un, en particulier d’un collègue (ou d’un candidat lors d’un entretien d’embauche !), ma nouvelle question préférée est : « Qu’est-ce qui, selon vous, distingue une bonne journée de travail d’une mauvaise ? »
Conclusion
Lors de notre dernière réunion du club de lecture, mes collègues ont gloussé en constatant que chacun d’entre nous semblait se reconnaître dans un ou plusieurs personnages, traits de caractère et/ou comportements. Puis nous nous sommes ressaisis, nous avons pris du recul par rapport à ces réflexions, et nous avons discuté de nos propres progrès personnels dans nos efforts pour mettre en place davantage de structure, améliorer nos processus et faire preuve d’une plus grande ouverture au changement, afin d’offrir de meilleurs produits et services à nos clients.
xTuple accorde une grande importance à l'innovation, à la cohésion au sein de l'entreprise et au partage de points de vue divergents — tant en interne, avec nos collaborateurs, qu'en externe, avec nos clients et la communauté technologique au sens large.
Mettons fin à cette folie et communiquons. Mettons en place un processus clair et durable, sur lequel tout le monde s'accorde. Les définitions sont importantes. La compréhension est importante. Continuons à peaufiner le processus jusqu'à ce qu'il fonctionne. C'est possible.
