Eh oui, le retour (bis) !
A la demande générale de mes fans (followers ?) , je reprends la plume après une trop longue période d’abstinence.
En fait, je m’aperçois que la fréquence de mes posts correspond parfaitement à mes périodes d’inter-mission. Je vous avoue être impressionné par les personnes qui réussissent à alimenter leur blog régulièrement tout en étant prises par leur travail quotidien : bravo à elles !

Aujourd’hui, un sujet qui m’est venu suite aux débats actuels sur la crise (ou la Crise ?) et qui m’ont fait penser à des situations rencontrées de nombreuses fois sur des projets informatiques : le cadre limite l’image …

Qui n’a pas entendu au moins une fois l’expression « Le tout est plus que la somme des parties » ? (une brève recherche par Google remonte des infos comme « Aristote » et « holisme ». Ce point n’a rien à voir avec le sujet mais je trouvais que cela faisait « culturel », surtout un 1er avril). Etant de nature optimiste, j’ai une tendance naturelle à effectivement adhérer à cette expression. Ma formation scientifique m’incline aussi à pencher en sa faveur (qu’on pense à l’auto-organisation complexe émergeant d’un grand nombre de systèmes simples).
Cependant, je n’oublie pas avoir utilisé « Yin & Yang » comme tag et j’ai donc considéré la vision selon laquelle le tout peut limiter les parties ou, dit autrement, « il est difficile de faire mieux que le système ne le permette » ou encore « le cadre limite l’image … ».

Afin d’illustrer mon propos, je vais prendre quelques exemples hors et dans l’informatique

Steve Jobs
Considéré par certains comme un génie ou un visionnaire. En tout cas, nous conviendrons tous qu’il s’agit d’une figure marquante de l’informatique « grand public ». Steve Jobs est né en 1955 à San Francisco (USA). Quelle aurait été la carrière de Steve Jobs s’il était né en 1955 de l’autre côté du Pacifique à Vladivostok (URSS) ? Je pense que nous serons tous d’accord sur le fait qu’il n’aurait jamais créé Apple (ou plutôt яблоко). On peut même se risquer à supputer que ses qualités vu de l’Ouest auraient été perçues comme des défauts vu de l’Est (version moderne de « vérité en deçà des Pyrénées, erreur au delà »).

La mécanique quantique
J’ai déjà utilisé cet exemple dans un autre de mes posts mais je ne peux pas m’empêcher de le reprendre : on ne peut pas expliquer les effets quantiques dans le cadre de la mécanique classique. Les tentatives en ce sens se sont soldées par l’application de rustines successives qui n’ont fait que complexifier le modèle sans apporter la réponse adéquate.

Le discours managérial
Exemple véridique : j’ai vécu une réunion à destination de l’équipe IT où le PDG de l’entreprise était intervenu avec les termes suivants : « Mesdames et Messieurs les informaticiens, faites-nous rêver ! ». Jusque là, tout allait bien mais deux jours plus tard, mail du responsable IT à toute l’équipe pour annoncer que les budgets seraient rognés de 10 à 20% … moralité « faites-nous rêver … avec du scotch et des bouts de ficelle » … dommage, l’image était belle mais le cadre manifestement trop étriqué.

Darwin
Les dinosaures ont vécu plus de 150 millions d’années (ce qui, au passage, doit nous faire méditer sur la « supériorité » de l’homme). mais un brusque changement de cadre (météorite et/ou volcanisme) a conduit à l’émergence des mammifères (dont l’homme).

Les projets IT
A mes yeux, la complexité des projets IT est très liée aux multiples cadres qui y sont appliqués : cadre humain (un projet est avant tout limité par les personnes qui y sont affectées), cadre Métier ( … « finalement, on veut quoi ? » …), cadre technique (qui n’a pas connu un projet où les performances ont amené à revoir la copie), cadre organisationnel (ou l’art de naviguer entre le micro-management et le chaos), …
La résultante de l’intersection de ces différents cadres conduit souvent à une image finale réduite sinon inexistante. Mon plan d’action sur ce sujet est de commencer par la fin, de mettre en production au plus vite une première image et, ensuite, d’élargir le cadre.

