Philo SI

On ne sait pas transmettre nos idées par duplication de cerveau à cerveau. C'est bien embêtant.

On a donc du avoir recours à différentes techniques qui nous permettent de communiquer les idées. On sait bien que nous communiquons par divers moyens, voix, gestes, expression, écrits… On connaît moins qu'il existe des niveaux d'échange différents selon les différentes idées que l'on cherche à communiquer.
En fait on peut reconnaître 4 niveaux de communication qui correspondent à 4 niveaux d'idées.

• Au premier niveau le message permet de faire passer les informations sur soi "au secours!".
• Au second niveau le message apporte une information simple à la communauté "Attention!".
  
  Ces 2 niveaux sont partagés par les animaux et sans doute également par les plantes si on en croit les études les plus récentes.
  Les circuits qui permettent de gérer cette information sont donc basiques, primaires, "hardcodé" dirait-on dans notre monde informatique. Ils sont très rapides et peu sujet à l'erreur.
• Au troisième niveau notre message porte sur la description. C'est un messages complexe adressé à la communauté "la nourriture est abondante dans le champs de l'autre côté de la rivière". C'est un niveau essentiellement humain mais on peut penser que certains animaux le partagent (je pense à l'abeille).
• Au quatrième niveau notre message porte sur l'argumentation. Niveau exclusivement humain qui met en œuvre notre matière cérébrale particulière, le neocortex, ça fonctionne moins vite mais ça a son efficacité.

On est assez fiers de notre capacité d'abstraction. Les animaux savent bâtir un modèle mental de leur environnement, très peu savent le transmettre à leurs congénères, mais aucun ne sait argumenter avec ces derniers sur l'opportunité d'aller chercher sa nourriture plutôt ici que là.

Nous si. On excelle dans ces 2 disciplines que sont la description et l'argumentation.
Enfin, on excelle… on sait communiquer des messages à ces niveaux.

Mais comme on ne sait pas répliquer nos pensées dans le cerveau de notre interlocuteur on utilise différents modèles. Pour que ces modèles soient efficaces, il faut une parfaite adéquation de toutes les parties quand au code utilisé. Si j'articule un son, par exemple "chaise", il faut que ce son évoque dans l'esprit de mon interlocuteur la même idée que j'ai présentement à l'esprit.

Avec mon fils qui vit dans la même maison que moi, il y a des chance que nos idées soient assez semblables. Avec d'autres ça dépend. On a de bonnes chances d'avoir nos idées en phase sur le nombre de pieds je pense, bois ou métal là nos idées pourraient ne pas se ressembler.

Modéliser lorsqu'il 's'agit d'éléments de notre environnement correspond toujours à généraliser. Et généraliser c'est perdre de l'information. Toujours.

Il existe une option.

Je peux t'apporter ma chaise. J'activerai alors la communication sur le niveau 2 "regarde!" et au niveau 3 je dirais juste un mot "chaise".
Quand on en parlera de chaise, je sais que l'idée que tu formeras est assez proche de celle que je forme moi-même.

Mais tu ne pourras quand même pas t'assurer qu'en en parlant à quelqu'un d'autre le message passe aussi clairement.

Read more...

Je remercie Jean de m'avoir par son article décidé à enfin écrire ce billet.

Si je me souviens bien c'était en 2003, sur un projet important de refonte et d'uniformisation des systèmes Gestion comptable et Gestion commerciale dans un grand groupe pétrolier.
Un groupe d'utilisateurs référents avait été constitué pour la circonstance. Ils venaient des 6 coins de l'hexagone pour représenter les besoins de leur filiale. Ils avaient été rassemblés à Paris "La Défense" pour des ateliers de rédaction de spécification qui devaient durer un an.


Les chefs de projets informatiques pestaient devant la difficulté à faire comprendre aux référents utilisateurs qu'ils devaient travailler en "mode projet" (en fait tout décomposer en niveaux d'abstractions et en fonctionnalités selon les attentes des informaticiens). Ces super utilisateurs étaient pour la plupart issus de directions opérationnelles et leur environnement était plutôt le "mode production" .

Avant ça, je n'avais jamais réalisé pour ma part que je travaillais en "mode projet".

