Revue : Peopleware (3rd Edition) par Tom DeMarco et Timothy Lister

Couverture Peopleware 3rd editionPeopleware, Productive Projects and Teams (3rd Edition) – (Amazon.fr) par Tom DeMarco (Wikipedia) et Timothy Lister (Wikipedia)

Je continue dans la série des revues pour vous parler d’une référence dans le domaine du management d’équipe et de projet : il s’agit bien entendu de Peopleware. Ecrits par 2 consultants légendaires en gestion de projets et organisation d’équipes, c’est un condensé de ce qu’il faut faire pour motiver sa troupe et réussir ses projets informatiques.

Je vais faire court : si vous êtes ou voulez devenir manager IT, quel que soit le domaine, c’est un incontournable. Dedans une grosse dose de bon sens délivrée en courts chapitres de quelques pages, un vrai plaisir à lire. Ça parle RH, vie de bureaux, relations interpersonnelles, construction d’équipe, mise en place d’organisations inscrites dans des cercles vertueux…

Morceaux choisis :

  • Il faut arrêter de croire que nos métiers sont centrés autour des technologies. Les chercheurs qui font les découvertes fondamentales de nos domaines sont ceux qui travaillent effectivement sur les technologies. Nous, nous ne sommes que les utilisateurs des technologies qu’eux développent. Et à ce titre nos métiers sont donc plus centrés autour des relations humaines qu’autre chose. (p5 )
  • Les statistiques sur la lecture sont particulièrement décourageantes. Le développeur moyen ne possède aucun livre sur son domaine d’expertise, et n’en a même jamais lu un. (p11, Vous en êtes où du DWH Toolkit? ;))
  • La qualité, bien au-delà d’un simple prérequis de l’utilisateur, est une mesure de haute productivité. (p21, cf le Lean)
  • La fonction d’un manager n’est pas de faire que les gens travaillent, mais de faire qu’il soit possible qu’ils travaillent. (p34, on ne doit pas motiver, mais plutôt limiter la démotivation…)
  • Loi de Gilb : tout ce qui doit être quantifié peut être mesuré d’une manière qui est meilleure que de ne pas le mesurer du tout. (p58, on parle qualité, satisfaction… à prendre en compte dans les ROI et décisions stratégiques en plus du numéraire)
  • Par exemple : le « E-Factor » = Nb heure de travail ininterrompu / Nb heure de présence physique. (p64, à utiliser pour vérifier qu’un environnement n’est pas trop toxique au travail)
  • L’effet pervers d’un taux de turnover élevé (cycle des démissions/recrutements) et qu’il s’auto-entretient. Les collaborateurs partent vite donc il n’y a pas d’intérêt pour l’entreprise à investir sur eux. Mais s’il n’y a pas d’investissement, les collaborateurs démissionnent rapidement. (p120)
  • Le but de la constitution d’une équipe n’est pas d’atteindre un objectif, mais de définir et travailler vers un objectif commun. (p136)
  • La short-liste des techniques pour détruire une équipe : management défensif, bureaucratie, séparation physique, fragmentation du temps de travail sur des projets multiples, réduction de la qualité du produit, fausses deadlines, micro-management. (p144, avec du détail sur chacun des points)
  • La liste étendue des techniques pour détruire une équipe : primes annuelles sur objectifs, management par objectif, récompenses individuelles, et plus globalement tout ce qui tourne autour de la mesure et la gratification des performances. (p157, toujours avec le détail sur place)
  • A l’inverse, la liste des activités qui contribuent à l’équipe: faire de la qualité un culte, permettre à tous de comprendre le pourquoi de chaque décision, construire un sens de l’élitisme, encourager l’hétérogénéité, préserver et protéger les équipes qui gagnent, apporter une vision stratégique mais laisser le champ libre au niveau tactique (p168, toujours avec le détail sur place)
  • Les bonnes méthodes pour atteindre une convergence sur les pratiques sont : les formations, les outils d’automatisation, les revues par ses pairs. (p180)
  • Le péché ultime du management c’est de faire perdre son temps à quelqu’un. (p193)
  • Le changement ne peut se produire que si les collaborateurs se sentent en sécurité. (p208)
  • Une organisation peut apprendre de 2 façons : elle instille des nouvelles compétences et approches à ses membres, ou elle se redessine pour opérer d’une manière différente. (p212)
  • Dans tous les cas, la maturation d’une organisation est limitée par sa capacité à conserver ses membres. (p212)

Je recommande chaudement !

Peopleware, Productive Projects and Teams (3rd Edition) – (Amazon.fr)