En conclusion, je rebouclerai sur ma réflexion première par rapport à la crise : on ne dépassera pas les problèmes actuels et futurs en appliquant les cadres de pensée du passé.
Et, comme nous sommes le 1er avril, je proposerai une solution élégante à la question des retraites :
Etre en retraite de 0 à 40 ans (je suis prêt à négocier sur la limite à 40 ans) et travailler ensuite sans limite …

bonne peinture !

Christophe Leroy

Eh oui, le retour !

Après un long moment de silence, je reprends la plume pour un post qui sent bon les prochaines vacances (rapport à la mer, bien sûr).

Plus sérieusement, ce silence fut lié (sans que cela constitue une excuse) à 2 missions d’intérim de 6 mois chacune que j’ai réalisées l’une à la suite de l’autre chez le même client : la première consistait à reprendre le rôle de directeur de programme sur un projet Oracle de centralisation des achats et la seconde à jouer le rôle de manager de transition dans le domaine Finance à la DSI. Je vous assure que mes temps libres ont été fortement réduits ces derniers mois.

Pour ce retour, je vous propose de vous livrer mes réflexions sur le livre de Christian Morel, Les décisions absurdes II, comment les éviter ?, Gallimard, 2012

Christian Morel avait écrit il y a 10 ans le premier tome de cet opus « Les décisions absurdes, sociologie des erreurs radicales et persistantes » qui présentait quelques exemples fameux de décisions singulières ayant mené à des résultats en totale contradiction avec le but recherché : exemple, l’explosion de la navette Challenger en 1986 pour un problème connu de joints non adaptés à la température extérieure lors du lancement.
Après les constats du premier tome, Christian Morel propose ici des pistes pour éviter de se fourvoyer.
Il illustre ses propos par de nombreux exemples d’organisations qui ont réussi à mettre en place des processus de haute fiabilité comme la marine nucléaire américaine (d’où le titre de ce post), l’armée de l’air française, les guides de haute montagne en Suisse, des équipes de blocs opératoires, …
Vous verrez que les démarches adoptées tranchent radicalement par rapport à notre vision a priori des moyens pour obtenir une haute fiabilité et par rapport à notre image première des organisations concernées (je me focaliserai sur la Navy qui me paraît l’exemple emblématique).

Dixit Christian Morel, « Les porte-avions et sous-marins nucléaires de la marine américaine sont considérés comme des modèles d’organisations hautement fiables. La fréquence des accidents y est nettement inférieure à ce que l’on pourrait attendre compte tenu des situations à haut risque auxquelles ils sont exposés ».

Selon lui, ces résultats sont obtenus grâce à 3 principes forts et originaux :
- La flexibilité de la hiérarchie militaire (vous lisez bien !) : la décision se prend au niveau opérationnel pertinent
- L’interaction éducative permanente : un sous-marin nucléaire est un modèle d’entreprise apprenante
- L’avocat du diable et le droit de veto : les débats contradictoires sont encouragés sinon obligatoires et des instances (ou acteurs) définies ont droit de veto sur la décision finale

Christian Morel s’appuie sur ces exemples pour proposer ce qu’il appelle des métarègles de la fiabilité
- Hiérarchie restreinte impliquée
- Avocat du diable et débat contradictoire
- Interaction généralisée
- Vision des interstices
- Non punition des erreurs

Hiérarchie restreinte impliquée
Comme déjà écrit, il s’agit de faire prendre la décision au bon niveau opérationnel. Christian Morel cite à ce sujet le nom d’un sociologue américain, Richard Sennet, qui soutient la thèse que les cadres supérieurs américains ont souvent moins de compétences que leurs subalternes (serait-ce possible en France ? ). Le rôle du responsable (ou manager ou chef) reste cependant bien réel (cf. le « impliquée » dans « hiérarchie restreinte impliquée ») et consiste à délivrer un objectif clair en expliquant les tenants et aboutissants, en bref, en donnant la vision d’ensemble dans laquelle s’insère la décision à prendre

Avocat du diable et débat contradictoire
Il s’agit d’instituer un processus fort de contestation productive lors d’une prise de décision. Ceci évite notamment les pièges classiques de la dynamique de groupe comme les faux consensus, la pression hiérarchique, l’effet des règles bureaucratiques ( « j’ai transmis le problème à l’autorité compétente, ce n’est donc plus mon problème » ), …
Le droit de veto sur la décision finale fait aussi partie de cette métarègle.