S'il est difficile à quelqu'un de basculer son comportement vers le "mode projet", c'est sans doute que ce dernier ne doit pas être trés naturel. Si faire des projets est un penchant humain, la façon d'aborder ceux-ci est loin d'être conforme à la méthode conçue dans le monde de l' informatique traditionnelle. J'ai d'ailleurs tendance à penser qu'il y a autant de méthodes que d'individus.

Le "mode projet" dont il est question dans le système d'information (mais pas que) est un comportement imposé, codifié, qui démarre par une étude théorique et qui termine par un tampon d'acceptation. Le chemin est balisé, il y a des passages obligés... bref ce mode de comportement doit obligatoirement être appris (et il n'est jamais totalement maîtrisé).

On peut parler longtemps du "mode projet" , en préciser le plan, la durée, les intervenants, le plan qualité, les risques… sans jamais définir quel est l'objet du projet. Le projet est un objet manipulable en soi.

On peut d'ailleurs définir quelques caractéristiques de cet objet : Il a une limite dans le temps, il est borné par un début et une fin, c'est une sorte de trou noir, l'information n'en sort pas naturellement…
Cet objet se manipule à l'aide de méthodes (il y en a plein) qui donnent les outils pour gérer le temps du projet, extraire l'information sélectionnée pour la diffusion…etc.

Ces méthodes ont toutes le même ADN de base , on y trouve inscrit les facteur temps (début-fin), information (validée), tâche(spécialisée), responsable(coupable), qualité (projet)... etc

Lorsqu'on aborde l'Agilité, on parle encore de projet. Méthode, pratique, nouveau type d'organisation….de projet.

J'accepte et j'utilise ce vocable principalement pour des raisons pratiques.

Pourtant, la mutation informatique vers l'Agilité (si elle réussit) remisera le "mode projet" au musée comme elle a remisé le langage procédural ou la base de données hierarchique (mais l'impact en sera sans doute bien plus grand).

Le mode de production Agile possède un génôme très différent de l'ADN des méthodes de projet. On y trouve des traces de temps (cycle), information(émulsion), taches(auto-affectées), responsable (collectif), qualité (produit) … etc.

Cet animal n'est pas équipé pour répondre au mode projet. Il est équipé pour attaquer la production logicielle comme celle d'un produit manufacturé. Un processus continu, une chaine de production qui adresse simplement des produits différents des assemblages matériels, des produits spécifiques au monde des théories (le monde 3 de Popper).

Cet ADN Agile est constitué de molécules "lean" adaptées au cycle de production matériel, ainsi que de molécules nouvelles, adaptées à l'injection de créativité tout au long du processus de production. Cet ADN évoluera avec la sélection naturelle mais jamais dans le sens du "mode projet".

Pour autant le projet n'est pas mort, il n'a pas vocation à disparaître. Il devrait même se renforcer, mais au niveau qui est le sien, celui de l'entreprise, celui des métiers.
Le projet c'est celui de l'entreprise, aborder un nouveau marché, simplifier la gestion comptable, réduire les coûts des opérations d'audit….

Le besoin de logiciel dans ces projets reviendra à lancer un nouveau besoin dans la chaine de production. Le lancement est standard, simple, rapide. La chaîne livre tôt et régulièrement du produit fini.
Bien sur, la façon de faire des projets va évoluer puisqu'elle était fortement empreinte des règles imposées par le "mode projet" du système d'information.

Cela va permettre d'adresser les besoins des projets métiers de façon plus rapide, plus intensive, de mettre en concurrence des solutions et de sélectionner ensuite les plus pertinentes, de répartir les budgets sur davantage de projets et de les pousser plus ou moins loin plus ou moins vite … et d'avoir la puissance des utilisateurs (ceux qui connaissent le micro management des informations) dans la boucle.

Mais ceci n'est pas encore écrit. Ou bien ça l'est ? Seulement si la fin des dinosaures était inéluctables...

Read more...

Je l'avoue, je suis un peu démuni face à toutes les théories qui cherchent à donner des modèles chiffrés à l'agilité et à Scrum en particulier.
Je regarde avec intérêt toutes les expériences. Je note avec intérêt le fait qu'un ratio ait pu être tiré d'un certain nombre de sprints sur ce projet ci ou que l'on ait constaté la véracité d'une théorie sur le coût de correction des bugs sur ce projet là.
Mais je suis mitigé sur les généralisations qui s'en suivent souvent implicitement.