Chefs de projet, Managers : la veille technologique, c’est aussi pour vous !

Je pense qu’on sera tous d’accord pour dire que l’industrie du développement logiciel connaît une accélération forte de son rythme d’innovation. Quel que soit le secteur ou la stack technologique, un développeur doit maintenir une veille technologique de plus en plus importante pour rester à jour et profiter de toutes les nouveautés. D’ailleurs ne croyez pas que je vois cela d’un mauvais œil, bien au contraire pour moi c’est très positif, mais ce n’est pas le sujet de cet article.

Le sujet de cet article, c’est qu’il ne faut pas croire que seuls les développeurs doivent se tenir à jour sur l’évolution des outils et techniques de leur profession. Parce que si la technique évolue, les méthodes et processus de travail évoluent tout autant. Agilité, SCRUM, Lean IT, Lean Startup, MVP / MMF, Kanban, Software Craftsmanship, autant dire que ça bouillonne côté gestion de projet / produit / équipe, avec des gains significatifs dans les performances du delivery et dans la satisfaction de toutes les parties prenantes du projet. C’est pour cela qu’à mon sens il est devenu vital pour les chefs de projet de trouver une place dans leur planning pour leur veille technologique.

Bon et là je parle de l’innovation, mais je ne peux pas m’empêcher de rappeler que s’il y a quelques années on arrivait plus ou moins par hasard au poste de chef de projet, aujourd’hui c’est un métier bien défini, avec des tâches élémentaires incontournables : savoir entendre un client/utilisateur sans imposer ses biais cognitifs, abstraire le besoin et modéliser élégamment les processus métier à couvrir par la solution, synthétiser tout ça pour le transmettre de manière efficace et efficiente au reste de l’équipe, déterminer la progression de l’équipe et la rapporter avec transparence à sa hiérarchie. Et que si toutes ces activités de base ne sont pas déjà maîtrisées, c’est le premier sujet à creuser.

Parce qu’entre nous, mettre un costume, passer sa vie en réunion et faire les gros yeux quand le projet n’avance pas tout seul, ça ne suffit plus en 2014 😉

The Office - Wow this is hard

Évidemment c’est le même combat pour les managers. Il se passe énormément de choses en ce moment en psychologie cognitive et en optimisation des organisations (cf les 4 liens de la semaine) et il est pour moi inconcevable de ne pas s’en inspirer dans son job de manageur aujourd’hui. Et évidemment je ne parle pas de déployer Yammer ou de choisir entre Paintball et Karting pour la prochaine sortie de « team-building ». Je parle de l’encadrement d’êtres humains dont la carrière est sous notre responsabilité.

Alors n’oublions pas que quel que soit son rôle dans l’organisation, il est fondamental de maintenir une veille technologique active, à travers la lecture des ouvrages de références, des formations, des conférences, la participation à des groupes d’utilisateurs, ou encore le suivi via Twitter de l’actualité de son domaine.

PS: J’écris cet article la semaine dernière, entre temps je lis The Hard Things About Hard Things, et évidemment ça fait changer mon point de vue sur le sujet – enfin pas qu’il faille entretenir son savoir, mais plutôt qui est responsable de maintenir l’effort dans la durée. On en reparle quand je vous débriefe le bouquin…

Commencer la gestion de projet en décisionnel

Je profite d’avoir rédigé cette petite liste pour un consultant de mon équipe pour la publier ici. Rien de mystique, juste une liste de lecture pour se lancer dans la gestion de projet en décisionnel.

La base, c’est évidement de Joel Spolsky sur son blog Joel On Software :

Puis pour s’y mettre pour de vrai :

  • En mode pratique, c’est évidemment Kimball et Ross avec The Datawarehouse Lifecycle Toolkit (2nd edition – à ne pas confondre avec le DWH Toolkit). Non seulement ils sont forts en modélisation, mais ils font aussi la gestion du projet décisionnel. Malheureusement non traduit en français. Notez pour ceux qui l’ont qu’on peut trouver un avant-gout sur le sujet dans le Datawarehouse Toolkit (3rd edition).
  • En mode théorique, c’est Scott Berkun avec Making Things Happen, il définit bien l’idéologie du chef de projet orienté facilitateur. Mais c’est déjà plutôt du niveau 2. Le niveau 3 étant le Mythical Man-Month de Brooks.

En terme d’approche, le Kimball Group est plutôt orienté itératif, et les théoriciens sont plus classiques (V, waterfall). Si vous voulez creuser le côté Agile appliqué au décisionnel, je vous renvoie aux articles que j’avais écrit tantôt.

