Je suis en pleine réflexion ces temps-ci quant au travail fourni par deux apprentis que j’encadre. Ils sont de niveau bac+2, et j’ai fais pour ma part un stage à ce niveau, donc je peux faire un parallèle entre eux et moi. Et quelque chose me frappe: Ils sont seuls au monde. Quand ils développaient, ils ont oublié qu’il existait des gens autour d’eux, des gens avec qui ils doivent travailler, des gens à qui il faut vendre leur produit et des gens qui doivent utiliser leur produit et à qui il faut assurer un support.
De plus, dans une très petite société (moins de 10), un développeur doit dépasser son contexte. Il doit pouvoir s’adapter à chaque situation, et celle ci peut passer du tout au tout à chaque moment de la journée de travail. Les développeurs l’oublient. Comme ils restent dans leur bulle, ils oublient que d’autres gens vont utiliser ce qu’ils produient. Ces développeurs produisent leur code à leur image, lisent une spec, la code, au mieux la teste, mais oublient tout simplement tout le reste.
⇀ Ils oublient leurs collègues développeurs, en décidant de ne pas respecter les conventions de codage, les règles de nommage, les principes de base, de documenter leur code, de le commenter;
⇀ Ils abandonnent l’ingénieur système, qui met en production leur application, en ne discutant pas avec eux aux moyens de remonter les problèmes (logs), en ne testant pas préalablement les package générés, en développant sur leur système en oubliant la configuration des systèmes en prod, en ne documentant pas les fichiers de configuration, les variables, les comportements attendus en cas de problème;
⇀ Ils ne facilitent pas la vie de la QA, en ne leur fournissant pas les moyens d’exploiter avec satisfaction l’application produite à des fins de tests: En faisant une application inutilisable, la QA prendra le moins de temps possible à la valider, et au final le produit ne sera pas testé. C’est au développeur de définir avec lui les moyens de tests, outils, jeux de données prèts à être utilisés;
⇀ Ils oublient de vendre leur application. Qui n’a jamais été la « victime » de l’effet démo ? Personne. Et la faute à qui ? Une coupure réseau pendant une démo d’une appli sur le net, certes, ça arrive. Mais la plupart du temps, c’est juste la faute du développeur, qui est resté dans sa propre idée de l’utilisation du soft. Il a juste oublié d’imaginer donc de jouer un simple test fonctionnel;
⇀ Et au final, et pour moi le pire, ils ignorent totalement le client final. Et là je me demande à quoi ils servent si ils ne réfléchissent pas un seul instant à cet utilisateur qui va devoir utiliser l’outil qu’ils produisent pour eux au quotidien. Je ne parle pas juste que de l’ergonomie générale de l’application qu’ils auront oublié, du manuel d’utilisation qu’ils n’auront pas rédigé, mais des tests de leur application qu’ils ne prennent même pas la peine de faire (je ne parle pas des tests unitaires, fonctionnels qu’ils sont censés faire !), du bâclage de la correction des bugs, des petits détails qui rendent utilisables le logiciel en question… toutes ces choses qui en font un outil formidable.
Alors, je n’ai qu’un conseil: Regardez autour de vous. Vous n’êtes pas seuls. Vous êtes entourés de gens surement compétants, surement formidables, de clients pressés d’utiliser vos produits (et au final de vous nourrir, pensez-y), alors ne les oubliez pas. Ils sont là, allez leur parler, communiquez, échangez. Pour moi, dans monde idéal, avant de la vendre, le développeur devrait faire tester à plusieurs personnes de sa société plus longtemps qu’un simple test leur application. Ca peut suffire de faire d’un tool qui passerait durement pour un prototype à un outil prêt à mettre en production.
0 Comments.