mardi 16 juillet 2019

 

  Soliloqueries et Marmonades à propos de

Division du travail IT & DevOps


Même pas accoudé au comptoir

Quand sur mon fil facebook est apparu un lien vers un article de blog.
 Division du travail IT & DevOps qui plus est avec appel à commentaires.

Franchement, c'est bien parce que je n'ai rien de mieux à faire comme Chief Sleeping Officer chez Gland d'Atome, que je me retrouve devant mon clavier.

Rétro

Rétroviseur, hein. Pas rétro comme dans Scrum. Ou alors après une itération de 40 ans. Est-ce qu'on peut faire des sprints de 40 ans en Scrum?
  • Divisions de 1978 (SSII de 500 personnes):
    • Analyste
    • Analyste-Programmeur
    • Programmeur
    • Perforatrice.
    • Perfo-vérif
    • Opérateur
    • Secrétaire
Ce n'est pas exhaustif. J'ai laissé de côté les aspects management. 

 Un "mini-ordinateur" pour une équipe d'une vingtaine de personnes. On écrivait nos programmes sur des feuilles de programmation, qu'on donnait à des perforatrices qui nous redonnait un paquet de cartes perforées quelques jours après. La compilation se faisait la nuit sous la responsabilité de l'opérateur. La doc était manuscrite et dactylographiée par une secrétaire.
Dans le temps, plus maintenant...
Parce que maintenant, mon Dieu, Seigneur !
Le monde a bien changé, sais-tu  (Julos Beaucarne, Périclès)
  •  Divisions en1989 et en 2002  (PME de 25 à 80 personnes)
    • Chef de projet
    • Architecte
    • Programmeur
    • Testeur
    • Support
    • Documentation
    • Formation
    • Avant-vente
    • Marketing
    • Recherche
    • Support IT
Alors que sur la division de 1978, on avait une fonction une personne, dans la PME de 25 personnes, un individu pouvait remplir toutes ces fonctions.
  • Divisions de 1997 (Groupe Mondial, 40 000 personnes)
    • La même chose que dans la PME
Sauf que. On retrouve la répartition, une personne une fonction. Si t'es architecte, tu architectes. Plus besoin de coder, plus besoin de voir des clients.
  • Divisions de 2010 à 2018 (PMEs de 150 personnes)
    • Étrangement  même affectation personne / fonction que dans le groupe de 40 000 personnes.
Curieusement dans la dernière entreprise de 150 personnes, j'avais autant d'échelons hiérarchiques (4) au dessus de moi que dans le groupe de 40 000 personnes. En dessous aussi d'ailleurs à savoir zéro!

