Gestion des priorités des actions

J’ai enfin retrouvé le modèle de priorisation des actions (apparement dit d’Eisenhower) en fonction de leur urgence et de leur importance.

J’apprécie toujours autant l’idée que l’on jette sciemment des actions à la poubelle sans même y prêter attention :-)

Le concret – Suite

Le principe agile qui consiste à livrer une version fonctionnelle (voire déployable en production) à la fin de chaque itération confronte l’équipe projet à tous les problèmes et lui interdit d’aller se perdre dans les méandres d’anticipations fumeuses et abstraites.

Je pense qu’on peut généraliser cette confrontation au réel au quotidien, à de nombreuses activités.

Par exemple, il y a une différence entre

1. se dire ce que l’on va mettre dans une présentation
2. être assis devant son portable et faire vraiment la présentation en 20 slides maximum avec si peu de place (ou trop de place)
3. être debout devant tout le monde et dérouler sa présentation en 50 minutes maximum avec tant de choses à dire (ou si peu à dire)

Passer du théorique à la rédaction/conception/devt, puis passerà la confrontation des pairs (au test), puis aux clients. Et faire cela souvent.

Planning

Paradoxalement, il ne faut pas trop se focaliser sur les dates quand on dresse un planning.

Identifier les tâches, les ressources, les contraintes d’affectation.

Estimer les tâches

Estimer les dépendances (strictes ou pas)

Une fois que c’est clair, la date se calcule toute seule.

Et ce n’est qu’alors que l’on doit la mettre en regard des contraintes de dates, et revoir l’ensemble si ca ne “rentre” pas, en priorisant à la baisse certaines tâches, en acceptant explicitement de prendre le risque d’en paralléliser d’autres, …

L’acte de  planifier en mode agile se fait en équipe, pour que chacun puisse contribuer : contrainte à laquelle on n’a pas pensé, tâche que l’on n’a pas explicitée, …

Ne pas se focaliser non plus sur la tête qu’il aura dans MS-Project, mais bien sur le découpage le plus adéquat, le plus proche du mode de fonctionnement réel.

Et puis, un de mes mentors m’a indiqué qu’il dressait son planning sous excel et n’utilisait MS-Project que pour le communiquer (en ressaisissant les éléments à un niveau de granularité faible).

Se préparer par écrit

Peut-être est-ce l’âge, mais j’ai du mal à réagir au tac au tac et à réfléchir en parallèle.
Donc a fortiori à essayer de me souvenir des points que je voulais évoquer lors d’une réunion.

Parade, recommandée par les formations Krauthammer : se préparer par écrit.
Ne pas aller à une réunion sans une liste des points à soulever, des réponses à obtenir, …
Cela libèrera l’esprit sur place, et vous pourrez, préparé, être plus réactif, plus souple (paradoxal, non ?)

Même si vous faites votre liste 5 minutes avant le début (mieux vaut prévoir un délai plus grand, parce que dans l’élaboration de votre liste, vous ferez des comparaisons fructueuses, et aurez des questions, des compléments à apporter avant la réunion).

Et dans le même esprit, si vous préparez une présentation ou une formation, imprimez vos notes séparément, écrit gros (visibles de loin), agrafées… Vos capacités cognitives doivent être au maximum disponibles pour les interactions.

Le concret

J’ai beaucoup plané en info, spéculé, imaginé. Que reste-t-il de ces projets ? Restent les bribes qui ont été partagées, utilisées, dans plusieurs contexte. Le summum étant ce qui a été utilisé en production chez un client (comme outil, voire consécration ultime comme brique livrée en production). Le top du top étant de publier un composant open-source utile. Restent aussi les idées discutées, publiées.

Nos rêves de soft doivent sortir de nos têtes et se confronter au monde réel : contraintes (de temps de réalisation, de fiabilité, …), échanges critiques.