Interaction généralisée
On retrouve ici l’aspect interaction éducative permanente (l’équipe s’auto-forme) mais aussi les notions de communication circulant de façon fluide, de haut en bas et de bas en haut. L’auteur évoque aussi les points bénéfiques d’une interaction en one-to-one et d’une communication explicite (ex. la validation orale de la bonne compréhension de la question par répétition de la question avant de donner la réponse dans une check-list avant décollage). Il termine enfin par louer les bienfaits d’une équipe stable (ex. les équipages des sous-marins nucléaires) et de la redondance dans les équipes (encore une fois, pour garantir de véritables contrôles croisés et ce, toujours dans un but constructif).

Vision des interstices
Par interstices, l’auteur entend les lieux où des éléments organisationnels doivent travailler ensemble. Je me permets de traduire par « interfaces » qui induisent des trous dans la communication et dans la vision globale du problème à traiter ainsi que des pertes en matière de connaissance. Ces interstices sont aussi sources potentielles d’erreurs par la divergence des intérêts des différentes parties prenantes. Enfin, Christian Morel donne un coup de griffe à la mode actuelle des mutualisations des moyens qui est supposée, par la division du travail, améliorer l’efficacité, ce qui est sans doute vrai en optimum local mais reste à démontrer en optimum global.

Non punition des erreurs
Ce point est selon l’auteur un des fondements de la haute fiabilité. Cette pratique permet notamment de faire remonter tous les « petits » incidents précurseurs et permet aussi de diffuser les retours d’expérience (évitant ainsi la reproduction d’erreurs déjà connues par ailleurs).
Plutôt que de chercher à punir à tout prix un bouc émissaire, il propose d’instaurer la notion de « rigueur jurisprudentielle » (à travers une charte), notion qui permet de raffiner sans cesse le meilleur processus en réponse à des erreurs identifiées.

Un des points les plus dérangeants et des plus intéressants que je retiens du livre de Christian Morel concerne le management :
Le mode hiérarchique classique fonctionne bien en période de stabilité (il écrit : « quand il ne se passe pas grand-chose »). Dans un environnement incertain, des approches plus fluides permettent d’optimiser la prise de décision au niveau le plus pertinent.
Après réflexion, Darwin ne disait pas autre chose par rapport à la survie des espèces : « seul le plus adaptable survit ». A méditer à notre époque de transitions de plus en plus rapides …

En conclusion, je vois un lien entre cette recherche de la haute fiabilité et le concept d’entreprise agile et, en tant que fervent promoteur des approches agiles, je compte bien faire le parallèle entre ces métarègles de haute fiabilité et les principes agiles dans un prochain post.

D’ici là, bon vent …

Christophe Leroy

J’ai participé récemment à une formation Scrum Master (Certified Scrum Master (CSM)) animée par Jeff Sutherland (un des « pères » de Scrum).

Nous étions 25 personnes à suivre ce séminaire sur 2 jours (et à Paris) répartis en 4 groupes (équipes ?) de 6 (ou 7) personnes. En dehors de la couverture exhaustive de l’approche Scrum, l’un des intérêts majeurs de cette formation venait des retours d’expérience de Jeff (et il ne s’est pas privé de nous faire part de nombreuses anecdotes tirées tant de sa vie professionnelle que de sa vie personnelle).

Par contre, un des points sur lesquels la plupart des participants ont été (relativement) déçus porte sur les exercices …

En effet, la densité de matière à présenter et le nombre important de participants rendaient difficile l’intégration des exercices dans le cursus de 2 jours. C’est sans doute pourquoi les exercices se sont trouvés relégués au second plan … ce qui est dommage par rapport à l’esprit Agile qui met l’accent sur le concret, le collaboratif, les tests, l’apprentissage par la pratique, …

