Contrat Agile… Attention vos clients ne sont pas dupes

C’est le problème des forums et des échanges mode texte (et encore, là c’est resté cordial).
Mieux vaut avoir ce genre d’échanges autour d’un café :slight_smile:

C’est parce que c’est resté cordial que c’est intéressant, l’émulsion s’est faîte, et c’est parce qu’un certain nombre d’entre nous sont passionnés, et son indépendant pour vivre (de leur) passion que les débats sont forcements intenses.

Retour dans le sujet :
C’est dur de faire un forfait, et d’estimer le temps lorsque tu ne maîtrise pas le sujet, et mon soucis c’est que j’aime la nouveauté, les nouveautés, travailler sur plein de choses différentes et peu connues, ce qui fait que je n’ai pas de process que je connais (c’est sûr que je sais comment faire un CMS ou un site de vente, mais quel intérêt de recoder ça…)
Après avoir « fais des sites » pendant longtemps, maintenant je m’oriente vers les sites (logiciels) métiers, où on trouve un couplage fort avec le métier du client (actuellement je suis dans XFT pour du tourisme) et quand je fais un truc nouveau j’ai une partie d’inconnue.

Je ne pense pas être fais pour être trop spécialisé et donc je suis mal à l’aise dans les cadres trop balisés où il faut être capable de dire, « dans X semaines/mois, j’aurais fais ça ».
Sans se projetter et s’engager, dur de bosser au forfait.

Et je suis 100% à l’aise avec une obligation de moyens, mais très très mal à l’aise avec l’obligation de résultats, tellement l’interprétation du « résultat » me paraît soumise à subjectivité.

1 « J'aime »

J’aimerai ajouter qu’ici (dans ce fil) on traite l’agilité comme une démarche de vente, mais c’est avant tout une philosophie de codage.
Je n’ai pas choisis de m’orienter vers les méthodes agiles pour vendre, ou réduire un risque quelconque, j’ai regardé, lu dessus et je me suis dit, voilà la philosophie de codage qui va me permettre d’être bien, et d’être libre de faire ce qui doit être fait, comme ça doit être fait pour produire le meilleur.
Un des points qui m’a séduit le plus, c’est d’intégrer l’amélioration continue au cœur de l’activité.

1 « J'aime »

Dis-moi, juste une petite question, tu travailles pour quelle boîte ?

Ton analyse est vraiment claire, et je comprends mieux tes problématiques ! En fait, si je comprends bien, le dev spécifique n’est pas vraiment le problème, mais c’est plutôt l’intégration au SI de la boîte qui en est un, et qui doit être bien ficelé dans un contrat.

Il est clair que quand on travaille pour des sociétés plus petites, on n’a pas vraiment ce genre de problématiques, dans le sens où le SI peut être quasiment totalement externalisé avec les google apps par exemple, et l’intégration à celui-ci peut se faire via oauth de façon simple et légère.

Je ne peux pas donner de noms de client sur un forum, mais je peux donner les secteurs et CA:

  • Industrie principalement, et services
  • CA annuel compris entre 10M€ et 50M€

Sinon oui, la priorité est l’intégration. Mais ça peut concerner une appli spécifiquement pour le client (mais c’est rare, ce sont les plus grosses boites qui le font).

Mais bon, pour partir complètement ailleurs…
Les PME et Grosses PME vont devenir des cibles de plus en plus compliqués à atteindre.
Les gros cabinets (type big 4 avec grosse partie conseil SI) créés des filiales orientées 100% PME.
J’ai discuté avec le DG d’un de ces cabinets pour PME issue du big 4… ça va cogner sec, ils vont tués le marché (avec les comptables en 1ère ligne de mire, les SI arrivent ensuite).
Et j’ai l’impression que les grosses SSII commencent à faire pareil…

Ca va être dur pour les dev et le conseil qui souhaitent se diriger vers cette cible.
La PME c’est l’eldorado de l’info.
Donc je pense à la réorientation professionnelle :slight_smile:

Bah écoute, si tu cherches une réorientation, et que tu aimes un peu le dev, n’hésite pas à venir nous voir au meetup ruby :slight_smile: on sera ravis de t’accueillir !

J’aime beaucoup trop l’AMOA pour quitter ce domaine, mais je te remercie pour cette proposition

A méditer… surtout la dernière phrase

Billet écrit par le créateur de la société: + de 4M€ de CA/an avec une progression de plus de 20% chaque année depuis quelques années.

1 « J'aime »

J’arrive tard :slight_smile:

Vous semblez tous prendre partie autour du binôme régie/forfait, en posant le curseur différemment entre les deux selon vos expériences et sensibilités.

Il y a à mon avis une troisième alternative : l’approche produit.