Reste aussi l’activité d’inception, si elle sait faire la part des choses entre besoin et solution (cf http://softreves.wordpress.com)

SOA : approche systémique

IMHO une approche de type SOA, ou Herzum (peu importe) devrait essayer d’intégrer la nécessité, quand on conçoit une interface (un contrat) d’intégrer 2 types de contraintes :

• in : les contraintes internes : moi je veux bien fournir un service qui renvoie le nom du client mais pour ça il faut me donner l’id du client ou une autre manière de le retrouver
• out : les contraintes d’utilisation par l’extérieur : moi j’ai besoin d’un service qui me ramène la liste des dossiers du client, je ne veux pas appeler n fois le même service

Cela vaut aussi pour l’organisation des équipes qui gèrent une famille de services :

• in : pour intégrer au mieux les contraintes internes, il faut les connaitre, donc les membres de cette équipe gagnent à rester au sein de l’équipe un minimum, à tourner sur les différents services gérés par l’équipe pour connaître au mieux le métier, etc…
• out : pour adapter les services au mieux aux contraintes externes :
  • ne pas réaliser les services par anticipation. Ne pas décider maintenant des besoins futurs (ou de l’absence de besoins futurs). Réaliser les services pour un (idéalement 3) projets actuels qui en ont besoin tout de suite
  • les membres de l’équipe “services” devraient être détachés au sein du projet une partie de leur temps, pour concevoir avec le projet les interfaces, pour les assister dans l’intégration, les jeux de données (les fameux bouchons), … Ils seront d’autant plus conscients des contraintes du projet, sauront au mieux justifier celles de l’équipe. Et les projets seront naturellement synchronisés en terme de planning.

« Trouvé » sur Google

On peut trouver tout sur Google.

Encore faut-il savoir poser la bonne question, la bonne combinaison de mots clefs qui va permettre d’obtenir la meilleure liste de réponse. Pour cela, il faut déjà connaître un peu le sujet, la problématique, pour pouvoir canaliser le moteur de recherche.

Par ailleurs, quand on survole un résultat de recherche, tout dépend de son état d’esprit, des documents que l’on vient de lire, de sa façon d’aborder le problème sur lequel on se documente, du contexte concret du problème, des idées que l’on a eu, de l’ordre dans lequel on a lu les documents précédents, du temps dont on dispose.

Ne pas lire trop de documents. Faire une sélection de 5 ou 6 sources bien choisies. Les comparer. Décider dans quel ordre les lire.  Les lire indépendamment en prenant des notes. Organiser les notes au fur et à mesure (avec un outil de mindmapping comme xmind ou au moins avec le mode plan de word). Faire cet exercice en ayant bien en tête le but (présentation à produire, décision à prendre et à argumenter, …)

Meneur de jeu

Avant les méthodes agiles, les rôles étaient établis.

Il y avait le développeur, le team leader, l’architecte, le chef de projet…

Chacun s’occupait de sa paroisse. L’architecte de la qualité des devts. Le chef de projet des délais. Le team leader du moral des troupes. Etc…

Maintenant que l’équipe s’organise comme elle le souhaite, les choses sont plus fluctuantes.

Tant mieux.

A condition que les débats s’organisent tous seuls autour des vrais axes. Arbitrage entre qualité et budget. Arbitrage entre veille techno et impératifs de délai.  Entre impératif pour l’équipe et formation des uns et des autres. Etc…

Peut-être faut-il quand même toujours un meneur de jeu, qui vérifie que l’on continue à se poser les questions (sans y répondre).

Le meilleur meneur de jeu étant celui qui s’efface, une fois son travail de mise en situation fait, derrière les joueurs et leur interprétation, les laissant libres et créatifs…

Small is beautiful

Un gros projet c’est plus long. Donc on oublie au bout de 1 an ce qu’on s’est dit, et pourquoi on se l’est dit.

Un gros projet c’est plus de personnes, chacune avec un rôle plus spécialisé, et puis avec de nombreux intermédiaires. Du coup la responsabilité est diluée. Et si la responsabilité est diluée, disparaît la capacité à réagir, mue par une volonté claire qui dépasserait les clivages

Un gros projet c’est des réunions avec plus de personnes, une combinatoire en n2 du nombre d’interactions au sein de ces réunions, des réunions qui durent longtemps, les participants qui se désintéressent, les listes d’action qui s’allongent.

Un gros projet ça fait des fois x3 le budget.

Un gros projet ça échoue même parfois. Ou pire, ça dure sans qu’on arrête les frais…

Une chose à la fois

Les formations à la gestion du temps préconisent toutes de ne faire qu’une chose à la fois, mais de la faire à fond.

Je pense que c’est en partie du au fait que chaque action vient avec sa grille de perception, son filtre (polarisé vers une direction précise). Quand on fait une chose précise, toutes les informations qui arrivent sont passées au crible de ce but : est-ce que ce document va m’aider dans cette tâche, …

Changer continuellement de tâche reviendrait à changer continuellement de grille, à remettre en question continuellement ces grilles successives, à remettre en question les tâches.  Peut-être est-ce cela l’explication du surcoût de trop de “context switch”. Trop de réflexion tue l’action.

En revanche, entre les tâches, ou avant de commencer la journée, ou après l’avoir finie, prendre le temps de regarder les actions à venir (sous forme de liste et non plus dans le détail), pour comparer, prioriser, …

Bref, un moment pour l’action, un moment pour le recul.

L’action et le recul

Quand on est dans l’action, toutes les formations de gestion du temps l’indiquent, on ne traite qu’une chose à la fois. L’une après l’autre. En tous cas, c’est ce qu’il faut s’efforcer de faire.

Quand on fait une pause pour prendre du recul, pour balayer ses listes, pour vérifier la couverture des risques et des oublis, on compare un grand nombre de choses. C’est alors que se fait le déclic, et que la vision de la globalité débouche sur l’idée, et avec l’accumulation des idées et leur travail, sur le recadrage.

On se livre quand même à cette activité quand on est dans l’action, mais c’est juste pour déterminer le plus urgent, non pour approfondir.

Prendre du recul, c’est aussi aller chercher des retours d’expérience, des grilles d’analyse qui pourraient être adaptées au cas présent. Activités qui consomment du temps, et nécessitent que l’on ne soit pas trop interrompu ni trop pressé.

D’un autre côté, l’urgence stimule. On s’efforce peut-être plus d’aller à l’essentiel.

Et puis il n’y a que le concret, que l’action finalement qui compte, la confrontation au réel, cette réduction des hypothèses et des projets aux seules actions effectives.

Pas plus de 20 items à la fois

Notre cerveau est limité. Nous avons du mal à comparer plus de 20 items à la fois.  N’avez vous jamais eu la sensation d’aller mieux quand votre todolist passait en dessous des 20 items ? Pour prioriser, regrouper, … bref avoir une réflexion globale et non analytique ?

Du coup, quand il faut prioriser une liste de 100 items :

1. balayer toute la liste en affectant chaque item à une catégorie. Au fur et à mesure vous identifierez des catégories supplémentaires. L’essentiel est de pas avoir plus de 20 catégories au final, pour pouvoir, pour chaque item, comparer les catégories possibles et choisir la meilleure (ou en rajouter une)
2. filtrer la liste par catégorie, et comparer les items au sein de la catégorie. Avec un peu de bol, votre catégorisation aura été suffisamment discriminante et donnera à chaque fois une liste pas trop complète. Au pire, ajustez la catégorisation (ce besoin devrait s’estomper au fur et à mesure).

Alors bien sûr, dans la vraie vie, il y a plusieurs catégorisations “en parallèle” (urgence selon la MOA, thème fonctionnel, risque technique, complexité, …) mais bon, si on se limite à 2-3 catégorisations bien choisies (i.e. éprouvée sur quelques items de la liste), on s’en sort.

Et on se retrouve avec une liste de 100 items triée, et on sait même plus ou moins pourquoi, ce qui est appréciable.

Globalité

Un premier article contre la tendance (peut-être française) à se limiter au découpage analytique, sans pousser jusqu’à la pensée globale qui met les éléments en regard et fait des synthèses et des comparaisons fructueuses.

Quelques exemples :

• globalité d’un échange d’information. Une somme d’échanges individuels est moins bien qu’une réunion. La créativité n’est pas la même quand plusieurs personnes sont là et interprètent ce que disent l’un ou l’autre, réagissent, comparent, complètent, transforment. N points de vue confrontés en même temps, globalement, valent mieux que N fois un échange entre 2 points de vue.
• globalité de l’optimisation. Quiconque a essayer de faire marcher un algorithme d’optimisation (recuit simulé, algorithmes génétiques, …) sait bien que pour trouver l’extremum absolu, on est obligé de prendre des décisions brutales, radicales, on ne peut pas se contenter de gagner un peu partout, de suivre la pente du gradient.
• globalité du chiffrage, de l’exercice qui consiste à dire quelle charge sera consommée pour réaliser tel ou tel développement.
  1. Quand on pratique le chiffrage, on se rend compte que ce qui est le plus intéressant dans l’exercice analytique, ce sont les hypothèses qui émergent au fur et à mesure.  Le chiffrage repose sur la créativité
  2. Le chiffrage repose sur la créativité. La confrontation des idées de plusieurs personnes permettra d’identifier les réelles hypothèses, contraintes à considérer, coûts sous-jacents, …
  3. Le chiffrage repose sur la comparaison entre les items. Certes cela implique un découpage analytique aussi fin que nécessaire (et possible au vu des informations dont on dispose). Cela suppose aussi et surtout une comparaison des items obtenus, pour identifier des correspondances (items coûtant à priori la même chose), des économies d’échelle, … Après vient le moment de l’évaluation quantifiée. Il est beaucoup plus juste d’évaluer les différents items en poids relatif, pour ensuite éventuellement traduire ces poids en charge.
  4. Le chiffrage repose sur l’historique. Comparer les items du chiffrage en cours avec l’historique de l’équipe sur ce projet s’avère très enrichissant, surtout si, dans l’historique, on dispose des hypothèses de départ, voire de la connaissance de comment les choses on tourné.
• globalité de la gestion de priorités. Il ne suffit pas d’arbitrer chaque bug pour dire on l’embarque / on l’embarque dans la release suivante. Il faut chiffrer les bugs (cf ci dessus). Il faut évaluer la charge que la somme représente, classer, comparer. Low/Medium/High pour chacun comporte beaucoup moins d’information qu’un classement.
• Globalité de la spécification, du chiffrage, du développement : le chiffrage ne doit pas être dissocié de la spécification de ce qui doit être réalisé. C’est (pour moi) à la base des méthodes agiles. Etablir un cahier des charge grosse maille pour une partie assez réduite de l’application. Chiffrer. En déduire des hypothèses à faire confirmer à la maîtrise d’ouvrage ou infirmer. En déduire ce qui coûte, et proposer des alternatives à la maîtrise d’ouvrage. Ré-établir le cahier des charge grosse-maille, réiterer. Cela va jusqu’au développements : si en cours de développement on se rend compte que quelque chose est beaucoup plus complexe que prévu, ou bien qu’il y a une autre approche beaucoup moins coûteuse, à nouveau reflexion globale specs/chiffrage/developpement. “Design to cost”. On a trop tendance à séparer specification et réalisation.
• Globalité des tests. Les tests unitaires (une couche d’un module), les tests d’intégration (toutes les couches d’un module) ne doivent pas faire oublier les tests de bout en bout, use case complet de l’utilisateur, peut importe qu’il passe par le module de gestion des utilisateurs (login) puis par le module de recherche puis par le module de passage de commande en ligne puis par le module de my space puis…
• Globalité d’une prise de décision rationnelle. On identifie les critères de décision. On identifie les scénarios à étudier. On évalue chaque scénario sur chaque critère. Voila pour la partie analytique. Lors de cette évaluation, on identifie de nouveaux critères, pour lesquels on évalue les différents scénarios. On commence à pondérer les critères. On calcule le poids final de chaque scénario. On compare. On se rend compte que tel ou tel critère est plus important, on augmente son poids. On identifie de nouveaux critères, pourquoi pas de nouveaux scénarios. Etc… Au final, on a l’illusion d’une décision analytique, le process était beaucoup plus complexe.