Diffuser un outil avec agilité

Procéder étape par étape : un projet, puis un autre projet (en refactorant ce qui a été fait pour le premier).
Poursuivre à chaque fois les échanges avec les utilisateurs, pour les sensibiliser mais aussi pour comprendre leurs attentes.

Capitaliser sur les bonnes pratiques, extraire des éléments réutilisables dans ce qui a été mis en place concrètement pour un projet (au lieu d’implémenter dans le vide du code transverse).
Pas de grande théorie ou de consensus préalable.
Pas de solution générique, mais faire émerger des patterns, en mutualisant les aspects fastidieux.

Concentrer ses forces sur un petit nombre de cibles, pour être pertinent et efficace.

Eviter les gros chantiers à effet tunnel, se mettre au contraire en situation (migration à blanc, démonstrations et retours utilisateurs, mise à disposition d’un environnement de test par les utilisateurs).

Surtout : apprendre au fur et à mesure, ne pas hésiter à jeter quand on comprend mieux les besoins, et l’outil (contraintes, forces).

Publié dans Agile, Entreprise | 1 commentaire

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.

Publié dans Efficacité | Laisser un commentaire

Je suis devenu #à compléter#

Je suis devenu architecte du projet PQR. Je suis devenu chef de projet. Je suis devenu responsable de l’offre X chez YZ.
On ne devient pas. On est, plus ou moins, en fonction du temps :
  1. on est effectivement nommé chef de projet, montré en tant que tel au client ou à l’équipe. Ca ne dispense pas le directeur de projet de fourrer son nez partout ou l’équipe de faire des deals en douce.
  2. si l’équipe n’a pas envie de vous comme architecte, elle fera oui oui de la tête et fera le contraire ensuite. Ou elle trainera les pieds. Où elle dira « j’aurais bien fait ça, mais là je n’ai pas le temps, car le projet est très en retard, plus tard peut-être ? ». Est-ce un manque de respect ? Est-ce que votre idée était inadéquate au moment où vous l’avez proposée ? L’avez vous mal proposée ? Votre casquette ne vous aidera pas en tous cas.
  3. on peut aussi être rétrogradé, par l’arrivée d’un cp plus senior « en refort », d’un PMO, d’un consultant en architecture,… Certes ce n’est pas très plaisant, mais si vous n’etiez pas fait pour le job (à cet instant précis), autant sortir d’une impasse
  4. responsable de l’offre… Tout est dans le regard du manager de Business Unit. S’il croit que cela a un avenir, et que vous pouvez l’aider, il vous nommera responsable de l’offre, pour un temps. Quand ca n’ira plus ou quand des candidats plus pertinents auront senti le vent tourner et se seront rapprochés de lui, tout sera remis en question.
Ce qui compte c’est ce que vous avez accompli (résultats tangibles, chiffrés), l’adéquation entre vos décisions et actions et le problème à traiter. L’expérience que vous en avez retiré (retenter la gestion de projet même après un échec, dans un contexte plus favorable, où les choses seront moins nouvelles pour vous, sera beaucoup plus facile). Les titres, les grades… Ce ne sont que des mesures, temporaires, de l’image que l’on a de vous. Qui est importante car elle conditionne les missions que l’on va vous confier. Mais ce n’est rien de plus que ça.
Publié dans Entreprise, Humain | Laisser un commentaire

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)

Publié dans Efficacité | Laisser un commentaire

La révolte agile

Il s’agit bien d’une révolte d’une catégorie de la population contre son oppresseur.

Des développeurs contre les chefs de projet et les méthodologues qui prétendent leur dire comment faire ou comment penser ou comment s’organiser. De l’abolition de la hiérarchie au sein d’un projet, en mettant tout le monde sur le même plan. Du raz le bol des développeurs qui n’aiment pas rédiger de la documentation ou suivre un plan et une attribution des tâches.

Mais aussi des chefs de projets à leur tour contre les managers de Business Unit et les contrats au forfait.

Tout ceci a un côté très lutte de classes. La direction me semble bonne, mais il ne faudrait pas jeter le bébé avec l’eau du bain.

Publié dans Agile, Entreprise, Humain, Leadership | 2 commentaires

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.
Publié dans Efficacité, Entreprise | Laisser un commentaire

« 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, …)

Publié dans Efficacité | Laisser un commentaire

Conviction

J’oublie toujours. Ce n’est pas parce que l’on est convaincu que l’on a raison. Ce n’est pas parce que l’on semble hésiter, que l’on a tort.

La force de conviction est indépendante de la pertinence du point de vue.

En particulier en ces temps agiles où l’on se remet plus en question, ayant paradoxalement du coup l’air d’être moins sûr et ayant pourtant un point de vue beaucoup plus adéquat.

