Le "Minimum Viable Product" a besoin du "Minimum Viable Support"

En tant que fan de fitness, “Moves” était mon app favorite pour iPhone. Le nombre de pas, la distance et le nombre de calories brûlées étaient enregistrés automatiquement de telle sorte que je pouvais combiner idéalement mes activités quotidiennes avec mes activités sportives. Je ne peux malheureusement qu’en parler au passé car l’app plante au démarrage depuis environ trois mises à jour. Des recherches sur Google n’ont pas pu m’aider et mon e-mail aux développeurs est resté sans réponse. Le “produit utile (viable)” est devenu inutile en raison de l’absence d’un “Minimum Viable Support” et je l’ai effacé le cœur lourd.

Dans le nouveau monde du développement incrémentiel et flexible de produits, il reste ainsi indispensable de réfléchir outre au MVP également au “Minimum Viable Service” et donc nécessairement au “Minimum Viable Support”.

Les évolutions technologiques et méthodologiques qui transforment actuellement substantiellement le secteur des services sont brièvement représentées dans le graphique suivant :

L’idée d’un produit minimum viable est de fournir au client une solution de base valable le plus rapidement possible pour que les développeurs puissent s’apercevoir comment l’utilisateur utilise le produit et dans quelle direction il voit l’évolution de celui-ci. Nous avons besoin pour ce faire d’un service de support de base correspondant qui doit générer le moins de coûts possible car un MVP ne génère que de faibles rendements mais peut fortement évoluer. Des marges réduites avec des volumes élevés indiquent toutefois qu’il faut, au niveau du support, éviter toute intervention manuelle car leur augmentation devient rapidement onéreuse et rogne immédiatement les marges.

C’est la raison pour laquelle les Self-Service et Predictive Analytics doivent être intégrés dès le développement d’un produit minimum viable. L’observation du comportement du client génère des données qui servent également à l’évaluation et au développement du besoin (automatisé) en support.

Cela signifie donc que les outils d’assistance doivent être conçus et pouvoir être adaptés de manière incrémentielle. S’il est nécessaire d’installer préalablement une plate-forme sur-site extrêmement complexe, cela génère des coûts d’opportunité en raison des obligations générées par les licences et qui étouffent rapidement l’innovation et la flexibilité espérées.

La solution : Software as a Service ou Open Source Cloud

Seules deux approches doivent être prises en compte : une solution Software-as-a-Service avec un modèle de souscription dynamique ou une solution Open Source venant du cloud. Dans le cas de la solution SaaS, on obtient généralement déjà de nombreuses fonctionnalités mais l’on est jamais totalement libre dans le choix des packs de souscription, ce qui entraîne un risque quant aux coûts d’opportunités liés au “shelfware” (fonctionnalité payée mais non utilisée). Un savoir-faire technique concernant les produits sélectionnés est indispensable pour le choix des produits Open Source. Ce n’est qu’ici que l’on dispose d’un contrôle total sur le développement incrémentiel des capacités (automatisées) de support qui se déroule de manière synchronisée avec le développement du produit.

Les approches service flexible et gestion du support présentées ici ne s’appliquent plus uniquement au domaine des applications et du web mais s’immiscent également dans le domaine de l’informatique d’entreprise. Avec le remplacement des applications propriétaires monolithiques par un mélange de modules internes et externes de solutions et de services, les prestations d’assistance internes doivent également devenir plus souples et être automatisées.