16 Aug 2015, 13:00

Le Généraliste - Dégrippeur de rouages, interconnecteur de personnes et grand orchestrateur du succès de vos projet - le transcript

J'ai eu le plaisir de participer à l'E1 Conférence en juin dernier, sous le thème "Problem solved" de pouvoir présenter un sujet autour du profil du généraliste (par opposition au spécialiste et à la tendance à une spécialisation accrue dans les métiers du web ces dernières années). Les slides en elles-mêmes n'étant pas très auto-portantes, voici le transcript. L'ensemble des conférences sont également disponible sur la playlist youtube E1 Saison 3.

J'indique les numéros de slides et le titre pour vous y retrouver le cas échéant.

Slide 0 - Une image de mécanisme

Slide 1 - Le Généraliste - Dégrippeur de rouages, interconnecteur de personnes et grand orchestrateur du succès de vos projet

Slide 2 : Nicolas Steinmetz

Ce sujet, c'est un peu le résumé de mes 10+ annnées de vie professionnelle.

Initialement sorti d'école de commerce mais ayant déjà fait des stages dans le domaine du Web et des Systèmes d'information. Je rejoinds ensuite le monde des SSII ESN alternant missions de conseil et projets d'intégration pendant 5 ans puis un client final depuis 7 ans avec différentes casquettes au gré des années et des projets.

De ces 10 ans, j'en tire deux enseignements :

  • En société de service : il est possible de créer un cercle vertueux en alternant mission de conseil et projet d'intégration :
    • On conseille ce que l'on sait implémenter/implémentable, du fait d'une expérience concrète sur le terrain
    • On implémente des solutions adaptées aux besoins, car on est capable de comprendre le besoin.
  • Equipe Intégration
    • Contexte : Etre situé entre les équipes de développement et de production et veiller à ce que l'architecture retenue pour le projet soit mise en place, s'assurer que les livrables fournis par les équipes de développement se déploie sur l'infrastructure et enfin s'assurer que la production peut exploiter l'application au quotidien.
    • Enjeu : s'interfacer avec l'ensemble des équipes pour faire en sorte que cela fonctionne

Dans les deux cas, on voit que la transversalité / la vue d'ensemble sont des facteurs clé de succès pour le bon déroulement des projets.

Mais avant d'aller plus loin dans les enseignements, revenons à la notion de spécialiste et de division du travail.

Slide 3 - La Division du travail

Quand je pense division du travail, de part mes études, j'ai pensé aux sociétés dites "modernes", à la Révolution Industrielle et notamment à Adam Smith (18ème). Mais en fait, grâce à Wikipedia, j'ai pu voir que Platon en parle déjà dans la République :

on fait plus et mieux et plus aisément, lorsque chacun ne fait qu'une chose, celle à laquelle il est propre

Adam Smith (1776), La Richesse des Nations : la fabrique d'épingles

En 1776, l'économiste Adam Smith dans son ouvrage Richesse des nations reprend à la fois l'expression mais aussi l'exemple de la fabrication d'épingles. S'inspirant de l'Encyclopédie, il décrit la « division technique du travail » à l'oeuvre dans une manufacture d'épingles au sein de laquelle les tâches ont été parcellisées et spécialisées entre les ouvriers, source d'une plus grande productivité.

Jusqu'à Frederick Taylor et l'OST

Ainsi Frederick Winslow Taylor, en réaction au manque de rigueur constaté dans les ateliers de son entreprise, va préconiser de mettre fin aux pratiques spontanées héritées de l'artisanat et des mentalités corporatistes. Pour ce faire, il propose de systématiser l'application du principe de l'organisation du travail selon deux axes :
  • division horizontale du travail : répartir clairement les tâches entre ateliers, et entre postes de travail avec des limites précises qui interdisent les recouvrements et querelles de compétence.
  • division verticale du travail : répartir fermement les responsabilités entre ceux (ingénieurs et direction) qui déterminent les règles selon lesquelles le travail doit être fait et ceux (ouvriers) qui doivent désormais se consacrer à leur stricte exécution.

Ou dit autrement :

  • décomposer les phases successives d'un travail ;
  • chercher les gestes les plus efficaces ;
  • définir la procédure optimale et y adapter les hommes ainsi que l'ensemble des moyens requis.

Tout cela semble logique et a été appliqué depuis plus d'un centenaire pour la théorie la plus moderne.

Slide 4 : Sauf que dans la vraie vie...cela ne fonctionne pas (bien)

Nous allons le voir à travers 3 exemples.

