GuiGui's Show

Je m'interroge…

J'ai aucun doute sur le fait qu'il faut présenter / publier / communiquer sur les ratés.
J'ai aucun doute sur le fait qu'on apprend aussi (mais pas que) en se foirant.

Ma question : comment différencier un raté définitif (le problème n'admet pas de solution sauf à retirer certaines contraintes et on sait expliquer cette absence de solution), d'un raté provisoire (manque de temps, de compétences, de finances, de ressources, etc.) ?

Exemples :

• Il y a un an, je n'avais pas idée de comment enrichir ma carte OSM des câbles sous-marins d'Internet avec des informations déjà disponible dans le jeu de données que j'utilise ;
  
  
• Il y a quelques mois, je ne savais pas configurer un service web précis pour qu'il traite un grand nombre d'utilisateurs simultanés puis je suis entré en contact par hasard avec un informaticien qui bosse à temps plein sur la thèmatique dont fait partie ce logiciel (donc il a creusé le fonctionnement interne, les xxxx combinaisons de paramètres, etc.) qui m'a donné la solution ;

Dans ces deux exemples, le problème n'était donc pas insoluble. Pourtant, je le croyais.

Parfois, surtout dans le deuxième exemple, il n'est pas possible d'identifier un sens au problème ni de le poser différemment. C'est ce service web précis qu'on veut fournir à nos utilisateurs car c'est le seul à avoir les fonctionnalités désirées, car tout le monde l'a adopté et l'on ne veut pas dépayser nos utilisateurs, etc. Il est de notoriété publique que la techno derrière ce produit est lente, mais tu dois lui faire encaisser masse d'utilisateurs simultanés.

La recherche de sens est parfois vaine ou entravée. Quel sens cela a de faire ce que j'ai écrit au paragraphe précédent ? Percevoir un salaire. Pourquoi ? Pour bouffer. Oui, tu pourrais poser différemment le problème de ton approvisionnement alimentaire, mais bon… Par entrave, je pense à des actions liées à des émotions genre tu fais ça pour telle personne car tu tiens à elle.

Demander du temps supplémentaire pour travailler le sujet du service web précis qui doit traiter un grand nombre d'utilisateurs simultanés, ça aurait pu le faire… si j'avais eu des idées sur comment m'y prendre pour avancer, ce qui revient à questionner mes compétences, la disponibilité des connaissances, etc. Il y a donc un cumul des obstacles. Donc plein de combinaisons à tester. Difficile d'avoir une vision complète sur cela. Ça limite la conclusion à tirer d'un échec (a-t-on identifié et expliqué toutes les causes d'un échec ?).

Quand bien même il est possible de poser un problème différemment, est-ce sain de le faire ? Parce qu'au final, quand on fera un retour d'expérience, on dira qu'on a choisi la solution X au lieu de la Y car il y avait un problème. Super info ! Si l'on a un peu creusé, on dira que le problème était plutôt de tel côté (réseau, serveur applicatif, BDD, etc.), mais sans plus. Notre échec apprendra rien à celui qui nous écoutera jacter. Ni à nous-même.

Inversement, chercher à tout prix à comprendre / résoudre un problème n'apportera pas grand chose non plus genre "je sais résoudre tel bug très précis quand il se produit dans tel contexte très précis, sur telle architecture très précise, etc", ouais, super, je suis le seul au monde à avoir ce contexte précis !

Mettre en œuvre une solution technique, organisationnelle ou procédurale moins démesurée / ambitieuse pour quand même tenir l'objectif recherché peut être casse-gueule : solution incomplète qui exigera des corrections ultérieures qui sont susceptibles de coûter plus cher.

• Genre changer une procédure ou un bout d'organigramme, ça nécessite de changer des habitudes, ce qui prend des années (conduite du changement) ;
  
  
• Genre les opérations de maintenance régulières d'une solution technique foireuse, ça peut être chronophage (au bout du compte, la solution technique abandonnée car on ne parvenait pas à la mettre en œuvre aurait été moins pénible) ;
  
  
• Migrer vers une autre solution technique, ça peut aussi prendre des années en fonction du périmètre, du volume de données, du nombre d'interconnexions avec d'autres bouts du système d'informations, etc.