Cependant, après avoir laissé décanter quelques jours les souvenirs de ce séminaire, il me revient à l’esprit un exercice qui consistait à construire des avions en papier de façon collaborative sur une période de 3 sprints (sprints de 7 min).
L’objectif était, semble-t-il, d’illustrer la montée en régime de l’équipe au fur et à mesure du déroulement des sprints. Si c’était bien l’objectif (ou l’un des objectifs) de l’exercice, nous (l’équipe dont je faisais partie) étions assurément restés sur notre faim à l’issue de la formation.
Mais, comme je le disais, après réflexion, je me suis rappelé un point « tout bête » qui s’était produit lors de cet exercice : le papier pour la construction des avions était fourni mais pas le mode d’emploi (ou de pliage). Une équipe n’a donc produit aucun avion faute d’un équipier sachant plier correctement une feuille de papier pour en faire un avion capable de voler plus de 3m (c’était le critère de « done » pour cette user story). Du coup, l’exercice devenait beaucoup plus enrichissant en rappelant qu’un des premiers critères de réussite d’une équipe (Scrum ou pas) réside dans la compétence de ses membres : si j’osais la métaphore footballistique, je dirais qu’il est inutile d’espérer jouer en Liga avec des amateurs.

En poussant plus loin les enseignements potentiels de ce fameux exercice, on pourrait considérer qu’il illustrait aussi la gestion d’un « impediment » (mot que Jeff a employé très souvent) majeur et que l’équipe aurait dû s’organiser pour trouver des moyens de gérer ce blocage.

En poussant encore plus loin, j’y vois une « réhabilitation » du rôle des managers externes à l’équipe ou, au moins, une explication d’un des rôles possibles des managers dans une approche Scrum : renvoyer un oeil externe sur l’équipe et sur ses performances (on pourrait aussi arguer que cela fait partie du rôle de l’équipe de gérer sa veille technologique et de s’évaluer par rapport à l’état de l’art mais, en dehors du fait qu’il s’agit d’un réel investissement, je ressens surtout la très grande difficulté à s’auto-évaluer (difficile d’être à la fois juge et partie)).
Cette mission d’éviter que l’équipe ne s’auto-isole ou n’évolue dans son monde clos me paraît donc dévolue au management externe à l’équipe (le Product Owner peut et doit, bien sûr, aussi participer à cette mission de par sa connaissance du marché).

Moralité : l’exercice de « Laissez parler les p’tits papiers » nous aura été finalement bien utile … merci Jeff des enseignements que nous pouvions en tirer ! soit :
- une équipe formée de joueurs compétents
- une gestion efficace des blocages
- une attention soutenue et un soutien attentif des managers à l’équipe
La prochaine fois, il nous faudrait juste le temps de faire une mini-rétrospective après chaque exercice et de partager le retour des différents participants.

De votre côté, si vous tirez d’autres enseignements potentiels de l’exercice des « avions en papier », n’hésitez pas à m’en faire part.

Bon vol !

atipyc –>

Christophe Leroy

La question exprimée de façon synthétique dans le titre de ce billet peut se détailler en multiples interrogations en gestion de projet :

- La méthodologie : un mal nécessaire ?
- Quel niveau de méthodologie utiliser pour la bonne marche du projet ?
- Quels bénéfices sont attendus de la méthodologie ?
- Quelle est la meilleure méthodologie en gestion de projet ?
- La méthodologie employée dépend-elle de la nature du projet ?
- La méthodologie et l’assurance qualité ?
- La méthodologie et l’Agilité ?
- …

Je m’arrête là et je rebondis sur un article de Tom DeMarco ( « Software Engineering: An Idea Whose Time Has Come and Gone », 2009) qui a publié de nombreux ouvrages sur la gestion de projet dont un intitulé « Controlling Software Projects: Management, Measurement, and Estimation », 1982.

Tom revient sur le sujet du contrôle des projets et des métriques associées avec un peu moins de 30 ans de recul et ses réflexions sont ébouriffantes : quelques morceaux choisis :
- « Today we all understand that software metrics cost money and must be used with careful moderation »
- « … strict control is something that matters a lot on relatively useless projects and much less on useful projects »
- « The question that’s much more important that how to control a software project is why on earth are we doing so many projects that deliver such marginal value? »

I could not agree more

Après ces retours d’expérience tristounets, Tom propose des pistes d’action :
- « Can I really be saying that it’s OK to run projects without control or relatively little control? Almost »
- « So, how do you manage a project without controlling it? Well, you manage the people and control the time and money »
- « I’m advocating a management approach, one that might well steer the team toward agile methods, at least toward the incremental aspects of the agile school »

