Hypothesis driven analysis

Souvent, dans des situations très différentes, on se retrouve à devoir mener des analyses. Qu’il s’agisse d’analyse technique sur le choix d’un algorithme, d’une analyse ergonomique concernant un webdesign, ou d’autre chose, il y a deux grandes façons de mener ces études.

L’approche brutale

C’est la démarche la plus courante. Elle consiste à récolter des données brutes sur la chose à analyser, puis d’utiliser ces données pour dégager des tendances, et tenter d’aboutir à une conclusion. À partir de là, il est possible d’envisager une ou plusieurs solutions au problème.

Cela peut être très efficace. Google est notamment connue pour monitorer tout ce qui est possible et imaginable. Quand vous avez de grandes quantités de données brutes, vous pouvez par exemple les faire passer dans une machine à vecteurs de support pour générer un modèle, puis faire des prédictions grâce à ce modèle.
Vous pouvez ainsi apprendre des choses que vous ne soupçonniez même pas. Ce n’est pas de la science-fiction, PHP supporte la libsvm, c’est assez amusant.

Néanmoins, il s’agit là d’une approche « de riche ». Car il faut partir du principe que toutes les données sont utiles ; donc il faut tout monitorer. Et il faut prendre le temps de générer des modèles et de les analyser finement. Tout ça est très chronophage. Continuer la lecture de « Hypothesis driven analysis »

Présenter ses arguments : la méthode APB

Dans le cadre de mon MBA, nous avons un module de commerce et négoce. En bon informaticien, j’avais quelques doutes sur le fait que cela puisse me passionner un tant soit peu, mais j’ai été agréablement surpris. Au-delà du fait de mieux comprendre la structuration d’une équipe commerciale, l’étude des différentes phases d’une vente est au final quelque chose de très intéressant.

Ce dont je veux vous parler, c’est d’une technique de vente qui peut être utilisée au quotidien pour présenter n’importe quelle argumentation. Même lors d’une réunion banale, au cours de laquelle il faut présenter une opinion personnelle, il est toujours plus efficace de structurer son discours plutôt que de jeter ses arguments en vrac ; si vous espérez que vos interlocuteurs feront le tri dans vos propos, vous vous mettez le doigt dans l’œil.

La méthode que j’ai découverte se nomme A.P.B., pour « Avantage, Preuve, Bénéfice ». Elle propose d’organiser son exposé en suivant ces trois étapes.

Avantage

On commence par présenter l’avantage réel de notre solution, produit, service ou idée. Un avantage, un vrai. Quelque chose qui marque les esprits.

  • « Mon projet va faire économiser 1 million d’euros par an à l’entreprise. »
  • « Notre SUV est le plus rapide du marché. »
  • « Notre souris est la plus précise au monde. »

Il faut capter l’attention, tout en générant une attente. Normalement, avec cet avantage vous obtenez d’un coup l’écoute attentive de votre interlocuteur, même s’il est un peu incrédule.

Preuve

Il faut maintenant montrer que vous étayez votre propos sur des bases réelles et solides. Prouver que vous n’êtes pas un pipauteur. Vous pouvez faire référence à des études, donner des chiffres fiables, montrer des exemples d’antériorité.

  • « La même méthode a fait économiser 10% du chiffre d’affaire des entreprises X, Y et Z sur les 5 dernières années. »
  • « Avec son moteur de 500 chevaux, notre SUV a 180 unités de plus que son plus proche concurrent. Ses valeurs d’accélération et de vitesse maxi ont été contrôlées comme les meilleures du segment. »
  • « Avec sa résolution de 5000 points par pouce, le capteur laser de notre souris est deux fois plus fin que la génération précédente. En appuyant sur le bouton spécifique, la résolution passe même à 50 000 points par pouce grâce à une interpolation logicielle. »

C’est le moment d’être factuel. Une preuve ne doit pas être sujette à interprétation, ni prêter le flanc à un questionnement.

Bénéfice

