Le coup du projet de deux semaines qui est dans les faits mené en un an est un grand classique en entreprise, hélas, à l’opposé exact de la méthode DevOps. Il va de soi que dans un monde où tout va de plus en plus vite ce genre de chose peut rapidement mener à une perte de compétitivité complète d’une entreprise. Dans la suite on va voir ce qu’il faut faire pour « y arriver »…
Une organisation en silos
L’organisation en silos est probablement la composante principale permettant à un projet de deux semaines d’être réalisé en un an ou plus. Il est vrai qu’elle apporte un certain confort car chacun peut renvoyer la balle à l’autre pour lui demander de faire telle ou telle tâche, en disant que ça relève de la responsabilité du voisin. À l’inverse en cas de doute une personne ne réalisera pas une tâche de peur de marcher sur les plates bandes de celui-ci. Et c’est un bon moyen de s’assurer que rien n’avance.
En fait si on veut raisonner en terme de silos il faut se dire que le silo, c’est toute l’équipe travaillant sur le projet. Ici on n’est plus dans situation de dépendance hiérarchique à un chef de service, mais bien à travailler tous ensemble autour du projet qui est ce qui compte.
Alors bien évidemment pour qu’une telle organisation fonctionne, où finalement les salariés sont détachés de leur responsable hiérarchique il est particulièrement important que celui-ci joue le jeu, et n’aille pas interférer à la bonne tenue du projet. De même au niveau des congés le responsable ne devrait plus être qu’informé, et au niveau des augmentations il doit être carré. Le mieux est bien évidemment que le responsable hiérarchique soit directement associé au projet, mais c’est rarement le cas.
Une mauvaise communication entre services
La communication inter-services est probablement le pire talon d’Achille des grandes entreprises et découle directement d’une organisation en silos, et c’est bien pire dans les grosses organisations quand les responsables d’un projet se retrouvent à communiquer face à une nébuleuse de personnes où tout le monde se renvoie la balle. Si en prime la hiérarchie de ces infortunées personnes met une pression très élevée et n’hésite pas à les clouer au pilori, on obtient un cocktail idéal pour un burn-out.
Là encore une organisation DevOps permet de largement fluidifier tout ceci. Si chaque équipe devant agir sur un projet alloue un certain nombre de personnes à temps complet ou partiel sur celui-ci, on résoud le problème car chacun saura qui contacter. Besoin d’un nouveau serveur ? On va voir directement la personne rattachée à l’infrastructure sur le projet, qui fera rapidement le nécessaire car elle a tout ce qu’il faut pour y parvenir. La même chose s’applique pour la sécurité. Bien évidemment pour qu’une telle organisation fonctionne il est nécessaire que chaque intervenant n’ait à agir que sur un nombre raisonnable de projets, trois ou quatre maximum. Une personne surchargée ferait en effet office de goulot d’étranglement et ferait tout échouer ! De même il est nettement préférable d’avoir une proximité géographique entre les différents intervenants, ou à défaut que ceux-ci se rencontrent souvent physiquement et pas uniquement par visioconférence. En effet il est bien plus simple d’expliquer nombre de concepts à côté de la personne sur un papier qu’à distance, même sur un tableau…
Une bureaucratie démesurée
La bureaucratie démesurée est un mal qui affecte principalement les équipes sécurité des grandes entreprises. Dans ces dernières il n’est pas rare par exemple qu’un nouvel arrivant attende deux mois avant d’avoir ses accès pour pouvoir travailler ! Et pendant tout ce temps la personne n’est pas productive, tandis qu’ensuite il faut la former.
Le problème est que la même chose se produit au sein des projets. Besoin d’un certificat HTTPS ? Ah oui mais vous comprenez ma petite dame il faut compléter le formulaire A47-X bleu en trois exemplaires. Bien évidemment la demande sera perdue puis retrouvée deux fois, et le demandeur devra la renouveler car l’exemplaire précédent ne sera plus valable au moment de sa prise en compte.
Dans certaines entreprises hélas tout se passe comme ça, ce qui multiplie les délais par un facteur rédhibitoire. Supposons que dans votre projet vous ayez besoin de deux serveurs et d’un certificat pour HTTPs. L’organisation fait qu’il faut une demande par serveur, une demande DNS et une pour le certificat. Chacune se fait par une équipe différente, en sachant que l’équipe en charge du DNS a besoin d’une IP valide pour prendre en compte la demande, et que l’équipe en charge du certificat a besoin d’un DNS valide… Les délais moyens constatés sont d’un mois pour un serveur, deux semaines pour le DNS et un mois pour le certificat. Un tel fonctionnement impose déjà un délai de deux mois et demis pour pouvoir… installer le projet ! Alors certes on peut paralléliser les tâches mais ce n’est pas toujours possible, par exemple dans le cas d’un progiciel externe.
Là encore avoir des personnes de chaque équipe impliquée dédiée au projet facilite grandement les choses et permet de traiter les problématiques en amont, et pouvoir gagner du temps car là encore une personne d’une équipe donnée a les bons contacts pour traiter les demandes le plus rapidement possible.
En bref…
L’organisation en silos peut amener un certain confort aux employés car elle dilue totalement les responsabilités, cependant elle est fortement nuisible aux salariés ainsi qu’à ceux qui ont besoin que les projets avancent. Ce confort procuré à certains peut donc être une source de stress intense pour d’autres à qui on demande de faire avancer les projets.
Si vous souhaitez approfondir sur le sujet je vous conseille vivement de lire le livre The Phoenix Project. Ce dernier, sous les traits d’un roman, illustre très bien la transformation DevOps et ses bienfaits.
Besoin de tester ton niveau en développement informatique ?
Cet article vous a plu ? Vous aimerez sûrement aussi :
- La démarche DevOps
- Entrepreneurs, pourquoi c’est important de bien payer vos développeurs
- Développeurs, attention au burn-out
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.