Il existe des boites de dev (et des freelances) qui, fassent au dilemme récurrent du régie/forfait, choisissent finalement de se spécialiser dans un ou plusieurs types de projets (les soft de gestion de devis, ou de gestion des appros, ou encore les RH, etc…). Certaines font ce choix dès le début.

La relation n’est alors plus du type « dites nous ce dont vous avez besoin et on vous le fait en [forfait|régie] », mais « on connait votre problème, on y répond déjà, regardez donc ce superbe produit que je peux vous installer dès demain moyennant [je regarde ma grille de prix] ».

My 2 cents. :slight_smile:

2 « J'aime »

Effectivement il y a cette approche qui est une approche par la standardisation.

Ca fonctionne bien sur des produits qui supplantent des tâches (ou actions) à peu de valeurs ajoutées selon la chaine de valeur de Porter.
Quoique la multiplication de ce type d’outils pose des problèmes en termes de Workfow, d’industrialisation des processus ou de business intelligence (pb de datapumping pour stats et suivi d’activité).

Sur les services à fortes valeurs ajoutées (levier de performance, coeur de métier ou tout simplement les services portant bcp de VA à l’entreprise), ce sont les process entreprise qui font toute la différence et la standardisation ne permet pas ceci.

Il y a donc l’alternative « approche processus » qui englobe produit et service (on n’en a pas parlé non plus)
=> Outil intégrant les standards de base mais entièrement paramétrable (comme par Ex: ERP, PLM, SCM, CRM, SIRH, etc.)
Mais bon là je pars sur les piliers fondamentaux d’un SI à forte valeur ajoutée, c’est un autre sujet.

1 « J'aime »

C’est effectivement un choix important à réaliser pour des devs, c’est d’ailleurs le choix que j’affectionne le plus car on créé de la valeur.
Mais on est plus du tout dans de la prestation de service pure, on est plus dans du logiciel (ou progiciel) avec éventuellement un peu de presta de service pour l’adapter aux clients.

Donc le thème du sujet ne correspond pas, par contre tu peux recréer un sujet qui serait plus : quels sont les avantages et incovéniens des business models suivants pour un Dev : presta de service au forfat, presta de service en régie ou créer un produit en mode saas ou …

Et même… Une des approches recommandée pour faire un produit dont les gens ont besoin, c’est commencer par faire de la presta, la boucle est bouclée :wink:

C’est un des fameux mantra du Y-combinator : « do things that don’t scale » => http://paulgraham.com/ds.html

Identifier un besoin et un marché, faire de la presta en régie pour un client en gardant les droits sur le code, quitte à bosser gratuitement.
Quand on a un outil dont le client est content, allez voir le client N°2 pour lui vendre.

1 « J'aime »

Faire supporter les couts liés à la courbe d’apprentissage et la phase de dév à son client pour faire son propre produit???

Si tu pars dans l’optique de développer ton propre produit au sein d’une structure:

  • Tu lui expliques les grandes lignes de ton projet, ou au moins pourquoi tu lui proposes ce deal
  • Tu ne le factures pas le temps passé
  • Tu lui offres le produit, même s’il lui est bénéfique parce que lui aussi aura passé du temps dans ce développement en tant que PO et te servira de référent.

Sinon ou est le service orienté vers le client (et non vers le presta, c’est à dire soi-même), la relation de confiance et l’éthique la dedans?

Ca me choque carrément de lire ça… vision à géométrie variable que celle du service client et de la confiance.

PS: et en plus ce n’est pas légal
Si je me souvient bien, lorsque tu es contractualisé pour un dev, il y a un transfert de propriété intellectuelle automatique au commanditaire (un truc dans le genre… j’ai pas le texte en tête)

Si tu pars dans l’optique de développer ton propre produit au sein d’une structure:

  • Tu lui expliques les grandes lignes de ton projet, ou au moins pourquoi tu lui proposes ce deal
  • Tu ne le factures pas le temps passé
  • Tu lui offres le produit, même s’il lui est bénéfique parce que lui aussi aura passé du temps dans ce développement en tant que PO et te servira de référent.

C’est exactement ça (Je pense qu’on s’était mal compris du coup)

Vu le contexte de la conversation je comprends que mon dernier message prêtait à confusion, on n’est plus du tout dans la logique de réponse à un appel d’offre. La c’est toi qui fait la démarche de proposer quelque chose d’utile à une boite. La logique derrière c’est de se dire que le meilleur product owner c’est le client et pas toi, c’est juste une approche pour trouver ce product owner :

Tu as une idée de produit, plutôt que de de foncer sur du dev et essayer de le vendre une fois que le produit est fait, tu prends l’initiative de contacter un client potentiel, tu lui expliques ton produit, si il est intéressé tu lui développes une version sur mesure.
Tu valides ton produit en s’assurant qu’il répond au besoin de ce client, tu gardes les droits sur le code et tu commences à faire du chiffre en le vendant à d’autres clients du même domaine.