Pour terminer, il faut démontrer que cet avantage − bien réel car étayé par des preuves − peut apporter un bénéfice direct à la personne avec qui on discute.

  • « Nous pourrons ainsi trouver le financement nécessaire pour aller à l’international, sans nécessiter de nouvelle levée de fond. »
  • « Vous serez le roi des kékés quand vous irez au casino de Bidule-les-bains. »
  • « Votre travail de graphiste sera facilité, votre productivité sera boostée instantanément. »

Si vous faites bien les choses, les gens seront pendus à vos lèvres. L’avantage paraît trop gros, mais on est intrigué. La preuve impressionne car elle valide l’avantage, et en même temps on se dit « ah oui, il a raison ». Enfin, le bénéfice enfonce le clou et fait que les gens se projettent en imaginant tout ce qu’ils pourront en retirer.

Chaque étape doit être rapide. Non seulement cela permet d’ancrer les idées dans les cerveaux, mais cela diminue aussi les risques d’opposition “par principe”.

Quand c’est bien fait, c’est imparable.
Et encore une fois, ce n’est pas simplement une manière de construire un discours commercial. N’importe quelle discussion pourra être structurée de cette manière. Pensez-y !

Professionnalisme : Le (mauvais) exemple de Fetchnotes

Cette nuit, le site Fetchnotes a procédé à des tests durant lesquels toutes les personnes inscrites à leur beta ont reçu l’email suivant, intitulé « Test » :

This is my

test

bitches

Évidemment, 45 minutes plus tard, ils envoyaient un message d’excuse, intitulé « We Really Screwed Up » :

Hi,

From all of us on the Fetchnotes team, we sincerely apologize for
the email you received earlier. We were working on a new email
system and unfortunately one of our test emails, with some
questionable language, slipped through. We are deeply sorry for
what happened and hope that we can continue striving to deliver an
excellent experience. This was just not one of those experiences
unfortunately.

Thank you,

The Fetchnotes Team

Ouaip, ils se sont vautrés comme des merdes. Non seulement ils ont envoyé un email de test à tous leurs abonnés, mais le message en question peut être très mal perçu (ce sont leurs abonnés, qu’ils traitent de salopes ?).

C’est le genre de grosses connerie qu’on redoute tous de laisser s’échapper un jour. En tant qu’informaticien, je comprends comment ce genre de chose peut arriver. Mais ça ne donne vraiment pas une bonne image de professionnalisme.

J’ai appris « à la dure » que le professionnalisme est une attitude à laquelle il faut prêter attention en toute circonstance. Lors de mon tout premier stage en entreprise, quand j’étais jeune et bête, je me suis retrouvé à devoir faire une maquette de page web, pour en faire ensuite l’intégration. Je ne suis pas graphiste, je ne connaissais pas encore les générateurs de Lorem Ipsum ; il a donc fallu que je remplisse la maquette avec des textes à la con. Et j’ai vraiment écrit des trucs à la con ; notamment que le patron de l’entreprise était poursuivi pour malversations financières…

Cette maquette, qui ne devait être utilisée que par un autre développeur et moi, a été utilisée par le chef de projet. Sans m’en informer (pourquoi aurait-il dû ?), il l’a placée dans un document de présentation qu’il a envoyé au client.
Quand je me suis rendu compte de ça, je me suis senti tout pâle. J’ai couru voir mon chef de projet, et on s’est heureusement rendu compte qu’il avait réduit l’image au point que le texte était illisible.

Que ce serait-il passé si le client avait lu mes textes débiles ? J’aurais pu me faire virer de mon stage. Au minimum.

Cela m’a servi de leçon. Désormais, je fais toujours attention à ce que j’écris. Quelle que soit la situation, je me dis que ce que je produis pourrait un jour être propagé en dehors du périmètre dans lequel je le crois confiné.