Slide 4.1 : Les process ne sont pas suivis... si tant est qu'ils soient définis et partagés.

Nous observons souvent des séries d'aller/retour inutiles entre les personnes du fait que les process ne sont pas définis ou pas partagés.

Cela se termine alors de deux façons :

  • Appel au sachant, à savoir "Le Gars Qui Sait". Quand bien même le process est décrit quelque part, par simplicité/fainéantise/paresse/..., on consulte la ou les personnes qui doivent bien savoir ce qu'il faut faire dans ce cas. En prime, s'ils peuvent faire le travail à notre place, c'est encore mieux.
  • Ou bien attendre que la demande se traite d'elle même ; mais la probabilité de succès est assez faible.

Slide 4.2 Chacun voit midi à sa porte

Dans une entreprise organisé en départements représentant des spécialités, nous avons 3 écueils :

  • Chacun obéit à sa propre logique / à ses propres objectifs : ce qui prime, c'est la logique du département et les instructions de mon manager et les objectifs qu'il m'a assigné. Ce qui se passe dans les autres départements ne me "concerne" pas (ou peu) ou en tous cas, passe après mes sujets.
  • Chacun ne voit que son propre périmètre : dans la continuité du précédent point, les spécialistes ne vont intervenir que sur une petite partie du projet. Le reste, ils ne le voient pas. C'est accentué également dans un contexte de prestation (infogérance, etc)

Exemple pour illustrer ce point :

  • Dans le cadre d'un projet Web, pour la résilicence du système, nous avions mis en place une réplication MySQL en plus des sauvegardes afin de garantir d'avoir une copie de la production en cas de défaillance du serveur maitre. L'objectif était  de pouvoir repartir sur le serveur esclave afin de limiter l'interruption de service.
  • En tant que responsable de la plateforme, j'étais donc confiant jusqu'à ce que je découvre qu'un administrateur de base de données (DBA) avait silencieusement ignoré des erreurs de réplication afin que son outil de monitoring ne se plaigne plus et qu'il n'y ait plus d'incident créé.
  • Cela pose alors deux problèmes : que l'on ne soit pas informé qu'il y avait des erreurs de réplication d'une part et que d'autre part, le DBA ait pris la liberté de modifier le système sans nous prévenir. Du coup, la réplication n'est plus intègre et on ne pouvait plus s'appuyer sur le réplicat pour redémarrer le service en cas de perte du serveur maitre.
  • Ici, chaque équipe pense que tout va bien pour le meilleur des mondes alors que ce n'est pas le cas, chacun voyant midi à sa porte.