Et voilà, avec les bons outils, rien d’impossible !

Avec les bons outils...

N’hésitez pas si vous en avez d’autres (des bonnes ressources pour débuter, pas de gifs hein…) 😉

Le retour des spécifications dans un projet décisionnel lean

Au risque de me faire encore conspuer par nos camarades agilistes militants, je vais vous raconter comment j’ai contribué à la sortie d’un des projets auxquels je participe du mode Agile/Lean. Car oui, je l’avoue, j’ai fait du lobbying pour le retour du cycle en V…

Tout commence par un projet de migration Cognos vers SQL Server, avec une petite équipe de développeurs experts et un client qui fait confiance. Aucun frein à la productivité, les résultats sont immédiats et visibles à travers les premiers états livrés après seulement quelques semaines de travail. Point de vue gestion de projet, l’équipe fonctionne alors en mode cowboy, juste quelques todo lists priorisées, une réunion de suivi hebdomadaire, et tout le monde est bien content.

Les choses s’accélèrent, la migration avance à bon rythme, et le succès rencontré par la production des premiers rapports déclenche la demande de nouveaux rapports. Le client trouve sa place en tant qu’évangéliste de la solution, il identifie des utilisateurs potentiels, vend sa solution en interne et génère encore plus de besoins.

On avance de 6 mois, et… la migration n’est toujours pas terminée. En effet la recette des rapports est décalée en permanence car chaque revue déclenche une flopée d’évolutions. Les nouvelles demandes s’entassent et parfois même disparaissent puisqu’elles ne sont pas suivie d’une manière centralisée (pas de réel backlog) et que la priorité est attribuée aux derniers utilisateurs venus se plaindre dans l’open-space. Il n’y a ni planning, ni suivi du consommé, ni documentation, et même l’architecture technique commence à en souffrir (effet de bord d’une autre décision qui n’est pas le sujet du jour).

Le problème est identifié et c’est à ce moment-là que je rentre en scène. Ma mission est évidemment de remettre de l’ordre dans tout ça. Je reprends donc la longue liste des demandes, je clarifie les items, génère un backlog unique et accroche au mur un beau Kanban tout neuf.

 Dilbert - Méthodes Agiles

Pourquoi un Kanban ?

  • L’équipe fonctionne en livraison continue, sans itération, point positif à conserver
  • On lui reproche un manque de visibilité sur son activité en cours, il faut y remédier
  • Les priorités changent tous les 2 jours, il faut pouvoir s’adapter
  • L’équipe travaille sur trop de sujets à la fois, il faut rationnaliser

On est donc dans le cadre d’application idéal pour cette technique.

Et hasard des réorganisations, c’est justement le moment où un des utilisateurs principaux de la solution, directement en provenance du métier, passe officiellement business owner à temps plein.

S’en suivent 2 mois plutôt positifs, où une fois les process mis en place, le business owner et les utilisateurs constatent une amélioration du delivery en terme de rythme, de réactivité et de visibilité sur l’activité (par ce que oui, un développeur qui ne fait pas de réunion et qui n’envoie pas de mail c’est bien un développeur qui travaille, et pas le contraire). Le reproche éternel de la capacité à s’engager sur des dates est évidemment toujours dans l’air, mais on atteint une visibilité à 3/4 semaines qui à mon sens est la seule période vraiment réaliste.

Et là, c’est le drame…

Devant le regain de productivité de l’équipe, les demandes explosent à nouveau. Les développeurs reçoivent plus de 5 mails par jour des utilisateurs, avec ou sans le business owner en copie. Les règles de gestion évoluent sans cesse, les couleurs dans les rapports aussi, les sources de données changent considérablement, et la mauvaise habitude de donner la priorité au dernier qui a parlé réapparaît. A nouveau l’équipe s’enlise et la satisfaction des utilisateurs sombre.

Pour moi le problème est clair : l’équipe est en sous-capacité. Si nous étions capables de dépiler plus vite les tickets, nous arriverions à retrouver un flux optimal. Mais dans notre cas, même avec l’ajout d’un développeur, la situation persiste. Le delta entre besoin et capacité de production est vraiment trop important. Pas possible d’ajouter plus de ressources, d’un point de vue budget et praticité, nous sommes au maximum.

 Dilbert - Product Owner vs Développeur

Alors j’ai pratiqué ce que je prêche, et j’ai demandé au business owner, qu’on considérera désormais comme un chef de projet MOA, de commencer à écrire des spécifications fonctionnelles. Chaque demande d’évolution doit mettre à jour la spécification correspondante, chaque nouveau besoin doit être pensé et écrit dans le dur.

