Accueil > Devops > DevOps par le contre-exemple

DevOps par le contre-exemple

Cet article est proposé par Henri Darmet, qui, s’il n’est pas un spécialiste du DevOps, adhère à l’idée qu’il faut fluidifier les relations entre les équipes de développement et celles qui assurent la production. Si le « comment » reste encore pour lui nimbé de mystères, le « pourquoi » se précise diablement. Il s’intéresse donc ici à ce qu’il connait le mieux : le problème, pour finir par proposer, en fin d’article, des pistes de solutions. Et histoire de rendre ça très concret, il l’explique sous forme d’une histoire que voici…

L’entreprise EasyTelco a décidé de moderniser son outil de prise de commandes (du BtoB), aujourd’hui basé sur des programmes GAP tournant sur une batterie d’AS400. Le CRM, en cours d’installation sera impacté puisqu’EasyTelco a décidé que la cohérence de son SI devait être renforcée. Pour mener toute l’affaire à bien, de nombreux chantiers ont été identifiés :

  • Modifier les programmes GAP afin de tenir compte de la définition des nouveaux produits,
  • Définir un jeu de WebServices permettant d’accéder aux fonctions essentielles de legacy AS400,
  • Développer en WebRIA (JQuery + Services REST sur Tomcat), une interface de prise de commandes. Notons que cette interface est munie de sa propre base de données, car le legacy ne connait que la notion de commandes fermes, pas celles de prospects, de devis, etc. Cette application doit être utilisée par le personnel commercial d’EasyTelco, pas par les clients finaux.
  • Permettre aux différentes applications d’accéder à des WebServices externes, comme ceux de Societe.com afin de récupérer, au besoin, des informations d’entreprise sur les nouveaux clients. Un WebService interne doit être développé pour extraire ces informations. C’est à lui d’interroger soit la base AS400 (lorsque le client est déjà connu), ou le WebService externe.
  • Mettre à jour le portail client afin de le doter de fonctions permettant à un client de passer directement commande, sans devoir passer, comme c’était le cas jusqu’à présent, par les services commerciaux d’EasyTelco.