Vous ne savez pas le nombre de fois où j’ai vu des échanges internes, à propos d’un projet par exemple, être transférés à un client ou un partenaire. Simplement parce qu’au milieu des échanges s’est retrouvée une information qui pouvait intéresser le client, quelqu’un lui envoie. Sans se rendre compte que c’est l’ensemble de la discussion qui a été transférée, y compris certains messages très peu professionnels voire même certaines remarques diplomatiquement difficiles à justifier vis-à-vis du client.

Un simple “Projet de merde !”, lâché par un développeur un jour de stress, risque de se retrouvé glissé dans une discussion ; à force de « reply-to », le texte est copié mais on n’y prend pas garde, jusqu’à ce que le client exprime son mécontentement et réclame une explication.

Si vous ne voulez pas vous retrouver dans ce genre de situation, dites-vous que vos échanges d’emails professionnels doivent toujours refléter votre professionnalisme.

Pour en revenir à Fetchnotes, ils ont cumulé les bévues. Envoyer un email de test à toute leur base de données, c’est con. Envoyer un email débile et limite insultant, c’est très con. J’espère pour eux que cela ne les empêchera pas de mener leur service avec succès ; et j’espère que le jeune développeur qui fait ses tests en écrivant des bêtises a été vacciné à vie contre ce genre de choses − comme je l’ai moi-même été, avec moins de conséquence.

Juste pour terminer sur le sujet : Quand on fait une connerie, il faut l’assumer. Fetchnotes l’a bien compris, menant une communication rapide et efficace, par email et sur Twitter. Ils s’excusent, reconnaissent leur erreur (faite par leur cofondateur), répondent individuellement à tous les messages sur le sujet. Bien joué.

Les erreurs de débutant

Il y a plusieurs erreurs typiques faites par tous les informaticiens débutants. Jusque là, pas de soucis ; on fait tous des erreurs, c’est normal, ça fait partie du processus d’apprentissage.

Ce qui m’énerve, c’est que je vois de temps en temps des informaticiens expérimentés (5 ans d’expérience au moins) continuer à faire le même genre d’erreurs. C’est crispant, parce que ça démontre que la personne n’a pas cherché à s’améliorer professionnellement.

Parmi toutes ces erreurs, j’en ai listé quatre principales (plus une cinquième pour le plaisir).

1. Rock’n roll, baby

Beaucoup de jeunes développeurs ne prennent pas le temps de réfléchir un minimum à ce qu’il vont coder. Ils se jettent directement dans le code, écrivent ce qui leur passe par la tête, le modifie, font des ajouts, re-modifient, complètent, renomment, re-re-modifient, et ainsi de suite.

À l’école, quelque soit la formation, il est demandé de réussir les projets. La manière d’y arriver n’est pas vraiment enseignée. La plupart du temps, on commence par écrire les choses comme elles viennent. Et au fur et à mesure qu’on emmagasine de l’expérience, on comprend qu’il vaut mieux se poser d’abord quelques questions. Si on a la tête bien faite, on finit par réfléchir à nos développements en terme d’architecture logicielle, et non plus seulement en terme de «bouts de codes qui fonctionnent».

Concrètement, dans mon entreprise, je ne demande pas à mes développeurs d’écrire des spécifications techniques de 300 pages avant chaque développement. Je ne leur impose pas de me faire des diagramme UML pour représenter les objets et leurs interactions.
Pourquoi ? Simplement parce que, dans une démarche agile, je sais que les développeurs vont gagner en compétence et en expérience pendant leur développement. Il ne sert à rien de vouloir graver dans le marbre l’ensemble des spécifications, car on risque de “sortir des clous” dès la première méthode du premier objet.

Par contre, il me semble absolument nécessaire d’avoir une certaine idée de «là où on va». On va sûrement changer de direction en cours de développement. Mais si on se lance bille en tête sans avoir la moindre vision directrice, on risque de tourner en rond. Le code va ressembler à un immonde plat de spaghetti, inefficace et impossible à maintenir.

2. Documentation

