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…

Dilbert du 2014-03-20

On en avait déjà parlé, c’est un thème récurrent de Scott Adams, l’auteur de Dilbert:

Dilbert du 2014-03-20

Traduction approximative:

Boss: Les experts affirment que les manageurs doivent recruter des gens talentueux, et fixer des attentes claires.

Boss: Mais ils ne disent pas quoi faire quand on a raté la première partie. J’ai tendance à penser au micro-management.

Alice: Ma bonne volonté vient d’en prendre un coup.

Boss: Elle était déjà inexistante.

Dilbert du 2013-10-09

En tant que chef de pôle je me sens un peu concerné :/

Dilbert du 2013-09-10

Traduction approximative:

Boss: Arrêtez de vous plaindre et apportez moi des solutions.

Dilbert: Okay.

Dilbert: Débarrassons nous de tous ces niveaux de management qui ne produisent rien mais qui demandent beaucoup.

Boss: Toujours aussi désagréable!

Dilbert: A votre tour de vous plaindre?

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 🙂

Dilbert du 22/04/2012

Excellent celui là! Il contient tellement de thèmes récurrents sur ce blog en une seule planche 🙂

Traduction Approximative:

Boss: Vous avez des questions concernant le plan projet?

Dilbert: Si on considère toutes les taches ensembles, elles forment un plan rationnel.

Dilbert: Mais si on regarde nos taches individuelles, elles sont tellement loin du plan global qu’elles n’ont plus aucun sens.

Dilbert: Vous avez réussi à éliminer tout sens à ma vie.

Dilbert: Rationnellement, je comprend le bénéfice de découper les taches en petits morceaux.

Dilbert: Mais ça n’a tellement plus de sens qu’émotionnellement vous m’avez détruit. Ma volonté est anéantie.

Boss: Ne pouvez vous pas trouver du sens dans votre vie personnelle?

Tina: C’est un ingénieur.

Dilbert: Ça c’est méchant.