Ça se saurait si la satisfaction client ne se résumait à une liste de features !
En effet ! Et je précise que ça ne répond à rien de ce que j’ai pu poster ^^
Pour citer (encore) Alan Weiss : « les livrables ont très peu de valeur ».
L’agile comme n’importe quoi, si c’est QUE du maketing c’est mal 
Et souvent au départ (ceux qui l’utilise plutôt que de le vendre) trouve que c’est top, puis l’adapte à eux, il doit y avoir autant d’implémentation que d’individus/équipes .
Alors ça par contre, c’est une discipline qui demande des efforts, je suis devenu dev parce que je suis comme je suis, avec une pensée clairement technique, du coup, ça me demande un effort de voir les choses autrement que comme un dev, parce que c’est par juste mon métier c’est ma nature
1 « J'aime »
Tu dis que quand le prix est fixe, la satisfaction du client est garantie contractuellement, et je dis que c’est faux.
Quand le prix est fixe, c’est le cahier des charges qui est fixe, et donc c’est une liste de features qui est fixe, et pour moi une liste de features n’a rien à voir avec une satisfaction du client !
1 « J'aime »
Si t’as un exemple de projet très réussi au forfait, ça m’intéresse, vraiment ^^
oui
C’est là que tu ajoutes des choses que je n’ai pas dites
1 « J'aime »
Bien que je sois plutôt d’accord avec ton approche, moi je ne supporte plus vraiment un cahier des charges, j’ai été traumatisé, je pense qu’il faut contraster par :
- ça dépends du projet, de sa nature
- ça dépends (beaucoup) du client, il existe une subjectivité dans le cahier des charges
Je pense que quand tu ne veux plus avoir à faire à l’approche (mentalité) cahier des charges, tu filtres automatiquement tes clients, et c’est bien pour ça qu’il existe (et heureusement) plusieurs avis, et des exemples de réussites (échecs) dans toutes les approches et méthodologies.
Il faudrait que tous les presta soient sérieux et tous les clients de bonne foi…
1 « J'aime »
Je tiens juste à signaler que je me suis permis cette boutade (qui est tout de même assez vrai) parce que j’ai une formation technique à la base dont une bonne partie consacrée au développement informatique (5 années quand même).
J’ai même commencé ma carrière en faisant du dev sur µC et µP et je continue à bosser avec des dev.
C’était pas méchant de ma part.
1 « J'aime »
Hello,
J’arrive après la bataille 
Sans vouloir relancer un débat stérile, j’apporte mon expérience.
Je ne suis pas technique, mais fonctionnel, donc coté presta mais là pour satisfaire les besoins de mes clients.
Et donc je peux parler du process et des besoins grand comptes dans des projets dev web de dispositifs marketings ou si.
coté grands comptes les interlocuteurs marketing n’y connaissent rien en technique et ne peuvent pas se projeter, quand ils font appel à l’extérieur c’est que leur DSI ne prend pas leur projet, ou est trop lente. Bien souvent ils ont pour obligation d’intégrer leur DSI qui gère donc le cahier des charges.
@Aka74 a raison, les grands comptes (là on est coté opérations marketing) préfèrent culturellement le Forfait pour planifier leur budget. Donc vendre un nombre de jour homme indéterminé est très complexe…
Mais étant donné qu’au marketing il est difficile de se projeter dans un niveau de détail maximal comme le demande l’exercice du cahier des charges, en cours de route, les clients demandent obligatoirement des changements.
C’est là l’exercice compliqué pour gérer les demandes, les orienter favorablement dans l’intéret du projet et dans les limites raisonnable du forfait vendu.
Sans aller donc jusqu’à l’agilité, on peut trouver une voie intermédiaire qui serait de lotir le projet en 3 ou 4 lots. Dans un premier temps définir un lot 1, en faire la cotation, le développer et le livrer. Ensuite le client décidera des prochains lots.
Je trouve que c’est moins frustrant pour tous les acteurs, et surtout c’est vendable.
qu’en pensez-vous ?
3 « J'aime »
Ton brûlot depuis le début, ce qui a animé houleusement le fil, semble ne présenter que ta vue comme amenant le client à être satisfait.
Ce n’est pas le cas, peux tu le concevoir?
Autre chose aussi, il n’a jamais été question de dire que le forfait était mieux que la régie.
Je ne comprends pas ta réaction depuis le début ni ce hors sujet (je ne te jette pas la pierre, je suis parti aussi en HS).
J’ai vraiment du mal à comprendre cet emballement… as tu lu le premier post?
(tu peux ne pas être d’accord, soit, mais parlons du sujet SVP)
Donc pour en revenir au sujet, je vais résumer:
- Je ne pense pas qu’utiliser le terme agile pour vendre de la régie soit la bonne voie marketing.
- Les grosses TPE, PME et filiales de grands compte (là ou se trouve la manne financière) préfèrent le forfait… j’explique pourquoi avec l’attribution des budgets.
- Le forfait restera la voie royale parce qu’elle est plus avantageuse pour le client
- Mieux vaux donc maitriser ce type de prestation, car les clients les plus intéressants financièrement ne reviendront pas à la régie (hors cas spécifiques).
Je me cite, pas que je sois nombriliste 
Donc, oui, tu prévois le MVP qui doit contenir un nombre limitée de feature, et si ton client veut du forfait, c’est plus « simple » de vendre le MVP au forfait (qui doit avoir un scope limité, le mvp c’est pas "je veux comme ebay mais pour mon business ^^).
Ensuite, tu peux facturer la feature ou le groupe de features à la livraison, mais au final, c’est pleins de petits forfaits, et ça n’est par LE forfait, donc, pour un grand compte qui budgétise d’une année sur l’autre, ça reste compliqué.
C’est ce qu’on appelle l’allotissement d’appels d’offre.
On le fait généralement lorsque les montants sont importants ou que l’on sait pertinemment qu’un seul et même presta ne peut couvrir l’ensemble de la demande.
Ou, mais là c’est carrément limite, casser les prix: on sait que les entreprises margent plus sur certaines partie et margent peu sur leurs produits d’appels ou standards.
En faisant ça, on force les entreprises à baisser les prix sur les presta ou elles margent le plus.
C’est assez infâme, mais ça existe (ce n’est pas la majorité quand même).
C’est une pratique courante (l’allotissement) qui fonctionne très bien mais qui peut poser des problèmes lorsque la décomposition en lot d’un même domaine est attribuée à différents prestataires.
Si les lots sont imbriqués, et qu’un problème survient dans le fonctionnement, c’est le jeu de la patate chaude… chaque presta se renvoie la faute.
L’allotissement doit donc , dans le cas de plusieurs presta:
- être fait avec précaution
- les tests unitaires bien pensés
- la recette bien décomposée
Mais surtout ça demande de bonnes connaissances techniques pour le superviseur ou une AMOA
Oui MAIS
Une grosse TPE, PME etc, qui a un SI avec un budget, qui prévois, tiens cette année on refait le site, bon, voyons ce qui se fait, budget, disons 40K. La SI a son budget, et le presta travaille avec la SI. Pourquoi la SI ne pourrait pas travailler avec un presta en régie ? (pas forcément Agile)
Ça reviendrai au même qu’embaucher deux dev pendant quelques mois (oui, sauf la RH, les charges etc)
Ça dépends du découpage de l’entreprise, et la latitude des départements qui la composent.
(D’ailleurs, le site pourrais aussi bien être soumis au budget de la com et pas du SI)
Un facteur important commence à émerger, j’ai l’impression en tout cas, grâce au web et au plate-formes (viadéo, linkedin, github) la notoriété et la confiance, si tu es connu pour savoir faire (bien) ce que tu proposes, le rapport commercial/humain est différent.
Personnellement, j’éviterai au maximum, maintenant que je suis indépendant de travailler dans un mode qui ne me conviens pas et où je ne me sentirai pas bien pour délivrer le top qualité. Donc, tant que c’est possible évidement, je filtrerai les clients pour ne travailler qu’avec ceux avec qui ça colle sur le plan philosophie de travail avant la facturation.
La contractualisation et la facturation sont deux contraintes que j’essaye de faire passer après le reste.
Qu’est-ce qui n’est pas le cas ?
Je ne comprend pas ta question.
Quand tu dis que tu travailles avec des développeurs, et que tu en côtoies personnellement, j’en conclue que tu ne développes plus toi même 
Or dans ma façon de voir le monde, une personne qui donne des ordres aux développeurs, j’appelle ça un manager, et pour moi le management n’est pas la voie idéale de gestion d’un projet informatique. Le CEO de github par exemple nous a fait une présentation exceptionnelle sur le leadership (vs le management), et ce que ça apportait à l’entreprise (http://2013.la-conf.org/#tom_preston-werner).
Quand tu dis que le forfait restera la voie royale, ça me fait sourire, surtout quand tu dis que c’est plus avantageux pour le client
J’avais mal compris
Alors je veux bien un exemple de prix fixe mais cahier des charges variable
…merci de revenir à nos moutons
Je comprends ton point de vue, mais je pense que tu ne vois ça que du coté de la prestation.
Pour avoir ces 40k, ça a bataillé en comité de direction (sauf si c’est le DG qui a initié le projet).
Car ces 40k, s’ils partent dans le site web, c’est 40k de moins pour les autres directions.
Et il a fallut défendre ce budget devant le DAF.
Le DSI s’engage donc auprès de sa direction à avoir un résultat tangible (un bon site web) pour la somme demandée.
Il faut bien comprendre qu’à chaque fois qu’un budget est demandée au sein de la boite, la personne se met en danger: si elle a mal calculé son coup, choisi le mauvais presta, etc. … ça peut finir par la case pôle emploi dans le pire des cas ou une perte de confiance auprès du comDIR.
Une fois la confiance perdue, monter ses budgets devient le parcours du combattant… et en règle général ça fini toujours mal.
Ensuite, pour budgéter un site à 40k, on entre déjà dans le gros truc avec bases de données, design léché, etc.
En régie, ça représente 50j/homme… soit 25 jours pour 2 personnes
Avec une telle somme, perso, je m’adresse à une grosse web agencie aux compétences multiples pour être sur de couvrir tous les champs possible.
Chaque jour de dépassement, à 2 personnes, c’est plus de 1500e… aie
il n’y a pas que les RS pour demander des références aux prestataires sollicités.
C’est même la première chose à faire lorsqu’on s’adresse à un presta: pouvez-vous me communiquer une liste de 10 référents… et on en appelle 3 à 5.
Ca à toujours marché comme ça.
Là c’est un choix personnel et tu as tout à fait raison d’aller sur cette voie si tu y trouves ton compte.
Je te rejoins quand tu dis que l’agile n’est pas une solution miracle qui fonctionne dans tout les contextes. C’est notamment un problème de chiffrage, et donc de cahier des charge :
Quand le problème est connu (ex: réaliser un pont), on peut produire un cahier des charges précis, faire un chiffrage précis, et c’est logique de le réaliser au forfait. Sur le choix de la méthode, la cascade est bien plus adapté que l’agile sur ce type de projet, c’est ce qui est utilisé dans l’industrie spatiale par exemple.
Un cas plus proche de notre métier est celui d’une refonte : on travaille à iso-périmètre, l’appli existante sert de specs.
Mais on sait tous que ça se passe rarement comme ca.
On est bien plus souvent dans un contexte ou :
- Le besoin est découvert au fur et à mesure que le projet avance (penser lean). Dans le cas des startups on ne connait pas son marché, on ne sait même pas quel métier on fera dans 6 à 12 mois
- Même pour une boite établie pour x raisons le client n’a pas de cahier des charges détaillés au moment de l’appel d’offre, juste une expression de besoin très générale.
La réalité est que même dans des PME / groupes c’est souvent le cas.
Quand on signe un contrat avec un périmètre fixe, un délais fixe et un budget fixe, le risque est porté intégralement par le prestataire. Il va donc se protéger en prenant des marges de sécurité importante. Ce n’est pas un mal car ce genre de projet dérive souvent
Ce n’est pas moi qui le dit, les agences l’expliquent elles memes : http://www.colestreet.com/outsourcing-web-development-myths-around-fixed-price/
A partir de là on dérive facilement dans un mode de fonctionnement qui n’est pas sain :
Afin de rester compétitif le presta réduit souvent sa marge de sécurité
En cours de projet les surprises s’accumulent
La pression monte, la boite de presta fait redescendre la pression sur l’équipe
Plus la fin du projet s’approche plus on sacrifie la qualité du code
La fin du projet se résume à une bataille d’interprétation sur les specs : débat sans fin pour déterminer si il s’agit d’une nouvelle demande ou si c’était inclue dans l’expression de besoin
Une fois le projet finit on négocie une série d’avenants distillés au compte goutte pour sortir quelque chose de montrable mais qui ne satisfait personne, ni le client qui n’a pas eu ce qu’il imaginait, ni le presta qui sait qu’il a livré un résultat de mauvaise qualité
Malheureusement c’est encore trop souvent comment se déroule un forfait.
Le point le plus important de l’agile au niveau de la contractualisation c’est la spécification au fil de l’eau : on va spécifier de manière itérative en s’assurant que ce qui est développé colle au mieux au besoin (que l’on s’autorise de changer du coup) et aux contraintes de délais (s’adapter aux inconnus en cours de projet)
C’est plus difficile à contractualiser mais c’est ce qui fonctionne le mieux quand on a pas de specs détaillés. Il faut accepter que l’on ne sait pas ou l’on va dans le détail et qu’on va le découvrir ensemble au cours du projet.
Cela étant dit tu as entièrement raison quand tu dis que le client doit pouvoir piloter son budget et faire un prévisionnel, les points de complexité c’est très bien au sein d’une équipe mais à un moment on paye en j/H
On peut tout à fait travailler en agile au sein d’un budget établie à l’avance. On accepte que l’un des 3 paramètres devra être flexible : délais / budget / périmètre
En général, c’est alors le périmètre que l’on ajuste au fil du projet (priorisation), c’est une pratique saine comme l’explique très bien Thibaut !
Tout cela pose la question de la confiance, on a besoin de travailler dans un cadre avec lequel les 2 parties sont à l’aise (le contrat) mais si on est dans une relation de défiance où chacun est dans un mode « cover your ass » le projet est condamné avant même de démarrer
4 « J'aime »
J’ajouterai à ce que tu dis que pour les clients septiques de cette méthode, un truc qui marche à la perfection, c’est de faire une journée satisfaite ou remboursée. À la fin de la première journée, on a délivré un maximum de valeur, et on part sur un contrat complètement flexible des 2 côtés, permettant à tout moment de soit continuer, soit arrêter la prestation (avec quelque chose de fonctionnel, et en ligne surtout).
Je ne sais pas où tu vas chercher tes prestataires, mais personnellement, coder et mettre un ligne une appli rails avec une base de donnée, et un design simple, si ça prend 1 à 2 jours, c’est le bout du monde, et ensuite, on commence les itérations successives
Bref, dans tous les cas, je pense qu’on est d’accord sur un point, c’est que c’est la satisfaction client qui prime. On a juste des points de vue différents sur la façon de procurer le plus de satisfaction.
Le principe est que le livrable a peu de valeur en soi et qu’en effet il ne sera jamais la garantie de satisfaction du client.
Au lieu de cela il faut chercher un accord explicite sur les objectifs « business » du projets (qui ont de la valeur) et les moyens de mesurer l’atteinte de ces objectifs. Et garantir la satisfaction du client sur ces critères factuels.
Vous pouvez lire les ouvrages de Weiss (et le résumé en français posté plus haut) pour un exposé poussé du principe.
1 « J'aime »