Ce point est un peu lié au précédent. Souvent, les jeunes développeurs ont tendance à ne jamais documenter leur code. Cela provient de plusieurs choses :

  • Ils pensent pouvoir garder éternellement en tête l’ensemble des informations relatives au code qu’ils écrivent. Bien souvent, ils n’ont eu à opérer que sur du code dont la durée de vie allait de quelques jours à quelques mois. Mais le jour où ils se retrouvent à maintenir du code écrit 1 an et demi auparavant, ça leur fait tout bizarre.
  • Ils considèrent − à juste titre − qu’un développeur doit pouvoir lire du code source de manière fluide, comme un texte écrit dans une langue étrangère. Ainsi, il suffit de relire le code pour comprendre ce qu’il fait. Sauf que l’effort intellectuel est quand même bien plus important si on n’a pas un minimum d’informations sur le contexte dans lequel opère le code en question. C’est une perte de temps.
  • Ceux qui sont le plus de mauvaise foi se justifient en disant que les noms de leurs objets, de leurs méthodes et de leurs variables sont suffisamment parlants pour ne pas avoir besoin de donner d’explications supplémentaires. Il est évident que les noms doivent être significatifs. Mais ils ne peuvent pas, à eux seuls, expliquer réellement à quoi sert le code, quels sont ses cas d’erreur et comment ils sont gérés, dans quels cas certains paramètres sont optionnels.

Continuer la lecture de « Les erreurs de débutant »

Kit de survie en entreprise

Contrairement à ce que le titre de cet article pourrait le laisser penser, je ne vais vous parler des situations conflictuelles que l’on peut rencontrer en entreprise. Je vais plutôt vous parler de quelques trucs qui sont facilement applicables, et qui peuvent faciliter les choses dans certaines situations. Ça vaut ce que ça vaut, mais ça peut vous sauver la vie (enfin, presque).

Diviser par deux

C’est une situation que nous avons tous connus : On discute avec une ou plusieurs personnes, chacun argumente dans le sens qui l’intéresse, et au moment où on veut exprimer nos propres idées, elles arrivent toutes en même temps. Au lieu de lister les points importants de manière intelligible, on délivre un amas de non-sens sans queue ni tête. Plus on s’en rend compte, plus on s’embrouille. Au final, quelqu’un d’autre captera la discussion pendant que l’on reprend notre souffle entre deux phrases, et tout le monde oubliera notre pathétique contribution.

Comment faire pour éviter ça ? La technique la plus simple est de systématiquement chercher à diviser nos idées en deux.
Si vous avez une idée en tête, mais que vous ne savez pas par quel bout l’aborder, essayer d’en distinguer deux facettes. Forcez-vous à y trouver deux aspects différents. Cela peut être les avantages et les inconvénients. Ou quelques enseignements liés à votre expérience sur le sujet, comme un “contre-exemple” qui apporterait un éclairage particulier. Prenez le temps de préparer mentalement votre «thèse / antithèse». Le but de la réunion sera de faire la «synthèse» à plusieurs.

Cela paraît débile, mais c’est une vraie méthode d’organisation de la pensée. Je connais une personne qui commence la moitié de ses phrases par « En fait, il y a deux choses dans ce que tu dis » ; c’est crispant à la longue, mais ça a le mérite d’éclaircir les idées de tout le monde quant au propos échangé.

Reconnaître les hypocrites

Tout le monde le sait : en entreprise, il y a des gens sympas et il y a des cons. On est prévenu et préparé à cela. Le problème, c’est quand on a affaire à des cons qui sont assez fourbes pour paraître sympas. Il y a plusieurs profils de ce genre :

Continuer la lecture de « Kit de survie en entreprise »

Livre : De la simplicité

J’ai lu récemment le livre De la simplicité, écrit par John Maeda.

De la simplicité