L’ensemble est donc plus qu’un projet : c’est un programme. Un coordinateur/directeur de projets a été nommé pour que toutes les pièces s’assemblent le plus harmonieusement possible. Et il a du travail, le bougre, car la façon dont est organisée la DSI d’EasyTelco, impose de faire ça très soigneusement :

  • Les équipes sont divisées en silos fonctionnels et techniques.
    • On a donc une équipe de dev GAP/AS400 « Commandes et Facture », une autre « Référentiel client », etc. Elles sont basées à Nantes. Notons que les équipes AS400 gèrent elles-mêmes leurs mises en production et leur RUN.
    • Il y a une équipe plateforme WebService (qui heureusement s’occupe des WebServices pour tous les silos fonctionnels). Elle est basée à Meudon.
    • Il y a une équipe « Portail Client » qui occupe une annexe du siège social à Boulogne.
    • Une équipe d’intégration, basée à Meudon, s’occupe des recettes et du packaging des nouvelles applications. Elle est distincte de l’équipe de production, basée elle à Nantes, et qui est sous-traitée, pour partie, à une SSII : SmartDev.
    • La gestion des bases de données est, elle, confiée à une cellule spécifique, la cellule DBA, relevant théoriquement de la production, mais travaillant en fait, de façon complètement autonome (à Nantes, elle aussi).
    • La gestion du réseau et de la sécurité est confiée à une cellule « réseau », basée à Meudon.
    • Il y a une cellule d’architecture, bien sûr, qui fait ses recommandations depuis Meudon. Pour tout ce qui relève du juridique et de la sécurité (relation CNIL par exemple), elle se coordonne avec une cellule Juridique/Sécurité basée à Boulogne.
  • Par le passé, EasyTelco a enregistré de nombreux couacs dans les mises en production et le RUN qui a suivi. Pour interdire (ou quasiment), que cela se reproduise, le processus de livraison a été industrialisé :
    • Lorsqu’une équipe de développement est prête à livrer, elle soumet à l’équipe d’intégration un « package » dont la structure et la documentation doivent respecter un des documents DSI-DCT-xxx-DEV.doc (xxx = plateforme technique : .NET, Java).
    • L’équipe d’intégration déploie l’application sur une plateforme dite d’intégration en respectant la procédure qui lui a été fournie par l’équipe de développement.  Si tout se passe bien, elle redéploie l’application sur une plateforme dite de « recette » sur laquelle les équipes MOA effectuent leurs tests. Enfin, si un GO de mise en production est donné, l’équipe d’intégration passe le bébé à l’équipe de production.
    • L’équipe de production déploie l’application sur une plateforme de pré-production. Après un test rapide de la MOA et si tout s’est bien passé, l’application est déployée en production.
    • Parallèlement, bien sûr, l’équipe de développement aura fourni un dossier d’installation et un autre d’exploitation, validés par l’équipe d’intégration puis celle de production qui en aura extrait un cahier d’exploitation.
    • Les équipes d’intégration et de production (au sens large, c’est-à-dire comprenant la cellule DBA et la cellule réseau), assaillies de partout, ont installé un outil de ticketing (JIRA) par lequel tous les solliciteurs doivent passer. Un créneau est alors réservé à chaque demande.
  • Il n’a pas échappé à EasyTelco que ce processus était un peu lourd. Alors, pour rendre la chose un peu plus digeste aux équipes de développement, on a créé une cellule de « coordination technique ». La logique est la suivante :
    • A chaque projet, on associe un chef de projet « opération », qui s’occupe des problèmes d’organisation
    • et un chef de projet « technique », qui s’occupe des questions techniques (redondance des machines, ouverture de ports, déclaration de comptes LDAP, etc…)
    • La cellule de coordination technique est basée à Boulogne.

Il n’aura probablement pas échappé au lecteur attentif que ce dispositif ne définit pas d’équipe « Outil de vente », alors qu’un projet WebRIA à destination des commerciaux est programmé : normal, ce projet a été confié à une SSII Parisienne : TetraSoft. C’est elle qui ensuite en assurera la TMA. TetraSoft a terminé ses développements au début de l’été pour une mise en production chez EasyTelco au début de décembre (juste avant le gel des confiseurs). Ses équipes sont passées à autre chose.

