Des outil de travail rustiques

Cet article est dans la droite ligne du précédent, dans lequel je vous parlais du concept de rusticité au sens large. Là, je voudrais vous donner un exemple concernant certains outils de travail que j’utilise au quotidien − personnellement ou avec mon équipe.

J’ai mis en place plusieurs outils numérique qui servent au travail collaboratif : email, wiki, partage de fichiers, todo-list, buglist, calendrier partagé, … Tout cela est très utile, et ces outils sont devenus essentiels à notre organisation. J’ai déjà parlé de tous ces outils par le passé, et je reviendrai certainement dessus.

Mais d’un point de vu très concret, on a tous besoin d’outils pour :

  • prendre des notes à la sauvette
  • établir des todo-lists éphémères
  • faire des dessins comme support à une réflexion
  • faire des croquis pour échanger des idées en équipe

Je ne sais pas pour vous, mais pour moi c’est vital. Je n’arrête pas de noter des choses, qui ont une durée de vie de quelques secondes à quelques jours. Souvent pour mon propre usage, pour ne pas oublier quelque chose ou pour m’aider à mettre mes idées en ordre quand je réfléchis à un modèle ou une spécification technique. Mais aussi lorsque je travaille avec mon équipe, pour synthétiser graphiquement les idées de chacun.

Pour tout ça, l’outil high-tech qui fait fantasmer tous les geeks, c’est définitivement l’iPad d’Apple. Allié à une application comme Draft, on pourrait y voir le meilleur moyen de faire des croquis rapides et les échanger.

Ah, c’est vrai que ce genre de gadget fait envie. Mais est-ce vraiment nécessaire ?

Pour ma part, j’ai trouvé les deux outils qu’il me fallait : des “post-it” et une ardoise “Velléda”.

Des post-it

Tout le monde connait les post-it, ces petites feuilles adhésives repositionnables commercialisées par 3M. J’en ai utilisé de toutes les tailles : des minis (très pratiques pour coller des notes tout autour de l’écran), des « normaux » (qui s’adaptent à la plupart des besoins), des géants (vite abandonnés).

Maintenant, j’utilise exclusivement des post-it de taille rectangulaire (76×127 mm pour être exact). C’est comme un post-it normal, sauf qu’il est plus large. Pris verticalement, c’est idéal pour faire des listes : la largeur est convenable, et la hauteur − plus grande que pour un post-it carré − convient parfaitement.

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

Communication et productivité : synonymes ou antonymes ?

Je suis assez étonné et amusé de remarquer qu’il existe des « courants de pensée » assez contradictoires concernant les méthodes à employer pour maximiser sa productivité personnelle. Certaines solutions proposées sont un peu extrêmes dans leur propos et revendiquent leur manque de nuance. Qu’elles soient le résultat d’une démarche personnelle et la dernière méthode à la mode, il semblerait que leur adoption doit être obligatoirement sans demi-mesure…

La sur-communication

Je vais commencer par vous parler de ce qu’on appelle l’«Entreprise 2.0». Derrière ce terme un peu brumeux (et repompé du «Web 2.0») se cache un ensemble de pratiques qui ont pour but d’amener les plate-formes de travail en entreprise vers des pratiques plus participatives, plus “organiques” − quoi que cela veuille dire.

Si on regarde bien, cette démarche a été entamée il y a un bon nombre d’années déjà, lorsque les entreprises ont commencé à migrer leurs gestions documentaires simplistes (partage de documents en réseau) ou difficiles d’accès (GED de premières générations) par des intranets intégrant wikis, blogs et bookmarks partagés. Et il faut bien avouer qu’en procédant ainsi, l’accès à l’information est devenu plus facile et leur mise à jour est plus fréquente.
Rapprocher l’information de ceux qui en ont besoin, tout en leur permettant de la modifier facilement, permet de rendre celle-ci moins « monolithique ».

C’est un bon exemple de cas où ce sont les outils qui ont amené un changement d’utilisation en douceur, ce qui n’aurait pu être fait par un changement d’organisation et de process.

Certains partisans de l’«Entreprise 2.0» veulent pousser ce concept beaucoup plus loin. Pour faire simple, Facebook et Twitter sont des outils super géniaux (et surtout particulièrement à la mode en ce moment), il faut à tout prix généraliser et codifier leur utilisation. Ils théorisent donc sur le fait que la prochaine étape est d’avoir des collaborateurs qui communiquent de manière proactive, informent leurs collègues de ce qu’ils font et à quoi ils réfléchissent, en utilisant des canaux de micro-information propres à l’entreprise.

La sous-communication

