Approche globale ou pas-à-pas

Il y a plusieurs manières de mener une équipe. Je vais m’intéresser ici à la manière dont on communique pour suivre l’avancement des projets. Cette question est assez intéressante et complexe, car elle a des impacts sur la méthode de gestion de projet.

En fait, les gens peuvent être placés dans 2 grandes catégories :

  • Ceux qui veulent voir leurs projets de manière globale.
  • Ceux qui privilégient les petites avancées.

Je ne parle pas de la manière dont on choisit d’aborder les projets, mais plutôt comment on a tendance à réagir naturellement, comment on se sent mieux de travailler. Il y a des avantages et des inconvénients aux deux. Il est bon de savoir dans quelle mouvance on se situe et comment sont nos collègues, pour améliorer le travail d’équipe.

L’approche globale

Certaines personnes éprouvent le besoin vital de comprendre les projets dans leur globalité pour pouvoir travailler dessus. Ils ont souvent une bonne vision de l’ensemble des forces et des faiblesses d’un programme en cours de conception. Pour eux, le seul moyen raisonnable d’exécuter une tâche est de le faire de la bonne façon (ce qui pour eux signifie souvent d’y réfléchir pendant des mois pour être certain de prendre en compte tous les cas imaginables et inimaginables).

Le problème avec ces personnes, c’est qu’elles peuvent tomber dans l’immobilisme. Elles considèrent souvent qu’une réalisation incomplète ou imparfaite est pire que de ne rien faire. Et les tergiversations peuvent durer longtemps avant de définir la manière dont une tâche peut être effectuée suffisamment bien pour les satisfaire.

Le pas-à-pas

D’autres personnes, au contraire, sont capables de démarrer un projet très rapidement et de le faire avancer par évolutions successives. Ils ont une bonne idée du travail qui peut être réalisé en fonction des ressources disponibles à un instant donné, et connaissent souvent tous les petits détails techniques de leurs projets.

Par contre, ces personnes ont besoin d’être encadrées de près, car elles peuvent faire prendre à leurs projets des directions non souhaitables. Le souci, c’est que chaque petite amélioration peut sembler à la fois sensée et peu coûteuse.

Livre : Getting Things Done – Présentation

La méthode Getting Things Done (ou GTD en abrégé) a été inventée par David Allen et publiée en 2001 dans un livre nommé « Getting Things Done – The art of stress-free productivity ». L’ouvrage a été traduit en français sous le nom « S’organiser pour réussir – La méthode GTD ou l’art de l’efficacité sans le stress ».

Getting Things Done - David Allen - couverture

Malgré son nom un peu ronflant (sans parler du « sous-titre » qui est une perle marketing), cette méthode bénéficie d’une très grande notoriété. On ne compte plus le nombre de sites qui y sont consacrés ni le nombre d’outils qui s’adaptent à ses recommandations.

Le principe

La première chose à savoir est que GTD est une méthode d’organisation personnelle. Vous pouvez l’utiliser pour être plus efficace dans votre travail et dans vos occupations personnelles, mais vous ne pourrez pas vous baser dessus pour définir l’organisation de votre équipe ou de votre entreprise.

Contrairement à la plupart des méthodes qui tentaient d’organiser la gestion du temps, la méthode GTD se concentre sur la réalisation des tâches qui nous incombent. Pour cela, il faut se reposer sur un système unique pour recenser l’ensemble des tâches, identifier leur ordre de priorité, et passer en revue cette liste très fréquemment pour en cataloguer les éléments.

Je vais vous donner les grandes lignes de ce qui fait la force de cette méthode d’organisation. Je reviendrai sûrement sur le sujet dans le futur, tant il est vaste. Mais nul besoin de lire les 287 pages du livre pour en comprendre les concepts les plus importants.
Un schéma récapitule l’ensemble du processus (il est d’ailleurs répété 4 fois dans le livre !).

Getting Things Done - déroulement

Action Method

Je vais vous parler aujourd’hui d’Action Method, qui est le nom d’un web-logiciel d’organisation et de gestion de projets, mais aussi celui de la méthode d’organisation qui y est préconisée et que le logiciel permet de suivre et appliquer.
Cet un bon exemple de la mouvance des nouveaux outils de gestion de projet, qui privilégient la communication et résolution de tâches plutôt que la gestion du temps et le flicage des gens.

Pour la petite histoire, l’entreprise qui est à l’origine de ce logiciel (Behance) a commencé par faire connaître la méthodologie Action Method en vendant des organiseurs papier. Jetez-y un oeil, certains produits pourraient vous intéresser si vous gérez vos projets « à l’ancienne ».

La méthode