Ce livre n’est pas seulement une ôde à la simplicité, mais il décortique consciencieusement les principes qui conduisent aux choses simples, et comment ils procurent un avantage. D’amblée, l’auteur applique à ce livre les préceptes qu’il met en avant. Ainsi, c’est un livre relativement court (185 pages), découpé en chapitres d’une dizaine ou une quinzaine de pages, particulièrement facile à lire car illustré − au propre ou au figuré − d’exemples bien trouvés.

L’auteur n’est pas un inconnu. Professeur au MIT et web-designer de renom, il a une approche des choses très intéressante, qui combine l’esthétique, la technique et l’ergonomie.

Les principes de la simplicité

John Maeda décrit la simplicité suivant 10 lois et 3 clés.

Les lois sont (telles que listés dans le livre) :

  1. Réduction. Pour atteindre la simplicité, le mieux est la réduction méthodique.
  2. Organisation. Avec de l’organisation, un ensemble composé de nombreux éléments semble plus réduit.
  3. Temps. En économisant son temps, on a le sentiment que tout est plus simple.
  4. Apprentissage. La connaissance simplifie tout.
  5. Différences. La simplicité et la complexité ont besoin l’une de l’autre.
  6. Contexte. Ce qui se trouve à la périphérie de la simplicité n’est absolument pas périphérique.
  7. Émotion. Mieux vaut plus d’émotions que moins.
  8. Confiance. Dans la simplicité nous avons confiance.
  9. Échec. Certaines choses ne peuvent jamais être simplifiées.
  10. Loi cardinale. La simplicité consiste à soustraire ce qui est évident et à ajouter ce qui du sens.

Les clés :

  1. Au loin. Plus semble moins si l’on s’en tient éloigné, très éloigné.
  2. Ouverture. L’ouverture simplifie la complexité.
  3. Puissance. Se servir de moins, en tirer plus.

Au milieu de tout cela, il utilise une méthode qu’il nomme AMI, pour «Atténuer, Masquer, Insuffler». L’idée est qu’il est souvent possible de réduire la complexité perçue de quelque chose en diminuant son impact psychologique. Cela peut être atteint en réduisant sa taille ou la “surface” (au sens métaphorique du terme) de son interface avec nous ; ou encore cachant les éléments ou les fonctionnalités les plus complexes afin de mettre en avant un sous-ensemble plus simple à appréhender avant d’avoir besoin de plus ; enfin en transmettant à l’objet en question des qualités qui dépassent sa définition au sens littéral − si la qualité réelle et la qualité perçue se rejoignent, on simplifie et justifie les complexités sous-jacentes.

Utilité et application

Chaque loi est détaillée dans un chapitre qui lui est dédié. Je ne vais pas vous en faire une explication de texte détaillée, les descriptions de l’auteur, que j’ai repris ci-dessus sont suffisantes pour comprendre leur teneur (et devraient titiller votre intellect).

Le plus intéressant, c’est que ce livre reste général sans pour autant se perdre en généralités. Les principes élémentaires qu’il exprime peuvent être appliqués à des cas aussi différents que l’ergonomie d’un appareil électronique, le design d’un site web, la définition d’un business, la mise en place d’une méthode d’organisation personnelle, le déploiement d’une procédure professionnelle, ou l’amélioration d’une formation supérieure.

Même quand le propos de l’auteur semble partir dans des directions incongrues, il retombe sur ses pieds et délivre un message qui nous apporte quelque chose.

Le livre se termine par une bibliographie qui vous permettra d’approfondir certains aspects si vous le souhaitez.

Mon avis

À mon sens, ce livre devrait faire partie des ouvrages de référence que tout le monde devrait connaître. Que vous soyez informaticien ou non, que vous ayez à réfléchir à de nouveaux produits, que vous développiez un logiciel ou une entreprise, ou simplement si vous souhaitez réfléchir aux moyens de progresser personnellement, il vous apportera des réponses et vous fera méditer certaines choses dont vous n’aviez pas forcément conscience auparavant.

Même si vous n’en étiez pas convaincu avant de le lire, vous saurez après pourquoi il faut aller vers la recherche de la simplicité, et comment ce but peut être atteint.

