Cet article est le deuxième d’une série de 3 articles.

  1. La première visualisation de notre système de collecte : Entre créativité et veille technique
  2. Pourquoi la connaissance métier est primordiale
  3. Être à l’écoute des besoins utilisateurs

On entend parfois qu’un développeur n’a pas forcément besoin de s’intéresser aux côtés purement métier de son application, qu’il lui suffit de lire les specs et de trouver des solutions techniques, qu’il peut passer d’un secteur à l’autre et que son métier sera toujours le même.

Je pense que la connaissance métier est plus qu’un atout pour le développeur, qu’elle est une nécessité. Dans cet article, je vais tenter de défendre cette idée en revenant sur une étape de notre aventure: Le premier indicateur de succès développé pour monitorer la collecte de factures.

Pourquoi la connaissance métier est primordiale

Échec de l’indicateur de succès

Comme on l’a vu dans l’article précédent, afin de monitorer notre système de collecte de factures, on a d’abord développé une heatmap. Malheureusement, on a rapidement fait face à des problèmes de scalabilté. On a alors développé des indicateurs numériques. Le premier indicateur fut un taux de succès.

La première chose à faire lorsqu’on développe un indicateur de succès, c’est de définir clairement ce qu’on entend par succès. Ça peut paraitre trivial, mais la qualité de la définition va avoir un impact important sur la qualité de l’indicateur. De notre côté, on est d’abord parti sur une définition assez générique:

Il y a succès lorsqu’il n’y a pas d’erreur.

Ainsi, pour une tâche donnée, si la dernière exécution s’était déroulée sans erreur, c’était un succès, sinon, c’était un échec.

Pour vous donner un petite idée, le taux de succès lié à l’ensemble de tâches représenté par la heatmap ci-dessous aurait été de 100%, car il n’y a eu aucune erreur lors des dernières exécutions.

Fort taux de succès: En vert, une exécution sans erreur et sans téléchargement, en rouge, avec erreur et sans téléchargement, en bleu, avec ou sans erreur mais avec téléchargement.

Dans cet autre exemple, une tâche parmi les 4 s’est déroulée sans erreur lors de sa dernière exécution, le taux de succès aurait été de 25%

Faible taux de succès: En vert, une exécution sans erreur et sans téléchargement, en rouge, avec erreur et sans téléchargement, en bleu, avec ou sans erreur mais avec téléchargement.

Malheureusement, on s’est assez vite aperçu qu’il y avait un décalage entre ce que nous disait l’indicateur et ce que nous remontait les utilisateurs. La remarque typique était la suivante:

Je ne comprends pas, la collecte a un taux de succès phénoménal, mais j’ai aucune donnée depuis des mois.

Et parfois pire, on se surprenait nous-mêmes à avouer:

Oui, l’indicateur de succès est au plus bas, mais en réalité tout fonctionne très bien !

Notre indicateur de succès ne reflétait en rien la qualité de notre collecte, où est-ce que nous nous étions trompés ?

Le métier c’est (aussi) mon métier

Il semble assez courant que les développeurs négligent le métier au détriment de la technique. On voit d’ailleurs sur ce sondage de stackoverflow que les développeurs interrogés accordent plus d’importance aux technologies qu’au secteur pour lequel ils travaillent.

Sans le vouloir, c’est exactement ce qu’on a fait. On a déclaré que la collecte était un succès à partir du moment où le code fonctionnait sans erreur: cette définition du succès n’est pas fausse en soi, mais elle est purement technique.

Le but de la collecte n’est pas de fonctionner sans erreur, mais de collecter des données. C’est un succès lorsque la quantité et la qualité des données collectées sont proches de celles attendues.

Alors évidemment c’est plus compliqué. Car premièrement, on doit être capable d’estimer la quantité de données qu’on est censé récupérer, et deuxièmement on doit déterminer des standards de qualité. Et pour cela, il n’y a pas 36 alternatives, il faut s’intéresser de près aux données que l’on collecte. Dans notre cas, il faut s’intéresser aux factures: aux différents types de factures, aux rythmes auxquels elles sont délivrées et aux informations plus ou moins détaillées qu’elles contiennent.

Il ne s’agit pas de devenir expert métier, mais de monter suffisament en compétence pour acquérir une certaine indépendance vis à vis d’eux. Chez Deepki, après avoir accepté le fait qu’il était aussi de la responsabilité des développeurs de s’intéresser au métier de l’énergie, et dans notre cas précis, à la facturation de l’énergie, les choses sont allées beaucoup plus vite: on s’est mis à envisager le succès sous plusieurs angles et à développer un panel d’indicateurs complémentaires. Certains indicateurs sont techniques, d’autres métiers, mais derrière chaque indicateur, putôt qu’un concept vague, il y a une règle qui a du sens et qu’on est capable d’expliquer simplement.

Changer de métier sans changer de métier

On l’a vu dans l’article précédent, la partie technique d’une application peut évoluer très vite, et les indicateurs d’hier ne sont pas forcément adaptés à la réalité d’aujourd’hui. Qu’en est-il de la partie métier ?

Avec le temps, est-il possible que le profil des utilisateurs change et que leurs besoins se modifient, rendant ainsi obsolètes des indicateurs qui furent longtemps efficaces ? Et dès lors, comment garder le contrôle sur un produit qui évolue de manière imprévue ?

Affaire à suivre…