Il y a une limite à ce qu’on peut imposer

J’ai déjà écrit plusieurs billets consacrés à l’investissement personnel que l’on doit mettre dans son travail, que ce soit parce que les problèmes sont similaires malgré les différences d’échelle, ou parce qu’il y a toujours quelque chose à apprendre en entreprise, qu’il ne faut pas se sous-estimer, ou encore parce qu’il faut rester honnête en toute circonstance.

Comme je l’ai dit par le passé, il faut toujours chercher à progresser ; se mettre à la place des autres ; pensez aux choses auxquelles ils n’ont pas le temps de penser ; faire les choses qu’on est censé faire, pour leur éviter d’y penser à notre place ; apprendre de ses erreurs et ne pas y chercher d’excuse.

Je voudrais juste nuancer mon propos en disant qu‘il y a une limite à ce qu’on peut imposer aux autres.

Au sein d’une équipe

Cette limite est facile à atteindre quand on est « en bas » d’une hiérarchie, et qu’on tente d’imposer des solutions à ses supérieurs ou à l’ensemble du groupe. Le manque d’autorité empêche bien souvent de faire prendre aux autres le temps d’écoute et d’analyse nécessaire.

Mais cela peut aussi concerner des requêtes « top-down », qui peuvent être mal perçues car elles chamboulent les (mauvaises ou bonnes) habitudes.

Forcer les choses est la pire des démarches. Cela ne peut aboutir que sur des levées de boucliers.
Il vaut mieux adopter la technique du « courage, fuyons ! » :

L’encadrement des juniors

L’encadrement de juniors (stagiaires et jeunes diplômés) est un sujet assez vaste, et je vais juste aborder ici un point de détail qui concerne la manière dont les entreprises abordent leur productivité.

Il existe un principe de base qui est valable pour tout le monde :
« Comprendre ce qu’on fait et ce sur quoi on travaille »

Quand on embauche une personne qui a de l’expérience, c’est souvent pour la faire travailler sur des projets assez pointus. Dans ce cas, on s’attend communément à ce que la complexité de la tâche implique un « temps de démarrage » conséquent.

Il est assez logique que les juniors, pour leur part, se voient affecter des tâches plus accessibles d’un point de vue technique. Mais de nombreuses personnes voudraient qu’un junior soit immédiatement opérationnel. La réflexion qui est faite est du style : « Ce n’est pas bien compliqué, franchement, il devrait avoir terminé dans 2 jours, non ? ».
Le problème, c’est que n’importe quel travail doit se faire en ayant une maîtrise de son environnement et de ses impacts potentiels.

On ne peut pas demander à un jeune embauché de faire du bon boulot, si on n’a pas pris le temps de le former correctement sur les méthodes et outils spécifiques employés dans l’entreprise. Même si le travail demandé semble mineur, il faut se souvenir que l’expérience du collaborateur est limitée elle aussi. Un défaut d’encadrement peut conduire à des situations désagréables. La plus commune est que le junior, après avoir travaillé 3 jours sans avoir reçu de formation interne, doit recommencer tout le travail parce qu’il n’a pas respecté les directives qu’il n’a pourtant pas eues. On voit aussi fréquemment des personnes qui commencent à modifier du code sans le comprendre, générant un nombre incroyable de bugs de régression.

La pire situation que j’ai vue, c’est une entreprise qui formait ses jeunes « à la dure » : aucune formation, directement affectés aux débuggages ! Autant vous dire que ce n’était pas très efficace…

Si vous encadrez un junior

Vous devez lui fournir toutes les informations nécessaires. On ne laisse pas les gens se débrouiller tous seuls ; cela revient à les laisser dans la merde. Prenez le temps d’expliquer les méthodes, outils et usages qui ont cours dans votre entreprise. Faites leur faire un premier projet pour se faire la main, sur lequel vous les encadrerez de très près.

Le nocif

