Bonjour à toutes et à tous,
Une question m’a été posée récemment : Comment vendre / facturer un produit Agile ?
A l’initialialisation avec des clients pilote ?
Une fois commercialisable ?
J’ai pensé au forfait annuel mais j’aurais aimé avoir votre avis / expérience.
La personne qui m’a challengé sur le sujet à suggérer un recurrent à chaque product goal livré en production.
Qu’en pensez-vous ?
En vous remerciant par avance pour votre éclairage
Cordialement
Isabelle
Bonjour Isabelle,
Ce n’est pas bien ce que je vais faire :
Est-ce Frédéric Leguédois, la personne qui t’a défié ?
Car cela ressemble à une de ses pratiques qu’il partage lors de ces conférences.
Bonjour Alexandre
J’aimerais bien pouvoir lol
La personne qui m’a challengé est un professeur associé du CNAM.
Je suis un cours de conduite de projet en FOAD pour valider un diplôme d’ingénieur SI sur le tard en cours du soir ^^
Dans ce cadre, je dois fournir les éléments de lancement d’un produit Agile de mon xp pro.
J’étais product owner sur le dit produit mais je n’ai pas gérer le financement et la commercialisation.
D’où ma question.
Intuitivement, je dirais qu’hormis le cas spécifique des clients pilote, une fois commercialisé, le financement et la facturation n’ont pas de raison d’etre différents car produit agile. Le forfait annuel avec options me semble viable.
Pour les clients pilotes, une réduction sur le forfait me semblait pertinente.
La facturation au product goal livré me semble dangereuse en créant de la pression sur la Scrum Team.
Cordialement
Isabelle
J’ai fait le rapprochement avec un abonnement, mais sans la condition d’un product goal livré soit le déclencheur d’un payement.
Concrètement
Avec un abonnement sans engagement, à la semaine.
C’est le principe d’un investissement.
Glossaire
Pour éviter toute confusion.Le client, c’est celui qui va vendre le produit.
Les experts, ce sont ceux qui réalisent le produit.
Les utilisateurs, ce sont ceux qui utilisent le produit.
Une ligne de code n’a aucune valeur, c’est son utilisation et son évolution qui en a.
Je passe le relai, je ne suis pas d’une grande aide pour y répondre.
N’ayant aucune expérience sur le sujet, j’ai juste reformulé les propos de Frédéric Leguédois, lors de ces 2 conférences.
Bonsoir Alexandre
Je pense qu’effectivement en remettant les bons mots au centre de ma question, la réponse émerge. 
En tant que Scrum Team de la R&D, le Client est l’éditeur lui-même.
L’éditeur, lui, vend à ses clients du service qui repose sur le produit mais pas le produit (éditeur Cloud).
Les clients de l’éditeur sont les utilisateurs du produit.
Le service est facturé sous forme d’abonnements.
La facturation du service est décorellée de celle du produit ou du moins n’est pas la préoccupation directe de la Scrum Team.
Le produit est effectivement financé par l’éditeur sur le principe de l’investissement.
L’éditeur évalue à un jalon fixe s’il continue d’injecter de l’argent pour de l’amélioration continue.
Le coût récurrent du développement produit pour l’éditeur correspond aux salaires de l’équipe Scrum Agile, la maintenance des infrastructures utilisées, les coûts relatifs à la logistique de l’équipe (ordinateurs, licences…).
A lui de décider de sa politique commerciale de vente du service pour rentrer dans ses frais.
La préoccupation de l’équipe Scrum Agile est de produire des fonctionnalités de valeur pour l’éditeur dans le but qu’il puisse continuer de vendre son service et/ou de mieux le vendre.
C’est pour cela que parmi les parties prenantes avoir l’éditeur et certains utilisateurs pilotes de son service est précieux pour l’évaluation de la valeur.
En tout cas, un grand merci pour ce recentrage
Isabelle
Prenons de la hauteur.
Si j’ai bien compris, dans ce contexte, l’équipe Agile (les experts) réalise alors
un « logiciel à la demande ».
J’aurais tendance à dire que ça le devrait, par simple instinct de survie. Pas de facturation, pas de fonds. Pas de fonds, pas de palais. Pas de palais, pas de palais.
Et cette partie là contredit justement le précédent point.
Bonsoir Alexandre
Je n’ai pas été dans le détail de l’organisation mais nous ne sommes pas dans du On Demand.
J’ai revu la vidéo et cela va dans ce sens.
Notre client, l’éditeur, celui qui paye, est notre sponsor. Il fait partie des parties prenantes à ce titre.
Néanmoins, nous avons aussi dans nos parties prenantes, des utilisateurs pilotes (clients de l’éditeur) qui vont tester les increments et faire leurs feedbacks sur lesquels va s’appuyer la démarche produit.
De plus, l’editeur est en réalité plus que sponsor.
Ses operationnels sont aussi utilisateurs comme pour paramétrer le produit par exemple. Le sponsor est également son propre client.
La démarche produit est bien présente et l’équipe Scrum est bien autonome.
En espérant avoir apporté l’éclairage nécessaire
Isabelle
Bonsoir Samuel,
Je me suis mal exprimée dans la 2eme citation en voulant inclure la question du sponsor.
Savoir comment ce dernier commercialise n’est pas la préoccupation de l’équipe, je pense neanmoins sain de savoir pourquoi l’équipe est financée.
De plus, cela ne retire rien au fait que la démarche produit doit s’appuyer sur les feedbacks des utilisateurs du produit (les clients de l’éditeur mais aussi les opérationnels de l’éditeur qui utilisent le produit).
Ce qui est donc bien le cas ici ! 
En espérant avoir éclairci mon propos
Isabelle
Il y a des moments où cela fait plaisir de se tromper, en voilà un. C’est le meilleur des apprentissages.
Bonjour,
La question du professeur du CNAM semble ambiguë
Dans le cadre de ton projet, on est sur un financement interne, c’est à dire que le DAF va écrire une ligne budgétaire d’investissement pour le développement du logiciel. Cette ligne répondra au budget négocié par le DSI et correspondra très probablement au coût annuel du fonctionnement de votre Scrum team. C’est un fonctionnement très classique.
Cependant si l’objet est de vendre un logiciel pour un client externe (type ESN) là on est pas pareil et on commandera/facturera le plus souvent un lot de sprints correspondant à la livraison de n Incréments de valeur tendant vers un product goal. Le client continuera d’acheter tant que son plafond budgétaire et/ou sa pleine et entière satisfaction d’usage n’est pas atteinte
Bonjour,
Je vais tenter de répondre à la question même si je n’ai jamais travaillé sur ce type de sujet.
Pour moi il y a 2 grand types de contrat :
En gros on sera sur, soit :
Entre les 2 on va trouver plein d’ajustement possible. Par exemple « un engagement de résultat » peut être sur un périmètre ou de la valeur.
Pour un produit Agile, on va chercher la satisfaction client et l’adaptabilité pour bien gérer les incertitudes. Pour ça on sera plus sur un type de contrat « stop ou encore » comme @Alexandre_Quercia le mentionnait plus haut. On assure le « moyen » qui est l’équipe agile, cette équipe peut ainsi se gérer elle même.
Bonsoir Nicolas et Jonathan,
Merci pour vos éclairages complémentaires !
Je pense désormais avoir une meilleure idée des differents modèles économiques possibles !
Quant à l’ambigüité de la question initiale, elle est je pense voulue pour que je creuse la question et que j’affine ma compréhension de ce sujet
Un grand merci en tout cas à tous ceux qui ont pris le temps de me répondre !
Isabelle
Ce sujet a été automatiquement fermé après 2 jours. Aucune réponse n’est permise dorénavant.