Notre histoire commence donc le 4 septembre lorsque notre coordinateur décide de demander à TetraSoft quelques ajustements mineurs avant de livrer à l’intégration, le premier candidat pour une recette. Il y en a pour cinq jours de travail, il faut, en particulier rédiger ce fameux cahier d’exploitation, indispensable aux équipes de production.

  • Notre coordinateur – appelons-le Pascal – téléphone à TetraSoft pour s’entretenir avec le directeur du projet EasySell, le projet WebRIA dont il est question plus haut. Ce dernier vient juste de rentrer de vacance et ne sait plus trop où en sont ces équipes. Il va se renseigner. Il rappellera.
  • Il rappelle en effet le 9, après avoir reçu deux autres mails d’un Pascal qui se demande si on ne l’a pas oublié. « Pas de chance » répond-il à Pascal, « entre Pierre qui est malade, Marie qui va accoucher, Tran qui est parti sur une mission à Singapour et Juline qui est encore en Corse, il ne peut solliciter personne avant le 18. »
  • Le 19, TetraSoft rappelle. La journée du 18 a été consacrée à l’étude des demandes de Pascal. Charge estimée : 6 jours. C’est Juline qui s’y colle. Mais comme elle a quelques trucs à terminer, elle ne sera là que le 21.
  • Juline vient faire les ajustements le jour prévu et termine le 29 car finalement, l’estimation était un peu courte. Pascal fait le point avec elle : tout est en place. On a passé la dernière heure à tester, c’est du bon travail. Juline s’est même frayé d’une petite note complémentaire d’installation. Le soir même, Pascal transmet à Yves, son « coordinateur opération » la demande d’intégration. Il le fait par mail car Yves est encore en réunion (les réunions occupent les managers d’EasySoft entre la totalité et les deux tiers de leurs temps).
  • Yves ne voit le mail de Pascal que le lendemain (le 30 donc) à midi. Il instruit la « JIRA » sollicitant une mise en intégration. Yves est pressé : des mails, il en a quatorze du jour, non lus qui viennent s’additionner au trente-sept des jours précédents. Et il est attendu pour un déjeuner à l’extérieur. Il n’a pas pris le temps de lire la petite note de Juline pourtant passée en pièce jointe. Dommage, elle expliquait deux choses :
    • qu’elle avait sécurisé les WebServices et que par conséquent, il fallait ouvrir le port LDAP.
    • que le schéma de la base était légèrement modifié et que par conséquent, il fallait passer un script de migration.
  • Kevin de l’équipe d’intégration traite la demande JIRA le 31 au matin. Premier créneau disponible : le 7 octobre. Il renvoie une proposition en ce sens à Yves, qui ne la lit que le lendemain. Il rédige un mail pour informer Pascal, lui aussi inondé de mail. Bref, Pascal sait le 2 que l’installation en intégration ne sera faite que le 7 : trop tard pour réagir.
  • Le 7, Francine de l’équipe d’intégration exécute la tâche demandée par Pascal, via Yves et programmée par Kevin. A midi, elle a fini, tout s’est bien passé (elle n’a pas tenté d’exécuter l’application, ce n’est pas son job). Elle complète la JIRA. Pour elle : end of the story.
  • Le 8 au matin, Yves, qui vient de passer en revue ses JIRA, envoie un mail à Pascal pour lui indiquer que son installation est terminée. Pascal, qui commence à trouver le temps long saute dessus, et vite, vite, va faire quelques tests. La réponse est brutale : le serveur est inaccessible.
  • Il téléphone à Yves qui n’est pas disponible. Pascal envoie donc un mail. Ce mail est pris en compte par Yves, au cours d’une réunion qui a lieu entre 14 et 15 heures (car il y a tellement de réunions chez EasyTelCo que la plupart des invités pianotent sur Outlook pendant que le speaker monologue). Yves n’a pas le temps de traiter en séance (il faut bien participer un peu à la réunion en cours). Comme il subodore un problème de DNS, il fait un « JIRA » en ce sens à l’adresse de la cellule réseau.
  • Nathalie, de la cellule réseau détecte, le 9, le « JIRA » d’Yves. Elle réserve un créneau pour le 11. Yves a de la chance, c’est rare d’avoir un créneau aussi vite.
  • Le 11, hélas, Manuel, à qui cette tâche était affectée a rencontré un gros souci avec les boitiers F5 et il a zappé la demande d’Yves. Il le signale à Nathalie – par mail. Nathalie qui s’en rend compte le 12, recherche un autre créneau pour Yves : ce sera le 15. Yves prend connaissance de la replanification le 13 et via mail, avertit Pascal ce même jour (en fin d’après-midi).

