Le «harcèlement positif» comme méthode de travail

Il y a environ un an, je vous parlais du logiciel Action Method. Il propose une fonctionnalité «nagging», qui permet de rappeler au responsable d’une tâche que celle-ci réclame une attention particulière ou une exécution rapide.
J’aime bien cette fonction toute simple mais très utile. J’ai implémenté la même chose dans l’outil de gestion de projets qu’on utilise en interne dans mon entreprise, et je pense l’inclure au projet Skriv.

Les leviers de productivité

Avec le temps, je me suis rendu compte que je me servais − et je ne suis pas le seul − du «harcèlement» comme d’une manière normale de travailler. Non pas que je harcèle les gens avec qui je bosse (c’est puni par la loi !), mais je les incite à me harceler.

Je m’explique : De par mon poste de directeur technique, je suis amené à réaliser un certain nombre de choses par moi-même, mais une part importante de mon travail est de permettre aux autres de travailler. Que ce soit en débloquant un développeur qui reste scotché sur un bug, en aidant l’administrateur sur des tâches IT, en discutant de spécifications avec un chef de projet, en organisant les procédures d’une équipe, … je passe plus de la moitié de mon temps à “mettre de l’huile dans les rouages“.
C’est un calcul simple à faire : Cette vingtaine de personnes, si je peux faire quelque chose pour la rendre plus productive, elle générera plus de résultats que si je me concentre uniquement sur mes tâches. Et même si je ne réussis qu’à améliorer la productivité de 3 personnes, ça en vaudra la peine.

Petit aparté : Cette manière de faire peut être dangereuse si on ne la maîtrise pas. Il ne faut pas devenir le point de passage obligatoire pour toutes les réalisations, sinon on se transforme en goulot d’étranglement. Au lieu de rendre les gens plus productifs, on ralentit au contraire leur travail.

Priorités vs réactivité

Malheureusement, devenir un tel «point central» fait qu’il y a souvent un défilement incessant de personnes qui viennent me demander quelque chose. Parfois c’est juste pour avoir une info ou pour me demander mon avis avant de prendre une décision, d’autres fois c’est pour me demander de réaliser une opération qui va prendre plus de temps.

Au début, je notais les requêtes au fur et à mesure qu’elles arrivaient, en utilisant ma todo-list personnelle, ou notre buglist ou notre logiciel de gestion des tâches. Mais ça ne fonctionnait pas. Les requêtes s’empilaient sans que les demandeurs ne fassent l’effort de réfléchir aux priorités de leurs demandes. Je les traitais suivant leur ordre d’arrivée et non pas suivant leur importance ; j’étais dans la réaction et pas dans la planification.
Évidemment, j’aurais pu simplifier les choses en répondant à chaque demande «Tu as créé un ticket dans la buglist ?», et attendre le lendemain pour revoir l’ordre de priorité de toutes les tâches en attente. Mais perdre en réactivité n’est pas la bonne réponse à un problème d’identification des priorités.

Le harcèlement positif

Au final, quand quelqu’un a besoin de moi, il y a 3 scénarii :

  1. Je suis occupé à faire quelque chose d’important et long. Je demande de revenir plus tard, mais je m’informe quand même de l’importance de la demande (au cas où).
  2. Je suis occupé, mais je n’en ai plus que pour 2 minutes. Je demande à la personne de s’asseoir à côté de moi et d’attendre que j’ai fini. Quand les demandes ne sont pas si importantes que ça, les gens n’ont naturellement pas la patience d’attendre. Ils agissent comme si j’allais systématiquement m’arrêter de travailler pour traiter leurs requêtes dans la seconde ; mais si on leur demande à eux d’attendre, ils y réfléchissent à 2 fois.
  3. Il y a déjà plusieurs personnes qui font le pied de grue pour utiliser mon «temps machine». Dans ce cas, on évalue collégialement les priorités. Mais il y a un effet naturel qui s’ajoute : Lorsque quelqu’un attend depuis longtemps, il fait ce qu’il faut pour ne pas continuer à attendre ; soit il finit par abandonner (ce n’était pas si important finalement), soit il réussit à nous convaincre de l’importance de sa demande.