Le client gagne un outil pour lequel il n’a pas payé et qui lui rend service, et toi gagnes une validation que ton produit repond à un vrai besoin.
C’est très morale et très éthique.

1 « J'aime »

C’est une des méthodes appliquées par les éditeurs pour étoffer leur offre de produit, à côté du rachat d’offre existantes et de l’embauche de compétences métier.

Je conçois qu’on soit un peu HS par rapport au débat initial sur la vente de presta en régie ou forfait, mais mon idée était de dire qu’il arrive aussi qu’on vende de la presta avec un produit à la clef, avec un donc troisième type de contrat autre que la régie ou le forfait.

Il m’est souvent arrivé de faire payer le client, et ça passe très bien si on joue la transparence et l’honnêteté…

Un quatrième avec ma proposition (celle d’Alan Weiss en fait) de « forfait valeur » et non « forfait features » :wink:

Hé bé !

J’ai tout lu hein !

Et franchement en tant que consultant Marketing/bizdev j’ai bien rigolé.

Imaginez un forum comme celui ci, mais avec des consultants orienté marketing, business design, automation, lean start-up…et vous obtenez (pas à la virgule) le même débat.

A la mission, à l’heure, al dente ? TPE, PME, Grands comptes, start-up, à la papa, à la Ygen.
Et chacun arrive avec ses références, son histoires (longue ou courte) et regarde le monde avec ses lunettes.

Par contre je vois bien que dans le monde de la techno, même quand on est passionné on reste poli. Dans l’univers des commerciaux et marketeux on maitrise le verbe à un niveau stratosphérique donc les insultes sont plutôt en rase motte. (je taquine hein, on se calme !).

Le mot « agile » produit le même effet dans votre environnement que dans le mien et la question de valeur apportée au client est la même. Nous pourrions donc considérer que ce n’est pas une question d’univers (commerce, marketing, dev, RH, finance…) mais bien d’effet de « mode ».

Pour ma part, j’ai le sentiment qu’aujourd’hui, d’aucuns tente de vendre du marketing à la sauce « agile » et du commerce à la sauce « agile » juste pour renouveler le discours. Dans le fond il ne se passe rien en sommes.

Pour ma part, j’ai créer une boite (edition de logiciel en SaaS) en 2008. Je ne suis pas dit : « Ha ben je vais faire de l’agile » aussi bien au niveau business que techno.

J’ai travaillé et les ingénieurs et avec un peu de bon sens tout à bien fonctionné. J’ai découvert l’agile bien après grâce à ma femme qui a travaillé sur un projet en scrum dans sa boite. Quand elle (et ses collègues) m’ont expliqué le SCRUM (genre la révélation de toute une vie) j’ai réalisé que c’est juste ma façon de fonctionner depuis tout petit.

Bref, je sui né agile au début des années 70’ :slight_smile:

A vous lire, je pense qu’il n’y a pas UNE méthode, UNE façon de gérer un projet, UN type de relation avec ses clients et UN contrat type et idéal.
Et Karim à raison sur 1 point : Vos clients ne sont pas dupes et croire qu’en ajoutant quelques termes à la mode cela va tout changer est un leurre.

Bon je retourne à mes contrats voir si je vais passer au forfait ou en régie (perso c’est à la tête du client :p).

Enjoy !

3 « J'aime »

Bonjour,

Je découvre ce sujet et ces échanges très intéressants. Il y a cependant deux points qui relèvent de mon expérience qui me semblent difficiles à gérer dans un contrat agile.

1- Le manque de disponibilité du « client » / « Product Owner ». L’enfer étant pavé de bonnes intentions, il arrive souvent que le client soit motivé, investi et disponible au début du projet et qu’au fur et à mesure du projet, le client soit moins présent, car rattrapé par son quotidien. Je pense plus particulièrement aux équipes du client portant le « métier », qui seront les futurs utilisateurs de l’application (commerciaux, administratifs…), mais pour qui la réussite du projet ne fait pas forcément partie de leurs objectifs sur lesquels ils seront évalués.
Dans ce cas ce manque de disponibilité ou de réactivité peu provoquer l’allongement des délais de validation, voire bloquer pendant une période significative les équipes de développement du prestataire.
Dans ce cas, qui prend en charge ce coût ? C’est toujours difficile à faire passer… Dans un contrat « régie », c’est simple : les équipes sont sur place donc c’est le client qui paie. Dans un contrat « forfait » pur, le problème ne doit pas se poser, car tout est dans le CDC. Mais dans un contrat agile, c’est plus compliqué.