Vous suivez toujours ? Oui ? Je continue.

  • Le 15, en fin d’après-midi, Manuel à fini. Mais il ne met le « JIRA » à jour que le lendemain matin et par conséquence Yves n’en prend connaissance qu’à 15h. Il transmet la bonne nouvelle à Pascal, par mail. Comme Pascal anime un « Comité Projet » pendant tout l’après-midi, il ne s’en rend compte qu’à l’arrivée à son bureau : il est 18h30. Avec le compte-rendu qu’il doit rédiger, il n’a plus le temps de vérifier quoi que ce soit avant le lendemain.
  • Et justement, le lendemain, le 17 donc, il s’aperçoit que le programme « plante » dès le second écran. Pourquoi ? Il aimerait bien le savoir ! Mais pour cela, il faudrait qu’il puisse regarder les logs. Hélas, il n’a pas accès à la machine d’intégration. Il téléphone à Yves, décidément injoignable. Il consigne donc son problème par mail et part pour sa prochaine réunion.
  • Yves, qui a conscience que la petite plaisanterie dure depuis un peu trop longtemps, appelle directement l’intégration. Réponse : « fais une JIRA, c’est le process, mon gars ! ». Yves s’énerve, fait remarquer que si on continue comme ça, on risque « le ballet des chefs ». En vain. A l’autre bout du fil, Kevin n’a qu’un seul mot : JIRA, JIRA, JIRA. Alors Yves se résigne : il fait la JIRA.
  • La JIRA tombe dans les mains de Marion, la « back-up » de Kevin, le lendemain (le 18, donc). Marion comprend que ce n’est rien du tout comme opération, mais hélas, elle ne connait rien à cette application. Il faut qu’elle contacte Francine. Mais Francine a pris un jour de congé. Elle interroge Kevin, qui lui dit que cela peut bien attendre lundi. « Okay pour lundi » soupire Marion. Action programmée pour Francine le 21 au matin : envoyer les logs à Yves.
  • Francine « fait le boulot » le 21, juste avant d’aller déjeuner (elle n’avait pas que ça à faire). Yves qui est, cette fois, à son poste, au bon moment pour recevoir l’info, stocke les logs sur un disque partagé et tente de joindre Pascal, hélas en réunion. C’est en dépilant ses mails, à 18h, que Pascal comprend qu’enfin, il dispose de l’information demandée. Vite, vite, il va consulter les logs (il est un peu technicien sur les bords) et comprend qu’il y a un problème avec le schéma de la base. Comment est-ce possible ? Il n’en sait rien. Juline de TetraSoft doit savoir, elle. Il l’appelle. Une voix lui répond que Juline est en clientèle et qu’il faut passer par Matthieu, son chef pour toute sollicitation, merci. Alors Pascal rédige un mail pour Matthieu.
  • Matthieu se décide à rappeler Pascal le surlendemain, car Pascal a envoyé trois mails avec de plus en plus de chefs en copie et qu’il est temps d’arrêter l’inflation. « Allo Pascal ? De quoi s’agit-il ? Ah oui… Ah bon… Juline ? D’accord. Je vais voir ce que je peux faire. » Ce qu’il peut faire, après avoir conversé avec Juline, c’est organiser un point téléphonique le lendemain, le 24 donc, à midi.
  • Le 24 à midi, point téléphonique avec Juline. Juline comprend tout de suite, sans même avoir elle-même consulté les logs, que le script de migration de la base n’a pas été passé. Elle explique à Pascal qui fulmine contre Yves. Fin du point. Après déjeuner, Pascal appelle Yves. Yves est absent. Pascal rédige un « SCUD ». Le « SCUD » atteint Yves en pleine réunion. A la pause, il appelle Pascal. L’explication est musclée : « Il faut lire les mails ! » clame Pascal. « Je ne fais que ça, dix heures par jour ! » rétorque Yves.
  • Yves, furieux mais confus fait une JIRA à destination de la cellule DBA, pour qu’enfin, on le passe ce p… de script ! Bien sûr, pendant ce temps, il n’écoute pas ce qui se dit dans la réunion. Il vient de louper le fait qu’il faudra déclarer deux comptes techniques sur le LDAP pour l’application de GMAO. Le prochain « drame » est « armé »…
  • La cellule DBA reçoit le JIRA le 25. Et comme c’est urgent, l’action est programmée pour le 28 par Sébastien (il y a le week-end entre temps). Bel effort. Le 28, Gaëtan tente de passer le script. Erreur SQL. Gaëtan investigue un peu et se rend compte, qu’il va avoir besoin d’aide. Il envoie un mail à Yves où il explique vaguement son problème et passe à autre chose. Yves, échaudé, transfère immédiatement le mail à Pascal. « Le voyage de retour » a néanmoins pris tout l’après-midi et il est trop tard pour que Pascal puisse rappeler Juline via Matthieu.
  • Le 28 au matin, donc, Pascal appelle TetraSoft, mais n’arrive à joindre Matthieu qu’à 16 heures qui lui, n’arrive à joindre Juline qu’à 18 heures. Une conférence à trois est prévue pour le lendemain à 10 heures « si cela ne dure pas trop », car Juline doit assurer une démo à 10h30.
  • Le 29, 10h30, Pascal, Matthieu et Juline décident d’une réunion tripartite entre Gaëtan de la cellule DBA, Pascal et Juline. A Pascal de l’organiser. Pascal appelle Yves qui est en réunion. Il envoie donc un mail. Yves reçoit le mail en début d’après-midi et appelle Gaëtan. Gaëtan propose trois dates : le lendemain à 12h30, mais il n’a qu’une demi-heure, le surlendemain de 16 à 18 heures ou le mardi suivant, le 5 novembre à 10 heures.
  • Après concertation avec Juline et Matthieu, la première date « faisable » pour Juline est le mardi 5 novembre.

