À l’heure actuelle la mouvance DevOps est à la mode, comme les méthodes Agile en fait. Sauf que dans bien des organisations la transition vers une mouvance DevOps est un échec patent. Il se trouve qu’à un moment où l’autre les entreprises qui veulent passer en mode DevOps font appel à un ou plusieurs consultants externes, ce qui peut être une bonne idée… ou une des causes de l’échec de la transition. Nous voyons dans la suite de l’article les attitudes à éviter tant de la part des consultants que des entreprises.
La tendance DevOps étant récente, on voit beaucoup de gens penser que le ou les DevOps se placent entre les développeurs et les opérationnels ou gens de la production, autrement dit que ce sont des intégrateurs. C’est une grave erreur. Les méthodes DevOps sont une extension de l’agilité qui visent à améliorer la confiance dans ce que vous livrez tout en réduisant votre time-to-market. Réduire le rôle de DevOps à celui de la personne qui fait le packaging de votre application risque de vous causer quelques problèmes de turn-over.
Pour rappel le DevOps consiste à :
Comme vous pouvez le voir la mise en place du DevOps est bien étendue que la seule intégration, et faire venir un consultant DevOps pour faire uniquement de l’intégration, autrement dit du packaging, c’est l’inciter à prendre ses jambes à son cou. Donc ne faites pas d’offres de postes DevOps simplement parce que c’est un terme sexy s’il vous plaît, vous courez droit à l’échec.
La méthodologie DevOps peut être longue et parfois éprouvante à mettre en place pour les consultants en raison d’incompréhensions de l’entreprise cliente. Cependant ceux-ci ne doivent en aucun cas être condescendants ou méprisants vis-à-vis du client et ce même en privé car dans ce dernier cas leur posture finit par être ressentie par l’entreprise cliente. Par exemple, un consultant DevOps ne devrait jamais employer en privé des phrases comme « je fais de l’humanitaire en les aidant à mettre en place de DevOps » car ceci finira par être ressenti par le client.
Par ailleurs une méthodologie DevOps doit être adaptée au cas par cas suivant les clients, tout en restant intransigeant sur l’essentiel à savoir les tests et le déploiement automatisés et répétables. Mais les clients ont aussi souvent de bonnes idées pour s’adapter à leur contexte, aussi il est important de les prendre en compte et faire preuve de pédagogie.
Il n’empêche que côté client il est important que la hiérarchie soutienne les consultants DevOps sinon le projet est déjà mort. Et il est important aussi que le client sache écouter le ou les DevOps sans faire de demande totalement farfelue. Un jour on m’a demandé de faire des RPM relogeables. J’ai expliqué au client que ce n’était pas une bonne idée car RedHat le déconseille et ce dernier m’a répliqué : « on te paie cher donc débrouille-toi pour nous faire des RPM relogeables ».
Se prendre pour Dieu sur Terre est une attitude encore plus extrême que celle évoquée ci-dessus. Ceux qui ont un tel comportement tiendront des propos du type : Je ne vais certainement pas adapter mes méthodes de travail pour vous – soit vous vous adaptez soit vous dégagez » ou encore voudront dégager tous ceux qui veulent se mettre en travers de leur chemin.
Même si ces propos ne sont pas prononcés ouvertement vos interlocuteurs les ressentiront à travers de mimiques inconscientes de votre part. En effet 80% d’une communication vient de ce que votre corps exprime, et pas ce que vous dites réellement.
La méthodologie DevOps pousse notamment à casser la notion de silos afin de fluidifier les projets. Or en adoptant une attitude du type ceux qui m’emm… dégagent vous allez surtout réussir à liguer vos interlocuteurs contre vous. Alors peut-être réussirez-vous à casser ainsi les silos pour un temps, mais ceux-ci vont se reformer immédiatement après, avec une ambiance fortement dégradée. Autrement dit en adoptant une attitude comme ci-dessus vous ne ferez que du mal à l’organisation que vous êtes censé aider, et laisserez derrière vous une sorte de terre brûlée.
Il m’est déjà arrivé d’échanger avec des consultants DevOps qui avaient cet état d’esprit et disaient eux-mêmes : « j’ai échoué les transitions DevOps partout où je suis passé, mais ce n’est pas grave car à chaque fois j’ai gagné de l’expérience ». Le problème est que ces individus n’ont jamais pu se remettre en cause, et que la raison de leur échec est précisément leur état d’esprit. Il va sans dire que je déconseille fortement de faire appel à de tels consultants pour votre transition DevOps, vous courez droit à l’échec.
Une entreprise qui veut réussir sa conversion vers le DevOps doit vraiment écouter les consultants qu’elle engage, et faire ce qu’ils lui suggèrent de faire. Cette transition peut être douloureuse, mais plus l’entreprise est coopérante mieux la transition se passera. Maintenant un consultant qui se prend d’emblée pour Dieu sur Terre ou méprise son client fera échouer toute transition DevOps qu’il entreprendra, et il est de la responsabilité de l’entreprise de bien interroger les gens qu’elle recrute pour éviter de telles personnes.
Besoin de tester ton niveau en développement informatique ?
Cet article vous a plu ? Vous aimerez sûrement aussi :
Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.
Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
Les maladies inflammatoires chroniques de l’intestin ou "MICI" sont invisibles, mais leurs impacts sur la…
Depuis l'été, j'ai un Pixel qui intègre à la fois un TPU (Tensor Processing Unit)…
On se retrouve dans un nouvel article avec toutes les infos sur cette nouvelle saison…
Pourquoi l’inclusion numérique est essentielle : le point avec Mathieu Froidure. Dans un monde de…
Elles sont passées où les femmes dans la tech ? Entre le manque de représentation…