Dans la série des billets consacrés aux types de collègues, et pour faire la suite à ceux consacrés aux affectifs et aux revendicateurs, je vais aujourd’hui vous parler des « nocifs », c’est-à-dire des personnes qui – pour une raison ou une autre – sont réellement néfastes pour une équipe ou une entreprise. Nous allons voir comment reconnaître un nocif, et quelles sont les solutions qui s’offrent à vous pour traiter leurs cas.

À quoi reconnaît-on un nocif ?

Nous avons tous cotoyé au moins une personne dont le comportement ne semblait pas correspondre à celui attendu. Cela peut toucher un assez grand nombre d’attitudes :

  • Connaissances techniques trop faible. Un développeur qui est tellement mauvais techniquement qu’il produit systématiquement du mauvais travail.
  • Problèmes d’horaires. Quelqu’un qui arrive à 11h00 le matin et part à 17h30 le soir, ou qui se prend 20 minutes de pause toutes les 45 minutes.
  • Non-implication dans son travail. Une personne qui se met dans un simple rôle d’exécutant, au lieu d’utiliser ses compétences et son imagination pour faire réellement avancer ses projets.
  • Mauvaise volonté systématique. Quelqu’un qui réfute par principe toutes les idées qui lui sont soumises, ou qui ne prend en compte que les choix qui l’arrangent.
  • Problèmes de communication. La personne qui reste dans son coin en parlant le minimum possible. La personne qui n’arrive pas à avoir un débat constructif, et s’énerve dès que ses idées ne sont pas suivies. Celui qui ramène toutes les discussions à ses propres problèmes immédiats.
  • Problèmes avec l’autorité. Quelqu’un qui n’accepte pas qu’une autre personne puisse décider de ses priorités et de son planning.
  • Comportement non professionnel. Une personne qui se permet d’insulter ses collègues. Un commercial qui tutoies les clients. Un chargé de clientèle qui n’offre pas toute l’écoute qu’li devrait.

Sus aux emails

Il existe plusieurs méthodes de travail qui s’intéressent à la relation que nous avons avec nos boîtes aux lettres électroniques. Pour n’en citer que deux, je dirais GTD et Zero Inbox, dont le but est d’améliorer le traitement des messages que nous recevons, pour être certain de traiter convenablement les informations reçues. Ce sont des approches très intéressantes, dont je vous parlerai dans de futurs posts.

Pour le moment, je vais vous parler de quelque chose d’autre, qui concerne aussi la manière dont nous utilisons les emails en entreprise. Plus particulièrement, je vais vous expliquer pourquoi il ne faudrait jamais – jamais – échanger de documents de travail par email.

Très souvent, les gens ont tendance à s’échanger les documents (spécifications fonctionnelles, spécifications techniques, listes de choses à faire, relevés de bugs, …) par email. Ça commence par un petit document rédigé par quelqu’un sur son traitement de texte ou son tableur. Voulant que ce document soit lu et utilisé par les autres intervenants du projet, cette personne va donc le leur envoyer par email. Les destinataires vont recevoir le document, le lire, et éventuellement le modifier. Les modifications seront elles-mêmes envoyées par email à toutes les personnes impliquées. Jusque-là, c’est assez clair.

Pourtant, malgré cette clarté apparente, le vers est déjà dans la pomme. Plusieurs pièges classiques peuvent apparaître :

  • Plusieurs personnes modifient le même document, puis le renvoient. Vous vous retrouvez avec autant de versions différentes du même document. Tant que personne n’aura fait le travail de « réconciliation » pour fusionner ces versions, vous allez devoir jongler tel un acrobate.
  • Le premier document aura certainement été nommé en respectant une norme, incluant le numéro de version du document et/ou sa date de création. Mais il y a de fortes chances pour que ceux qui l’éditeront ne pensent pas à modifier le nom du fichier avant de le renvoyer.

L’effet tunnel