En tant que fervent convaincu des bienfaits d’une approche Agile de la gestion de projet et plus généralement d’une approche agile du management, I could not agree more (bis)

Tom rappelle par ailleurs le côté expérimental de tout projet informatique (cf. « Art ou Science ? ») et j’aime beaucoup son insistance sur le côté « humain », condition nécessaire à la réussite de tout projet ; je répète donc avec plaisir :

« You manage the people and control the time and money », Tom DeMarco

atipyc or no!

Christophe Leroy

après un galop d’essai en solo lors du passage de l’Agile Tour à Lille en 2009 (le titre de la présentation était alors « L’Agilité est-elle soluble dans la culture française ? »),

avec Marc Lainez (un collègue (et ami) Agile belge), nous avons repris le flambeau à l’Agile Tour (toujours à Lille) en 2010 (le 4 novembre dernier) en élargissant le débat à la communauté francophone et voici le résultat : « L’Agilité est-elle soluble dans la culture francophone ? »

… Marc et moi sommes maintenant à la recherche d’un collègue suisse pour une prochaine présentation en trio

francophonement (?) vôtre

atipyc … atypique

Christophe Leroy

Une attente classique d’un client vers son consultant favori est de lui demander « la meilleure solution » (au sens français du terme « the best ») pour un problème donné.
Prenons (au hasard) le cas du choix d’un système informatique.

Nombre de consultants ont travaillé (et travailleront) consciencieusement sur ce sujet du cahier des charges et de l’aide au choix. Ils dresseront de magnifiques tableaux comparatifs combinant de multiples axes d’analyse et proposeront (normalement) 3 possibilités en short-list (avec 2 qui se dégagent) sans s’engager dans une préférence (impartialité oblige).
En supposant le cas idéal où la décision n’est pas déjà prise et où l’étude ne sert qu’à la « confirmer » (on arrive à mettre en avant n’importe quelle solution en jouant sur les poids attribués aux critères de choix), je n’ai, pour ma part, jamais connu que des cas de figure du type « meilleure solution » (au sens français du terme « the better »).
Si on ajoute à l’analyse à un moment donné, la volatilité des solutions informatiques tant du point de vue technologique ( « high tech » aujourd’hui, démodé demain) que du point de vue mode ( « ERP » aujourd’hui, « Best of Breed » demain), la prise de décision devient un exercice extrêmement délicat.

Que faire ?
Quelques pistes de travail :

• Reconnaître que la solution parfaite n’existe pas … et qu’il faut se décider maintenant
• Prendre en compte l’aspect humain des équipes qui vont mettre en place la solution : que ce soit des équipes internes (et dans ce cas, les faire participer au choix) ou des équipes externes (et dans ce cas, les rencontrer et travailler concrètement un minimum avec elles avant de lancer le projet)
• Acter le fait que dans 5 ans (au grand maximum), la solution devra être changée : par évolution (nouvelle version) ou par révolution (nouvel outil) … (une autre approche (plus Agile) étant de faire évoluer constamment la solution. 5 ans plus tard, la solution ne ressemblera alors plus à la solution initiale (… idéalement, l’outil informatique aura accompagné les évolutions Métier)).

Bonne quête …

ati???
Christophe Leroy

Petit échange lors d’une réunion de famille où j’essayais (vainement) d’expliquer ce qu’est le travail d’un chef de projet informatique : question d’un cousin éloigné : « selon toi, quelles sont les qualités premières d’un chef de projet ? ».
J’ai été sauvé in extremis par l’arrivée de la pièce montée mais la question m’a trotté quelque temps dans la tête.

Après moultes réflexions, j’ai accouché de la réponse suivante
… un optimisme inébranlable conjugué à une paranoïa maladive …

Au jour le jour, cela se traduit par une attention et un soutien total à ses équipes en gardant constamment à l’esprit les échéances de mise en production tout en traquant inlassablement les zones d’ombres et les sujets à risque.

Yapluka
Haut les coeurs !

atipyc
Christophe Leroy

Comme d’habitude, un petit retour sur une lecture,
cette fois-ci d’un billet publié dans InfoQ :
« Ars Magna: The revolution is overdue », posted by Dave West on Aug. 04, 2010
http://www.infoq.com/articles/arsMagna-agile-essay