C'est une tendance naturelle de l'humain de vouloir rationaliser et trouver des lois générales à partir d'expériences (ce que l'on appelle en philosophie l'induction). Je me demande s'il n'est pas imprudent de généraliser si rapidement à partir d'éléments factuels (les projets, les équipes, le degré de pratique) si différents, d'ailleurs sans les considérer tous ensembles.
Et tant qu'a chercher des modèles, je crois qu'il faudrait intégrer dans notre réflexion ceux de notre temps et ré-interroger les vérités dogmatiques pré-agile.

Il y a un terme utilisé en écologie qui est absent de l'entreprise et qu'il faudrait je pense intégrer dans notre réflexion : "écosystème"

La notion d'écosystème concerne une communauté d'êtres vivants ainsi que les conditions de son environnement. Il est caractérisé par ses interactions dans ses aspects biotiques et abiotiques (Source wikipedia).
La composante biotique se rapporte à l'intéraction du vivant sur le vivant (compétition, prédation, symbiose...), la composante abiotique se rapporte à l'action du non-vivant sur le vivant (sol, climat,...).

Les modèles écologiques ne se traduisent pas simplement. Enfin pas toujours. Je veux dire par là qu'ils peuvent être temporairement simples et prédictifs et puis basculer dans quelque chose d'imprévisible. Ce n'est pas que l'équation soit complexe, au contraire elle peut-être trés simple. Mais elle est fortement liée aux conditions initiales de l'expérience. Ce type de modèles est appelé chaotique.

Un bon exemple est donné par la fonction logistique de Robert May . Le diagramme de bifurcation ci-dessous montre les variations possibles dans la production du vivant en fonction de son environnement(aspects biotiques et abiotiques confondus). La population est exprimée en % de la capacité maximale du territoire considéré.
On peut lire en ordonnée (nommée "x") le % de population animale de l'année prochaine (calculée à partir d'une population actuelle de 25%) en tenant compte du facteur correctif ("r") qui matérialise les conditions particulières propre à l'environnement.

Lorsque le coefficient traduisant le facteur environnemental est inférieur à 3,5 les choses sont assez simples et prévisibles. Par la suite ça se gâte sérieusement et au dela de 3,57 toute infime modification, que ce soit du coefficient "r" ou bien de la population initiale, affiche un résultat qu'on ne pouvait prévoir.

Si l'on veut apporter un regard neuf sur notre travail, il peut-être intéressant d'aborder la réflexion sous cet aspect. D'un point de vue du projet informatique, la partie environnementale (non vivante) se rapporterait aux éléments tangibles (locaux de l'entreprise mais aussi équipement du projet - serveur d'intégration par exemple). La partie biotique serait composée des relations entre membres de l'équipe, hiérarchie, client ..etc

L'écosystème du projet est sensible à ces 2 composantes.

Un bon environnement de travail, un équipement de haut niveau, est facteur de facilité de travail mais aussi de motivation. Cette partie est assez simple à identifier en général, les actions d'amélioration sont souvent facilement quantifiables, cette partie est plutôt rationnelle.

Le fait qu'une équipe s'entende bien ou pas, qu'un "prédateur" se manifeste, qu'un "leader" soit en vacances, que la confiance soit là ou qu'elle n'y soit plus,... sont des éléments irrationnels. Il n'y a pas de loi simple qui puisse de l'une de ces causes quantifier un effet.
On saurait sans doute dire dans quel sens l'un de ces éléments fait avancer le curseur "r" mais on ne sait pas dire de combien (et quid s'il y a plus de 2 élèments?). Difficile d'identifier l'impact. Pire, on pourrait croire que l'impact est faible alors qu'il vient de pousser le curseur en zone rouge...vers les 3,56 disons.

Je ne sais pas qu'elle est la fonction qui permettra de modéliser la production agile. Mais il me semble clair qu'elle sera plus proche de celle de May que de la droite euclidienne ou de la courbe en cloche de notre ami Gauss.