Mon objectif est clairement d’introduire une contrainte au niveau métier, pour stabiliser la génération des besoins (le rythme est sincèrement démesuré) et ainsi faire basculer au niveau MOA le goulet d’étranglement du flux.

Car à être trop disponible et réactive, l’équipe de développement était devenue une extension du cerveau du business owner, et de certains utilisateurs trop exigeants. Chacune de leurs pensées à demi digérée était rapidement écrite dans un mail et transmise en priorité 1, trop souvent en totale contradiction avec l’info précédante. J’espère que le fait d’avoir à se poser pour penser et écrire concentrera leurs idées et diminuera les changements d’avis. Le travail de réconciliation et d’harmonisation fonctionnelle doit définitivement être réalisé par le business owner, pardon, le chef de projet MOA.

Evidemment c’est une étape temporaire, une astuce qui donnera également à l’équipe le temps de souffler un peu et traiter les vraies priorités. Je compte bien retourner à nouveau dans un mode plus lean une fois l’orage passé. Et je provoque en parlant du retour du cycle en V, puisqu’on conserve bien la livraison continue et le fonctionnement en mode pull. J’impose juste une contrainte de documentation plus lourde côté utilisateur avant d’accepter les activités dans le backlog.

On en reparle dans quelques mois, pour voir si l’expérience porte ses fruits !

PS : Evidemment toute cette histoire se vit dans un contexte d’entreprise plus global, sur fond de guerre politique entre services, de rachat de sociétés et d’avancement de carrière des internes, qui expliquent beaucoup plus mais que je ne peux évidemment pas raconter ici 😉

Savoir rester lean dans son projet décisionnel

Vous vous demandiez peut-être à quoi je passais mon début d’année (plutôt que de vous écrire des articles de 3 pages de long) ? Et bien en dehors de ma récente promotion (une fois nos expérimentations d’organisation stabilisées je vous en parlerai, soyez patients), je le consacre à la finalisation d’un projet de plusieurs mois, réalisé par un padawan de talent et supervisé par mes soins.

Padawans en tenue

Sont pas beaux mes padawans? Tenue obligatoire en clientèle!

Entre 2 anomalies à corriger, nous rédigeons la documentation et préparons le voyage de l’application de l’environnement de développement, et de notre responsabilité, à celui de production, et à la responsabilité de l’exploitation. Au passage c’est toujours pendant ce genre de transition que l’idée du devops revient me faire des yeux doux. Ou encore le concept de livraison continue. Malheureusement ici je n’ai pas réussi à convaincre le métier et l’IT de bosser en mode Agile. Mais ce n’est pas le sujet du jour, revenons à nos moutons !

La documentation technique terminée, elle est relue par le directeur d’étude (respect, ce n’est pas souvent que ça arrive). Et ce dernier s’étonne : quasiment pas de règles de gestion, un schéma en étoile simpliste, un cube à la DSV vide, des dimensions sans surprises techniques. Ok on trouve bien quelques calculs MDX, et ok la partie ETL fait pas loin d’une centaine de packages, mais ce n’est que parce qu’on a fait un bon travail et bien tout découpé en flux de données unitaires. En dehors de ça la solution semble étonnement vide pour 3 mois de développement.

Un tout petit plat gastronomique dans une grande assiette

Minimaliste mais plein de goût, comme au resto gastronomique!

Et bien pour tout vous dire, j’en suis assez fier. Parce que pour arriver à cette apparente simplicité, ce « vide » dans la solution, cela nous a demandé des efforts considérables. Un projet informatique est soumis à une certaine forme d’entropie. Plus on avance, plus des éléments viennent se rajouter, des fonctionnalités, des données, des exceptions, des contournements, et si on n’y fait pas attention, sans rien toucher au périmètre initial de l’application, la solution est tout de même devenue un plat de spaghettis indémêlables avant même la livraison du lot 1.

Lutter contre cette tendance demande un effort constant. Dès qu’on se relâche, on se retrouve avec des règles de gestion implémentées dans des vues (ou pire, dans la DSV du cube), parce que c’est rapide, plutôt que de faire les choses proprement et d’ouvrir une énième fois l’ETL, modifier les métadonnées, les flux, et tout re-tester après.