L’auteur y dresse le constat (classique) du fort taux d’échec des projets informatiques (ex. 31 % des projets sont arrêtés avant le terme prévu). L’idée prévalente ces 60 dernières années a été que le développement informatique est une science (Software Engineering) (SE) et non pas un art (Ars Magna) (AM) (d’autres auteurs utilisent une comparaison différente entre « craft & production assembly » (artisanat & production de masse)).
Dave liste 9 points de divergence conceptuelle et 4 points sur les valeurs :

Concepts :
1- artifact / system
2- deterministic / non-deterministic
3- production / theory
4- mechanical / organic
5- prediction / exploration
6- episodic / continuous
7- self conscious / no-self conscious
8- control / coordination
9- science / art

Valeurs :
1- History
2- Philosophy
3- Liberal Arts
4- Humanity

(Avec ma fibre Agile, je dirai que les points « Art » correspondent plutôt bien avec les valeurs énoncées dans le Manifeste Agile …)
L’auteur raffine ensuite ces différents points de vue pour arriver à la conclusion que les projets informatiques relèvent plus de l’art que de la science.

Sans rentrer dans des considérations philosophiques, je mettrai en garde sur une des grandes faiblesses de la croyance en l’aspect purement scientifique de la gestion de projet. Cela conduit à penser qu’une méthodologie parfaitement huilée est la garantie du succès du projet : que nenni !
La démarche a, en effet, un côté rassurant notamment lors des comités de pilotage mais elle prend parfois un côté surréaliste où l’on confond la pipe et l’image de la pipe …

La méthodologie est nécessaire … l’aspect humain est obligatoire …
La science, oui mais sans art, point de salut …

Salut les artistes !

…
Christophe Leroy

Dans la grande veine du Yin &  Yang (ou du revers de la médaille en version française), j’ai redécouvert récemment deux articles que j’avais mis de côté et qui traitent tous deux du leadership de façon très contradictoire :

Time, March 16, 2009
« Why Bosses Tend to Be Blowhards »
The study: Teams of four are observed as they compete to solve tough math problems
The findings: People are likelier to be perceived as leaders if they offer more answers even if those answers are wrong

Courrier Cadres, février 2010
« Les introvertis font d’excellents patrons »
Revue du livre « The Introverted Leader: Building on Your Quiet Strength », Jennifer Kahnweiler, juin 2009
Ce livre montre que « ce n’est pas parce que vous parlez peu ou moins fort que vos collègues que vous faites de moins bons dirigeants. Au contraire. »
http://www.theintrovertedleader.com/

Pour ma part (et sans avoir consulté le détail des études réalisées dans les deux cas ci-dessus), je suis toujours un peu sceptique sur les études initiales qui ont permis d’apporter des conclusions « scientifiques » sur des questions sociologiques : qu’un « chef » soit un minimum charismatique ne choque pas le sens commun et qu’une personne « discrète » puisse faire un bon leader ne me paraît pas, non plus, être une découverte.
Cependant, l’article de Time flattera le côté presque français du management sur le mode du « chef à grande gueule ». Alors que l’article de Courrier Cadres donnera une vision opposée (ou plutôt complémentaire à mes yeux) du profil du dirigeant.

L’exemple présenté dans l’article de Time me paraît, par contre, intéressant à creuser :
« Lors d’un exercice mathématique, une assertion fausse mais péremptoire et sur le mode de l’autorité sera acceptée par le groupe ». (resterait là-aussi à vérifier que le niveau mathématique des membres du groupe leur permettait de déceler l’erreur). On retrouve les effets classiques de la soumission à l’autorité.
Qui d’entre nous n’a pas connu dans sa gestion de projet le cas du grand chef « je sais tout » imposant son opinion au projet et le conduisant tout droit dans une impasse alors que la majorité de l’équipe avait des doutes mais n’a pas su (pu ? osé ?) les exprimer ? (l’article de Time ose, pour sa part, le conseil suivant : « … if you think your boss is making stupid moves, maybe the best thing you can do is say so. Loudly and frequently. The result could be your getting promoted – or fired »).
Quoiqu’il en soit, que de temps perdu à corriger le tir (alors que l’idée initiale était bien de gagner du temps sur l’hypothèse de l’omniscience d’un gourou).
De façon caricaturale, je présenterai cette approche « Loudership » en management comme le pendant de l’approche « Waterfall » en mode de gestion de projet : çà marche si on suppose tous les paramètres connus, déterminés de façon fiable et maîtrisés dans le temps.