C'est pourquoi le rôle du Scrum Master n'est pas de mettre en pratique des lois tirées sur les nombres mais d'observer et d'être attentif en permanence aux conditions de l'écosystème. Il remet toujours en question son jugement, il n'intervient pas en dogmatique mais dose ses interventions en fonction de l'état (biotique / abiotique) de l'environnement.

C'est une fonction davantage sensible que rationnelle.

Read more...

L'une des choses dont l'homme a besoin, c'est de maîtriser son environnement. Il n'y a rien de plus désagréable que d'avoir le sentiment de ne pas avoir de prise sur ce qui se passe.

C'est vrai dans les projets informatiques comme ailleurs. Ou en est-on ? qu'est-ce qui reste à faire ? est-ce qu'on va dépasser, de combien ?

Voila, la messe est dite : combien ?

L'homme saisit son environnement au moyen de concepts. La plupart des concepts sont acquis au moyen de l'expérience. C'est en voyant, entendant, touchant les choses que l'on arrive à assembler des connaissances et à en concevoir des règles que l'on réutilise pour appréhender d'autres choses. Une voiture ça roule, un vélo ça roule, une poussette ça roule... s'il y a des roues il est vraisemblable que ça roule.

Dans les cas qui touchent à notre rapport à notre environnement nous travaillons par utilisation des concepts. Beaucoup d'interprétations sont discutées autour de ces notions qui sont forts intéressantes. On s'aperçoit alors que les choses ne sont pas simples. Tout ou presque est contestable. La notion de cause et d'effet par exemple, qui semble généralement admise est habilement discutée par les sceptiques (une chose est la cause d'une autre, qu'est-ce qui le prouve ? une chose est observée en compagnie d'une autre , je constate que ce phénomène ce répète et de là j'en déduit que la première est à l'origine de la seconde - mais c'est juste un abus de ma part).

Les concepts qui nous sont nécessaire à connaître notre environnement ne sont donc pas exacts ou tout au moins n'ont pas une acceptation commune à l'ensemble de l'espèce.

Il en va autrement des concepts créés par l'homme. Puisqu'ils n'ont pas d'existence en dehors de la raison humaine il ne sont pas soumis à interprétation. Ces concepts sont regroupés sous le nom de "mathématiques".
Le père de ces concepts est le nombre. Les nombres sont rassurants. Ils suivent des règles rigoureuses, on ajoute 3 on retire 3 on retrouve le nombre du début. Même quand ça ne marche pas ça peut quand même marcher. J'ai 5 j'ajoute 7 je trouve 12, NON c'est faux !
- C'est faux ?
- Oui c'est faux !
- Ah ah facile tu est informaticien tu compte en hexadécimal. Le résultat est donc égal à "C" (oui, C a aussi le droit d'être un nombre).

La raison humaine à besoin de tranquillité (elle a inventé Dieu, l'inconditionné, pour être tranquille avec les concepts de causes et d'effet). Avec les mathématiques elle est tranquille: tout à une cause, les même causes produisent les mêmes effets, tout est maîtrisé.

Il n'est pas étonnant alors que face à nos problèmes métaphysiques de gestion de projet la tentation soit grande de se raccrocher à des choses qui nous stabilisent : combien ?

A partir de chiffres je suis en terrain connu. La somme des jours sur les taches est égale à la somme du temps prévu pour chacun ? Parfait. Ah, mais attention, le nombre de jours des mois considérés, compte tenu du pont du 11, n'est pas égal aux nombres précédents. Il faut ajuster quelque chose: réduisons la tache d'analyse OK ? J'ajoute, je compare au prévu... c'est trop ? Je soustrait, on va dire que ces jours passés sur un nouveau logiciel ne font pas partie du projet, on va les passer en formation. Je maîtrise.

Aborder le projet par des chiffres est bien entendu nécessaire à un certain moment, au bout du compte on va bien devoir compter l'argent et calculer une rentabilité. Mais j'observe souvent que l'énergie passée à ce jeu dépasse le nécessaire. Il y a une sorte de confusion entre la maîtrise des chiffres et la maîtrise du projet.
Ce qui est fait (en substance, pas en jours) comme ce qui reste à faire (en substance aussi) ne sont jamais que des concepts posés sur des informations tirés de l'expérience et soumis aux aléas des lois de la nature. On ne peut espérer qu'ils puissent se soumettre à notre volonté.

Read more...