Mais il ne faut pas se leurrer : tout ça c’est de la dette technique, et rien de pire pour une solution informatique de commencer sa vie encore plus endettée qu’un étudiant américain ! Alors ne relâchez pas la lutte, pensez marathon plutôt que sprint (rien à voir avec SCRUM ;)), pensez Lean, et faîtes un cadeau au vous de dans 6 mois qui devra bosser sur le lot 2 ou corriger une anomalie: laissez-lui une solution toute propre, il vous remerciera!

The Mythical Man-Month – Frederick P. Brooks, Jr.

J’ai profité de mes dernières vacances pour lire « The Mythical Man-Month » (Amazon) de Frederick P. Brooks, Jr. (un des ténors du génie logiciel).

C’est LE livre qui apparaît systématiquement dans les tops 10 des livres à lire pour les ingénieurs logiciels, chefs de projet, développeurs ou encore manageurs de développeurs.

Même si l’édition originale date de 1975, et l’édition anniversaire de 1995, la plupart du contenu reste entièrement d’actualité, puisqu’il s’agit principalement de bon sens. Enfin surement qu’à l’époque beaucoup des choses qu’il raconte étaient nouvelles. Aujourd’hui elles font partie – ou devraient faire partie – de la culture de base de l’informaticien au sens large

Je vous livre quelques idées du bouquin histoire de bien cerner l’ouvrage :

  • (p5,6) On peut étendre un programme en travaillant sur son industrialisation (généralisation, documentation, tests, maintenance…) ou sur son intégration (interfaçages à d’autres systèmes, intégration dans l’écosystème de l’IT), mais pas les 2 en même temps.
  • (p16-19) Ajouter des développeurs à un projet en retard le retardera encore plus, aussi connu sous « 9 femmes enceintes ne font pas un bébé en un mois ».
  • (p32-36) Il propose une méthode d’organisation pour les très gros projets : mettre en place N équipes de 10 personnes chacune centrées autour d’un lead programmer (le chirurgien, un mec ultra talentueux), son copilote (le même en un peu plus junior, qui apprend et vérifie), les 2 seuls à développer et une équipe de support.
  • (p45,46) Définition de l’architecte (il le sous-entend fonctionnel – la MOA quoi) : qui représente l’intérêt de l’utilisateur, qui doit indiquer quel est le résultat attendu mais pas comment cela doit être fait. Par opposition au constructeur (la MOE), qui lui prend en compte les contraintes et le ratio coût/performance, et conçoit  la solution. Ce qui amène un cycle de développement : Architecture (MOA – On définit la fonction d’une boîte noire) > Implémentation (MOE –  On établit le contenu de la boîte) > Réalisation (MOE – On fabrique la boîte). Ne vous offusquez pas sur son choix de vocabulaire, qui diffère de ce qu’on a l’habitude d’employer en France, l’important c’est le découpage des tâches et des responsabilités.
  • (p62) Les spécifications sont le manuel utilisateur.
  • (p116) Le mieux est de toujours commencer par un prototype, jetable ci-besoin, plutôt que de vouloir y arriver du premier coup, puisque la plupart du temps on recommencera plusieurs fois du début.
  • (p117) Tous les besoins utilisateurs ne doivent pas être pris en compte dans le design. Et plus on avance dans le projet, plus c’est vrai.
  • (p142) Il faut tester les spécifications : faire des maquettes, tester les règles de gestion, avant même de commencer le développement.
  • (p143) Le mieux est de faire des programmes modulaires, afin d’augmenter la capacité d’adaptation du système (En 1975 manifestement ce n’était pas évident ;)).
  • (p155) Les jalons sur le planning doivent être clairement identifiés (périmètre et date), afin de ne pas pouvoir se mentir à soi-même par rapport à l’avancement.
  • (p157) Un directeur de projet ne doit pas intervenir dès le premier retard d’un de ses chefs de projet, sans quoi ils arrêteront de rapporter les glissements pour fuir le micromanagement.
  • (p201) Le développement itératif c’est le top (En 1975 ! C’était révolutionnaire !)

Évidemment il y a plein d’autres choses très intéressantes, et à chaque fois il développe et justifie ses idées, mais pour moi le top est dans cette liste.

Vous faut-il le lire ?  Je dirais oui si :

  • Vous vous devez d’avoir de la crédibilité en tant que bloggeur qui ramène sa fraise sur la gestion de projet (mon cas ;)).
  • Vous êtes ou aspirez à devenir chef de projet et que vous voulez comprendre le pourquoi de ce que vous appliquez.

Dans le cas contraire, votre bon sens, l’expérience personnelle et suivre la « BI ça vous gagne » suffiront largement à faire votre culture 🙂