Je vous ai déjà parlé du site « Jester Management » créé par mon ami Loïc. C’est un très bon blog qui parle de management, de gestion de projet, de geekeries, etc. Si vous appréciez mon blog et que vous lisez l’anglais, c’est vraiment une lecture indispensable. Les blogs ont souvent un…
Livre : Managing Humans
Je vais vous parler un peu d’un très bon livre, nommé Managing Humans, écrit par Michael Lopp et publié par Apress en 2007. Depuis 2002, il tient sous le pseudonyme de Rands le blog Rands in repose, dans lequel il parle de ses expériences en tant que manager d’équipes techniques. Et il en a des choses à dire, le bougre, après avoir travaillé pour Symantec et Netscape, entre autres.
Le sous-titre du livre est assez explicite : « Biting and humorous tales of a software engineering manager ». Le livre est truffé d’anecdotes amusantes, de mises en situation réelles ou imaginaires, qui en font un ouvrage à part dans l’univers très fourni des livres dédiés à la gestion de projet et au management.
Personnellement, j’ai une affection particulière pour ce livre. Je l’ai acheté à sa sortie en 2007, alors que j’étais en train de créer mon entreprise. Je n’y ai pas trouvé de recette miracle, mais plein d’exemples de choses à faire ou ne pas faire ; je pense avoir évité plusieurs pièges dans la création de mon équipe grâce à ce livre.
Ne pas être un con
Le premier chapitre du livre se nomme « Don’t be a prick ». L’ensemble des 209 pages pourrait être résumé dans cette simple phrase. Ça paraît débile tellement c’est simple. Mais au cours de ma carrière, j’ai franchement rencontré tellement de personnes qui agissaient comme des gros cons, que ça mérite d’être souligné. Que ce soit par bêtise, inexpérience, indélicatesse, fainéantise, vanité ou parce qu’ils n’avaient rien à faire à ce poste, il est sidérant de voir combien de dirigeants sont inaptes à gérer les hommes et les femmes qui composent leurs équipes.
Le carquois du management
Rands utilise une métaphore assez intéressante. Il dit que nos compétences en management sont comme des flèches dans un carquois. Quand on rencontre un problème, on peut prendre la flèche appropriée, prendre un peu de recul, viser et tirer. C’est le titre qu’il a donné à la première partie du livre.
Échelle différente, problèmes similaires
Une des choses que j’ai apprises au fil des années et des expériences professionnelles, c’est que les problèmes rencontrés sont globalement les mêmes quel que soit le niveau où l’on se situe. Ce n’est qu’une question d’échelle.
Prenons l’exemple qui nous intéresse particulièrement : la gestion de projet.
- Un développeur éprouve souvent des difficultés à faire son travail dans de bonnes conditions. Ce qu’on lui demande de faire est très imprécis. Il a beau essayer de faire du mieux qu’il peut, ses supérieurs trouvent toujours quelque chose à lui reprocher (ce n’est pas fait assez vite, ce n’est pas fait assez bien, ce n’est pas fait dans le bon ordre…).
- Un chef de projet s’arrache régulièrement les cheveux. Il a plusieurs projets à gérer simultanément, chacun étant classé « haute priorité ». Les demandes des clients sont systématiquement incomplètes. Les développeurs ne sont pas disciplinés et font ce qu’ils veulent quand ils le veulent.
- Un directeur technique doit réussir à trier les différents projets, les affecter aux chefs de projets, suivre de près leur évolution. Il enrage souvent de ne pas avoir les remontées d’informations nécessaires pour anticiper les problèmes, de devoir pallier à la non-organisation de l’ensemble de ses collaborateurs et de passer plus de temps à « résoudre » et « corriger » qu’à « préparer » et « produire ».
Je ne vais pas expliquer maintenant comment il faut s’organiser pour gérer les projets (il y aura plusieurs autres billets sur ce blog à ce sujet). Mais ne voyez-vous pas qu’il y a des tendances qui sont les mêmes ?
Je vois 3 choses fondamentales :
- L’information entrante : Elle n’est jamais satisfaisante. Si ce sont des spécifications, fonctionnelles ou techniques, elles sont incomplètes. Si c’est une liste de tâches à réaliser ou un ordre de mission, il n’est pas suffisamment clair. La question reste « Qu’est-ce que je dois faire ??? » (et par ricochet quand on doit gérer une équipe : « Qu’est-ce que je dois déléguer ? »).
- L’organisation : Principalement, cela consiste à savoir qui fait quoi, et dans quel ordre. Et parce qu’elle est – à tort – considérée comme uniquement personnelle, l’organisation est souvent laissée à l’écart des processus globaux de gestion des projets. C’est une erreur, car c’est là que se joue la productivité des collaborateurs d’une entreprise.
- L’information sortante : Il n’y a jamais de situation réellement insoluble en entreprise. Mais c’est par la qualité de nos remontées d’information que les problèmes pourront être anticipés, que les projets vivront correctement dans la durée, que nous devenons acteurs au lieu de spectateurs.
Ces trois points restent immuables, quels que soient votre poste et vos responsabilités.