Vous êtes en pleine mission lorsqu’un responsable côté client vous dit : « Nous avons besoin que ce workflow fonctionne pour nos trois régions, chacune ayant des règles d’approbation différentes, et il faut que la plateforme en garantisse l’application. » Vous pourriez probablement bricoler une solution rapide dans le cadre du déploiement, mais vous savez aussi que le prochain client demandera probablement la même chose.
Cette leçon porte sur la manière d’identifier le moment où une demande client cesse d’être une simple tâche de livraison ponctuelle pour devenir un travail sur le cœur du produit, et sur la nécessité de bien définir ce qui continue de relever de votre responsabilité en tant que Forward Deployed Engineer (FDE). Un FDE est un ingénieur qui déploie des solutions dans l’environnement du client tout en traduisant les besoins de ce dernier en tâches de développement produit et d’ingénierie.
Avant de décider ce que vous allez construire, vous devez déterminer la nature réelle de la demande. S’agit-il de « faire fonctionner la solution pour ce compte d’ici vendredi » ou de constater « qu’il nous manque une fonctionnalité réutilisable et que ce client constitue le premier signal fort » ?
Explorez la différence entre une modification ponctuelle pour un client et une fonctionnalité réutilisable.
Une demande relève de la stratégie produit lorsqu’elle ne concerne plus simplement la configuration d’un client spécifique, mais met en évidence une fonctionnalité manquante du produit. Vous le percevez lorsque le client ne réclame pas un simple résultat, mais une règle que la plateforme elle-même doit prendre en charge.
Prenons un exemple : le client souhaite que des validations spécifiques à certaines régions soient appliquées directement au sein de la plateforme, et non via un tableur, une étape manuelle ou un script personnalisé que seule votre équipe comprend. C’est le signe qu’il demande une fonctionnalité nécessitant une conception produit, un support à long terme et une définition claire de son comportement.
Un moyen rapide de faire la distinction est de se demander ce qui se passera une fois que vous serez parti. Si la solution exige que vous mainteniez une branche personnalisée, un correctif privé ou un comportement spécifique impossible à expliquer sans vos notes, elle bascule dans le domaine du produit, car elle nécessite une interface officielle et une stratégie de support pérenne.
Si une fonctionnalité doit être prise en charge, elle doit être conçue Dès lors qu’un client s’attend à ce qu’une fonctionnalité survive aux mises à jour et à l’arrivée de nouveaux utilisateurs, traitez-la comme un élément du produit, et non comme une astuce de livraison ponctuelle.
Même lorsqu’une demande devrait relever du développement du produit central, c’est à vous de faire avancer la mission. Votre rôle consiste à débloquer la situation du client sans pour autant réécrire discrètement le produit sur le terrain.
Cette responsabilité comporte deux volets.
Premièrement, vous assurez la continuité de la livraison. Vous transformez la demande en une exigence claire, identifiez ce qui est réalisable dans le déploiement actuel et proposez une solution intermédiaire en toute transparence quant à ses limites.
Deuxièmement, vous préservez l’intégrité du produit. Cette intégrité garantit que le produit reste cohérent dans son ensemble, plutôt que de devenir un assemblage de comportements spécifiques à certains comptes qui finissent par entrer en conflit. Concrètement, cela signifie éviter les bifurcations du code (forks), les options cachées utilisées par un seul client et les engagements qui placeraient l’équipe d’ingénierie dans une impasse par la suite.
Dans notre exemple concernant les validations, vous pourriez mettre en place un processus temporaire répondant aux besoins d’audit tout en rassemblant les éléments nécessaires à la création d’une fonctionnalité native. Vous ne refusez pas la demande, vous en gérez simplement la chronologie.
Le problème est que chaque type d’erreur peut, sur le moment, donner l’impression d’une grande réactivité. Les conséquences ne se manifestent que plus tard, généralement lorsque vous travaillez déjà pour un autre client.
Découvrez quelques exemples concrets illustrant comment ces erreurs engendrent des coûts ultérieurs.