Toutes les personnes qui ont géré une équipe connaissent l’effet tunnel. C’est lorsqu’il vous est impossible de connaître l’état d’avancement d’une tâche ou d’un projet et que vous n’avez pas d’autre solution que d’attendre que le travail soit terminé pour pouvoir l’évaluer.
Avant d’étudier les origines de ce mal et comment le prévenir, voyons pourquoi l’effet tunnel est très mauvais :

  • Vous n’avez aucune visibilité sur le planning. Comme il est impossible de savoir si la tâche sera terminée demain ou dans 2 semaines, il est tout aussi impossible de prévoir les retards sur l’ensemble du projet. Comment répartir les tâches et affecter les ressources lorsque vous ne maîtrisez pas la réalisation du travail ?
  • Vous ne pouvez pas redresser le tir si le projet part dans une mauvaise direction. Vous pourrez évaluer les dégâts qu’une fois que tout sera terminé. Et bien souvent, vous aurez alors le choix entre vous satisfaire d’une réalisation bancale (travail incomplet, qui ne répond pas aux spécifications, insensé à maintenir) ou tout recommencer à zéro.

L’effet tunnel a toujours pour origine les choix des individus à qui vous confiez les tâches, et la manière dont ils les abordent. Dans tous les cas, vous pouvez l’éviter avec de la diplomatie et de la méthode.

Le glandeur naturel

La plupart du temps, l’effet tunnel est le fait d’une personne à qui vous avez laissé la possibilité de glandouiller tranquillement. Laissez 5 jours à un développeur pour créer un nouveau module, et vous pouvez être certain qu’il va passer 3 jours à faire autre chose, puis 1 journée à se demander ce qu’il va faire et à se motiver pour le faire, puis passer 3 jours à coder comme un fou. Résultat, il sera en retard et aura oublié qu’il devait faire une documentation succincte.

Lorsque vous demandez à un glandeur naturel ce qu’il est en train de faire, il ne va pas vous répondre « Je surfe sur des sites de foot parce que le nouveau championnat commence bientôt », même si c’est ce qu’il a fait pendant les 3 dernières heures. Il va plutôt prendre un air très affairé, peut-être même semblera-t-il agacé que vous lui fassiez perdre son temps, pour vous faire comprendre qu’il est vraiment plongé dans le boulot jusqu’au cou. Vous repartirez avec pour seule information « Je suis en plein dedans, c’est bientôt fini, je te préviendrai quand ce sera bon« , et une indéfinissable impression de vous être fait bananer.

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.

Managing Humans - couverture

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.

L’affectif

Pour bien gérer les rapports entre les intervenants d’un projet, il est nécessaire de comprendre comment chaque personne fonctionne. Je vais ainsi vous brosser plusieurs portraits types. Évidemment, les collaborateurs avec qui vous devrez travailler ne colleront jamais complètement à ces portraits ; ou plutôt, chaque personne présente des aspects qui peuvent être assimilés à tel ou tel type. À vous de les comprendre et de vous adapter en conséquence.

L’affectif

Si j’ai choisi de commencer par ce profil, c’est parce que nous avons tous une part d’affectif en nous. C’est quelque chose que nous connaissons bien, mais que nous avons parfois du mal à reconnaître ou à accepter chez les autres.

Un « affectif » a tendance à réagir à l’instinct. Quand il a un bon moral, que tout semble se mettre en place favorablement autour de lui, il devient un travailleur efficace et très impliqué. Malheureusement, il suffit d’un petit grain de sable pour stopper la machine.
Un des facteurs les plus importants pour ce genre de personne, c’est la reconnaissance de sa valeur, et donc de son travail. Un affectif pourra se donner à fond, même pendant de longues périodes, tant qu’il sent que ses supérieurs lui en sont reconnaissants et qu’ils apprécient son travail. C’est souvent quelqu’un qui doit être motivé de manière positive continuellement.

À l’inverse, il suffit parfois d’une remarque pour que l’affectif se démotive complètement. Cela peut être juste une question légitime, au sujet d’un bout de code que vous ne comprenez pas ; il aura quand même l’impression que vous pensez qu’il a fait du mauvais boulot. Il existe alors 2 versions, qui aboutissent au même résultat :

  • L’affectif « combatif » décidera que vous avez tort, et travaillera moins ou moins bien par choix. C’est une manière de revendiquer.
  • L’affectif « démoralisé » se mettra à douter de ses capacités et commencera à cogiter, jusqu’à ne plus pouvoir travailler parce que son cerveau est trop occupé.