Quand quelqu’un a réussi à m’atteindre (si je puis dire), je lui demande de rester assis à côté de moi pendant tout le temps que je vais prendre pour réaliser ce qu’il me demande. Ceci est valable pour toutes les tâches «normales». Si une tâche va me prendre plusieurs heures, je l’intègre à ma todo-list globale.
On pourrait s’étonner du fait que je force des non-techniciens à rester près de moi, même quand je ne fais qu’exécuter des actions techniques. Pourtant, c’est justement ce qui fait que cela fonctionne :

  • Si la personne s’en va, il y a de gros risques que quelqu’un d’autre arrive juste derrière et me fasse travailler immédiatement sur une tâche plus urgente. Cela a moins de chances d’arriver si je suis visiblement occupé avec une autre personne.
  • Si la personne qui me demande quelque chose ne peut pas rester avec moi, si elle a plus important à faire que de s’assurer que je m’en occupe rapidement, c’est sûrement que ce qu’elle me demande n’est pas très important. Ou en tout cas, cela veut dire que j’ai moi aussi d’autres tâches plus importantes dont il faut que je m’occupe.
  • En gardant les requérants auprès de moi, je peux leur donner les informations qui leur permettront d’être indépendants la prochaine fois. Si par contre je m’en charge toujours de A à Z, tout seul dans mon coin, il n’y a aucune chance qu’ils montent en compétence.
  • Au moment où la tâche est terminée, ils en ont aussitôt un statut exact et complet. Il n’y a pas de tergiversation, il n’y a pas de perte d’information à cause d’une communication incomplète.

Qu’en penser ?

Je suis conscient de l’aspect complètement empirique de cette manière de travailler. Peut-être qu’elle ne peut pas s’appliquer à toutes les personnes ni à toutes les situations. Mais je l’ai vu fonctionner à maintes reprises, et ça fonctionne dans mon entreprise.

D’une certaine manière, cela me rappelle certains aspects de la méthode Getting Real de 37signals. Entre autres son paragraphe Start With No. On peut y retrouver des notions similaires :

  • On doit parfois ajouter des contraintes pour devenir plus efficace.
  • Les idées importantes finissent toujours par se faire entendre. Sans système de filtrage, c’est la cacophonie.

Les premiers enseignements de Rework

J’ai déjà parlé plusieurs fois de l’entreprise 37signals, de ses logiciels de gestion de documentation et de projet, et de sa méthode Getting Real. Actuellement, ses membres travaillent au successeur de leur livre, dont le nom sera Rework. Ils ont présenté quelques bribes d’information sur le livre, et je me suis arrêté sur le quatrième de couverture :

Je trouve que le texte qui s’y trouve est très intéressant, un brin controverse, et mérite qu’on s’y attarde. Voici une traduction très libre de son contenu, et ce que j’en pense.

“Dès que possible” est un poison

Il est vrai qu’en entreprise, on rencontre bien souvent ce genre de situation : On essaye de se mettre d’accord sur la spécification d’une nouvelle fonctionnalité, et quand vient le moment d’en définir la date de livraison, on se voit répondre “Dès que possible”. Cela peut sembler la réponse la plus honnête, la plus simple à comprendre de tous et la plus facile à gérer ; mais en fait il s’agit souvent d’un pis-aller qui démontre que le projet n’est pas réellement pris en main.

Quand on demande un développement ASAP (as soon as possible), on abdique sur tous les facteurs qui définissent un projet :

  • La définition exacte du projet n’a pas été faite correctement. On sait bien qu’on n’a pas pris le temps de réfléchir à tous les cas limites, à penser à toutes les situations. On sait − mais on ne le dit pas ouvertement − que les développeurs devront affronter tous ces culs-de-sac fonctionnels au fur et à mesure qu’ils se casseront les dents dessus, ce qui empêche d’apporter une quelconque valeur aux estimations qu’ils peuvent faire de leurs développements.
  • À partir du moment où la seule contrainte exprimée est celle du temps passé sur le projet, on accepte implicitement que des raccourcis soient fait pour atteindre l’objectif au plus vite. Un aspect en pâtira forcément, qu’il s’agisse de la qualité générale de la réalisation, de la maintenabilité du code, des tests, du débuggage, …
  • À l’inverse, l’absence de deadline réaliste autorise les développeurs à se lancer dans des développements inutiles (je ne parle même pas de ceux qui se tournent les pouces). On arrive ainsi à des situations où on découvre au bout de 2 semaines que le développement “ASAP” aurait pu durer 4 jours si on avait pris le temps de dimensionner et budgéter le projet correctement ; mais si on en fait la remarque au(x) développeur(s), on obtient une réponse du genre «Ah, moi j’estime que tout ce que j’ai fait était nécessaire pour que le projet fonctionne correctement. Il fallait me prévenir si c’était plus urgent que ça !».