Pour bien utiliser ce logiciel, il faut donc comprendre la méthode sous-jacente. Ses idées principales sont :

  • Réduire les échanges de communication (bannir les emails !) au profit de l’action et de la résolution des tâches. Les discussions importantes doivent pouvoir être suivies facilement et non être cachées dans des chaînes d’emails.
  • Partager uniquement les informations qui le nécessitent.
  • Les actions peuvent être déléguées et non assignées ; on ne s’en débarrasse pas.
  • Les fonctionnalités prouvent leur importance par « sélection naturelle ». Voir la notion de harcèlement plus bas.

Cette méthode définit 5 types d’éléments de base :

  • « Action steps » : Actions à réaliser. Devrait toujours commencer par un verbe (« Appeler machin », « Faire ceci », …).
  • Références : Toutes informations (notes, liens, fichiers) liées à un projet qui donne du contexte aux Action Steps.
  • « Backburners » : De simples idées qui ne génèrent pas encore d’action, mais sur lesquelles on veut revenir plus tard.
  • Discussions : Toutes les communications concernant un projet (documents partagés, décisions, solutions aux problèmes, feedbacks, …) sont regroupées au même endroit et sont accessibles aux personnes travaillant sur ce projet.
  • Evénements : Réunions, étapes, occasions particulières, dans le futur du projet. Peuvent servir de deadline aux Action steps.
Le logiciel

La vue globale de chaque projet récapitule tous ces éléments d’une manière assez réussie à mon goût. Les informations sont clairement affichée et facilement accessibles.

Action Method - Page projet (image © actionmethod.com)

Le cycle itératif

Si vous avez lu mon billet sur le Cycle en V, vous savez pourquoi ce type de méthode de travail n’est pas adapté à la plupart des projets informatiques, qui réclament une plus grande souplesse. En l’appliquant de manière rigide, on finit par obtenir des logiciels mal adaptés (fonctionnalités sans priorités), livrés en retard (chaque étape bloque les suivantes) et souvent buggués (la technique se plie au fonctionnel).
C’est ainsi qu’est née la méthode du cycle itératif (ou incrémental), qui tente de formaliser une approche plus pragmatique et maniable.

Cycle itératif

Définition

Cette méthode se décompose en 6 étapes, dont 4 qui en constituent le « coeur » :

  • L’expression de besoin : Le client explique ce qu’il veut obtenir. On peut faire un parallèle avec l’étape de faisabilité du cycle en V, et dans une moindre mesure avec les spécifications fonctionnelles. L’idée reste que les informations en entrée peuvent être modifiées par la suite du processus.
  • Le coeur du processus itératif :
    • Spécification : C’est la traduction en langage technique des besoins fournis en entrée. C’est la réponse aux questions « qu’est-ce qu’on fait ? » et « comment on va le faire ? ».
    • Développement : Il s’agit de la réalisation concrète de ce qui a été défini.
    • Validation : C’est l’ensemble des tests qui permettent de s’assurer que le développement effectué correspond bien à ce qui était attendu.
    • Évaluation : Cette étape sert à effectuer un retour sur les écueils rencontrés et les fonctionnalités abandonnées pendant les 3 étapes précédentes, et l’utiliser comme informations d’entrée pour un nouveau cycle.
  • Déploiement : Les livrables qui ont été validés sont déployés pour que le client y ait accès.

Sous-estime, surestime et implication

J’espère que vous avez lu mon article Échelle différente, problèmes similaires. J’y décris le fait que les obstacles rencontrés sont souvent les mêmes, quel que soit notre place dans notre entreprise, seule l’échelle de valeurs de ces problèmes diffère. C’est une constatation simple, que tout le monde peut faire en observant les personnes qui les entourent.

Mais il existe un corollaire à cela, qui est très intéressant lui aussi, et qui touche au comportement des gens. Quand on arrive dans une nouvelle entreprise ou un nouveau poste, on a tous une tendance naturelle à se sous-estimer et à surestimer nos supérieurs. Si, si. Je vous vois déjà faire la moue en vous disant « Mais non, pas du tout ! ». Mais si vous prenez le temps de regarder les choses en face, vous vous rendrez compte que plus d’une fois vous n’avez pas osez remettre en question une décision d’un supérieur, alors que vous n’auriez eu aucun scrupule si l’idée était venue de quelqu’un de même niveau hiérarchique que vous. Et combien de fois avez-vous remis à plus tard une implémentation ou une discussion dont vous étiez convaincu de l’utilité, uniquement parce que vous n’osiez demander l’aval de votre – très occupé – manager ?

Le cycle en V

Le cycle en V est une méthode d’organisation très connue dont l’origine remonte à l’industrie et qui a été adaptée à l’informatique dans les années 80. C’est l’une des premières méthodes qu’on apprend à l’école, et elle reste toujours d’actualité.

La grande force du cycle en V, c’est qu’il définit assez précisément la manière dont les choses devraient se passer.

Cycle en V - théorie