2- Le risque induit par une estimation de charge faîte trop rapidement. Le fait d’avoir des itérations nombreuses, augmente considérablement les changements de périmètres, petits ou importants - c’est un peu le but de la méthode. A chaque réunion avec le client, il y a donc une estimation en temps réel (ou dans un délai très court) sur l’impact potentiel, en termes de charge et de délai, pour telle ou telle option prise. Les décisions de faire ou de ne pas faire sont prises notamment en fonction de ces critères.
Le problème d’un tel processus, c’est que pour que l’estimation du prestataire soit pertinente, il faut que le périmètre technique et fonctionnel de chaque nouvelle évolution soit parfaitement connu et maîtrisé par le prestataire. Dès que l’on est dans l’inconnu (nouvelle librairie graphique, nouveau composant…) il y a un risque de dépassement significatif qu’il sera difficile de faire valoir au client.

Ce sont à mon avis les deux risques principaux, qu’il est difficile à gérer contractuellement avec dans le cadre d’une relation commerciale agile.
Mais peut-être avez-vous des retours d’expériences différents ou des astuces qui vous permettent de traiter ces points.

Bonne journée.

Bonjour,

Effectivement, c’est un risque mais facilement contournable.

Il suffit d’expliquer au client et d’ajouter dans le contrat qu’à réception d’un livrable qui demande une validation du client, celui-ci à X jours pour confirmer (à négocier avec le client si recette doit être faite).

Au delà, le prestataire ne peut plus garantir les délais en raison du retard pris par le client.
Bloquant ainsi le prestataire, ce dernier pourra redéployer, sur d’autres projets, l’équipe.
Les délais devront donc être renégociés en fonction de la disponibilité des équipes.
(en général, une fois prévenu et dans le contrat, le client fait gaffe)

Si il s’agit d’un product owner, lors d’un projet par itération, il faut définir, avec le client, les dates de présence des personnes concernées(à éviter absolument: le PO présent tout le temps… ça sert à rien, démotive le PO et provoque ces pb). Et spécifier dans le contrat cette obligation de moyens de la part du client.
Idem, prévenir sur les garanties liées aux délais.

C’est une faute de débutant.
Et là seul le prestataire est en cause… on a tous rencontré ce cas de figure et appris à nos dépends.

On en revient toujours à la même chose: le niveau de professionnalisation d’un prestataire.
Si celui-ci répond à une offre, c’est par ce qu’il maitrise le domaine normalement.
Donc techniquement il ne devrait avoir aucun problème.

Pour le périmètre fonctionnel, et là on parle bien fonctionnel et non fonctionnalités:
Si le périmètre fonctionnel (plus délicat car demande de bonnes connaissances métier) change pendant le contrat et va au delà des compétences du prestataire, à ce dernier de l’expliquer au client pour que celui-ci prenne une AMOA.
L’AMOA assistera le prestataire sur la partie fonctionnelle.

Ce point se discute facilement lorsqu’au départ d’une prestation le nouveau périmètre fonctionnel n’était pas prévu et oblige a un avenant (pour se protéger et facturer le travail supplémentaire).

Si le client est con, il ne peut, de toute manière, pas se retourner contre le presta puisque le périmètre n’était pas inclus dans le contrat de départ (mais je n’ai jamais rencontré ce dernier cas de figure).

Mais franchement des changements de périmètre fonctionnelle tels que le presta n’est plus en mesure d’assurer… c’est vraiment rare.

Ce sont effectivement des pistes intéressantes, cependant :

  • Concernant la menace de remobiliser ses équipes sur un autre projet en l’absence de réactivité du client, c’est une menace qui peut atteindre sa cible, pourquoi pas, mais dans le cas contraire, elle ne protège pas beaucoup le prestataire, car elle est difficile à appliquer. En effet, il est assez compliqué de remobiliser une équipe de 5 ou 6 personnes au « pied levé » sur un autre projet client du jour au lendemain. Il y a toujours une certaine inertie. Ne serait-ce que pour trouver ce nouveau projet client inattendu.
    Il y a toujours une période durant laquelle les équipes seront au « chômage technique / interprojet » qui sera toujours à la charge du prestataire, car difficile à faire supporter au client.

  • Concernant l’erreur d’évaluation de changement de périmètre qui serait « une faute de débutant ». Ok, pourquoi pas, mais je pense que les méthodes agiles sont des facilitateurs de ce type d’erreur, car, incitant le client à changer régulièrement le contenu, même à la marge de son application, elles demandent une évaluation très rapide, car sinon le projet serait bloqué le temps de l’estimation et donc cela nuirait à la fluidité du projet.
    Et plus une évaluation est réalisée rapidement, plus le risque d’une erreur d’appréciation augmente (oublis…).