Depuis le 4 septembre, deux mois viennent de s’écouler. Déjà dix acteurs, des dizaines de mails et de JIRA. Et on est loin du compte ! Car il y a aussi le compte LDAP à déclarer qu’Yves a oublié et que Pascal a omis de lui rappeler. Et il y a aussi toutes les autres composantes du projet géré par Pascal qui souffrent pareillement, chacune dans sa propre galère.

Alors, à qui la faute ? A TetraSoft qui ne sait pas se rendre immédiatement disponible ? A l’intégration qui ne réagit jamais assez vite ? A Yves qui surchauffe en permanence ? A Pascal qui ne sait pas anticiper l’imprévisible ?

La faute n’incombe pas aux acteurs, tous sérieux et dévoués. Et tous, quoi qu’il arrive, faillibles.  Aucun d’entre eux ne peut réellement mieux faire. La faute incombe à l’organisation, totalement inadaptée à la mission. Une organisation de ce type convient peut être bien à une usine qui produit UN modèle de voiture, toujours le MEME pendant DES MOIS. Mais pour une DSI en perpétuelle évolution, elle est démentielle. Analysons pourquoi :

  • Elle gaspille le temps. Toute question qui pourrait être traitée en quelques minutes, l’est en presque autant d’heures, si ce n’est de jours. La raison en est très simple : le processus est complètement asynchrone avec des temps de latence « mail ».
  • Elle gaspille l’information. En multipliant les acteurs, on dilue la connaissance, on affadie les messages. Le mail, en particulier est un vecteur très pauvre, car l’écrit présente le pire rapport information/effort. Si cet effort peut se justifier lorsqu’on veut pérenniser l’information (spécification, documentation), il devient absurde pour simplement expliquer une action « one shot ».
  • Elle gaspille l’effort. Une charge considérable est dépensée en rédaction et lecture de mails, de JIRA, de feuilles excel en tout genre. Donc il faut plus d’acteurs pour l’assumer. Donc plus de réunions pour les informer, donc encore plus de mails pour qu’ils se coordonnent, donc encore plus d’acteurs, etc…
  • Elle stresse. La charge de certains acteurs devient terrible. Ils ont peur des reproches et donc ne veulent rien louper de ce qui touche à leur périmètre. Ils enchainent réunions sur compte-rendu, rédigent et rédigent encore des mails qui les garantissent contre les aléas. L’entreprise devient alors une arène où « l’ennemi » est le service d’à côté et non la société concurrente. Délivrer n’est plus l’objectif. Ce qu’il faut, c’est accumuler les « preuves » qu’on a bien fait son travail et que s’il y a problème, c’est la faute de « l’autre ».
  • Elle sclérose. Chacun, spécialisé sur son petit domaine n’a plus le temps de comprendre ce qui se passe autour. Et donc, comme l’ouvrier spécialisé d’une caricature de taylorisme, il répète sur sa machine, le geste pour lequel il est missionné. Il n’utilise plus, ni son esprit de synthèse, ni son sens de l’initiative. L’intelligence collective, n’est plus constituée des cerveaux des humains, elle est diluée dans les mails…

