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.

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.

Scénarii

Peut-être est-ce du à notre enfance bercée par les histoires racontées avant de s’endormir, toujours est-il que nous appréhendons la réalité à l’aide d’histoires, de scénarii. 

Quand on spécifie un système informatique, il s’agit des “use cases“, histoires racontant ce qui se passe concrètement quand l’utilisateur fait telle ou telle action. La liste des uses cases permet d’avoir une vision d’ensemble, macro, des fonctionnalités que doit remplir le système. C’est là que ça se gâte. D’abord parce qu’on est réduit à avoir recours à un formalisme abscons (extension, héritage, inclusion,…) parce que l’utilisateur peut vouloir parcourir le système en suivant des voies diverses. Les décrire toutes est impossible. S’en tenir aux use cases identifiés est réducteur. Ensuite, on se rend bien compte que cette description, bien pratique sous l’angle contractuel ou de la rédaction des tests, pêche dès qu’il s’agit de rendre la complexité du métier. On ajoute alors des “business rules”, des renvois sans fin et le document devient illisible.

Quand on gère un projet, on cherche à gérer les risques. Les identifier, les anticiper, prendre des actions préventives. Pour gérer les risques, il faut les identifier. On se fait donc une image mentale du système, on essaie de dérouler tout ce qui peut se passer (utilisation normale, intrusion, crash système, incident d’exploitation, …). On affecte ensuite une probabilité à l’incident (celle que la salle machine soit détruite par une explosion nucléaire est faible par exemple). Si l’incident est jugé probable, on construit un nouveau scénario incluant le fruit d’actions préventives. La difficulté de cet exercice, c’est de savoir jusqu’où allé, ce que l’on gère et ce sur quoi on fait l’impasse. L’autre difficulté c’est l’exhaustivité. Penser à tout. C’est un réel travail de créativité, qui gagnera beaucoup à être réalisé en groupe. Malheureusement, la mise en situation étant relative, nous avons tendance à “découvrir” des problèmes au dernier moment, alors qu’il est trop tard…

Modèles mentaux et idoles

Je suis en train de finir “Death March: The Complete Software Developer’s Guide to Surviving “Mission Impossible” Projects ” de Edward Yourdon qui parle d’un peu tout sur les projets “plan loose”, et, pour ce qui m’intéresse ici, des modèles mentaux.

Comment s’organise l’expérience “soft” que l’on acquiert en général et en gestion de projet en particulier ?

J’ai tendance à retenir ce qui a pu marcher, sous forme de règles (non écrites) du genre : si tel évènement se produit, alors ca veut dire que tel fait est vrai et dans ce cas il faut prendre telle action. On reproduit ce qui a fonctionné par le passé.

Le problème étant dans ce cas que les choses ne sont pas forcément identiques. Il ne s’agit pas des mêmes personnes, de la même culture d’entreprise, du même contexte, du même historique. Même l’auteur de ces lignes à changé. Et donc une fois l’action prise, les conséquences ne seront pas les mêmes.

J’ai une autre tendance, qui consiste à idéaliser les gens avec qui j’ai pu tavailler. Vous n’avez pas connu Jacques R. ou Philippe R. ou Henri P. ou Georges H. . Moi si. Ils ont représenté à un moment donné l’idéal, même perfectible, le modèle, l’idole. Et donc même après avoir travaillé avec eux, ils reste un écho de nos échanges, de leur propos, un fantôme qui peut vouloir me guider.

Le problème c’est que dans la situation présente, ils n’auraient pas forcément réagi comme ils ont réagi par le passé. Et quand bien même ils auraient eu une réaction simillaire, ma mémoire défaillante ne m’aurait pas restitué tous les détails. Et même si j’avais tous les détails, je n’ai pas forcément les qualités pour faire les choses comme ils l’auraient fait.

Conclusion : conserver l’esprit du débutant pour rester vigilant et adapter son comportement à ce qui se passe, ici et maintenant, avec les personnes présentes.

Chef de projet ou d’équipe

Quelques aspects demandé à un chef de projet ou d’équipe :

- respecter ses engagements : budget (charge), délai, qualité, périmètre, dans l’ordre de priorité défini pour le projet

- défendre son périmètre et les intérêts de son équipe, quitte à demander un arbitrage à l’étage au dessus. Etre un premier filtre pour les sollicitations extérieures (comme un Scrum Master)

- gérer les risques (anticiper, prévenir, soigner)

- ne pas faire ce qu’on aurait pu éviter de faire

- faire les choses par ordre d’importance (imaginer que l’on puisse tout arrêter avant la fin)

- prendre les décisions en temps utile en s’appuyant sur des évaluations chiffrées (et obtenir au préalable ces évaluations, de manière stable et prédictive)

- éviter que son équipe ne soit en famine ou en surcharge. Idem pour les équipes dépendantes ou sources

- répartir les responsabilités de façon à ce que tout sujet ait au moins un et au plus un responsable (y compris la prise en compte des nouveaux sujets)

- donner de la visibilité à l’étage au dessus

- optimiser le fonctionnement de l’équipe, collecter les suggestions, être force de proposition

- lever le stylo, prendre du recul parfois pour établir une stratégie, pour comparer, ordonnancer

- communiquer avec l’exterieur, faire passer les messages, convaincre, négocier

- s’informer sur la situation, créer les canaux qui permettront cette information

- collecter un historique (qualitatif et quantitatif) pour pouvoir s’appuyer sur le passé pour prédire l’avenir, tant en terme de charge qu’en terme de liste des tâches

- anticiper les problèmes pour que les décisions puissent être prises à temps (on peut dépasser un peu le budget, si ca permet de tenir les dates, …)

- contrôler la couverture du besoin, l’exhaustivité des sujets traités

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 rationelle. 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.

Recul

Difficile de prendre du recul sur son job quand on a la tête sous l’eau. Je tiens un blog perso qui m’aide un peu en ce sens, je vais essayer ici de généraliser à l’info.

Ce qui est ambivalent, c’est la finalité d’un tel blog :

• formaliser un peu ses idées et donc prendre du recul ?
• communiquer ses idées ?
• échanger sur ses idées ? vue la faible audience à laquelle j’espère, j’ai des doutes. Ce blog n’aura pas d’autre pub qu’un lien depuis mon profil LinkedIn et la magie de Google.
• dire ce que je n’ose dire en direct, en profitant de la “suspension of decency” de la communication avec des inconnu(e)s via internet. Ca marche bien pour mon blog perso, mais là, l’url contient mon nom, et le blog sera accessible aux recruteurs, alors… ?
• parler sans contradicteur. C’est peut-être ça le plus crédible :-)

Quelques sujets en vrac, pour démarrer :

1. Ce que j’appellerai le chef de projet “holistique” ou “humaniste”
2. Les causes d’échec d’un grand projet (j’ai un exemple bien précis en tête…)
3. Les limites de la pensée modulaire / par composant
4. Comment faire carrière dans le conseil (ce que je n’ai pas encore réussi à faire)
5. La perception du temps
6. La “shock therapy” (pour reprendre le terme de Sutherland), je pense à une experience récente
7. Que faire quand vous avez atteint votre niveau d’incompétence de Petters
8. Le développement en cascade, CMMI et les méthodes agiles
9. Chef de projet vs Scrum Master
10. Forfait vs Agile
11. De la réticence à rentrer en profondeur dans les sujets