Problems.md 2.2KB
Le problème
Eventually, I settled on a list of questions I would ask myself for each problem as it arose. I found that asking these questions, in order, helped me make the best decision possible:
- Is this really a problem?
- Does the problem need to be solved?
- Does the problem need to be solved now?
- Does the problem need to be solved by me?
- Is there a simpler problem I can solve instead?
Each question is designed to reveal something about the problem that allows you to go to the next step, or if you’re lucky, just avoid the problem altogether.
C’est le principal fléau de notre industrie : tenter de résoudre des problèmes là où il n’y a pas de besoin. Le solutionnisme technologique ne devrait être que la dernière option mais cela serait mauvais pour le business. Alors on met des paillettes pour faire passer la pilule et encaisser le chèque en fin de mois.
Vous connaissez le fameux « Je vous écris une longue lettre parce que je n’ai pas le temps d’en écrire une courte » de Blaise Pascal, il se trouve que cela s’applique aussi à l’élaboration d’un produit. Les solutions frugales coûtent parfois autant (si ce n’est plus !) que les usines à gaz. Cela prend du temps de comprendre une problématique, cela prend du temps d’échanger avec des utilisateur·ice·s, cela prend du temps de déterminer quelles sont les fonctionnalités qui ne sont pas/plus utiles. Cela prend du temps de produire des choses im·pertinentes.
En contrepartie, elles permettent d’économiser sur le long terme en réduisant la maintenance, le périmètre de support et l’exploitation du produit. En se focalisant sur la pertinence, on conserve une application à échelle humaine. Autant dans l’usage que dans la conception.
Mon contentement est grand lorsque je suis surpris par la résilience du code auquel je contribue. J’ai soudain l’impression d’avoir pas trop mal fait les choses. C’est assez rare pour être célébré comme il se doit.