On peut y distinguer 3 grandes parties : La phase de conception, la phase de réalisation (codage) et la phase de validation. Les phases de conception et de validation se découpent en plusieurs parties. Chaque étape ne peut être réalisée qu’une fois que l’étape précédente est terminée, ce qui diminue les prises de risque sur le projet.
Ce qui est bien visible sur le diagramme, c’est que chaque étape de conception possède son alter ego de validation. Il devient alors assez aisé de valider un projet, car le référentiel de test est connu très précisément.

Les différentes étapes

Le cycle en V est constitué de 9 étapes qui ont toutes leur importance.

La todo-list pour geeks : todo.txt

Le premier outil que je vais passer en revue sur ce blog ne pouvait être qu’un outil pour gros geeks. Je vais donc vous parler d’un logiciel qui permet de gérer vos todo-list en mode texte, juste en utilisant la ligne de commande sous Unix (testé sous Linux, Mac OS X et Windows/Cygwin, mais ça doit marcher sur n’importe quel système Unix-like possédant l’interpréteur Bash) : Todo.txt

Présentation

Le parti-pris de ce logiciel repose sur deux choses :

  • Pour les gens qui se sentent confortables avec l’utilisation de la ligne de commande, rien n’est plus rapide que de taper quelques commandes dans un terminal.
  • Pour le stockage de données, vous ne trouverez jamais rien de plus universel, de plus simple à échanger, à interpréter et même à lire directement que les simples fichiers texte.

Hé, on ne peut pas leur donner tort. Fondamentalement, ces deux points sont vrais.

L’ensemble des fonctionnalités est accessible via un script shell. Voici une petite vidéo de démonstration qui explique plutôt bien comment il s’utilise :

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

Les listes

Les listes constituent le « niveau zéro » de l’organisation. Quand j’utilise cette expression, ce n’est pas pour dire que les listes ne servent à rien, mais bien qu’elles sont la base de toute organisation, qu’elle soit personnelle ou collective. Vous ne pouvez pas espérer mettre en place une méthode de travail complète si vous n’êtes pas capable de gérer une simple liste de chose à faire.

Je vais détailler 3 types de listes : les listes de choses à faire (todo-list), les listes de bugs (buglist) et les listes de choses à vérifier (checklist).

Todo-list

Il s’agit du plus évident. Tout le monde, un jour ou l’autre, a noté quelque part une liste de choses à ne pas oublier ou de courses à acheter. Le premier pas en direction d’une organisation personnelle efficace est la tenue d’une liste de tâches. À chacun de faire de la manière qui lui semble la plus confortable, et en la matière il existe une quasi-infinité de recettes : utiliser un cahier ou un bloc-notes qu’on peut emmener partout avec soi, tout noter sur des post-it qu’on collera dans une pochette ou un classeur, utiliser la todo-list intégrée à notre logiciel de messagerie électronique, éditer des fichiers bureautiques (traitement de texte ou tableur), utiliser un wiki ou un système dédié à la tenue de todo-list.

Dans le cadre professionnel, il faut dissocier 2 types de todo-list :

  • Les listes de tâches que chaque employé doit tenir, et qui lui permettent de ne pas perdre le fil du travail qu’il a à réaliser. On est alors complètement dans le cas d’une liste que chacun est libre de tenir de la manière qui lui convient le mieux.
  • Les listes de tâches relatives à chaque projet. Celles-ci doivent être visibles par toutes les personnes ayant un rapport avec le projet. Il est important de savoir où le projet en est de manière globale ; c’est motivant pour tous les intervenants, mais c’est aussi nécessaire aux managers pour effectuer un suivi de l’avancement du projet. Il faut que les managers puissent modifier la liste de tâches, et que les personnes à qui elles sont assignées puissent indiquer la progression du travail.

De la modélisation à la réalité

La gestion de projet – et l’organisation en général – est une discipline très intéressante. On rencontre rarement deux fois la même situation. Entre les clients, les demandes fonctionnelles, les ressources disponibles, le facteur humain… les variables sont trop nombreuses. Et pourtant, on continue à chercher à modéliser les flux d’information en entreprise, on tente d’améliorer sans cesse la manière dont les projets naissent et vivent, on espère secrètement trouver la formule miracle qui fonctionnera à tous les coups et qui nous permettra de gérer les choses de manière optimale dans toutes les conditions.

Mais entre nous, franchement, on sait que ce n’est pas possible, hein ? Eh bien… c’est ce qu’on va voir.

Un modèle ?

D’après le dictionnaire, un modèle est une « représentation théorique d’un système d’éléments et de relations plus ou moins complexes ». Si la définition vous intéresse, vous pouvez toujours aller lire l’article consacré à la théorie des modèles sur Wikipédia. Un exemple : En électronique, on utilise des modèles mathématiques pour simuler le comportement de composants ; ces modèles ne sont pas « vrais » dans la mesure où ces composants ont une réponse différente de celle du modèle, mais cela permet à la fois de simplifier les simulations et de savoir vers quoi doit tendre le fonctionnement des composants réels.