15 Nov 2017, 00:05

The Phoenix Project

Cette année, il y a 2 contenus pour lesquels j’ai eu un effet “Whaou” :

  • Le hacker, ce héros : comment être un bon growth hacker : si le titre est plutôt mal choisi, la vidéo fait réflechir sur la tendance à l’over-engineering que l’on a tendance à appliquer vs “le juste ce qu’il faut quitte à améliorer plus tard” de la startup ou du hacker. Le code généré n’est peut être pas à l’image de l’état de l’art mais il est en production, permet de vendre le produit et d’avoir des retours. Quand on sort d’un grand groupe pour faire des missions dans des petites structures, cela fait définitivement réfléchir.
  • The Phoenix Project : sous la forme d’une fiction, le livre sensibilise à la transition d’une équipe IT puis d’une entreprise vers une démarche DevOps/Lean/Agile mais pas uniquement pour faire face aux défis que doit relever l’entreprise.

Il y a les 3 principes :

  • 1er principe : maitriser le flux de bout en bout depuis la phase de développement jusqu’à la mise à disposition à l’utilisateur. Pour optimiser ce flux, il faut des petites itérations et avoir en objectif un but global à l’entreprise (et non local à l’IT). Par ailleurs, on évite les retours en arrière dans le processus, cela est signe d’un dysfonctionnement. Il faut voir le flux comme uni-directionnel allant du développement vers l’utilisateur. Les pratiqes associées tournent alors principalement autour de l’intégration continue et du déploiement continu.
  • 2nd principe : avoir une boucle de feedbacks permanente permettant de faire de l’amélioration continue. Cela permet d’améliorer la qualité du code source et de créer/formaliser la connaissance autour du projet. La pratique consiste donc à mesurer/évaluer les différentes étapes et à les faire évoluer au fur et à mesure.
  • 3ème principe : créer une culture qui permet l’expérimentation en permettant la prise de risque & des apprentissages rapides d’une part et d’autre part en considérant que la répétition et la pratique sont requis pour avois plus de maitrise et de confiance dans le process.

Il y a 4 types de travail dans l’IT :

  • Les projets métiers,
  • Les projets internes à l’IT
  • Les changements
  • Le travail innatendu (incidents, activité non planifiée, etc)

Il y a alors 4 enjeux :

  • Identifier et rendre visible ces 4 types de travaux afin de pouvoir s’organiser, estimer son travail et planifier en conséquence,
  • Garder le contrôle / Maitriser le travail innatendu vu qu’il est le plus perturbateur et apporte le moins de valeur. Quand on travaille sur ce travail innatendu, on perd du temps sur les 3 autres types de travaux.
  • Identifier le “Work in process”, à savoir le travail en cours et qui mobilise alors tout ou partie de la chaine de travail. Les analogies avec la gestion d’une usine permettent d’avoir une meilleure vision des choses et rendre nos flux IT plus concrets.
  • Identifier les contraintes et faire en sorte de les réduire/lever.

On retrouve également le thème habituel des démarches Agiles/Lean/DevOps avec tout le travail autour de la notion de valeur pour l’entreprise et pas uniquement pour la partie IT. Il faut se concentrer sur des éléments apportant de la valeur, de petite taille pour ne pas bloquer la chaine et pouvoir être envoyer en production rapidement. Le livre montre également des contre-exemples comme des contraintes de sécurité que l’équipe cherche à s’imposer alors que le risque d’une part est géré par ailleurs (autres départements) et qu’appliquer des correctifs n’apporte aucune valeur à l’entreprise d’une part et d’autre part compromet sa capacité à avancer.

Une statistique intéressante est celle du temps d’attente d’une personne (time wait) : elle rapporte le temps d’occupation au temps de disponibilité d’une personne. Si une personne est dispo à 5050, le taux est de 1 et il faut attendre 1 unité de temps pour qu’elle fasse la tâche dont vous avez besoin. A l’inverse, une personne occupée à 90% a un taux d’attente de 9 unités de temps. Même si la réalisation de la tâche par cette personne est rapide, il vous faudra attendre 9 unités de temps pour qu’elle le fasse. On crée et identifie alors rapidement des goulets d’étranglements dans votre process de création de valeur qu’il faudra traiter. Pour bien donner l’idée, si un process requiert l’intervention de 7 personnes occupées à 90% du temps, il faudra alors 63 unités de temps pour réaliser l’action.

Au final un livre rapide et agréable à livre. Vous pourrez avoir la sensation que le livre raconte votre project actuel (ou des projets passés) à de nombreuses reprises. Vous pourrez alors évaluer les progrès de votre entreprise au regard des transformations opérées dans le livre et voir si vous êtes en phase ou pas.

Plus que juste l’approche DevOps/Lean/Agile, ce que je retiens de ce livre, c’est surtout l’effort d’alignement de l’IT avec les besoins du reste de l’entreprise et que l’on oublie souvent d’une part et d’autre part les analogies avec le monde de l’usine. Nous considérons parfois à tort que l’IT n’a rien à voir avec une usine et l’on voit bien ces dernières années que cela est faux et que le monde industriel peut nous apprendre énormément de choses et nous faire gagner un temps précieux et ainsi être plus performant et au service des besoins de l’entreprise.

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

05 Dec 2012, 22:16

Web Giants patterns

Octo, a French consulting company, published on their blog (in Frenh) a series about patternes used by Web Giants (Google, Amazon, etc). Patterns are about organisation, methodology, development and technology. So it not only concerns IT department but can also interest business ones

A few examples :

  • Minimum Viable Product
  • Reccurent Beta
  • Feature flipping
  • Hardware commodity
  • Features teams - see also how it works at Spotify
  • NoSQL data bases
  • DevOps
  • Build vs Buy
  • Pizza teams
  • Cloud first
  • Etc

For each topic, the presentation principles are simple :

  • Pattern definition
  • How web giants use the pattern
  • How can I use the pattern in my firm / department / team

They also published (still in French) a book you can buy or download.

They organised a breakfast some weeks ago to introduced their book and the topic in general, you can watch the video and/or read the minutes. Of course in French

I would strongly recommend French readers to read this serie as it shows in an easy way how traditionnal IT patterns are evolving and what we can learn from such companies.

Definitely a must read for me.