A contrario, un bon nombre de méthodes d’organisation personnelle obligent à fermer les vannes de l’information entrantes. Qu’il s’agisse du téléphone (toujours laisser le répondeur gérer les appels), des emails (à ne lire qu’une à deux fois par jour) ou des réunions (à éviter comme la peste), l’idée est la même : Ce sont des sources de distraction qui empêchent de se concentrer sur les tâches qui réclament notre attention. Éliminer les sources de distraction permet donc, par un effet mécanique, de consacrer plus de temps à faire du travail « utile », et donc de devenir plus productif.

Livre : Getting Real

Je vous ai déjà parlé de la société 37signals, au travers de ses outils Backpack et Basecamp. Je vais maintenant vous parler du livre qu’elle a publié en 2006 et qui contient toutes les règles de création et de gestion de projets web qu’elle applique en interne : Getting Real, The smarter, faster, easier way to build a successful web application.

Ce livre est disponible :

Le titre du livre est sûrement un gentil jeu de mots avec la très connue méthode Getting Things Done. Ce clin d’œil est une manière à peine déguisée de dire qu’il faut oublier toutes les méthodes existantes, faire table rase et suivre leur direction. Le livre décrit leur propre méthode agile, qui est censée s’appliquer à la réalisation d’applications web, mais peut être utilisée – au moins partiellement – pour d’autres types de projets ou d’organisations.

37signals

37signals a été fondée en 1999, exerçant une activité de web agency. Au cours des années, elle s’est fait connaître en publiant tout d’abord Basecamp, l’outil de gestion de projet utilisé en interne, puis le framework Ruby on Rails sur lequel Basecamp est basé. Depuis, 37signals a sorti plusieurs services en ligne, allant de la gestion de données jusqu’à la relation client, en passant par la messagerie de groupe. Leur blog d’entreprise, Signal vs Noise, qui parle aussi bien des outils édités par la société que de design et de développement web, est très connu et visité.

Basecamp

Je vais vous présenter aujourd’hui le logiciel Basecamp, qui est développé par 37Signals. C’est un peu le grand frère de Backpack dont je vous parlais la semaine dernière.

Là où Backpack visait à faciliter le stockage et l’échange d’information autour de projets, Bascamp va plus loin et propose des outils pour gérer plus finement le travail de groupe. On peut distinguer 5 fonctionnalités principales :

  • Les todo-lists.
  • La messagerie partagée.
  • Le partage de fichiers.
  • Les objectifs calendaires.
  • « Reporting » du temps passé sur chaque projet.

Auxquelles s’ajoutent des panneaux de vues globales sur un projet ou sur tous les projets.

Les todo-lists

(image © 37signals.com)

Je vous ai déjà expliqué pourquoi les listes sont à la base de toute organisation. Basecamp permet de créer facilement des listes et de les organiser comme on le souhaite. Très similaires à celles de Backpack, on peut éditer leurs titres en utilisant la syntaxe Textile (syntaxe wiki-like simplifiée), et leur affecter un état fait/à faire simplement en cochant ou décochant une case. Par contre, elles offrent la possibilité d’affecter une tâche à un utilisateur, ce qui était un des manques que je pointais du doigt sur Backpack.

Il est aussi possible de créer des listes privées, qu’on est le seul à pouvoir voir. C’est une bonne idée, qui permet d’avoir au même endroit les todo-lists générales et celles qui nous concernent ; cela évite d’avoir à gérer plusieurs systèmes de listes en parallèle.

La messagerie partagée

(image © 37signals.com)

On a beau classer nos emails dans des dossiers, il est toujours pénible d’y rechercher une information intéressante. On est souvent obligé d’ouvrir une demi-douzaine de messages – de quelques lignes chacun – avant de retrouver ce qu’on veut.

Backpack

Je vais vous parler de Backpack, un outil réalisé par 37Signals, une entreprise dont nous aurons l’occasion de parler de nouveau.

Backpack se définit comme un outil d’organisation et de partage d’information. Voici des images qui vous feront comprendre rapidement de quoi il retourne :

(image © 37signals.com)

(image © 37signals.com)

Fonctionnalités

Ce logiciel est d’une grande simplicité d’utilisation. Sa fonctionnalité principale est la création de « pages ». Une page est, comme le montrent les exemples ci-dessus, la combinaison de plusieurs éléments :

  • Des listes minimales, qui comprennent juste un titre et un état fait/à faire.
  • Des notes, composées d’un titre et d’un texte.
  • Des « writeboards », qu’on peut assimiler à des pages de wiki simplifiées.
  • Des pièces-jointes (uniquement disponibles dans la version payante).