Au Pied Levé - À Main Levée
I-1.1. Développer Au Pied Levé
par , 01/04/2020 à 04h50 (253 Affichages)
■ Développer in situAPL-AML est une monographie fragmentée en plusieurs billets pour des raisons de volume.
Un billet SYNOPSIS et un billet SOMMAIRE agrègent tous les billets du blog via des liens hypertextes.
■ ■ ■ SOMMAIRE DU BILLET ■ ■ ■
- Développer in situ
- Un projet
- Une aventure
- Développer Au Pied Levé
- Une démarche personnelle, individuelle ?
Le concept s’est imposé immédiatement, en réaction à la méthode classique top-down « étude-préalable/cahier-des-charges/analyse/programmation » produisant trop d’applications de gestion en situation d’échec. Un haut responsable métier ira même jusqu’à considérer que son application n’existe pas et refusera par la suite de recevoir les informaticiens.
En cause : le cloisonnement, l’incompréhension de deux mondes, celui des entités métiers et celui des informaticiens. Les deux mondes ne savent échanger qu’entre responsables de même niveau hiérarchique à travers l’incontournable hygiaphone : la feuille d’interview hier, les users-stories aujourd’hui. Leur incompréhension n'est qu'un bête problème de communication que les informaticiens ne savent résoudre que par leur technique. L’utilisateur transmet certes l’information mais en la déformant de multiple façons, en l’exagérant, en l’occultant, en l’inventant.
Développer in situ, c’est enfiler le vêtement de travail de l’utilisateur, celui du responsable de l’entité métier et surtout celui de ses gestionnaires :
« Communiquer, c’est davantage que transmettre des informations. »
CHANGER D’ALTITUDE - Bertrand PICCARD
Ce que nous croyons être un dialogue entre deux individus, n'est en réalité que deux monologues. Le premier a lieu entre nous-même et notre imaginaire et le second entre notre interlocuteur et son propre imaginaire.
Quand on parle à quelqu’un, les mots que l’on prononce correspondent, lorsqu’ils sortent de notre bouche, à une image, une émotion ou une représentation que l’on pense être très claires et univoques dans notre esprit. Du côté de notre interlocuteur, il n’en sera pas de même. Les mots arriveront soit sur un terrain vierge, où ils devront être décodés, puis interprétés, soit sur un terrain familier, où ils seront tout de suite associés à des images, émotions ou représentations personnelles, qui peuvent se révéler différentes des nôtres. À défaut d’expérience commune, notre interlocuteur essayera de construire la situation dans son imagination, mais nous devrons rester conscients du décalage inévitable que cela engendrera.
Une idée ou un ressenti qui passe dans notre conscience sera traduit en mots (première déformation) pour être communiqué à notre vis-à-vis (deuxième déformation). Ce dernier comprendra les mots comme il peut (troisième déformation) pour les retraduire en idées ou ressentis (quatrième déformation) qui seront intégrés en fonction de son propre vécu (cinquième déformation).
Il faut bien comprendre que quelqu’un qui entend nos paroles, il les passe au filtre de ce qu’il est prêt à comprendre, qu’il essaie de les intégrer en fonction de son propre vécu pour ensuite se créer une représentation mentale de ce que l’on a voulu dire.
Des mots, des phrases ont certes été perçus mais leur sens n’a pas été identique pour l’émetteur et le récepteur. D’un côté comme de l’autre, les sources de déformations et de distorsions sont multiples et comme nous négligeons le plus souvent de nous enquérir de ce que l’autre a compris, nous vivons régulièrement dans des mondes parallèles. Ce n’est qu’en cherchant à percevoir ce que l’autre a réellement compris et en comparant les expériences personnelles de chacun face à un même sujet que l’on peut commencer à communiquer. Pas avant !
Dans notre rapport à l’autre, nous devons abandonner l’idée d’une réalité unique et comprendre la communication comme un partage d’expérience et non comme un échange d’informations.
Chacun fabrique l’autre par projection. Il s’en suit un décalage qui peut devenir abyssal. La projection peut être positive ou négative se faire par idéalisation ou par rejet. Dans les deux cas, ne pas en être conscient engendre une bonne partie de nos problèmes relationnels.
En réalité, il importe moins de savoir ce que pense, ce que dit quelqu’un que pourquoi il le pense, il le dit. Les désaccords peuvent faire peur et il est très confortable d’être d’accord, les similitudes rassurent mais ça ne sert à rien. Chacun a de bonnes raisons de dire ce qu’il dit en fonction de son vécu. On s’enrichit mutuellement au contact du vécu de l’autre. Rejeter les divergences, chacun prouvant qu’il a raison et l’autre tort, rend les relations difficiles, voire même inutiles.
Il y a trois règles pour construire une relation :
- Parler de son ressenti…
Lorsque l’on dialogue, nous n’avons pas à juger le comportement de l’autre, la règle d’or consiste à exprimer ce que l’autre provoque en nous, ce que nous ressentons vis-à-vis de son attitude.
- Partager des expériences…
On communique véritablement quand on partage des expériences personnelles, pas quand on transmet des informations.
Si nous n’apprenons rien de nouveau sur l’autre ou sur nous-même dans une discussion, ou que pire encore notre seul but est de persuader l’autre qu’il a tort, nous ne communiquons pas, nous transmettons des informations qui ne peuvent que susciter le rejet de quelqu’un de différend et l’approbation de quelqu’un de similaire.
Une expérience est unique ; elle appartient à celui qui en fait part et à personne d’autre, jusqu’à ce que l’interlocuteur en saisisse le caractère spécifique. Il est donc important pour faire passer notre message d’expliquer simultanément d’où provient notre avis et sur quelle expérience nous nous fondons car soit notre discours devra être décodé puis interprété, soit il sera associé à des images, des émotions ou représentations personnelles qui peuvent se révéler différentes des nôtres.
Les mots, les phrases sont certes perçus mais leur sens n’est pas identique pour l’émetteur et le récepteur. La transmission de notre pensée subit plusieurs déformations :
- Une idée ou un ressenti qui passe dans notre conscience est d’abord traduit en mots,
- Communiqués à notre interlocuteur, ce dernier comprend, filtre les mots comme il peut et les retraduit en idées ou ressentis,
- Il s’en crée pour finir une représentation mentale qu’il intègre en fonction de son propre vécu.
À défaut d’expériences communes, nous essayons de construire la situation dans notre imagination.
- Réaliser qu’il y a autant de réalités différentes que d’individus…
Cela signifie que la plupart des conflits sont aussi vains qu’inutiles.
Comme nous négligeons de nous enquérir de ce que l’autre comprend, nous vivons régulièrement dans des mondes parallèles. Il nous appartient de choisir si nous préférons résister face à des manières différentes de fonctionner ou développer la liberté de découvrir d’autres façons de penser.
CHANGER D’ALTITUDE - Bertrand PICCARD - Octobre 2014
- pour vivre la problématique dans sa réalité,
- pour structurer le métier d’après son mode d’organisation,
- pour découvrir ce que l’utilisateur et ses gestionnaires ne savent pas qu’il savent.
La solution : Dès lors que le développeur et l’utilisateur ont le même objectif, il n’y a pas de raison de ne pas aboutir. La solution, c’est de supprimer les intermédiaires, de se rapprocher le plus possible de l’utilisateur jusqu’à développer dans son entité métier et de s’approprier la problématique de gestion. Les responsabilités ne sont pas diluées, le développeur assume seul son informatisation.
Mais comment s’y prendre ?... s'interrogent le petit oiseau et le petit poisson qui s’aiment d’amour tendre…
■ Un projet
Développer « in situ » c’est un projet à prospecter, à organiser, à construire, et l’administration offre un terrain de jeu idéal. Cela commence par la prospection d’un sujet porteur, d’une problématique de gestion particulière, rassemblant deux critères favorables :
- une situation en difficulté, à l'agonie, une cause complètement désespérée donc potentiellement en recherche de solution,
- et un utilisateur « qui vaut le coup », qui s’investit dans son domaine et semble prêt à jouer le jeu.
Contrairement à ce qui se pratique habituellement, la prise de contact est une initiative du développeur. L’approche prend la forme d’une rencontre opportune et le contact est d’autant plus aisé que le développeur est fonctionnaire avant d’être informaticien.
Après accord tacite, il reste à concrétiser « l’intrusion » dans l’entité métier. Cela peut être immédiat comme demander six mois, un an, voire davantage. L’administration offre un panel de possibilités comme le détachement, la mise à disposition, le concours administratif. L’installation pure et simple dans un service gestionnaire de la même entité administrative n’est pas forcément la démarche la plus simple, ni la plus rapide. Bien qu’il y ait eu accord tacite, l’utilisateur peut mettre un certain temps à lâcher prise, sans doute par peur de l’inconnu. Pour le développeur, ce n’est alors qu’une question de patience ; une problématique en grande difficulté s’enfonce inéluctablement jusqu’à atteindre son point de rupture.
Développer in situ, donc pour l’informaticien, s’extraire du service informatique, c’est se marginaliser au sein de l'entreprise structurée fonctionnellement, c’est générer fatalement des réactions, de la part du responsable de l’informatique, des collègues informaticiens, de la direction, du responsable du service gestionnaire, des gestionnaires.
L’affectation officielle du développeur dans une entité informatique reste toutefois une constante. La raison est double :
- La première raison est financière car une prime informatique dépendant du grade est liée à l’affectation dans une structure informatique. Cette prime est dite « programmeur » pour un grade de catégorie B, et « analyste » pour un grade de catégorie A. La prime n’a rien à voir avec la fonction réelle. Ainsi, il n’existe pas de prime de « chef de projet ». Cette ambiguïté permet à un « programmeur » ou un « analyste » d’exercer la fonction générique de « développeur ».
- La deuxième raison a tout simplement pour objectif de responsabiliser l’entité informatique quant-aux développements réalisés. Développer in situ se fait en toute transparence, ce n’est pas développer sur le tas, hors système, avec des objectifs personnels, faire de la « perruque » comme l’on disait à l’époque.
■ Une aventure
En développant « in situ », le développeur démystifie la création du logiciel, les gestionnaires comprennent très vite qu’il s’investit pour les aider et leur participation lui est toute acquise. Une aventure collective est en train de se construire.
Une URL="https://fr.wikipedia.org/wiki/Force_opérationnelle"]task force[/URL] ou force opérationnelle se constitue de façon informelle. Les gestionnaires qui sont finalement autant de chefs de projet y gagnent un outil performant, fait sur mesure et le développeur y gagne sa liberté, le plaisir de créer, la satisfaction d’être utile, de relever divers challenges.
Pour le développeur, c’est une opportunité unique d’apprendre, d’être confronté à des points de vue différents, à des zones de l’entreprise, à des collègues et à des compétences.
Chaque projet est une aventure à risques avec sa période d’inconfort, son lot de surprises agréables et désagréables. C’est une aventure qui doit être vécue comme telle, dans une atmosphère d’excitation, d’expérimentation et d’urgence.
Cela suppose d’être libre de ses mouvements et dans sa tête, de penser par soi-même, de réfléchir et non de s’appuyer sur des recettes ; cela suppose d’avoir cherché et construit sa propre vérité, d’être autonome, pluridisciplinaire, de s'engager, de prendre des risques, d’adopter une véloce attitude.
Anecdote :
■ Une task force (force opérationnelle)
Il est institué dans l’applicatif un « Générique » qui recense toutes les personnes ayant participé à la réalisation de l’applicatif.
L’application est considérée comme une œuvre de l’équipe ad hoc, constituée :
- du développeur,
- de l’utilisateur responsable de l‘entité métier (maître d’ouvrage),
- du ou des chefs de service,
- des gestionnaires.
Comme pour un film, le Générique cite toutes les personnes ayant participé à l’élaboration de l’œuvre. Avec le temps, la composition de l’équipe évolue, le Générique est une forme de reconnaissance des apports de chacun, et la concrétisation en quelque sorte de l’appropriation de l’applicatif par ses utilisateurs. C’est le moyen d’intéresser, de motiver une nouvelle recrue intégrant l’équipe car il est attendu de sa part qu’elle apporte sa contribution au logiciel.
Le développement APL-AML n’est pas seulement une aventure que pour le développeur. Tous les contributeurs vivent la même aventure exaltante. À chaque nouvelle rentrée, il peut toujours y avoir quelques mutations mais globalement, la façon de travailler fidélise les gestionnaires.
Une gestionnaire a renoncé deux années de suite au bénéfice d’un concours au prétexte qu’elle ne trouverait jamais ailleurs une telle ambiance. Il a fallu beaucoup de persuasion pour qu’elle finisse par accepter une affectation dans une autre administration. Beaucoup d’entre-elles se reçoivent et gardent contact via les réseaux sociaux.
Générique Formation Continue :
Générique Examens-Concours :
■ Développer au pied levé
Classiquement, le point de départ d'un développement pragmatique d'applicatif (Au Pied Levé) est le challenge. Plus le challenge présente de risques, de difficultés, un caractère urgent voire vital, plus il a de chances d'être « accepté ». Accepté par le responsable du service informatique, le chef du service de gestion, les gestionnaires eux-mêmes. Accepté, parce que les raccourcis qu'il implique bousculent quelque peu l'organisation fonctionnelle de l'entreprise et chahute la hiérarchie, laquelle compte tenu de la situation, n'a d'autre alternative que de s'en remettre entièrement, non sans quelque appréhension, à l'informaticien développeur qui devient alors l'homme providentiel.
Ainsi, le responsable informatique doit accepter les risques inhérents à cette démarche, comme budgéter un projet sans garantie tangible de résultat, laisser se poursuivre un développement avec l'incertitude de sa pérennité, admettre l'installation à demeure de l'informaticien développeur dans le service de gestion. De son côté, l'utilisateur, à savoir le responsable de l'entité métier, doit vivre au quotidien la présence de l'intrus qui considère davantage ses gestionnaires que lui-même. Quant aux gestionnaires, leur confiance et leur collaboration sont à priori acquises dans la mesure où ils sont demandeurs. Il suffit d'entretenir cette confiance par une écoute attentive de leurs besoins, une réactivité sans faille, une grande disponibilité, une très grande disponibilité. A ce sujet, l'adhocratie dit ceci :
Après des prémices plus ou moins longs, coordination, recherche d’un budget, contact avec des fournisseurs, installation d’un serveur, installation du développeur dans l’entité métier, etc., la situation généralement critique de la problématique de gestion impose un démarrage immédiat de l’ordre de la semaine, voire moins. Le challenge, c’est le développement au pied levé et à main levée.« La contribution à des équipes ad hoc lorsqu'elle s'avère devoir être très intense ne se limite pas à 40 heures par semaine, mais suppose de travailler autant que nécessaire. Certains utilisent l'expression de "double plein temps" »
Au démarrage, il n’y a rien, juste un serveur, un développeur, des gestionnaires dans les starting-blocks qui attendent de pouvoir utiliser leur application et des milliers de personnes qui s’attendent à être convoquées incessamment. Cela demande d’être capable d’appréhender clairement la problématique métier, de savoir se projeter dans le futur proche, lointain, très lointain et de connaitre son métier, tout simplement. Ha, si !... Cela exige également de s’investir, d’avoir confiance en soi, de savoir prendre des risques.
Personne n’y croit vraiment mais ça marche. Le challenge se vit seul, sans l’expliquer à la hiérarchie arrimée à ses certitudes.
■ Une démarche personnelle, individuelle ?
La démarche est indéniablement personnelle mais pas impérativement individuelle. Le cas s’est présenté de démarrer une informatisation en binôme. L’expérience eut pu être intéressante et répondre à beaucoup de questions mais a tourné court après seulement trois jours. Pas d’explication du co-développeur, il n’est tout simplement pas réapparu le 4ème jour.
Il y a beaucoup d’avantages à développer seul, il n’y a pas de perte de temps en réunions, en coordination ; la réalisation est homogène, riche en synergie. Pas d’étude préalable, pas de cahier des charges, pas de MCD, de MCT… Rien ! Le démarrage est quasi immédiat ; selon le contexte : un jour, trois jours…
Une informatisation au pied levé ne s’envisage semble-t-il que dans un contexte désespéré. Il n’y a pas d’obligation mais quel utilisateur accepterait l’informatisation de son entité métier sans garanties, s’il ne se trouvait pas dans une impasse, sans autre choix que de s’en remettre les yeux fermés au développeur.
Chef d’orchestre sans partition ouverte, l’informaticien providentiel développe in situ et « just in time ». Son challenge (low cost, high speed, high quality) s’inscrit dans une approche basée sur l’investigation in situ, l’intuition et le pragmatisme et non sur la technicité méthodique.
Ce type de développement s’apparente à du prototypage d'application, du prototypage de luxe mais du prototypage qui reste du jetable... Même si ça dure 17 ans. L'idée, ce n'est pas de créer du définitif très beau, très sophistiqué, mais de résoudre une problématique immédiatement, avec des moyens simples et d'aboutir au final à la création d'une documentation à postériori qui fasse office de documentation utilisateur, de support de formation et surtout de cahier des charges pour un développement ultérieur par une méthode classique Top-Down. On n'est plus alors dans l'inconnu (effet tunnel), ni dans l'urgence.
Retours d’expérience :
L’expression « Au pied levé » signifie ne pas avoir le temps de se préparer, ou que quelque chose se fait ou se décide à l'improviste. Cette expression existe depuis le XVème siècle et vient du fait que lorsqu’on a envie d’aller quelque part, on lève d’abord un pied puis l’autre. Si au cours de cette action, quelqu’un nous surprend à l’improviste, sans avoir le temps de nous préparer à sa demande, il nous apercevra le pied levé. A ses débuts, l’expression n’était employée que lorsque l’on s’adressait à quelqu’un au moment où il s’apprêtait à partir, c’est-à-dire lorsqu’il avait le pied levé ! Puis au fur et à mesure, l’expression s’est généralisée à toutes les personnes qui exécutent quelque chose à l’improviste ou sans disposer du temps nécessaire pour préparer ce qu’on lui demande. Au milieu du XVème siècle, l’expression employée était « à pied levé » puis au milieu du XVIème siècle elle est devenue « au pied levé ». I-1. Les règles de conception
► I-1.1. Développer in situ, au pied levé
▼ I-1.2. Développer à main levée
Consulter le profil
Marquer ce blog comme lu