Continuer la lecture de « Les premiers enseignements de Rework »

Et si Gordon Ramsay était informaticien ?

Depuis quelques temps je ne rate pas un épisode de l’émission Cauchemar en cuisine, qui est diffusée sur plusieurs chaînes télévisées françaises de la TNT ou du câble.

Le concept de cette émission est assez simple : Gordon Ramsay, un chef cuisinier écossais renommé, vient en aide à des restaurateurs au bord de la faillite. Là où ça devient amusant, c’est que Gordon n’a vraiment pas sa langue dans sa poche ; il n’hésite pas à s’énerver très fort quand il le faut, pour faire prendre conscience aux gens qu’il sont sur la mauvaise voie.
Bon, la traduction française a tendance à édulcorer son langage. Ainsi, la phrase «I will smash this plate on your fuking head» est devenu «Je vais casser cette assiette sur ta tête de bois»…

Au fil des épisode, on peut voir des cuisiniers sans talent, des gérants à l’égo stratosphérique, des restaurants complètement vides, des engueulades à côté des clients, …
Gordon goûte les plats, regarde comment fonctionne l’organisation du personnel, étudie les comptes financiers. Il met ensuite les responsables − le propriétaire, le gérant de salle, le chef cuisinier − face à leurs lacunes, leurs faiblesses, leur fainéantise, leur désorganisation. Quand les problèmes ont été compris (au bout de quelques bonnes engueulades hautes en couleur), il met en place un plan de bataille qui permet de remonter les résultats du restaurant.

Il utilise souvent les mêmes recettes (au sens figuré du terme, désolé je n’ai pas pu m’en empêcher) d’un restaurant à l’autre, mais à chaque fois avec des résultats différents. Ce qui est vraiment intéressant, c’est qu’il met en application des principes qui tiennent plus de l’entrepreneuriat que de la restauration. Il y a beaucoup d’inspiration à trouver là pour une équipe technique.

L’étude de marché

À chaque fois, Gordon fait un petit tour dans la ville où il est tombé. Il fait attention aux autres restaurants existants, et essaye de trouver le type de restauration qui n’est pas représenté. Il regarde aussi la clientèle existante (ou ce qu’il en reste), et à partir de tout ça il invente un nouveau visage au restaurant pour lui faire trouver une nouvelle clientèle.
Cette nouvelle identité est souvent mal vécue par les patrons qui voient leurs habitudes remises en question. Le menu est complètement revu (je vais y revenir), le restaurant est redécoré, parfois même renommé. Mais ce nouveau positionnement est gagnant, et l’augmentation des bénéfices lui donne toujours raison.

Continuer la lecture de « Et si Gordon Ramsay était informaticien ? »

Pas de productivité miracle

Il existe un grand nombre de soit-disant « méthodes », qui sont censées nous enseigner tout ce que nous avons besoin de savoir pour augmenter notre productivité de manière incroyable. Qu’ils s’agisse de livres ou de sites web, vous les trouverez sous des noms plus tentants les uns que les autres : « 101 trucs pour booster votre productivité« , « Travaillez à 400%« , « Soyez 10 fois plus productif« .

Évidemment, il existe des vraies méthodes d’organisation personnelle qui permettent d’augmenter notre efficacité et donc notre productivité, comme la très connue méthode GTD.