L’article de Courrier Cadres présente une vision différente du manager sur le mode « introverti ». Là aussi, la vision est réductrice car l’utilisation du mot « introverti » est trompeuse. Elle sous-entend, non pas, un manager seul dans sa tour d’ivoire et perdu dans ses propres réflexions mais un manager « modeste » et demandant l’avis de ses équipes, en bref, un manager se basant sur sa « Quiet Strength ». Il eut donc été préférable de traduire « Quiet Strength » non pas par « introverti » mais tout simplement par « Force tranquille » si ce slogan n’avait pas déjà été utilisé par ailleurs … humour à part, ces responsables dits introvertis disposent visiblement d’un certain charisme : les noms cités sont, entre autres, ceux de Bill Gates et Warren Buffet .
Dans ces conditions, on observe des bénéfices tels une ambiance rassurante pour leurs équipes et leurs pairs, une argumentation construite et documentée, …
De façon toujours caricaturale, je rapprocherai cette démarche « introvertie » de l’approche Agile qui met l’accent sur l’itération, l’incrémental et l’équipe pour faire « accoucher » au plus vite les projets.

Bien entendu au moment de la synthèse, je ne pourrai que souligner qu’aucun camp ne détient la vérité (si vérité absolue il y a).
Les circonstances d’un projet pourront exiger une prise de décision arbitraire (cf. « Tout choix est arbitraire ») : dans ces conditions, le minimum attendu de la part du responsable de projet est de préciser le caractère arbitraire de ce choix (ce qui permettra, entre autres, que ce choix ne soit pas élevé au rang de « dogme » à l’avenir).
Dans d’autres circonstances, une décision concertée s’imposera :
la grande difficulté et tout l’art du responsable étant de choisir la bonne approche au bon moment
et, bien sûr, de parvenir à une décision (cf. « Il faut se colleter avec la nécessité »).

Bon, allez, je la ferme …

atipyc pyc pyc …

Christophe Leroy

Un de mes amis (côté Métier) me demandait récemment pourquoi tous les projets dits informatiques (sic) sur lesquels il était impliqué n’en finissaient jamais.

C’est effectivement une bonne question (et, en tout cas, une question récurrente).

Et si la réponse était toute bête ? … pour terminer au plus vite, commençons par la fin !

Afin de transformer cette réponse de bon sens en quelque chose de plus compliqué (mais vendable), appliquons-lui un vernis de consulting mâtiné d’une couche de communication. Pour cela, étendons le concept déjà connu de Test Driven Development (TDD) à l’ensemble du projet et lançons le concept de Test Driven Project (TDP).

Concrètement, cette philosophie se traduit par une volonté de « faire un truc qui marche » et de garder constamment cette mantra tout au long de la vie du projet.
Pour cela, quelques pistes (je suis preneur de toute suggestion) :

• penser, chaque jour du projet, à livrer une solution qui marche le 1er jour de la mise en production
• ne pas demander de spécifications fonctionnelles au Métier mais lui demander de fournir des cas de tests dès le début du projet (ou même avant).
• concevoir les documents de tests comme les futurs documents de formation
• mettre en place de suite une version transverse de la solution
  • on parle bien d’une version minimaliste d’une solution qui marche
  • cette action permettra de soulever (et résoudre) 80% des points critiques transverses
• initier une démarche de démo et feedback Métier sur des prototypes présentés de façon périodique au Métier (une base de 2 semaines est un bon premier choix)

et pour élargir le débat (et sortir de l’aspect commercial du consulting), rendons la parole au philosophe (La Fontaine) qui avait déjà tout dit : « En toute chose, il faut considérer la fin »
(quant à déterminer du Renard et du Bouc qui est lié au Métier qui à l’Informatique, je ne m’y risquerai pas … prudence est mère de sûreté)

… c’est la fin !

cypita

Christophe Leroy