Alors que faire ? La réponse est à deux niveaux :

  • Adopter un style de management qui récompense la réussite plutôt que de punir l’échec.
  • Adopter une organisation simplifiée qui présuppose la confiance et la compétence et qui responsabilise tous les acteurs.

En bref, et pour paraphraser une des valeurs de l’agilité : privilégier l’homme à l’organisation.

Vous ne voyez pas où je veux en venir ? Okay. Prenons la machine à remonter le temps et revenons au 4 septembre. Ou même plus tôt encore : au début de l’année, au moment où TetraSoft commence ces développements :

  • Chaque matin, à 9h30, Francine, de l’intégration/production (il n’y a qu’un service) assiste au daily-meeting du projet. EasySell. C’est « son » projet, qu’elle partage avec Marion. Elle comprend ce que fait le projet, quels seront ses besoins. Si elle ne participe pas directement aux développements, elle peut apporter des conseils, prévenir de certaines difficultés. Elle va elle-même rédiger dossier et cahier d’exploitation comme personne ne peut le faire mieux qu’elle : elle a tous les éléments en main. S’il lui manque une information, elle pourra, juste après le daily, aller la chercher à la meilleur des sources : l’équipe elle-même.
  • Comme elle a deux projets de ce type à gérer, Francine consacre en moyenne une heure par jour à soutenir les projets à venir. Le reste du temps, elle effectue les tâches normalement dévolues à l’intégration/production. En cas de problème, elle appelle immédiatement la bonne personne de l’équipe, ce qui lui est facile, puisqu’elle la connaît. D’ailleurs, pour EasyCell, Francine et Marion ont largement anticipé, sans même que Pascal le leur demande : elles ont installé les machines d’intégration, de recette et de production, dès février. A chaque fin d’itération, avec Hervé, de l’équipe de développement, elles font « tourner » l’intégration continue pour s’assurer que ce qui est développé se déploie correctement (à défaut de fonctionner parfaitement).
  • Francine et Marion sont multi-compétentes : elles connaissent bien les problèmes liés à la production. Elles savent comment administrer une base de données, configurer le réseau et le LDAP. Au début Francine était plutôt DBA et Marion, plutôt réseau. Mais comme EasyTelCo à généralisé le « Pair-Working », elles sont très rapidement montées en puissance sur les sujets qu’elles connaissaient moins en se formant l’une, l’autre. Marion qui attend un heureux évènement pour Noël est confiante : elle sait que Francine saura « assurer » tout en accompagnant la prise de connaissance de Paul qui vient d’arriver, toujours en « Pair-Working ». Francine, elle, est ravie de travailler chez EasyTelCo : elle sait que le rôle qu’on lui fait jouer et les connaissances qu’elle a acquises, préservent son employabilité.
  • Par ailleurs TetraSoft a intégré Eric d’EasyTelCo dans l’équipe de développement. C’est le moyen, le plus simple, le plus sûr, le moins coûteux et le plus efficace pour s’assurer d’un haut niveau de réversibilité. C’est tellement évident qu’on se demande pourquoi il a fallu attendre 2012 pour systématiser cette pratique. TetraSoft a un peu râlé, mais on ne leur a pas laissé le choix. Quand TetraSoft partira,  Eric pourra suivre la maintenance de près, sans prise de risque notable pour EasyTelCo.