Slide 4.3 : Les spécialistes ne sont pas nécessairement au niveau et la sur-spécialisation est mauvaise pour la santé

  • Rien ne vous garantie le niveau du spécialiste. Il faut prendre soin de distinguer la notion de spécialiste (au sens de segmentation de l'activité) et d'expertise que l'on confond aisément.
  • Dès Adam Smith a minima, la (sur)spécialisation est vue comme contre productive depuis Adam Smith a minima (perte d'autonomie, perte de motivation, etc). On passe de la notion d'artisan qui connait son métier à la notion d'ouvrier spécialisé qui ne fait que répéter un ensemble de geste pré-définis.
  • NB : Il est d'ailleurs intéressant de voir ces dernières années le retour en force d'un mouvement "Software Craftsmanship" (artisan du logiciel) et qui remet en valeur des savoir faire. Le développeur n'est pas qu'un simple "pisseur de code".

Slide 5 : Quels choix avons nous ?

  • D'un côté, on peut prôner le status quo avec comme conséquence une frustration croissante et une efficacité moindre.
  • De l'autre, on peut partir du principe qu'un process éprouvé est un process contourné

Slide 5.1 : Un process éprouvé est un process contourné

Naturellement, dans le cadre de cette conférence, je ne peux que prendre ce parti.

Slide 5.2 : Sortir de sa zone de confort

  • Le but ici n'est pas de tout remettre en cause mais plutôt d'aller voir les sujets limitrophes à vos activités courantes. Puis progressivement et en fonction de vos intérêts d'élargir progressivement.
  • Ca coûte un peu de sortir de sa zone de confort certes mais le jeu en vaut la chandelle.
  • Exemple 1 : dans le cadre d'un projet web, les fonctionels se plaignaient toujours du mauvais fonctionnement des "Reverse Proxy". A force de les entendre râler, je suis allé voir de quoi il en retournait alors que je n'étais pas sensé m'en occupé. En regardant la configuration et en lisant la documentation du logiciel, j'ai ainsi pu voir qu'ils ne faisaient que "passe-plat" entre le réseau et le serveur web. S'il y avait des problèmes, ils ne venaient pas de là (ou pas nécessairement comme le pensait les fonctionnels). Plus tard, j'ai aussi pu améliorer le fonctionnement de cet équipement et réécrire l'application qui les gérait pour mieux répondre à nos besoins.
  • Exemple 2 : les développeurs PHP vs Java. J'ai toujours trouvé que les premiers étaient plus touche à tout que les seconds. Les développeurs PHP font souvent un peu de HTML/JS/CSS et ont des bases d'administration système ou de base de données en général. Ils sont certes spécialisés sur PHP mais ils sont en mesure de travailler sur l'ensemble de leur "stack". Ils ne sont pas du niveau d'un DBA ou d'un intégrateur HTML mais bon, ils peuvent apporter un certain nombre de modifications de façon autonome. Je ne retrouve pas ou très rarement cette compétence chez des développeurs Java. Même pour réaliser des interfaces Web, ils préfèrent coder du Java et avoir un générateur d'interfaces. Mais hors de question de coder en HTML/JS/CSS.

Slide 5.3 : Chercher et se faire aider

  • Sortir de sa zone de confort, c'est certes en partie chercher par soi-même mais cela ne veut pas dire qu'il ne faut pas se faire aider par les spécialistes. Si vous dites "ton truc, ça marche pas, c'est de la m*****" ; cela n'incite en général personne à t'aider. Par contre, si vous faites une première analyse et une première recherche, c'est à dire que vous faites preuve de bonne volonté, alors le spécialiste sera plus enclin à prendre en compte votre demande et à vous aider à solutionner votre problème.
  • Attention, toutefois à ménager le spécialiste qui ne voit pas d'un bon oeil qu'on vienne marcher sur ses platebandes. On vient avec des éléments factuels, on évite trop le "j'ai lu sur internet que ..." et qui sous-entend que l'on a déjà la réponse au problème. Il faut trouver le juste équilibre.
  • Exemple :  dans le cadre d'un intranet, je n'arrivais pas à faire fonctionner le protocole d'authentification transparente (SSO). Je suis donc allé voir l'ingénieur en charge de ce sujet avec la documentation fournie par l'éditeur, lui faisant un résumé de ce que j'avais compris du mécanisme et de ce que j'avais fait mais que j'atteignais mes limites sur le sujet. Nous avons alors travaillé de concert jusqu'à trouver comment faire fonctionner le composant.

Slide 6 : Sauf que cela ne "scale" pas même si cela permet de faire avancer les projets

  • Malheureusement ou pas, un humain reste un humain et ne se multiplie pas.
  • Pour autant, cette méthode permet de faire avancer les projets à un niveau individuel
  • Mais elle a (au moins) 3 inconvénients

Slide 6.1 Super-héros mais surtout Super-dépendances !

  • Vous intervenez certes sur l'ensemble du projet, mais le projet est aussi très dépendant de vous
  • Cela peut vous empêche de changer d'activité ou a minima de vous suivre comme une casserolle
  • Plutôt que d'être le super-Héros, il faut plutôt travailler à vous rendre dispensable.

Slide 6.2 : Poste aux frontières floues

  • Les gens sont content de vous avoir mais ont du mal à vous positionner dans l'organisation. Tu fais quoi déjà ? Tu es consultant ? développeur ? administrateur système ?
  • Cela peut bloquer la mobilité au sein d'une entreprise : vu que vous faites tout sur le projet, on ne va surtout pas vous remplacer d'une part et de l'autre, vous pourriez ne pas pouvoir évoluer vers un autre métier, n'étant pas jugé assez spécialisé pour le faire.
  • Pour une personne tout à tout, il en faut au final 3 ou plus suivant le nombre de casquettes possédées. Cela peut coûter cher de vous remplacer.
  • Tout le monde aimerait bien avoir un mouton à 6 pattes mais les intitulés de poste ne le disent pas. Donc pas toujours évident de se revendre à l'extérieur.

Slide 6.3 : Attention à ne pas se dilluer soi-même

  • Attention au syndrome du grand-écart ; cela peut être compliqué à géré de faire des activités très variées dans une même journée. Au final, on peut avoir l'impression de ne plus faire grand chose de productif.
  • La solution est de maitenir des fondamentaux ; ceux ci peuvent évoluer ponctuellement en fonction des équipes ou des projets ou de façon plus pérenne. Dans ce dernier cas, cela veut dire qu'il y a des compétences que vous délaissez progressivement.
  • Mythe du "full stack employee" ; il y a beaucoup de littérature sur le sujet en ce moment avec des avis allant d'un extrême à l'autre. Pour moi, le point n'est pas d'être expert en tout mais d'avoir des fondamentaux et un vernis solide sur les sujets connexes. C'est déjà beaucoup plus soutenable.

Slide 7 : Mauvaise échelle, changeons d'échelle

  • Comme à un niveau individuel cela ne fonctionne pas bien, regardons ce que l'on peut faire au niveau d'une équipe.
  • Un point très facile avant de décloisonner/désiloter les équipes, c'est "d'ouvrir les fenêtres" entre les équipes. Chacun reste dans son département mais se parle et voit ce qu'il se passe à côté.
  • Il s'agit aussi de faire progresser les équipes. Cela peut se faire très facilement avec des meetups internes ou lors de réunions de service. L'idée est qu'un membre de l'équipe présente un sujet sur lequel il travaille et de le partager avec le reste de l'équipe. Ainsi, on diffuse un savoir au sein de l'équipe pour la rendre globalement plus résiliente.

Slide 7.1 : BusDevOps

  • Il y a une tendance actuellement qui vise à fluidifer / mieux partager l'information au sein des organisations afin que ces dernières gagnent en flexibilité / agilité.
  • D'un côté, entre les équipes métiers (business) et développement, il ya toutes les méthodes dites "agiles" qui visent a améliorer les méthodes de développements logiciels en privilégiant proximité et itération afin de construire un produit adapté aux besoins.
  • De l'autre côté, il y a la tendance DevOps qui vise à créer également une proximité entre les équipes de développement et les équipes qui exploitent les applications. L'idée étant que chacun apprenne de l'autre et collaborent afin que les attentes et les contraintes de chacun soient prises en considération. Tout ceci afin que l'application fonctionne dans les meilleures conditions possibles.
  • Dans les deux cas, l'idée est la même : il s'agit de remonter ou descendre la chaîne de valeur pour une meilleure compréhension et une vision plus globale plutôt que de s'arrêter à son propre périmètre.

Slide 7.2 : Feature Teams

  • C'est un modèle d'organisation récent et qui est appliqué à minima chez Spotify. Il y a pas mal de littérature sur le sujet.
  • Le principe est assez simple et place l'autonomie au coeur du système.
  • Si on prend une application web, on va par ex créer une tribu pour la partie "front-end" et une autre pour la partie "back-end". Chaque tribu responsable de son périmètre.
  • Au sein de chaque tribu, il y a des squads. Ce sont des équipes autonomes sur un sous ensemble donné de l'application. Elle fonctionne selon les méthodes agiles. On peut par ex imaginer une tribu pour la version desktop de notre application, une tribu pour la version iOS, une tribu pour la version Android, etc. Elle est chapeautée par un "Product Owner" qui définit ce que doit contenir son produit et ensuite le squad est composé de l'ensemble des profils nécessaires pour gérer le produit. On peut y retrouver par ex un designer, un développeur d'interface et un testeur.
  • Pour autant, il faut arriver à garder une cohérence d'ensemble et à partager les bonnes pratiques. Cela se fait au travers de communautés de pratiques que sont les guilds et les chapters.
  • Les chapter regroupent les mêmes type de profils au sein de l'organisation. Il y aura donc un chapter des designers, un chapter pour les testeurs, etc. Au sein de ce chapter, ils peuvent partager leurs expériences et diffuser leur savoir faire.
  • De façon un peu plus large, les guildes permettent de traiter d'un sujet mais tout le monde peut y participer. Si on imagine une guilde sur l'UX par ex, on pourra y trouver des designer, des développeurs et des testeurs où chacun pourra partager sa vision des choses et faire progresser globalement l'entreprise.

Ce type d'organisation met fin aux silos traditionnels tout en cherchant à maintenir une cohérence d'ensemble. La vision globale est portée au niveau de l'équipe qui devient du coup généraliste dans son ensemble. De fait, l'organisation transverse permet ce généralisme.

Slide 8 : Bâtissez des ponts

En conclusion, le débat n'est pas généraliste vs spécialistes mais plutôt de miser sur la complémentarité des deux profils.

L'image du pont est alors intéressante : vous devez pouvoir vous appuyer sur des spécialistes (ici les piliers du pont) mais pour vous permettre de relier une rive à l'autre et mener à bien vos projets, il vous faut des généralistes (ici les traverses).

Slide 9 : Merci

Slide 10 : Crédits