Dans un groupe de 40 000, il est difficile de passer d'une fonction à une autre. Ça perturbe violemment les DRH. Les DRH tiennent à ce que "tu" progresses. Si après avoir piloté une équipe, tu veux retourner à la technique, le DRH ne peut pas comprendre. L'amélioration individuelle pour un DRH (de l'époque) passait par plus de spécialisation. L'amélioration par la diversité et une vision globale ne devait pas être mentionnée dans leurs tablettes RH.


Dans les situations où l'affectation se fait sur la base une personne / une fonction, on a plus de situations de crispation (en clair les équipes se fritent) que dans la situation où une personne a divers rôles.

Gestion par Objectifs et KPI


Est-ce que la taille critique se trouve entre 80 et 150 personnes ?

Ça peut jouer. Mais je pense que la clé est ailleurs.

Quand une entreprise veut être organisée comme une grande (la start-up est "ready to scale" pour rassurer les investisseurs, ou même s'organise pour projeter une ombre plus grande que la réalité, ça rappelle la grenouille de La Fontaine)...

Donc, quand une entreprise veut être organisée comme une grande, elle met en place des objectifs et des outils de mesure pour suivre l’efficacité des équipes. A charge pour le chef d'équipe de présenter des bons indicateurs (Key Performance Indicators) régulièrement.

Donc même si on n'a pas un management par objectifs au sens strict, l'effet est le même. Chaque équipe se retrouve avec un intérêt particulier qui ne prend pas en compte l'intérêt des autres équipes et pas celui de la communauté (l'entreprise).

Résultat, même avec de la bonne volonté, la coopération entre équipes est limitée par l'intérêt des équipes défini par les KPI de chacune de ces équipes.

C'est évidemment très simplifié.

De l'agilité

Avant 2010, la gestion était plutôt classique genre Cycle en V informel. 
Ensuite, j'ai goûté à Scrum, j'ai été initié à Kanban sans pratiquer.
Et j'ai fini par du AINO.(Agile In Name Only).
 
De ce que j'ai aperçu de Scrum, il semble que l'idée de laisser les développeurs s'auto-organiser, conduit surtout à leur mettre beaucoup plus de pression psychologique que dans une gestion en V avec Gantt chart. Les sprints de 2 ou 3 semaines avaient l'air d'épuiser les moins robustes (les plus jeunes?). Par contre, le supérieur hiérarchique semblait plus épanoui.

A la réflexion, l'auto-organisation est limitée à "comment s'organiser pour faire au mieux les tâches à accomplir". Les contraintes qui s'appliquent sur l'équipe ne sont pas négociables (ou à la marge). Et l'équipe doit montrer que ses KPIs s'améliorent.

Ah, le burn-rate de l'équipe sur l'écran géant dans l'open-space, et/ou à côté de la machine à café.  On te collerait un Jiminy Criquet dans l'oreille ça ne serait pas pire.

On en revient à l'élément précédent: la direction d'entreprise fixe un découpage et des objectifs à chacune des boites ainsi découpées. Laisser les gens libres dans la cage en bas est sympathique (plus sympathique que de les forcer à adopter une organisation donnée), mais ne peut être que très limité.

Du Dev et du DevOps

Dev... Hum. 

 Au fil des années, le développement s'est fortement teinté d'intégration.

Dans mes pérégrinations, la partie développement a toujours été traitée raisonnablement sérieusement. Par contre, les critères de choix pour s'appuyer sur telle ou telle brique existante à intégrer m'ont toujours laissé rêveur.

J'ai sévi essentiellement chez des éditeurs de logiciel. Avec des clients qui pouvaient mettre plusieurs mois à déployer une nouvelle version, ou plus récemment avec des clients plus réactifs.

Prenons un exemple: un logiciel développé suffisamment complexe, pour qu'une équipe soit en charge d'aider les clients à installer, maintenir, opérer le logiciel. Donc une fonction "Ops" ou proche de "Ops".

La communication entre Ops et Dev était raisonnable pour le support. Quand un bug était suffisamment sérieux, il devenait visible de la direction et donc les coopérations jouaient. Quand un bug est bloquant, le client menace le CEO de la boîte qui fournit le logiciel, et les problèmes se résolvent. C'est vrai dans les boites de 150 personnes et dans celles de 40 000.

Pour la partie "facilité d'installation et d'opération". C'est plus compliqué. La première version du logiciel est conçue sans les équipes "ops". Les développeurs n'ont aucune idée (ou une idée simplifiée, naïve) de la complexité de ce qu'ils sont en train de concevoir (du point de vue opérationnel). Quand il s'agit de produire une nouvelle version, le point de vue "opérationnel" même s'il est exprimé et entendu a peu de chance de faire son chemin, si le marketing produit décide que la feature superX est celle qui doit être implémentée au plus vite.

Idée intéressante mais sans effet: faire que chaque développeur passe 2 semaines avec un opérationnel, pour revenir convaincu de la nécessité de prendre en compte le côté opérationnel. Bon. 3 développeurs sur une quarantaine ont suivi ce cursus. Flop. Lâcher un développeur 3 semaines n'a pas d'incidence positive sur les KPIs de l'équipe, ni sur le parcours ultérieur de ce développeur. Reste l'envie personnelle et déterminée de quelques développeurs.


Autre idée ingénieuse (?!): créer une équipe DevOps entre l'équipe Ops et l'équipe Dev. Du DevOps In Name Only en quelque sorte.

Là encore, ça ne s'est amélioré que quand la décision est venue du haut. J'imagine que d'une manière où d'une autre les Ops ont fini par montrer des mauvais KPI. Pour les redresser, il fallait prendre en compte le point de vue "Ops" du côté Dev.

Agrégation de DevOps?

Comment vont faire les entreprises qui agglutinent les services fournis par d'autres au sein de leur offre?

Soit une entreprise qui permet à des artisans de créer en quelques clics leur site web. Puis de pouvoir prendre des commandes et de traiter les paiements associés, puis de pouvoir expédier les commandes par un service de livraison, etc...

Dans cet exemple, on aurait donc un service rendu par une entreprise qui s'appuierait sur un service de Cloud, et qui dialoguerait avec des services bancaires et des services d'expéditions eux-même hébergés sur des Clouds.

Le bon fonctionnement du service suppose que 3 hébergeurs de Clouds et 3 fournisseurs de services fonctionnent sans problème. :-)

Les SLA peuvent partiellement répondre. Ça semble cependant plus complexe. Voir (Nines are not enough: meaningful metrics for clouds).

Mais surtout à la question "qui comprend le système de bout en bout ?",  j'ai peur de malheureusement connaître la réponse.

D'autres pistes

Côté méthodologie, j'ai pendant un temps regardé les travaux de "SEMAT". C'était très embryonnaire quand je m'y suis intéressé. 

Chez Gland d'Atome la méthodologie pour faire la sieste est assez éprouvée et les rétros de fin de sieste ne montrent pas de nécessité de faire évoluer cette méthodologie. Du coup, je n'ai pas suivi les travaux de SEMAT récemment.

Ensuite, il y a des boîtes qui prennent le problème de l'organisation à bras le corps. Comme Semco: 
 Sinon, on m'a recommandé:

HTH

 LeFA




Publié par à Aucun commentaire:
Libellés :
Inscription à : Articles (Atom)