Les réunions

Ah, les réunions… Suivant l’entreprise dans laquelle vous êtes, vous avez l’impression de ne pas en faire suffisamment ou au contraire d’en faire trop. J’ai connu les deux.

La recette

Voici les éléments-clés d’une réunion :

  • Un ordre du jour. Tous les participants à une réunion doivent savoir quel va en être le sujet. Cela peut être formalisé dans un email, ou être implicite si c’est une réunion qui se répète régulièrement. Mais si quelqu’un ne sait pas quel est le thème de la réunion à laquelle il se rend, pour pouvez vous attendre à une belle perte de temps.
  • Des participants. Oui, ça semble un peu bête. Mais pensez bien que toutes les personnes nécessaires aux prises de décisions doivent être présentes, sinon vous serez bon pour refaire une autre réunion par la suite. Évitez aussi les réunions où est conviée la moitié de l’entreprise « au cas où on aurait besoin d’eux » ; vous risquez surtout d’avoir des discussions sans fin qui s’éloignent du sujet, et des personnes qui perdent leur temps à se demander ce qu’elles font là. Si à un moment donné vous vous rendez compte que vous avez besoin de la présence d’une personne qui n’a pas été conviée, interrompez immédiatement la réunion pour aller chercher cette personne.
  • Des décisions claires. Trop souvent, les gens quittent une réunion parce qu’ils ont l’impression d’avoir fait le tour d’un sujet, ou par épuisement personnel. Il faut que les décisions prises à la fin de la réunion soient claires pour tous les participants. Si certains avis n’ont pas été tranchés, soyez clairs aussi sur cet état de fait, en notant éventuellement les impacts que cela peu avoir, et surtout en vous accordant sur les éléments qui empêchent de prendre la décision. S’il manque une analyse, notez à quelle date elle doit être terminée, et qui en est le responsable ; si la personne qui peut prendre la décision n’était pas présente ou n’a pas pu se décider, prévoyez immédiatement une prochaine réunion.
  • Un compte-rendu. Les décisions peuvent sembler claires en sortant de réunion, il n’en reste pas moins que chacun en gardera les souvenirs qu’il aura bien voulu mémoriser (ou qu’il aura daigné noter sur son cahier). Le seul moyen de s’assurer que la réunion sera suivie des effets prévus, c’est d’en rédiger un bilan qui sera envoyé à tous les participants. Impossible alors de se rétracter derrière le « Ah ? Je ne me souviens pas qu’on ait dit ça en réunion… ».

Choisir ou être choisi

Quand on a un poste de manager, que l’on doit gérer des personnes, il y a une notion qui peut parfois faire une grande différence : avoir été choisi pour occuper ce poste, ou choisir les personnes que l’on aura à gérer.

Choisir

C’est l’option la plus confortable. Vous arrivez au tout début d’un projet, à la création d’un service ou d’une entreprise. Saisissez cette grande opportunité ! Vous allez pouvoir faire les choses à votre manière.

Recrutement

Votre équipe est vide, il va falloir la constituer. Vous allez pouvoir choisir les personnes qui vont vous rejoindre. Même si je ne vais pas m’étendre sur le sujet pour le moment (il est trop vaste), il n’en reste pas moins que c’est le meilleur moyen d’entamer une collaboration. Vous allez choisir ces personnes ; dès l’embauche vous aurez commencé à tisser des liens privilégiés. Cela ne garantit pas le succès d’une collaboration, mais ça peut grandement la faciliter.

Méthodes de travail

Vous pouvez mettre en place les méthodes que vous voulez, soit parce que vous les avez déjà rodées, soit parce qu’elles vous semblent pertinentes. N’ayez pas peur ! Ce ne sont pas vos supérieurs qui s’y opposeront : ils seront très heureux de s’en remettre à vous, et plus vous montrerez votre dynamisme à ce niveau, plus ils vous feront confiance.