Les 5 niveaux de conscience d'un développeur

Posted in coding with tags coding -

On peut juger un développeur sur la compréhension qu’il possède de son métier : 5 niveaux qui détermine bien souvent sa plus value pour une organisation.

Niveau 0 : pisser de code

Il pense que son boulot est de produire des lignes et des lignes et des lignes de code. Généralement peu intéressé par ce qu’il fait, c’est juste un poste qui paye la soupe. Ou alors c’est un boulot temporaire avant de passer chef de projet.

Le développeur du niveau 0 se voit très fréquemment et forme le gros du bataillon des SSII. Chaque fois qu’on le rencontre, on se pince les lêvres pour ne pas lui demander pourquoi il fait ce métier. Mais il faut bien reconnaitre que c’est souvent ce que lui demande son chef de projet…

Niveau 1 : livrer du code

Intéressé par la qualité du code, il pense qu’il doit livrer du code fonctionnel. Il s’intéresse aux Design Patterns, lit des livres sur le développement logiciel, refactore de temps en temps son code pour le rendre plus beau et s’intéresse aux tests.

Celui ci peut se rencontrer dans les groupes de développeurs, dans les soirées consacrés aux codes… Il a souvent la passion de son métier. Il discute longuement de code, et lit régulièrement blogs et livres sur le sujet.

Niveau 2 : livrer un logiciel

Le développeur livre un ensemble de code cohérent, qui possède une structure et fonctionne comme un bloc uni. Il s’intéresse à la conception, à la robustesse, à l’architecture logicielle. Il sait que les tests sont très importants, autant unitaire que fonctionnel, avec une couverture suffisante pour être rassuré quand il modifie des pans entiers du logiciel.

Le niveau 2 est plus rare. Trop souvent, à la question quel est ton métier, un développeur me répond :

Liver du code !

Et non, ton métier est au minimum de livrer un logiciel. Avez vous déja vu un client satisfait d’une livraison d’un dépôt Git ?

Niveau 3 : livrer un produit

Le développeur livre plus qu’un logiciel, il livre un produit. Il s’intéresse donc à la couche système, aux procédures d’installation et de mise à jour, à la reprise sur incident, à la mise en production. Il participe à la documentation utilisateur et se met à la place des admins.

Livrer un produit signifie souvent l’abandon du travail d’intégration pour un travail de conception, bien plus difficile. Il faut réfléchir avant tout à ses problématiques (et non celles que le framework X à résolu pour vous), au développement sur le long terme et donc à l’évolution du produit.

Niveau 4 : livrer de la valeur

Plus qu’un produit, même bien ficellé, le développeur apporte de la valeur. Car le réel objectif est d’améliorer le business du client. Niveau ultime et de loin le plus difficile car il demande de bien comprendre le métier du client en plus de parfaitement maitriser le sein (le développement logiciel).

Constat

Je vous concède que c’est un poil schématique. Une des particularités quand on travaille chez un éditeur logiciel est que le niveau minimum est… 4.

Le niveau 3 est malheureusement rare alors que c’est pourtant le niveau que tout développeur devrait atteindre. Mais il faut bien avouer que le développement logiciel est un métier à la fois très exigeant et nouveau (moins de 40 ans !).

L’autre raison que la plupart des développeurs travaillent en France dans le service, et peu dans le monde de l’édition. Ce qui veut dire bien souvent être en cascade (peu ou prou, même ceux qui disent faire de l’agilité, voir mon article «l’agile est mort») avec un cahier des charges fixe. Il faut une collaboration étroite avec le client pour échanger sur son business et comprendre, au dela des besoins exprimés (qui sont le plus souvent des solutions exprimées et non des besoins), les besoins réels et utiles. Ce qui est rarement le cas en SSII ou la plupart des clients estiment que ce n’est pas votre boulot de remettre en cause leurs besoins (comment voulez vous ensuite que les développeurs se sentent conernés ?).

Je raconte souvent cette anectode : En tant qu’éditeur, il nous a fallu pratiquement un an entre la première version commerciale et la version crédible. Car nous avons trop misé sur des clients et partenaires incapables d’exprimer clairement des besoins, ce qui a affecté notre vision du produit. Nous avons donc sorti une version apportant peu de valeur. C’est en rencontrant des partenaires spécialisés et connaissant bien le métier que nous avons pu rectifier le tir et mieux comprendre ce dont ils avaient besoin.

C’est évidemment de notre responsabilité, et je ne rejète en aucun cas la faute sur des tierces personnes. Mais cela m’a bien un peu éloigné de la sainte croyance qu’il faut écouter le client. Comme le disait Henry Ford :

Si j’avais demandé à mes clients ce qu’ils voulaient, ils m’auraient réclamé un meilleur cheval

Au passage, c’est en rencontrant des partenaires et clients Suisses, Belges, Allemands… (et non plus Français) que cela s’est amélioré :).

Conclusion

Etre éditeur logiciel, c’est être capable de livrer un produit robuste et fiable rapidement. Il faut maitriser le développement logiciel de bout en bout : le codage bien sûr mais aussi l’infrastructure, la conception, le packaging, le déploiement, la production, la documentation, le support… Il faut être foncièrement multi-compétences et vouloir s’améliorer dans tous ces domaines. Mais ce qui rend le travail si intéressant et dur, c’est que vous devez aussi maitriser votre coeur de métier. Là ou les niveaux 0 à 3 se focalisent uniquement sur la technique (qu’elle soit système, réseau, algorithmie, ihm, gestion de projet…)

C’est pour cette raison que les livreurs de code, même excellents, ne sont bons au final, qu’a produire de la dette technique car plus intéressés par la beauté d’un code que de trouver une finalité utile à celle ci.

Coder dans le cadre professionnel, ce n’est pas se faire plaisir avec le pattern X ou la techno Y, c’est avant comprendre un métier et apporter le maximum de valeur. Même si cela peut sembler inintéressant au premier abord, livrer un produit fonctionnel, fiable et robuste, utilisé par des clients heureux est le summum de la satisfaction, bien loin d’un algo lisible et performant. C’est ce qui fait tout le charme du métier d’éditeur.

Mais ne me faites pas dire ce que je n’ai pas dit, il faut aussi se faire plaisir en tant que développeur :).

Written by Sébastien Douche
comments powered by Disqus
Older article
L'Agile est mort