Nous sommes donc le 4 septembre. L’application est déployée sur la plateforme de pré-production depuis longtemps. Pascal, qui a donc des ajustements à faire faire, appelle TetraSoft.

  • Impossible de joindre le directeur de projet TetraSoft. Pascal appelle Didier, le Directeur des Etudes. Didier tranche : « il faut déployer EasySell le plus vite possible. On dégage Eric pour quelques jours. Sa mission actuelle n’est pas prioritaire. »
  • Eric se met au boulot dès le 9 (il a demandé deux jours pour « finir » le travail en cours). Le 12, il a terminé. Il lui a fallu quatre jours (le cahier d’exploitation a été rédigé depuis longtemps par Francine). Il va voir Marion et Francine et explique ce qui a été fait. J’ai bien dit : il va « voir », c’est-à-dire qu’il a dépensé quelques calories  pour traverser le bâtiment, il a toqué à leur porte et la réunion a commencé devant une tasse de thé (où il a récupéré les calories perdues J). Il indique qu’il y a une légère correction de base de données à faire et un compte LDAP à déclarer. Okay ont répondu Marion et Francine, on fait ça mardi prochain, le 17. Cette date est importante pour Eric : il sait qu’il doit être disponible. La réunion se termine par un petit mail récapitulatif à Pascal. « Salut les filles ! Salut Eric ! »
  • Le 17, comme prévu, Marion et Francine font « tourner » l’intégration continue. Tout ce passe bien. On déclare l’utilisateur dans LDAP. On passe le script SQL. Zut, il y a un problème. Marion qui connait relativement bien l’application, voit la modification à faire. Elle appelle Eric pour être sûr. Eric prend la demi-heure nécessaire pour les aider. Il fait une chose incroyable : il se déplace jusqu’à elles. Okay, le script est ajusté et appliqué. On lance l’appli. Rezut, un autre problème : elle est inaccessible. « Ah oui ! » se rappelle Francine, on a modifié le DNS, il faut redéclarer le serveur. Elle sait faire. Elle ouvre l’outil qui convient. Voilà, c’est fait. On lance, ça marche. Assez fièrement, le trio co-rédige un message de réussite à Pascal.
  • Nous sommes le 17 septembre, il est 15h30, l’application est en pré-production. Cinq acteurs (en comptant Didier et Pascal), deux meetings, deux mails.
  • Pascal félicite Eric, Marion et Francine. Il annonce la bonne nouvelle à Didier qui à son tour félicite Pascal, Eric, Marion et Francine. EasyTelCo vient de gagner deux mois de « time to market » et d’épargner des milliers d’euros. Pendant ce temps Yves assure la direction d’un autre projet et Gaëtan, Kevin et Nathalie sont en train d’apporter une aide tout aussi efficace sur le portail client. Le projet dans son ensemble est déployé le 10 octobre.
  • Le 11, on fête ça au champagne. Tout le monde est là. EasyTelCo n’a pas lésiné sur les petits fours. Une équipe de qualité, ça s’entretient.

C’est idéal ? Ah bon ? Pourquoi ?

Les responsabilités sont strictement respectées : la production reste entièrement dans la main d’équipes dont c’est la mission. Ces équipes sont infiniment mieux préparées pour affronter les aléas de production que celles d’EastTelCo v1.0. Le risque d’incident n’est pas supérieur, le temps d’analyse et de correction est plus réduit, d’un ou deux ordres de grandeur.

Alors qu’est ce qui empêche EasyTelCo de passer en version 2 ?

1/ La multi-localisation. Oui, c’est vrai, c’est une question. Elle n’est pas insoluble. Soyons créatifs :

  • Solution 1 : multiplier les salles de visio-conférence.
  • Solution 2 : multi-localiser les équipes ! Qu’elles soient de développement ou de support. C’est ma solution préférée.
  • Solution 3 : voyager. La Bretagne comme la Vendée ont des charmes insoupçonnés. Paris est la plus belle ville du monde…

Un mixte des solutions 2 et 3 permettrait de dynamiser efficacement la DSI d’EasyTelCo.