Publié dans Humain | Laisser un commentaire

Sortir du bois

On peut sortir du bois, mais cela suppose :

  • que l’on pense que l’on peut changer les choses
    • y-a-t il un intérêt à changer les choses
    • sera-t-on assez convaincu pour être convaincant (sans parler du fait qu’il vaut mieux garder un peu de recul pour trouver les meilleurs arguments)
    • pourquoi serai-je mieux placé que les autres pour changer les choses ? pourquoi moi et pas un autre ?
  • que l’on est prêt à prendre le risque de proposer autre chose, que l’on accepte la possibilité d’un échec
  • que l’on soit prêt à répondre à la question : « qu’est-ce que tu y gagnes »
    • parce que l’on y gagne quelque chose
    • ou pas (quand on est altruiste)
  • que l’on connaisse le sujet  / le problème suffisamment pour être pertinent
    • en particulier parce qu’on l’a creusé (sans avoir eu l’aval de consommer de la charge dessus)
    • par ce qu’on a échangé dessus avec ceux qui savent (sans avoir la légitimité)
    • malgré un manque d’expérience (pour prouver que l’on a l’expérience de faire une chose pour la première fois, il faut l’avoir déjà faite. pas simple)
  • que l’on soit prêt à exprimer une opinion non sollicitée (on s’expose à l’indifférence ou au rejet)
  • que l’on accorde plus de crédit à sa propre opinion que le consensus mou existant, qui s’appuie sur l’expertise et l’expérience accumulée
  • que l’on franchisse le fossé qui sépare l’idée de l’action, malgré un agenda chargé par ailleurs, avec des tâches priorisées, elles
  • que l’on empiète sur les prérogatives de sa hiérarchie avec les risques de conflit vertical que cela comporte.

Mais il faut, avec mesure et bon sens, sortir de bois. C’est la seule façon de faire avancer les choses, de recadrer un effort collectif, de prendre du galon. Une fois que vous serez sorti du bois, on attendra de vous que vous sortiez à nouveau, à bon escient, mais souvent.

Publié dans Humain | Laisser un commentaire

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…

Publié dans Agile, Efficacité, Humain, Leadership | Laisser un commentaire

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…

Publié dans Efficacité | Laisser un commentaire

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.

Publié dans Efficacité | Laisser un commentaire

Mécanique de la compréhension d’une nouvelle techno

IMHO, la compréhension d’un sujet n’est pas une activité continue mais une succession d’instants de compréhensions, de révélations plus ou moins profondes.

D’abord un peu (on est exposé par hasard au sujet, ou indirectement), ensuite beaucoup (on est confronté à une doc riche sur le sujet, qui s’entrechoque avec les éléments que l’on avait) ensuite cela s’épuise.

Puis on pratique le sujet professionnèlement, en confrontant le modèle mental que l’on a à l’expérience. De nombreux instants de compréhension, puis cela rallentir.

En parallèle on échange (beacoup d’impact au début de la discussion avec chaque interlocuteur, puis moins) puis de moins en moins.

Puis on s’exprime sur le sujet. L’effort de rédaction, la confrontation des sources, dans un but précis (auditoire (experts ? novices ?), format (présentation ? formation ?), tout cela bouillone et affine la maturation, sans parler des questions de l’auditoire.

Enfin, la confrontation du sujet avec d’autres problématiques d’autres domaines, la cross-fertilization, apporte les quelques dernières gouttes.

Et puis on passe à autre chose !

Publié dans Humain, Pensée | Laisser un commentaire

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.

Publié dans Efficacité | Laisser un commentaire

Mon manifeste à moi

En m’inspirant de la forme du manifeste agile (l’humain plutôt que les processus et les outils, …), voici un peu mon manifeste

  • Exprimer ses convictions, ses contraintes, ses raisons plutôt que dissimuler
  • Ecouter et changer d’avis plutôt que résister à l’influence
  • Interroger avec précision plutôt que convaincre sans écouter
  • Faire émerger un consensus sous contraintes plutôt que contraindre à adopter une solution
  • Réagir avec souplesse plutôt que prévoir à l’avance
  • S’orienter avant de se lancer plutôt que foncer tête baissée pour respecter les charges
  • Connaître les différents métiers de l’informatique pour les avoir un peu pratiqués plutôt que de se spécialiser, même dans le management
Publié dans Humain, Leadership | Laisser un commentaire

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.

Publié dans Efficacité | Laisser un commentaire

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…

Publié dans Pensée | Laisser un commentaire

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.

Publié dans Pensée | 1 commentaire

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
Publié dans Humain, Leadership | Laisser un commentaire

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.
Publié dans Efficacité, Pensée | Laisser un commentaire