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…

Lire la suite

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

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.

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

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 :

(image © Avangel, Wikipedia)

  • Le directeur de produit : 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 temps 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é.

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 :

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

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.