Notez que je ne parle pas d’outillage informatique de partage. Pourquoi ? Parce que quelles que soient leurs qualités, ils ne peuvent être qu’un pis-aller. Les homo sapiens ont besoin de se voir, de se parler, de se toucher. Une signature au bout d’un mail, c’est un étranger. Une voix au téléphone, c’est une personne. Une image en visio conférence, c’est un collègue. La personne qui partage votre bureau et avec qui vous prenez vos repas, c’est un intime. Allez-vous travailler une ou deux heures de plus, un soir, pour sauver la mise de quelqu’un que vous ne connaissez que par mail ? Peu probable. Allez-vous partir sans regret, ce même soir, sachant que Paul ou Isabelle qui sont toujours assis près de vous, vont y passer une partie de la nuit ? Difficile. Toute la différence est là.

N’oubliez jamais : le travail en entreprise est un travail d’équipe. Meilleure est la qualité de l’équipe, meilleur sera le travail.

2/ L’entreprise doit gérer des compétences informatiques.

Oui, c’est vrai. L’organisation 2.0 suppose que la DSI d’EasyTelCo ne soit pas constituée que de chefs de projets, ou plutôt, que ces chefs de projets ne soient pas que cela. Ils doivent, c’est vrai, continuer à être pleinement opérationnels. Est-ce une hérésie ? Mais autorise-t-on un directeur commercial à ignorer ce qu’est une pratique de vente ? Est-il possible pour un membre de l’équipe juridique de ne plus savoir ce qu’est la loi ? Le directeur financier peut-il tout ignorer de la comptabilité ? Alors pourquoi un responsable opérationnel de la DSI peut-il se permettre de ne plus être capable de réaliser le travail qu’il commande ?

C’est l’intérêt de l’entreprise :

  • Les chefs de projets seront bien plus à même de challenger intelligemment les prestataires externes. Cela veut dire : comprendre tout de suite quand on tente de leur faire prendre des vessies pour des lanternes, mais aussi savoir ne pas demander l’impossible.
  • Etre capables d’effectuer certaines petites tâches où des tâches délicates en toute autonomie. Et ne pas être obligé, par exemple de définir un nouveau projet pour juste développer un WebService de 200 lignes. Appelez-vous un électricien pour changer une ampoule ?
  • Etre capable, en cas de contraction du marché de continuer à produire. Se séparer des prestataires permet de diminuer partiellement les coûts. Mais si le personnel encadrant ne sait pas les remplacer, c’est la totalité de vos développements qui est arrêtée.
  • Eviter la sclérose avec son très dangereux corollaire : la résistance au changement. Au fil des années, les gens qui se sont doucement laissé couler dans leurs habitudes vont constituer un frein et un poids d’autant plus ferme que leur employabilité aura fortement diminué et leurs salaires augmenté. Ils n’oseront jamais affronter le marché. Tenir les choses en l’état devient pour eux, au sens propre, une question de vie ou de mort. Quitte à faire mourir l’entreprise.

Alors comment faire ?

  • Adopter des pratiques efficaces de montée en compétence comme le « Pair-Working ». Si travailler à deux vous parait une perte de temps, pensez aux giga-octets de mails et aux siècles-hommes de réunions que cela va éviter. L’entreprise est immédiatement gagnante et largement.
  • Participer aux projets. Au contact d’équipes affutées aux compétences variées, les membres « embarqués » vont apprendre beaucoup. Et ce savoir va se solidifier, car il est mis immédiatement en pratique.
  • On peut aussi, bien sûr, prévoir des formations. C’est utile pour démarrer. Mais le « Pair-Working » et l’embarquement sont bien plus efficaces.
  • Promouvoir la double compétence managériale et technique, tant du point de vue responsabilité que salaire.

Bref, il faut favoriser la qualité humaine et technique des membres de l’entreprise. L’entreprise étant d’abord une affaire d’hommes, elle a, très égoïstement, tout à y gagner.

Categories: Devops Tags:
  1. Franck Besnard
    09/09/2015 à 10:01 | #1

    Excellent ! J’ai adoré !

  1. Pas encore de trackbacks


6 − = quatre