Il faut comprendre la différence entre ces deux approches.
Les méthodes d’organisation personnelle offrent des outils qui aident à faire les bons choix dans le traitement des tâches qui nous incombent. Elles se focalisent principalement sur la définition et l’identification des priorités, et le tri rapide des tâches. Leur efficacité est réelle, même si elle est inversement proportionnelle à l’organisation « naturelle » de la personne qui en applique les principes.

A contrario, les méthodes de « productivité miracle » font miroiter la possibilité de traiter plus de tâches sur la même période de temps.
Cela peut être atteint en agissant sur deux fronts : traiter les tâches plus rapidement, et réduire les périodes non consacrées au travail directement productif. C’est très honorable, et au final assez naturel quand on essaye d’optimiser notre productivité. Mais espérer multiplier sa productivité par 3, 4 ou 10, semble plutôt naïf.

  • La plupart du temps, quand on traite une tâche on le fait avec une efficacité relativement satisfaisante. Même s’il est toujours possible d’améliorer les choses (par exemple en supprimant les éléments perturbateurs, afin d’améliorer la concentration), il est souvent vain de vouloir traiter une tâche deux fois plus vite que d’habitude. On est surtout sûr de la traiter deux fois moins bien.
  • Réduire le temps non productif est une très bonne idée. Une partie de ce temps est nécessaire et relativement incompressible : tout le temps qu’on passe en formation (à en donner et à en recevoir), à réfléchir à des spécifications, à encadrer son équipe, …
  • Reste le temps pendant lequel on se gratte la tête, on joue avec des trombones, on touille son café, on va lire le journal au toilettes… Hum. Même en imaginant que vous perdiez ainsi 2 heures par jour (grosse feignasse !), et en espérant diviser ce temps par trois − ce qui constitue déjà un bonne optimisation − vous ne gagnerez que 40 minutes par jour. On est loin de la productivité décuplée !

Donc oubliez les solutions miracles. Faites votre boulot posément et dans le bon ordre. Identifiez les urgences. Déléguez.

Simple GTD

Je vous ai déjà fait une introduction à la méthode GTD (Getting Things Done) de David Allen. C’est une méthode d’organisation personnelle très efficace, mais qui réclame une discipline et une rigueur constantes, qui peuvent être usantes à la longue.

Je suis tombé il y a quelques temps sur un article très intéressant du site WebWorkerDaily, qui présente une alternative simplifiée. Cette alternative ne concerne que la partie de « tri » des tâches. Il semblerait qu’elle soit extraite du livre Les 7 habitudes de ceux qui réalisent tout ce qu’ils entreprennent de Stephen R. Covey.

Le tri de tâches GTD

Souvenez-vous, voici les étapes imposées par le GTD, pour trier les informations entrantes (et j’ai déjà pas mal simplifié les choses) : Getting Things Done - déroulement

Le tri de tâches simplifié

Maintenant, l’alternative évoquée sur WebWorkerDaily propose de trier les tâches suivant 4 possibilités simples :

  • UI : Urgent – Important
  • NUI : Non Urgent – Important
  • UNI : Urgent – Non Important
  • NUNI : Non Urgent – Non Important

Continuer la lecture de « Simple GTD »

Scrum : introduction

Scrum est une méthode de gestion de projet très intéressante. Pour mon premier article à son propos, je vais vous la présenter rapidement, et vous parler de l’un de ses concepts-clés : les sprints.

Scrum est une méthode agile qui ne se focalise pas spécialement sur les techniques de développement, mais plutôt sur l’organisation de projet et la gestion d’équipe. C’est une méthode moderne qui a fait ses preuves dans de nombreuses circonstances.

Présentation des rôles

L’image suivante présente d’une manière assez synthétique les différents rôles qui interviennent dans une équipe Scrum :

Scrum