Sachez enfin que John Maeda a créé un site pour accompagner le livre, du nom de LawsOfSimplicity.com. Si vous lisez l’anglais, allez y faire un tour. Même si aucune mise-à-jour n’y a été faite depuis un an et demi, il reste très enrichissant.



Livre : Public Speaking in an instant

Comme vous le savez, j’ai présenté plusieurs conférences ces derniers mois. Cela m’a amené à m’intéresser aux livres traitant de la prise de parole en public. Comme pour n’importe quel autre sujet, il y a toujours quelque chose à apprendre ; même ceux qui se sentent naturellement à l’aise devant un auditoire peuvent bénéficier du retour d’expérience de ceux qui font ça fréquemment.

Parmi les différents livres auxquels je me suis intéressé, il y en a un que je veux vous conseiller : Public Speaking in an instant, 60 ways to stand up and be heard

Public speaking in an instant

Les qualités principales de ce livre :

  • Il est court, à peine 150 pages. Pas de bla-bla inutile, le style est simple et direct. On sent bien que les auteurs ont l’habitude de faire des présentations.
  • Il est pratique et utile. Ce n’est pas une énième ode au charisme de Steve Jobs ou un traité d’art graphique. Chacun des 60 mini-chapitres donne des explications, des astuces, des idées qui aident et inspirent quand on doit parler en public.

Le bouquin commence par expliquer comment aborder une audience. Puis explique comment construire son discours, comment préparer son introduction, capter l’attention dès le début d’une présentation, pimenter son propos, conduire une séance de questions-réponse, … Il donne tout un tas de trucs et astuces : utiliser des jeux de rôles, faire participer l’audience, ajuster le ton et le volume de sa voix, amuser et motiver l’audience, et ainsi de suite.

Surtout, tout au long de ces chapitres, ce petit livre vous apprend à raconter une histoire qui captera l’attention de vos auditeurs. Bizarrement je n’avais rien trouvé de tel dans les autres livres que j’avais lu jusqu’ici.

Chose intéressante, certains chapitres sont consacrés à des aspects moins «glamours» (et donc souvent éludés) : Comment faire un toast lors d’un banquet, comment se comporter à la télévision ou à la radio, quelles sont les spécificités d’une vidéoconférence à distance, comment gérer les problèmes techniques, etc. C’est aussi ce qui en fait un traité presque universel sur le sujet. Et même si ces perspectives de vous concernent pas, cela reste des conseils judicieux à connaître et à adapter.

Si vous devez parler en public, ne serait-ce qu’une seule fois dans votre vie, et que vous voulez vous préparer un minimum, ne vous jetez pas sur tous les énormes livres qui existent sur le sujet. Commencez par celui-ci. Il est petit, rapide à lire, pas cher. On peut le garder dans le sac, pour y jeter un coup d’œil au dernier moment «au cas où».

Et si vous voulez appronfondir par la suite, il sera toujours temps de consulter d’autres ouvrages. Mais passer à côté de celui-ci serait une énorme erreur.



Découper les tâches comme un gnome

Peut-être connaissez-vous l’auteur anglais Terry Pratchett, connu ses romans de science-fiction et de fantasy à succès.

J’aime beaucoup son ouvrage Le grand livre des gnomes. Et entre autre, il contient une phrase toute simple, pensée par le héros principal :

“ Pour accomplir une tâche impossible, on la débite en petits bouts de tâches simplement très difficiles, qu’on divise ensuite en tâches horriblement pénibles, qu’on segmente à leur tour en travaux délicats et ainsi de suite… ”

Pour le coup, Masklinn (c’est le nom du gnome) se fait cette réflexion en réfléchissant à la manière de découper et ramener à sa tanière un rat qu’il vient de tuer… Mais c’est en appliquant la même méthode qu’il finit par sauver son peuple en l’emmenant dans l’espace.

