En tant que CTO en agence, il y a une phrase que je suis amené à répèter régulièrement :
Si les clients savaient faire ce que l’on fait, on n’aurait plus de boulot.
Au départ, je disais ça en parlant du fait même de comprendre certains aspects du code. Mais au fil du temps je me suis rendu compte que cette phrase a un impact bien plus large.
J’ai toujours été très en phase avec la vision de Jeff Atwood sur le fait que le travail des développeur·euse·s n’est pas d’écrire du code, mais plutôt de trouver une solution à un problème. Le code est juste la façon de faire avec laquelle nous sommes les plus à l’aise.
Mais il y a tout un tas d’autres éléments avec lesquels nous sommes familiers : les outils informatiques en règle générale, les méthodes de gestion de projet type “agile”, les bonnes façons de signaler un incident ou un bug …
D’ailleurs qu’est ce qu’un bug ?
Je pourrais caricaturer en disant que du côté de la technique, on considère trop souvent que s’il n’y a pas d’erreur/exception déclenchée, ça n’est pas un bug. En revanche, pour beaucoup d’utilisateur·rice·s, un bug c’est simplement un comportement qui n’est pas celui attendu … encore faut-il que le comportement attendu soit (correctement) spécifié …
La spécification … encore un concept qui peut être sujet à interprétation, avec son lot d’informations implicites évidentes, mais pas pour tout le monde.
Vous l’aurez compris, on a tous·tes un background professionnel et personnel qui fait que l’on voit les choses différemment des autres.
Quand on est tenté de s’énerver contre une personne qui a remonté un bug sans préciser dans quelles conditions, sans indiquer s’il est reproductible, quand il a eu lieu, etc … , il est souvent plus productif d’essayer de se mette dans la peau de cette personne, et de comprendre pourquoi le ticket a été remonté de cette façon. Cet exercice permet un meilleur accompagnement, et souvent une résolution plus efficace.
Si nous avons cette logique de détailler un incident correctement, de faire la recette complète d’une application avant de déployer une évolution, de découper notre travail en taches qui peuvent être validées unitairement, c’est parce que notre métier et surtout notre expérience nous ont conduit à comprendre l’importance de ces travaux.
Ça n’est pas le cas de tout le monde, et c’est aussi notre métier d’accompagner ceux qui ne raisonnent pas de façon technique. Parce que s’ils et elles raisonnaient comme nous, on n’aurait plus de boulot (au mieux, on serait des singes qui codent)
Ça n’était pas prévu quand j’ai commencé à l’écrire, mais cet article se prête parfaitement à un shameless plug, puisqu’avec Novaway nous avons récemment lancé une offre CTO as a service qui part d’un constat similaire, et vise justement les créateurs·rices de startups qui ressentent le besoin d’un véritable accompagnement dans ce monde un peu particulier, et pas simplement une réalisation technique sur cahier des charges.