(image © Avangel, Wikipedia)

  • Le directeur de produit : (aussi appelé Product Owner) Je préfère utiliser le terme de chef de projet fonctionnel. Son rôle est de présenter à l’équipe les fonctionnalités qu’elle devra développer, et de transmettre l’ordre de priorités. Il opère un suivi régulier avec l’équipe de développement, et remonte régulièrement les informations d’avancement au client.
  • Le Scrum Master : C’est un personnage très spécial qui prend en charge tous les aspects non techniques pour « protéger » l’équipe, particulièrement pendant les périodes de sprint (voir plus bas). Toutes les requêtes doivent passer par lui, pour s’assurer du respect de la méthode. C’est un rôle qu’on pourrait approcher de celui que je tiens – en tant que directeur technique – vis-à-vis de mes développeurs (hormis que je gère en plus des aspects techniques comme la validation des spécifications techniques).
  • L’équipe de développement : La théorie voudrait que l’équipe soit auto-gérée, et que ses membres prennent eux-mêmes leurs décisions de manière collégiale. D’expérience, j’ai rarement vu une équipe fonctionner correctement quand on la laisse faire ce qu’elle veut. Pour que ça fonctionne, il faut avoir des développeurs très compétents, avec de l’expérience, et surtout qui apprécie les contacts humains. Et malheureusement, toutes les équipes ont leurs stagiaires, leurs pas-très-bons-techniquement ou leurs autistes…

Les sprints

Au coeur de Scrum, il y a la notion de sprint. Le principe est de définir un lot de fonctionnalités à développer, puis de partir dans une phase de développement de durée « raisonnable » (2 à 4 semaines). Évidemment, l’ensemble des fonctionnalités doit avoir été prévu pour pouvoir être développé dans ce laps de temps.

L’important dans cet exercice, c’est de bien comprendre – et surtout faire comprendre aux autres acteurs – qu’une fois qu’on a défini la liste des fonctionnalités et qu’on a écrit les spécifications fonctionnelles, on entre dans une phase de quelques semaines pendant laquelle il est absolument interdit de changer les objectifs de développement. Cela a pour effet de pousser les clients à bien spécifier leurs besoins, car une fois que le sprint est lancé, il n’est pas possible d’ajouter de nouvelles fonctionnalités ni de changer l’ordre de priorité.

Continuer la lecture de « Scrum : introduction »

Loïc’s golden rule of management

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 message central. Pour le mien, c’est sûrement problèmes similaires, échelle différente. Pour Loïc, la règle d’or du management est la suivante :

Quand l’équipe réussi, c’est le succès de l’équipe ;
quand l’équipe échoue, c’est l’échec du manager.

De nombreuses personnes devraient s’inspirer de cette devise. Eh oui, quand vous gérez une équipe (même si elle n’est constituée que d’une seule personne !), vous devez prendre sur vous tous les échecs. C’est à ce prix que vous serez légitime en tant que manager. C’est ainsi que vous montrerez à vos gars (et filles) que vous êtes avec eux. Vous leur donnerez envie de se dépasser, car ils auront le sentiment d’appartenir à une vraie équipe.

Si vous devez faire face à un échec, commencez par vous demander si vous avez formé convenablement les membres de votre équipe. Avez-vous suivi leurs plannings correctement, avec toute l’attention que cela nécessitait ? Avez-vous toujours été disponible pour leur fournir l’aide dont ils avaient besoin ?

C’est l’inverse pour les succès. Ce sont les individus qui ont travaillé sous votre contrôle qui doivent être félicités. Ils se sentiront privilégiés et reconnus, et auront à coeur de s’investir davantage.

L’estimation du travail

Quand on veut planifier son travail ou celui de son équipe, il faut obligatoirement commencer par faire une estimation du temps nécessaire pour réaliser chacune des tâches qui sont listées. Et c’est souvent un casse-tête, car on ne sait jamais par quel bout s’y prendre.

Nous allons voir les raisons qui doivent vous pousser à réaliser des estimations, les réactions les plus récurrentes, et les pistes à suivre pour y arriver.

À noter : J’avais commencé à écrire ce texte au sein d’un article consacré à la planification et aux approches top-down et bottom-up. Mais un article présent dans le dernier numéro du magazine PHP Architect (très bon magazine canadien, en anglais) m’a convaincu d’y consacrer un billet à part entière. Le sujet est intéressant.

Les motivations

On peut voir plusieurs aspects qui conduisent à la nécessité d’estimer préalablement la durée d’une tâche ou d’un projet :

Continuer la lecture de « L’estimation du travail »

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 ! » :

Continuer la lecture de « Il y a une limite à ce qu’on peut imposer »

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.

Continuer la lecture de « Sus aux emails »