Je répète sans cesse que les listes sont à la base de toute organisation personnelle. Mais avant même de pouvoir placer des tâches sur une liste, il faut déjà définir le niveau de granularité nécessaire.

Pourquoi découper

Trop souvent, j’ai vu des gens qui se satisfaisaient d’une todo-list contenant des tâches dont les intitulés résumaient à eux seuls un projet entier. C’est complètement insensé !
Ce type de comportement a plusieurs effets pervers :

  • On a une mauvaise vision de l’ensemble des actions nécessaires pour la réalisation du projet. Cela laisse la porte ouverte à de mauvaises interprétations. Arrivé aux trois-quart de la réalisation de la tâche, on peut découvrir qu’elle nécessite un développement imprévu, qui va durer à lui seul 3 fois plus longtemps que la tache initiale. Si on l’avait anticipé, cette tâche aurait peut-être été planifiée différemment, voire même abandonnée.
  • Cela participe à l’effet tunnel : Comme on ne sait pas précisément ce qu’il va falloir faire, il est impossible d’évaluer la charge de travail correctement. Ça va peut-être prendre 3 jours, peut-être 3 semaines…
  • Et quand on ne voit pas le bout d’un projet, on se démotive rapidement.

Comment découper

Si tout le monde s’accorde habituellement sur la nécessité de découper ses tâches, on ne sait pas toujours comment s’y prendre. Ce n’est pourtant que du bon sens :

Continuer la lecture de « Découper les tâches comme un gnome »

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.

Ne pas faire confiance à sa mémoire

Je vais le marteler une nouvelle fois : les listes sont la base de toute organisation, qu’elle soit personnelle ou d’équipe.

L’une des erreurs qu’on voit le plus souvent, que ce soit que les juniors que chez les gens désorganisés, est de faire confiance à sa mémoire.

Par exemple, un jeune développeur qui ne prend pas de notes. On lui donne 3 choses à faire pour la journée, et il revient le soir tout fier de lui. Malheureusement, il en a oublié une en cours de route.
Ou encore, un graphiste qui doit corriger une création, sans utiliser une buglist. Évidemment, il faut alors plusieurs itérations pour lui rappeler les petits détails qui lui ont déjà été remontés.
J’ai même vu une DRH qui n’avait établi aucune procédure, pensant avoir tout bien en tête. Régulièrement, il fallait lui rappeler qu’on était en attente d’un justificatif qu’elle n’avait pas préparé.

Le fondement de cette erreur, c’est qu’au moment où on reçoit une information, notre attention se focalise dessus. Elle remplit toutes nos « cases mémoire ». On a naturellement l’impression qu’à tout moment cette donnée sera disponible dans un coin de notre tête.
Malheureusement, il faut composer avec 2 choses :

  • Chaque nouvelle information pousse les précédentes vers la sortie.
  • Les informations se périment en mémoire avec le temps, et toujours plus vite qu’on ne le croit.

La conjonction de ces deux facteurs fait qu’il est difficile de se souvenir de plusieurs choses bénignes (qui ne sont pas d’une importance marquante) plus de quelques heures d’affilée.

Dans certaines disciplines, comme en ergonomie ou en présentation, on considère habituellement qu’il ne faut pas présenter plus de 7 éléments à la fois. C’est la limite au-delà de laquelle le cerveau humain ne peut pas tout retenir instantanément. Une liste comportant plus de 7 choix demandera plusieurs lectures successives avant qu’une personne puisse s’en faire une représentation mentale.
Sachant cela, combien de ces 7 éléments vont s’envoler de votre mémoire avant la fin de la journée ?

La solution pour remédier à ce problème, c’est de noter toutes les informations qu’on ne peut pas traiter dans la seconde, et qui nécessitent une action. Ce ne sont pas les moyens qui manquent : dans un cahier, un outil de gestion de projet, une buglist, une feuille de papier volante, un wiki, etc.
C’est simple, c’est facile. Pas d’excuse.