Dans la frénésie actuelle de création de SaaS, c'est étonnant de constater combien de lignes de codes inutiles sont écrites.
Probablement des millions.
C'est dommage parce que les développeurs coutent cher, en raison de la complexité technique du métier qu'ils exercent avec talent et panache (et brio).
Et paradoxalement, on écrit assez facilement du code qui ne sert à rien sans s'en rendre compte. Ça vient un peu tout seul.
J'observe 2 causes fréquentes :
- On n'a pas assez réfléchi à ce qu'on veut faire.
L'idée reste vague, et l'étape de shaping (cf lien à la fin) est passée à la trappe. Du coup, on code trop tôt un truc provisoire, que l'on jette à la poubelle plus tard.
- On n'a pas bien qualifié l'intérêt de la fonctionnalité pour l'utilisateur.
On veut coder un truc génial que personne n'utilisera. C'est pire.
Car ce code-là ne va pas à la poubelle. Il alourdit inutilement le projet, ou ajoute une contrainte qui va plomber les évolutions suivantes.
Mais alors c'est quoi une fonctionnalité qui a de l'intérêt pour l'utilisateur ?
Pour moi, si elle n'entre pas dans l'une des trois catégories suivantes, il faut lever les mains du clavier.
Catégorie #1 : présenter des informations pour décider de quelque chose
C'est facile de coder des écrans avec pleins de trucs affichés.
On brûle d'envie de montrer à l'utilisateur combien notre outil est riche et complet. On lui en met plein la vue sur toutes les données qu'on a sous la main.
Et alors ?
Pourquoi lui afficher tout ça ?
Je propose un test simple : CHAQUE donnée affichée sur l'écran doit lui servir à décider de quelque chose.
Parce qu'afficher des trucs juste pour le plaisir de les voir, ce n'est pas un logiciel.
C'est un livre.
Ou une télé.
La valeur d'une information délivrée à un lecteur, c'est ce qu'elle lui permet de décider.
Pour un site de e-commerce, vous présentez la photo d'un pull-over pour que l'utilisateur décide de l'acheter (ou de partager la photo, ou de la commenter, etc...)
Pas pour l'entendre s'extasier "il est vraiment joli ce pull-over".
Si une information ne contribue pas à une action, inutile de l'afficher. Et donc de la coder.
Catégorie #2 : les commandes
Un code est aussi utile s'il implémente une commande.
Non, je ne parle pas de commander de votre barbecue électrique pliable chez Amazon.
Je parle d'une action décidée par l'utilisateur et qui va modifier l'état du système. Il y a un avant et un après la commande.
Par exemple, une inscription. Avant, l'utilisateur n'existe pas dans la base de données. Après, il y est.
La commande est implémentée par une fonction. Elle prend en entrée l'état initial du système, et calcule en sortie un nouvel état.
C'est dans ce code que se loge la logique métier. L'intérêt de votre SaaS. Ce qu'on peut faire avec. C'est du code utile.
Mais ce n'est pas tout. La 3e catégorie est la plus délaissée alors qu'elle constitue un puissant moyen de différenciation.
Catégorie #3 : les événements
Probablement l'endroit ou se loge "l'intelligence" du code : celle de déclencher des actions automatiques après le traitement d'une commande.
Une sorte de commande, non pas initiée par l'utilisateur, mais déduite de ce qu'il vient de faire.
Observez les SaaS à succès : ils recourent massivement à ce concept.
A la lecture de votre adresse (catégorie #1), vous décidez de la mettre à jour (#2). C'est peut être que vous venez de déménager et qu'il y a quelque chose d'opportun à proposer à ce moment : par exemple un lien d'affiliation vers un fournisseurs de gaz bio.
Autre exemple : vous venez de prendre en photo un paysage de bord de mer et vous le postez sur un réseau social (#2) : c'est le moment de notifier (#3) vos abonnés / amis de l'apparition de cette photo pour qu'ils la voient (#1) en étant incités à mettre un like (#2).
Ici aussi, un événement modifie l'état du système, mais sans demande directe de l'utilisateur. On interprète son intention et on en déduit une nouvelle commande.
A la fin, on dispose donc d'un état modifié du système.
Et qu'en fait on ?
On l'affiche à l'utilisateur pour qu'il comprenne ce qui a changé, et lui donner l'opportunité de prendre de nouvelles décisions.
C'est un cycle.
Alors prenez une ligne au hasard dans votre code qui est spécifique à votre SaaS (je ne parle pas de la glue technique pour que ça tourne).
Pouvez-vous la classer dans l'une de ces 3 catégories ?
Non ?
Supprimez-la.
Références :
- Le "shaping", ou comment décrire mieux que des mots sans dessiner les écrans au pixel près : https://basecamp.com/shapeup/webbook
