Une culture de la résolution de problèmes

Tout est public dans l’open-source : le code, les bugs, les demandes, la discussion. Tout le monde peut s’inviter — ce qui est une force seulement si la conversation est disciplinée, et un désastre au ralenti sinon. Cette page est la discipline. Ce n’est pas de l’étiquette : chaque règle ici existe parce que sa violation a un coût mesurable en travail perdu, et le protocole de signalement des bugs comme le protocole de conception sont bâtis dessus.

Pour le contexte, lisez The designer and the drilling machine  et Design by committee will not save FLOSS .

La discussion existe pour aboutir à des décisions

Le volume d’information auquel chacun fait face dépasse déjà ce que les humains peuvent traiter. Les fils sans fin et les conversations non régulées nuisent activement à la communication : ils diluent l’information importante et épuisent le lecteur. La discussion sert uniquement à atteindre une compréhension commune et à en tirer des décisions actionnables. Tout le reste est de la conversation informelle — bienvenue, mais sur les canaux de chat, en dehors du processus de résolution de problèmes.

Qu’est-ce qu’un problème ?

Une photographie a un cycle de vie, du déclenchement de l’obturateur jusqu’au moment où l’image finale est tirée, archivée ou publiée. Les problèmes sont tout ce qui rend ce travail plus long, plus compliqué ou moins fiable qu’il ne devrait l’être. Un problème est quelque chose qui vous empêche d’accomplir votre travail.

« Ce que ça devrait être » est borné par ce qui est possible, et « possible » veut dire trois choses à la fois : ça peut être réalisé tout court ; ça peut l’être avec les ressources actuellement disponibles ; et ça peut être maintenu dans le futur avec ces mêmes ressources. La troisième condition est la plus oubliée, parce qu’elle vit dans un futur lointain et flou — et c’est celle qui tue les projets. L’industrie est pleine de technologies meilleures abandonnées parce que leur coût de maintenance était trop élevé.

Définissez les problèmes par le but, pas par le remède

Les utilisateurs sont mal placés pour définir leurs propres problèmes — ce n’est pas une faute personnelle, c’est un fait structurel : vous êtes trop près de votre problème pour en voir la forme, et vous ne voyez que l’interface, sans aucune vue de ce qui est câblé derrière. La façon naturelle de demander est donc « ajoutez un bouton qui fait ceci », « faites tel graphique », « modifiez légèrement telle chose existante ». Ces définitions par l’interface promeuvent toujours des solutions sans généralité qui ajoutent de la complexité, parce que penser en éléments graphiques court-circuite la pensée abstraite — et l’abstraction est la seule façon de simplifier les affaires complexes.

Énoncez le but à la place :

• bien : « je veux que mon image ait l’air plus X ou moins Y », « j’ai besoin d’exporter des images pour Z », « je me retrouve à refaire W tout le temps » ;
• mal : « X est cassé » (que faisiez-vous ?), « Y devrait être comme le logiciel Z » (mesuré à la portée de quelqu’un d’autre), « je n’aime pas W » (quelqu’un d’autre l’aime — le goût n’est pas actionnable), « j’ai besoin que cet outil, conçu pour A, fasse aussi B et C ».

Le problème que vous voyez est généralement le bout d’une branche. Concentrez-vous sur le bout, et vous manquez la tige et la racine ; trouvez la racine, et la solution sort plus simple, plus générale, et corrige souvent d’autres problèmes de bouts de branches au passage. Se concentrer sur les bouts de branches produit des rustines contextuelles, et les rustines contextuelles sont la façon dont un logiciel pourrit. Une bonne définition de problème est celle qui aide à trouver la racine — c’est pourquoi elle nomme le but, jamais l’implémentation.

Restez sur le problème

L’erreur numéro un est de suggérer une solution en même temps que la définition du problème, en espérant aider. C’est l’inverse qui se produit : cela biaise le processus dès le premier message, en faveur de la technologie fétiche du premier qui a parlé. Les humains sont paresseux — comme ils doivent l’être —, donc n’importe quelle solution à moitié cuite déjà sur la table aura toujours l’air meilleure que de rester assis plus longtemps avec le problème. La rigueur prend un temps incompressible ; le brusquer coûte plus de temps plus tard, quand la solution sous-optimale et tout ce qui a été construit dessus devront être refaits. Pendant la définition du problème, pas de solutions. Il y a une étape pour elles (le protocole de conception), et elle vient en second.

Contextualisez le problème

La conception et l’ingénierie ne résolvent pas des problèmes techniques — idée reçue courante. Elles résolvent des problèmes de personnes, avec de la technologie. Il n’y a donc pas de solution avant de savoir qui a le problème. Le contexte utile comprend :

• quel genre de photographie vous faites et comment (mariage → gros volumes traités par lots ; art → peu d’images, réglées finement une par une) ;
• votre aisance avec les ordinateurs — elle calibre la réponse, elle ne disqualifie jamais la question ;
• la version du logiciel et son origine ;
• le système d’exploitation (nom, version, pilotes graphiques) ;
• le matériel, en particulier la marque et la génération du GPU.

Trop de contexte dilue ; trop peu laisse des questions ouvertes. C’est réellement difficile à doser — penchez vers l’exhaustivité pour les faits techniques, et vers la brièveté pour tout le reste.

Un fil, un sujet

Pour le lecteur, pour la gestion du projet, et pour le moteur de recherche qui servira la prochaine personne avec le même problème : chaque fil, signalement ou demande porte exactement un sujet. Ouvrez de nouveaux fils pour de nouveaux sujets.

Les compromis ne sont pas des solutions

Un compromis est un arrangement perdant-perdant : des conflits résolus en se rejoignant à mi-chemin dans les pertes. Vous voulez le cinéma, votre partenaire veut le restaurant ; le compromis est un demi-repas et un demi-film, et une mauvaise soirée garantie pour les deux. Enquêtez plutôt sur les motifs : le restaurant, c’était ne pas cuisiner et ne pas faire la vaisselle ; le cinéma, c’était décompresser — un plat à emporter et un film à la maison remplissent les deux buts en entier, et personne n’a rien compromis.

Chaque fois qu’un compromis semble nécessaire, c’est généralement que les buts racines n’ont jamais été explorés — un processus de conception arrêté trop tôt, à la pointe de l’iceberg. Dans ce projet, « faisons les deux moitiés » et « faisons-en une option » sont lus comme des symptômes, pas comme des solutions : la discussion repart à la racine.

Travailler vers une solution

Une fois le problème défini, cadré et contextualisé, les solutions s’explorent sous le protocole de conception — la spécification d’abord, les prototypes ensuite, la validation en dernier. Concevoir est une compétence comme une autre dans ce projet : ceux qui l’ont démontrée portent la décision, et quiconque veut l’apprendre est bienvenu pour commencer — avec l’apprentissage que toute compétence exige.