Forum
Développement d'une application mobile : quelle forme?
pacodoso
Nombre de posts : 350
Nombre de likes : 7
Inscrit :
21 janvier 2016
Bonjour,
Suite à une mauvaise expérience lors d'un contrat de sous-traitance avec une SSII (https://www.free-work.com/fr/tech-it/forum/t/18016-contrat-de-sous-traitance-depassement-facturation), je souhaite être particulièrement vigilant par rapport à une nouvelle opportunité qui se présente.
J'ai été contacté par un client qui souhaite développer une application mobile de type "La Fourchette", mais pour un autre secteur d'activité. L'application devrait donc reprendre les mêmes fonctionnalités : création de compte utilisateur, géolocalisation de partenaires, réservation de prestations chez un partenaire, offres promotionnelles, etc... De même il faudrait développer l'interface web permettant d'administrer les données (prestataires, promos, ...), et les APIs permettant de récupérer les données depuis l'application.
Je sais que la personne qui m'a contacté est "sérieuse", car je l'avais déjà rencontré il y a quelques mois pour un autre besoin : elle gère une société qui développe des applications mobiles dans l’événementiel. Cette société a aujourd'hui plus d'un an et compte 5 salariés.
Par contre, le projet ne me semble actuellement pas suffisamment "cadré", et c'est ce qui m'inquiète. Lors de notre premier échange, mon contact m'avait parlé d'une "maquette fonctionnelle", lui permettant de démarcher les partenaires localement.
Nous nous sommes donc rencontré pour approfondir le sujet, et voir comment il souhaiterait fonctionner. Je lui ai ainsi proposé de développer l'application suivant une méthode Agile, en priorisant les fonctionnalités, et en enrichissant l'application de manière progressive. Mais il souhaite que l'ensemble des fonctionnalités (création de compte utilisateur, géolocalisation de partenaires, réservation de prestations chez un partenaire, offres promotionnelles, etc...) soient disponibles dès la première version publique.
Mon contact m'a demandé de revenir vers lui avec une première proposition chiffrée (jours/budget), ce qui reste délicat comme il n'existe pas de cahier des charges.
La maquette de l'application serait par contre fourni par une graphiste de sa société, et il parle d'un budget de communication de 200 000 € pour promouvoir l'application.
Je me demande donc quelle serait la forme la plus adaptée pour cette prestation, sachant qu'il n'y a pour l'instant pas de cahier des charges? (sous-traitance? forfait? régie? autre forme?)
Puis-je me positionner comme "maîtrise d'ouvrage" en proposant de rédiger le cahier des charges fonctionnel? (je l'estime à 5 jours de travail)
J'ai réalisé une première estimation "rapide" à partir des informations dont je dispose depuis ce simulateur (https://www.nomeo.fr/simulateur/) :
- 30 à 60 jours de développement
- 15 000 à 30 000 € HT de budget pour le développement
- 7 000 à 12 000 € HT de coût d'exploitation annuelle
Si je reprends une première analyse rapide de mon côté, ça semble assez cohérent avec la fourchette (sans jeu de mot) "haute" :
1 - Conception graphique : 15 jours => 6 750 €
2 - Développement backend : 20 jours => 9 000 €
3 - Développement front : 25 jours => 11 250 €
4 - Tests : 5 jours => 2 250 €
=> TOTAL : 60 jours => 29 250 €
Mais il faudrait sans doute que je rajoute une marge supplémentaire, et des jours de "gestion de projet".
Que pensez-vous de cette opportunité? Comment pourrais-je avancer pour mieux cadrer le projet avant de contractualiser?
Merci d'avance,
Suite à une mauvaise expérience lors d'un contrat de sous-traitance avec une SSII (https://www.free-work.com/fr/tech-it/forum/t/18016-contrat-de-sous-traitance-depassement-facturation), je souhaite être particulièrement vigilant par rapport à une nouvelle opportunité qui se présente.
J'ai été contacté par un client qui souhaite développer une application mobile de type "La Fourchette", mais pour un autre secteur d'activité. L'application devrait donc reprendre les mêmes fonctionnalités : création de compte utilisateur, géolocalisation de partenaires, réservation de prestations chez un partenaire, offres promotionnelles, etc... De même il faudrait développer l'interface web permettant d'administrer les données (prestataires, promos, ...), et les APIs permettant de récupérer les données depuis l'application.
Je sais que la personne qui m'a contacté est "sérieuse", car je l'avais déjà rencontré il y a quelques mois pour un autre besoin : elle gère une société qui développe des applications mobiles dans l’événementiel. Cette société a aujourd'hui plus d'un an et compte 5 salariés.
Par contre, le projet ne me semble actuellement pas suffisamment "cadré", et c'est ce qui m'inquiète. Lors de notre premier échange, mon contact m'avait parlé d'une "maquette fonctionnelle", lui permettant de démarcher les partenaires localement.
Nous nous sommes donc rencontré pour approfondir le sujet, et voir comment il souhaiterait fonctionner. Je lui ai ainsi proposé de développer l'application suivant une méthode Agile, en priorisant les fonctionnalités, et en enrichissant l'application de manière progressive. Mais il souhaite que l'ensemble des fonctionnalités (création de compte utilisateur, géolocalisation de partenaires, réservation de prestations chez un partenaire, offres promotionnelles, etc...) soient disponibles dès la première version publique.
Mon contact m'a demandé de revenir vers lui avec une première proposition chiffrée (jours/budget), ce qui reste délicat comme il n'existe pas de cahier des charges.
La maquette de l'application serait par contre fourni par une graphiste de sa société, et il parle d'un budget de communication de 200 000 € pour promouvoir l'application.
Je me demande donc quelle serait la forme la plus adaptée pour cette prestation, sachant qu'il n'y a pour l'instant pas de cahier des charges? (sous-traitance? forfait? régie? autre forme?)
Puis-je me positionner comme "maîtrise d'ouvrage" en proposant de rédiger le cahier des charges fonctionnel? (je l'estime à 5 jours de travail)
J'ai réalisé une première estimation "rapide" à partir des informations dont je dispose depuis ce simulateur (https://www.nomeo.fr/simulateur/) :
- 30 à 60 jours de développement
- 15 000 à 30 000 € HT de budget pour le développement
- 7 000 à 12 000 € HT de coût d'exploitation annuelle
Si je reprends une première analyse rapide de mon côté, ça semble assez cohérent avec la fourchette (sans jeu de mot) "haute" :
1 - Conception graphique : 15 jours => 6 750 €
2 - Développement backend : 20 jours => 9 000 €
3 - Développement front : 25 jours => 11 250 €
4 - Tests : 5 jours => 2 250 €
=> TOTAL : 60 jours => 29 250 €
Mais il faudrait sans doute que je rajoute une marge supplémentaire, et des jours de "gestion de projet".
Que pensez-vous de cette opportunité? Comment pourrais-je avancer pour mieux cadrer le projet avant de contractualiser?
Merci d'avance,
- Contacter en MP
mbCoCo
Nombre de posts : 235Nombre de likes : 1Inscrit : 8 mars 2013Bonjour,
Si je fais un calcul simple, vous vous engagez au forfait (60J) à un TJM de 487€. Je trouve que c'est assez bas pour un engagement forfaitaire. Il faut à mon avis ajouter au moins:
Le temps pour la rédaction de la documentation (manuel utilisateur / document d'exploitation / architecture technique....)
10% de marge de risque
10% de gestion de projet
Vous comptez uniquement le temps en développement sachant que le reste est aussi important. - Contacter en MP
pacodoso
Nombre de posts : 350Nombre de likes : 7Inscrit : 21 janvier 2016
En fait je ne sais pas si il y aurait des alternatives au forfait, qui me semble assez risqué justement.mbCoCo a écrit : Bonjour,
Si je fais un calcul simple, vous vous engagez au forfait (60J) à un TJM de 487€. Je trouve que c'est assez bas pour un engagement forfaitaire. Il faut à mon avis ajouter au moins:
Le temps pour la rédaction de la documentation (manuel utilisateur / document d'exploitation / architecture technique....)
10% de marge de risque
10% de gestion de projet
Vous comptez uniquement le temps en développement sachant que le reste est aussi important.
Mon estimation est également "approximative" dans la mesure ou il n'existe pas de cahier des charges. Du coup je me suis basé sur les écrans de l'appli LaFourchette, comme c'est pour l'instant le seul élément de comparaison : une dizaine d'écrans => 15 jours de conception graphique + 25 jours de développement.
Du coup, comment gérer l'absence de cahier des charges?
Proposer de réaliser 5 jours d'analyse et de rédiger le cahier des charges?
Concernant la marge de risque, je l'avais déjà inclus dans mon estimation : mais encore une fois, faute de cahier des charges cette estimation reste abstraite.
Ensuite, il faudrait effectivement que je prévoie également la rédaction de la documentation et la gestion de projet, comme vous le suggérez : quel pourcentage allouer à la rédaction de la documentation?
- Contacter en MP
mixomatose
Nombre de posts : 7214Nombre de likes : 13Inscrit : 12 février 2008pacodoso a écrit : [Du coup, comment gérer l'absence de cahier des charges?
On ne gère pas l'absence de cahier des charges. On ne se lance pas dans un projet au forfait sans cahier des charges. Point final.
Surtout pour un client qui veut tout et tout de suite.
Je suis d'accord sur l'approche agile, mais il faut diviser le projet en étapes fonctionnelles.
Pour chaque étape il faut un descriptif précis des vues implémentées, des fonction disponibles FE/BE, le dimensionnement, les test de recette.
Et pour chaque étape, la date de verrouillage des specs, le paiement qui y est attaché, sans oublier l'accompte à la commande.
Pas de livraison de source avant le paiement final, tu gardes la propriété de l'ensemble jusqu'au paiement final.
Et la première étape, c'est les specs.calculette de charges sociales TNS indépendant en ligne, comparateur simulateur Autoentrepreneur EI EURL http://www.entrepriseindividuelle.info/Calc_CharSoc.php - Contacter en MP
cacail
Nombre de posts : 381Nombre de likes : 1Inscrit : 18 avril 2012pacodoso a écrit : La maquette de l'application serait par contre fourni par une graphiste de sa société
Hmm, votre client doit vous fournir une maquette et vous prévoyez 15j de "conception graphique" ? Vous vouliez peut être plutôt dire "Intégration graphique", non ? :)pacodoso a écrit : 1 - Conception graphique : 15 jours => 6 750 €
2 - Développement backend : 20 jours => 9 000 €
3 - Développement front : 25 jours => 11 250 €
4 - Tests : 5 jours => 2 250 €
=> TOTAL : 60 jours => 29 250 €
De plus, il faut se méfier du format sous lequel sera livré la maquette. Si c'est un PSD et qu'il vous faut effectuer tous les découpages, ça peut vite faire grimper le temps passé sur l'intégration.
Dernier point important, lorsque votre client vous dit qu'il va vous donner des éléments, il faut absolument expliciter les jalons liés à ces entrants. Si jamais il est en retard sur la livraison, il faut bien qu'il comprenne (et accepte) que vous vous retrouverez bloqué sans pouvoir bosser !
Je rejoins mbCoCo sur le temps de rédaction des docs. Perso, je l'expliciterai même en en faisant des items distincts avec leurs chiffrages.
N'hésitez pas non plus à prendre une marge de 20% environ pour les aléas et la gestion du projet.
Concernant le cahier des charges, si vous avez une liste exhaustive des fonctionnalités souhaitées, il peut suffire de les décrire en quelques lignes et d'inclure cela dans votre devis. Autrement, si vous voulez vraiment être assuré, vous pouvez effectivement lui proposer une première prestation de cadrage pour produire le cahier des charges validé et précis.
De là, vous pourrez lui produire un second devis pour la réalisation (mais il pourra aussi s'en servir pour aller voir ailleurs :P).
Le forfait est toujours plus risqué que la régie... C'est pour ça qu'il coûte aussi plus cher. - Contacter en MP
mbCoCo
Nombre de posts : 235Nombre de likes : 1Inscrit : 8 mars 2013
Comme dit plus haut, l'absence de cahier des charges est un risque et ça peut devenir rapidement n'importe quoi. Proposez à votre client une prestation de cadrage avec comme document en sortie un cahier des charges décrivant toutes les fonctionnalités (Attention également à préciser le début et la fin avec une estimation du temps client: par exemple 3 ateliers de 3H donc le client doit dégager ce temps et vous préciser ses dispos). Il faut aussi mettre un max d'hypothèse structurantes.pacodoso a écrit : Du coup, comment gérer l'absence de cahier des charges?
Proposer de réaliser 5 jours d'analyse et de rédiger le cahier des charges?
Honnêtement, j'évite les forfaits car si on maitrise pas à 100% le périmètre ça tourne vite au cauchemar. - Contacter en MP
pacodoso
Nombre de posts : 350Nombre de likes : 7Inscrit : 21 janvier 2016
Je parle de la "conception graphique" au niveau de l'application : c'est à dire créer les écrans à partir des maquettes fournies, avec des données statiques, permettant de tester l'application (navigation, enchaînement des écrans, ...)cacail a écrit :pacodoso a écrit : La maquette de l'application serait par contre fourni par une graphiste de sa société
Hmm, votre client doit vous fournir une maquette et vous prévoyez 15j de "conception graphique" ? Vous vouliez peut être plutôt dire "Intégration graphique", non ? :)pacodoso a écrit : 1 - Conception graphique : 15 jours => 6 750 €
2 - Développement backend : 20 jours => 9 000 €
3 - Développement front : 25 jours => 11 250 €
4 - Tests : 5 jours => 2 250 €
=> TOTAL : 60 jours => 29 250 €
De plus, il faut se méfier du format sous lequel sera livré la maquette. Si c'est un PSD et qu'il vous faut effectuer tous les découpages, ça peut vite faire grimper le temps passé sur l'intégration.
Dernier point important, lorsque votre client vous dit qu'il va vous donner des éléments, il faut absolument expliciter les jalons liés à ces entrants. Si jamais il est en retard sur la livraison, il faut bien qu'il comprenne (et accepte) que vous vous retrouverez bloqué sans pouvoir bosser !
Pour la V1, le client souhaite utiliser une technologie "cross-platform" afin de réduire le temps de développement, ce qui engendre forcément quelques contraintes : il sait que la maquette fournie ne pourra pas être complètement reproduite dans l'application.
Comme j'ai identifié une dizaine d'écrans, les 15 jours me semblent donc pertinents. Et une fois que cette étape aura été validée par le client, je pourrais passer aux problématiques "métier".
Je manque un peu de recul et d'expérience sur la rédaction de docs. Difficile pour moi de trouver une "norme" ou un mode de chiffrage sur ce point.cacail a écrit : Je rejoins mbCoCo sur le temps de rédaction des docs. Perso, je l'expliciterai même en en faisant des items distincts avec leurs chiffrages.
N'hésitez pas non plus à prendre une marge de 20% environ pour les aléas et la gestion du projet.
Je suis d'accord sur le cahier des charges, c'est le vrai point noir selon moi.cacail a écrit : Concernant le cahier des charges, si vous avez une liste exhaustive des fonctionnalités souhaitées, il peut suffire de les décrire en quelques lignes et d'inclure cela dans votre devis. Autrement, si vous voulez vraiment être assuré, vous pouvez effectivement lui proposer une première prestation de cadrage pour produire le cahier des charges validé et précis.
De là, vous pourrez lui produire un second devis pour la réalisation (mais il pourra aussi s'en servir pour aller voir ailleurs :P).
Le forfait est toujours plus risqué que la régie... C'est pour ça qu'il coûte aussi plus cher.
Je pense qu'une analyse poussée est indispensable. Car si un test de l'application de référence permettrait de lister les fonctionnalités de l'appli mobile, il reste à définir toutes les problématiques métier des prestataires (tpyes de services, catégories, horaires, adresse, type de promotion, gestion d'une réservation, etc...) - Contacter en MP
pacodoso
Nombre de posts : 350Nombre de likes : 7Inscrit : 21 janvier 2016
C'est pour la phase d'analyse que vous prévoyez 3 ateliers de 3h?mbCoCo a écrit :
Comme dit plus haut, l'absence de cahier des charges est un risque et ça peut devenir rapidement n'importe quoi. Proposez à votre client une prestation de cadrage avec comme document en sortie un cahier des charges décrivant toutes les fonctionnalités (Attention également à préciser le début et la fin avec une estimation du temps client: par exemple 3 ateliers de 3H donc le client doit dégager ce temps et vous préciser ses dispos). Il faut aussi mettre un max d'hypothèse structurantes.pacodoso a écrit : Du coup, comment gérer l'absence de cahier des charges?
Proposer de réaliser 5 jours d'analyse et de rédiger le cahier des charges?
Honnêtement, j'évite les forfaits car si on maîtrise pas à 100% le périmètre ça tourne vite au cauchemar.
Du coup ce serait gérable en 1 semaine ou il vaudrait mieux l'étaler sur plus de temps?
Je pense que je vais donc fournir une première estimation "approximative" au client, en lui expliquant qu'une analyse plus approfondie est nécessaire. - Contacter en MP
mbCoCo
Nombre de posts : 235Nombre de likes : 1Inscrit : 8 mars 2013Le nombre d'ateliers pour l'analyse est à définir en fonction des sujets et thématiques à traiter (les 3h x3 est un exemple).
J'attire ton attention sur 1 point, imaginons tu te lances dans un cadrage en 5 jours (forfait) et que ton client traîne pour organiser les ateliers et ne t'alimente pas en éléments pour bien faire ton analyse, tes 5 jours vont s'étaler sur plusieurs semaines.
Il faut avant de démarrer l'analyse préciser dans ton devis ou proposition commerciale la durée de la mission et les pré requis côté client pour le bon déroulement de la mission. - Contacter en MP
pacodoso
Nombre de posts : 350Nombre de likes : 7Inscrit : 21 janvier 2016
D'accord je comprends mieux.mbCoCo a écrit : Le nombre d'ateliers pour l'analyse est à définir en fonction des sujets et thématiques à traiter (les 3h x3 est un exemple).
J'attire ton attention sur 1 point, imaginons tu te lances dans un cadrage en 5 jours (forfait) et que ton client traîne pour organiser les ateliers et ne t'alimente pas en éléments pour bien faire ton analyse, tes 5 jours vont s'étaler sur plusieurs semaines.
Il faut avant de démarrer l'analyse préciser dans ton devis ou proposition commerciale la durée de la mission et les pré requis côté client pour le bon déroulement de la mission.
Après le client "semble" pressé, comme ma disponibilité quasi immédiate est un des critères pour lesquels il m'a contacté : il ne devrait donc pas trop laisser traîner les choses...
J'ai également eu des retours positifs à son sujet (sérieux, professionnalisme, moyens) donc je suis un peu rassuré : je verrais si j'ai également un retour positif une fois que je lui aurais transmis mon premier chiffrage et ma demande de cadrage. - Contacter en MP
mbCoCo
Nombre de posts : 235Nombre de likes : 1Inscrit : 8 mars 2013Je pense que beaucoup de Freelance sur ce forum vont vous dire la même chose: il faut mettre le maximum de choses par écrit avant de commencer. Les problèmes d'incompréhension autour du développement d'applications sont récurrents et puis le besoin évolue avec le temps et beaucoup de client ne comprennent pas qu'un forfait euuh comment dire c'est un forfait et toute demande non prévue initialement donne lieu à chiffrage et facturation supplémentaire.
Même avec des clients de longues dates et une confiance au plus haut niveau, il faut tracer et définir le périmètre d'intervention (surtout s'il est pressé)....
Dites-vous également que s'il doit passer par une société pour son projet, il aura le droit à un chef de projet, un analyste, un développeur... alors que la il a un seul poste qui fait tout - Contacter en MP
Hans
Nombre de posts : 515Nombre de likes : 0Inscrit : 5 mai 2008Bon résumons.
Ce qu'on sait clairement : le client veut une application de démonstration avec un budget de 60 jours. C'est une charge qui est un peu courte pour faire un projet avec tout plein de doc et d'analyse, un mode "agile" (agile au sens iso 1664 du terme (95% des SSIIs), pas au sens scrum ou XP) se prêtera pas trop mal. Les grandes lignes sont "à priori" définies pour l'application mais il n'y a aucun détail pour pouvoir s'engager sur une prestation forfaitaire.
C'est le genre de projet casse-gueule ou ton client te dit au départ, pas de souci, tu fait l'application et on verra. Et puis arrive les premières présentations et il y a des choses qui ont changés depuis le départ, des visuels à changer, des petites fonctionnalités en plus. Et rebelote à la réunion d'après. Au bout du compte, tu manges la chemise. C'est mon expérience sur certains projets ainsi que celle d'autres.
Pour des projets plus gros, il est possible de vendre en plusieurs phases avec des moyens fixées pour chacune : une phase d'analyse de XX jours puis des lots YY jours. Les lots ne sont commandés qu'après accord des deux partis sur le contenu de chacun, contenu qui sera défini grâce à la première phase et en affinant après la réalisation de chacun de lot. Dans ton cas, ce n'est pas cela du tout. Le gars veut te payer 60 jours et que tu lui fasses l'application de démo avec tout ce qui va lui passer par la tête au fur et à mesure de tes développements, sérieux ou pas. Le "vide" au niveau des specs lui permettra de manœuvrer (délibérément ou inconsciemment) autour des "specs" pour obtenir ce qu'il vaudra au final.
Ma conclusion : il est absolument interdit de faire ce projet au forfait
Je sens que le projet t'intéresse beaucoup : tu es dispo et a peut-être besoin de travailler mais au delà de cela, en te lisant (en me reconnaissant dans mon passé sur certaines expériences), je sens quelqu'un près à prendre le projet coûte que coûte. Il faut clairement que tu te mettes en tête comme limite DURE: JE NE FAIT PAS CE PROJET AU FORFAIT. En gros, il faut que tu te dises qu'il est possible que tu ne fasses pas ce projet. Pour t'aider, continu de chercher d'autres missions histoire de ne pas focaliser ton esprit sur cet unique projet.
L'approche avec ton client : une obligation de résultat n'est pas possible, faute de besoin clair et précis qui permettrait de cadrer le forfait. Il faut parler d'obligation de moyen. Préciser très clairement que c'est une condition SINE QUA NONE et que tu ne feras pas le projet avec une obligation de résultat (car lequel ?). ET dès qu'il revient à la charge (au début ou en cours), lui rappeler que tu as clairement dit que tu n'aurais pas fait le projet si c'était au forfait. Ne pas hésiter à la mettre dans un mail qui accompagnera ton contrat commercial pour pouvoir lui rappeler ton explication mail du XX/YY/2017.
Contrairement à un contrat de pure régie ou ton engagement tient sur 3 lignes (compétence techniques, durée et tarif), la tu peux mettre un peu plus le contexte du projet en quelques lignes pour rassurer le client en présentant le projet, les objectifs à long terme. En concluant que le but est de réaliser une application fonctionnelle avec la charge de 60 jours. Les fonctionnalités de cette application de démonstration seront par contre limitées si la charge de réalisation ne permet pas de rester dans ce premier objectif d'une réalisation à 60 jours. Cela est à reformuler probablement.
Si ton client veut vraiment un engagement au forfait, tu lui dis simplement que cela n'est pas possible et que tu passes ton chemin. en rappelant que tu serais très heureux de le faire dans un cadre de régie. Soit surtout près à accepter toi même de ne pas faire ce projet. - Contacter en MP
Hans
Nombre de posts : 515Nombre de likes : 0Inscrit : 5 mai 2008Pour compléter :
Est-ce que le client est proche de chez toi ? Si oui, propose de travailler chez lui, cela me parait la "bonne" méthode vu le contexte du projet.
J'ai envie de dire : propose lui 2 mois en régie à ton client.
Mon chiffrage se résumerais à cela : On peut faire une application en 2 mois avec des fonctionnalités de création de compte utilisateur, géolocalisation de partenaires, réservation de prestations chez un partenaire, offres promotionnelles, etc. . Mais pour que la réalisation en 2 mois aboutisse, cela dépend de beaucoup d'élément, dont certain que tu ne connais pas ou ne maîtrise pas, notamment :
- disponibilité et forme des éléments visuels,
- définition précise des fonctionnalités. C'est parti pour fonctionner par itération, genre vas-y fait un truc, on voit ce que cela donne et tu refait après ...,
Autre possibilité :
Après s'il veut un chiffrage et un engagement de résultat, il termine d'abord les maquettes (cela permettra de figer le visuel et un peu les fonctionnalités) puis vous vous rencontrez pour faire le tour des fonctionnalités. A part de cela, tu rédiges ta proposition en listant et détaillant précisément les fonctionnalités (avec visuels), l'environnement technique, etc. Tu donnes le chiffrage pour cela, en concluant que les modifications fonctionnellement par rapport à ce contrat/devis feront l'objet d'un avenant à définir mais dont le taux journalier est de XX€ HT. Cela prends du temps mais c'est nécessaire avant d'envisager un forfait. S'il veut un forfait mais ne veut pas cette démarche, c'est qu'il veut clairement que tu ne cadres pas le projet pour qu'il garde de la marge de manœuvre. - Contacter en MP
phili_b
Nombre de posts : 536Nombre de likes : 12Inscrit : 8 octobre 2014Idem un forfait sans cahier des charges c'est vraiment se créer des problèmes.
Ou alors il faut adapter l'agilité au contrat, et le contrat à l'agilité.
Faire qu'à chaque itération corresponde un lotissement marqué par un compte-rendu des spécifications, validé par le client, et qui déclenche un paiement. Et que dans le contrat qu'il y ait une adhésion au principe de validation/paiement par itération, et qu'il n'y ait pas d'engagements de fonctionnalités détaillées ni de délais notamment, mais c'est une quadrature du cercle ce dernier point puisque ça correspond à de la régie.
Quand on fait des recherches sur "mode agile forfait", il y a des tonnes de réponses.
Pour un indépendant faire un projet au forfait est risqué, et faire un projet en mode Agile est risqué surtout si le client n'est pas habitué à cela. Mais faire un projet en mode Agile ET forfait, c'est de la haute voltige surtout pour un jeune indépendant.
- [*:7aa33e8e62] Xebia: Pourquoi les projets Agiles ne peuvent pas vraiment être menés au forfait ?
[*:7aa33e8e62] Le MagIT, comment donner de l'agilité à un contrat au forfait Et ils utilisent le cahier des charges quand même.
[*:7aa33e8e62]Blackbird, Comment envisager une relation gagnant/gagnant entre commanditaire et prestataire ?Une des clés de cette contractualisation consiste à « séparer le cahier des charges de la partie contractuelle », insiste Jacques Witté. Une stratégie qui conduit à séparer le nombre de jours dans la pratique et les fonctionnalités. « L’équipe de mise en oeuvre (en particulier l’architecte logiciel) réécrit le cahier des charges en le découpant en milestones (groupes de fonctionnalités) chiffrés en jours x homme. Puis, l’ensemble des milestones (le chiffrage du cahier des charges) détermine un nombre de jours x homme total du projet », explique-t-il. Enfin, « le client s’engage à signer la mise en oeuvre d’un pourcentage de ce nombre de jours total du projet ». Alors que le contrat définit chaque tranche de temps qui serviront à calculer les itérations, le cahier des charges reste basé sur le fonctionnel et peut être modifié « à la volée ». Selon les critères des méthodes agiles. Sur cette base, les jours non-utilisés sont ré-attribués à l'itération suivante. La facturation peut être alors effectuée en fonction de chaque itération.
[*:7aa33e8e62] Le blog du management de projet, Rédiger un contrat au forfait sur un projet AgileLe forfait est une offre commerciale construite sur un périmètre fermé, la méthode de production Agile autorise le changement.Mon conseil à toute société travaillant dans le marché de contrat au forfait Agile est de passer du temps à définir votre évaluation, cadencement et l’approche de définition du contenu. [...]La première chose que nous avons faite a été de regarder le processus Agile que nous avions entrepris et le découper en trois domaines distincts.[...]Alors, combien cela coûtera-t-il et combien de temps sera nécessaire ? Avec notre contenu défini nous pouvons maintenant concentrer à établir le prix et la durée. Et, pour ce faire, nous devons regarder la Vélocité de l’Équipe, combien de points une équipe peut-elle réaliser pendant une itération ?
EURL / IR / BNC - [*:7aa33e8e62] Xebia: Pourquoi les projets Agiles ne peuvent pas vraiment être menés au forfait ?
- Contacter en MP
kzg
Nombre de posts : 2927Nombre de likes : 4Inscrit : 2 mai 2012
Délicat ?pacodoso a écrit : Bonjour,
Suite à une mauvaise expérience lors d'un contrat de sous-traitance avec une SSII (https://www.free-work.com/fr/tech-it/forum/t/18016-contrat-de-sous-traitance-depassement-facturation), je souhaite être particulièrement vigilant par rapport à une nouvelle opportunité qui se présente.
Par contre, le projet ne me semble actuellement pas suffisamment "cadré", et c'est ce qui m'inquiète. [...]
Mon contact m'a demandé de revenir vers lui avec une première proposition chiffrée (jours/budget), ce qui reste délicat comme il n'existe pas de cahier des charges.
Doux euphémisme.
Êtes-vous sûr d'avoir l'expérience nécessaire pour prendre en charge un tel projet ?
Vous sortez tout juste d'une mauvaise expérience sur laquelle vous avez commis de graves erreurs de débutant. Avant d'aller sur un autre forfait bancal, peut être serait-il plus judicieux de vous faire la main et acquérir l'expérience qui, à mon avis, vous fait défaut, sur un projet plus cadré et en régie. - Contacter en MP
pacodoso
Nombre de posts : 350Nombre de likes : 7Inscrit : 21 janvier 2016
Oui je comprends.mbCoCo a écrit : Je pense que beaucoup de Freelance sur ce forum vont vous dire la même chose: il faut mettre le maximum de choses par écrit avant de commencer. Les problèmes d'incompréhension autour du développement d'applications sont récurrents et puis le besoin évolue avec le temps et beaucoup de client ne comprennent pas qu'un forfait euuh comment dire c'est un forfait et toute demande non prévue initialement donne lieu à chiffrage et facturation supplémentaire.
Même avec des clients de longues dates et une confiance au plus haut niveau, il faut tracer et définir le périmètre d'intervention (surtout s'il est pressé)....
Dites-vous également que s'il doit passer par une société pour son projet, il aura le droit à un chef de projet, un analyste, un développeur... alors que la il a un seul poste qui fait tout
C'est pour ça que j'aurais proposé de réaliser le projet avec 1 ou 2 autres freelances, compte tenu de la charge de travail, et du caractère "urgent" du projet. Mais ce mode de fonctionnement ne pourrait sans doute convenir que pour un mode forfait, pas sur que cela lui convienne pour de la régie.
Je termine néanmoins une première "estimation" comme je m'y étais engagé, mais en lui faisant bien comprendre qu'elle est très "approximative", et qu'il reste beaucoup d'éléments à cadrer. - Contacter en MP
Hans
Nombre de posts : 515Nombre de likes : 0Inscrit : 5 mai 2008
Et vu comme c'est peu cadré et encore en réflexion, à part lui dire "oui, on doit être capable de faire quelque chose en 60 jours mais est-ce que cela correspondra à ce que vous allez vouloir au final ..."pacodoso a écrit :
Oui je comprends.mbCoCo a écrit : Je pense que beaucoup de Freelance sur ce forum vont vous dire la même chose: il faut mettre le maximum de choses par écrit avant de commencer. Les problèmes d'incompréhension autour du développement d'applications sont récurrents et puis le besoin évolue avec le temps et beaucoup de client ne comprennent pas qu'un forfait euuh comment dire c'est un forfait et toute demande non prévue initialement donne lieu à chiffrage et facturation supplémentaire.
Même avec des clients de longues dates et une confiance au plus haut niveau, il faut tracer et définir le périmètre d'intervention (surtout s'il est pressé)....
Dites-vous également que s'il doit passer par une société pour son projet, il aura le droit à un chef de projet, un analyste, un développeur... alors que la il a un seul poste qui fait tout
C'est pour ça que j'aurais proposé de réaliser le projet avec 1 ou 2 autres freelances, compte tenu de la charge de travail, et du caractère "urgent" du projet. Mais ce mode de fonctionnement ne pourrait sans doute convenir que pour un mode forfait, pas sur que cela lui convienne pour de la régie.
Je termine néanmoins une première "estimation" comme je m'y étais engagé, mais en lui faisant bien comprendre qu'elle est très "approximative", et qu'il reste beaucoup d'éléments à cadrer. - Contacter en MP
pacodoso
Nombre de posts : 350Nombre de likes : 7Inscrit : 21 janvier 2016
Hans, encore une fois, merci pour tes retours.Hans a écrit : Bon résumons.
Ce qu'on sait clairement : le client veut une application de démonstration avec un budget de 60 jours. C'est une charge qui est un peu courte pour faire un projet avec tout plein de doc et d'analyse, un mode "agile" (agile au sens iso 1664 du terme (95% des SSIIs), pas au sens scrum ou XP) se prêtera pas trop mal. Les grandes lignes sont "à priori" définies pour l'application mais il n'y a aucun détail pour pouvoir s'engager sur une prestation forfaitaire.
C'est le genre de projet casse-gueule ou ton client te dit au départ, pas de souci, tu fait l'application et on verra. Et puis arrive les premières présentations et il y a des choses qui ont changés depuis le départ, des visuels à changer, des petites fonctionnalités en plus. Et rebelote à la réunion d'après. Au bout du compte, tu manges la chemise. C'est mon expérience sur certains projets ainsi que celle d'autres.
Pour des projets plus gros, il est possible de vendre en plusieurs phases avec des moyens fixées pour chacune : une phase d'analyse de XX jours puis des lots YY jours. Les lots ne sont commandés qu'après accord des deux partis sur le contenu de chacun, contenu qui sera défini grâce à la première phase et en affinant après la réalisation de chacun de lot. Dans ton cas, ce n'est pas cela du tout. Le gars veut te payer 60 jours et que tu lui fasses l'application de démo avec tout ce qui va lui passer par la tête au fur et à mesure de tes développements, sérieux ou pas. Le "vide" au niveau des specs lui permettra de manœuvrer (délibérément ou inconsciemment) autour des "specs" pour obtenir ce qu'il vaudra au final.
Ma conclusion : il est absolument interdit de faire ce projet au forfait
La première estimation de 60 jours était vraiment à "minima".
En faisant un tour un peu plus complet de l'application LaFourchette (vu que c'est qui me sert pour l'instant de référence), j'ai identifié une quinzaine d'écrans, certains étant assez "complexes" techniquement.
De plus, il reste à définir toute l'architecture métier et les règles associées pour le backend.
En rajoutant les tests, une marge d'erreur et la gestion de projet j'arrive cette fois à 105 jours, tout en restant "approximatif" 😲
Oui le projet m'intéresse, si :Hans a écrit :
Je sens que le projet t'intéresse beaucoup : tu es dispo et a peut-être besoin de travailler mais au delà de cela, en te lisant (en me reconnaissant dans mon passé sur certaines expériences), je sens quelqu'un près à prendre le projet coûte que coûte. Il faut clairement que tu te mettes en tête comme limite DURE: JE NE FAIT PAS CE PROJET AU FORFAIT. En gros, il faut que tu te dises qu'il est possible que tu ne fasses pas ce projet. Pour t'aider, continu de chercher d'autres missions histoire de ne pas focaliser ton esprit sur cet unique projet.
- il y a un cahier des charges bien défini (ce qui n'est pas le cas actuellement) en mode forfait "traditionnel"
- ou si on part sur un mode régie
- ou comme tu le suggères plus bas, on part sur un mode forfait "sans obligation de résultat"
- et que j'ai une liberté sur les choix techniques
Hans a écrit :
L'approche avec ton client : une obligation de résultat n'est pas possible, faute de besoin clair et précis qui permettrait de cadrer le forfait. Il faut parler d'obligation de moyen. Préciser très clairement que c'est une condition SINE QUA NONE et que tu ne feras pas le projet avec une obligation de résultat (car lequel ?). ET dès qu'il revient à la charge (au début ou en cours), lui rappeler que tu as clairement dit que tu n'aurais pas fait le projet si c'était au forfait. Ne pas hésiter à la mettre dans un mail qui accompagnera ton contrat commercial pour pouvoir lui rappeler ton explication mail du XX/YY/2017.
Contrairement à un contrat de pure régie ou ton engagement tient sur 3 lignes (compétence techniques, durée et tarif), la tu peux mettre un peu plus le contexte du projet en quelques lignes pour rassurer le client en présentant le projet, les objectifs à long terme. En concluant que le but est de réaliser une application fonctionnelle avec la charge de 60 jours. Les fonctionnalités de cette application de démonstration seront par contre limitées si la charge de réalisation ne permet pas de rester dans ce premier objectif d'une réalisation à 60 jours. Cela est à reformuler probablement.
Mais ça existe donc un contrat en mode forfait sans obligation de résultat? J'ai un collègue freelance qui sur un projet similaire bosse en mode régie, avec un engagement reconductible chaque mois.
Hans a écrit :
Si ton client veut vraiment un engagement au forfait, tu lui dis simplement que cela n'est pas possible et que tu passes ton chemin. en rappelant que tu serais très heureux de le faire dans un cadre de régie. Soit surtout près à accepter toi même de ne pas faire ce projet.
On est d'accord, je n'ai pas envie d’enchaîner avec un nouveau projet pouvant occasionner des problèmes!
Hans a écrit : Pour compléter :
Est-ce que le client est proche de chez toi ? Si oui, propose de travailler chez lui, cela me parait la "bonne" méthode vu le contexte du projet.
J'ai envie de dire : propose lui 2 mois en régie à ton client.
Mon chiffrage se résumerais à cela : On peut faire une application en 2 mois avec des fonctionnalités de création de compte utilisateur, géolocalisation de partenaires, réservation de prestations chez un partenaire, offres promotionnelles, etc. . Mais pour que la réalisation en 2 mois aboutisse, cela dépend de beaucoup d'élément, dont certain que tu ne connais pas ou ne maîtrise pas, notamment :
- disponibilité et forme des éléments visuels,
- définition précise des fonctionnalités. C'est parti pour fonctionner par itération, genre vas-y fait un truc, on voit ce que cela donne et tu refait après ...,
Oui le client est proche de chez moi : nous sommes dans la même ville.
Mais suite à l'analyse plus "réaliste", la durée serait plutôt de 105 jours : je ne sais donc pas si une régie de 5 mois est intéressante pour le client, surtout qu'il semble "pressé".
Du coup quelles seraient les alternatives?
- proposer de prendre 1 ou 2 freelances que je connais, et monter "une équipe" en mode régie?
- essayer de découper le projet en lots, et de rester sur un mode forfait plus classique? cela devrait permettre de limiter les risques pour moi, comme pour lui...
D'accord, cela permet de cadrer le projet et les éventuelles demandes du client, mais c'est la solution la moins souple et la plus risquée non?Hans a écrit : Autre possibilité :
Après s'il veut un chiffrage et un engagement de résultat, il termine d'abord les maquettes (cela permettra de figer le visuel et un peu les fonctionnalités) puis vous vous rencontrez pour faire le tour des fonctionnalités. A part de cela, tu rédiges ta proposition en listant et détaillant précisément les fonctionnalités (avec visuels), l'environnement technique, etc. Tu donnes le chiffrage pour cela, en concluant que les modifications fonctionnellement par rapport à ce contrat/devis feront l'objet d'un avenant à définir mais dont le taux journalier est de XX€ HT. Cela prends du temps mais c'est nécessaire avant d'envisager un forfait. S'il veut un forfait mais ne veut pas cette démarche, c'est qu'il veut clairement que tu ne cadres pas le projet pour qu'il garde de la marge de manœuvre. - Contacter en MP
mbCoCo
Nombre de posts : 235Nombre de likes : 1Inscrit : 8 mars 2013Hello,
Un mode qui peut fonctionner "la régie forfaitée", en partant d'une estimation validée avec le client vous travaillez pour livrer un maximum de fonctionnalité. Lorsque l'enveloppe allouée est proche de 0, vous faites le point avec le client pour voir s'il reprend des jours ou s'il veut arrêter.
Ce mode suppose que le projet peut être découpé en fonctionnalité autonome et "complète".
Il faut également travailler sur le site du client pour éviter les remarques / soupçons... - Contacter en MP
pacodoso
Nombre de posts : 350Nombre de likes : 7Inscrit : 21 janvier 2016
Ah donc c'est ça la vrai régie forfaitée?mbCoCo a écrit : Hello,
Un mode qui peut fonctionner "la régie forfaitée", en partant d'une estimation validée avec le client vous travaillez pour livrer un maximum de fonctionnalité. Lorsque l'enveloppe allouée est proche de 0, vous faites le point avec le client pour voir s'il reprend des jours ou s'il veut arrêter.
Ce mode suppose que le projet peut être découpé en fonctionnalité autonome et "complète".
Il faut également travailler sur le site du client pour éviter les remarques / soupçons...
C'est le mode de fonctionnement que la SSII m'avait vendu pour mon dernier contrat de sous-traitance, mais elle n'a jamais assumer les dépassements, dont elle était pourtant en grande partie responsable :
- webservices développés par la SSII et bogués
- pas de serveur de test
- tablette de test fournie seulement 3 mois après le début du projet
- assistance au client final pendant x jours
etc... - Contacter en MP
mbCoCo
Nombre de posts : 235Nombre de likes : 1Inscrit : 8 mars 2013Ce mode de projet demande une grande maturité du client. Je l'ai pratiqué avec 1 client (sans intermédiaire), le projet s'est bien déroulé même si à la fin on avait un peu de frustration de ne pas finir toutes les fonctionnalités.
Faut dire aussi que les derniers jours le client mettait la pression pour avoir un max de trucs (quitte à faire dans la précipitation et avoir des bugs). - Contacter en MP
pacodoso
Nombre de posts : 350Nombre de likes : 7Inscrit : 21 janvier 2016
Merci pour ton analyse et des liens.phili_b a écrit : Idem un forfait sans cahier des charges c'est vraiment se créer des problèmes.
Ou alors il faut adapter l'agilité au contrat, et le contrat à l'agilité.
Faire qu'à chaque itération corresponde un lotissement marqué par un compte-rendu des spécifications, validé par le client, et qui déclenche un paiement. Et que dans le contrat qu'il y ait une adhésion au principe de validation/paiement par itération, et qu'il n'y ait pas d'engagements de fonctionnalités détaillées ni de délais notamment, mais c'est une quadrature du cercle ce dernier point puisque ça correspond à de la régie.
Quand on fait des recherches sur "mode agile forfait", il y a des tonnes de réponses.
Pour un indépendant faire un projet au forfait est risqué, et faire un projet en mode Agile est risqué surtout si le client n'est pas habitué à cela. Mais faire un projet en mode Agile ET forfait, c'est de la haute voltige surtout pour un jeune indépendant.
- [*:666707df89] Xebia: Pourquoi les projets Agiles ne peuvent pas vraiment être menés au forfait ?
[*:666707df89] Le MagIT, comment donner de l'agilité à un contrat au forfait Et ils utilisent le cahier des charges quand même.
[*:666707df89]Blackbird, Comment envisager une relation gagnant/gagnant entre commanditaire et prestataire ?Une des clés de cette contractualisation consiste à « séparer le cahier des charges de la partie contractuelle », insiste Jacques Witté. Une stratégie qui conduit à séparer le nombre de jours dans la pratique et les fonctionnalités. « L’équipe de mise en oeuvre (en particulier l’architecte logiciel) réécrit le cahier des charges en le découpant en milestones (groupes de fonctionnalités) chiffrés en jours x homme. Puis, l’ensemble des milestones (le chiffrage du cahier des charges) détermine un nombre de jours x homme total du projet », explique-t-il. Enfin, « le client s’engage à signer la mise en oeuvre d’un pourcentage de ce nombre de jours total du projet ». Alors que le contrat définit chaque tranche de temps qui serviront à calculer les itérations, le cahier des charges reste basé sur le fonctionnel et peut être modifié « à la volée ». Selon les critères des méthodes agiles. Sur cette base, les jours non-utilisés sont ré-attribués à l'itération suivante. La facturation peut être alors effectuée en fonction de chaque itération.
[*:666707df89] Le blog du management de projet, Rédiger un contrat au forfait sur un projet AgileLe forfait est une offre commerciale construite sur un périmètre fermé, la méthode de production Agile autorise le changement.Mon conseil à toute société travaillant dans le marché de contrat au forfait Agile est de passer du temps à définir votre évaluation, cadencement et l’approche de définition du contenu. [...]La première chose que nous avons faite a été de regarder le processus Agile que nous avions entrepris et le découper en trois domaines distincts.[...]Alors, combien cela coûtera-t-il et combien de temps sera nécessaire ? Avec notre contenu défini nous pouvons maintenant concentrer à établir le prix et la durée. Et, pour ce faire, nous devons regarder la Vélocité de l’Équipe, combien de points une équipe peut-elle réaliser pendant une itération ?
J'ai bien aimé le cette phrase :
Et cette statistique est assez intéressante et doit nous parler à tous :Forfait vient du vieux français fors faire qui signifie… faire du mal !
Ceci dit, il est vrai que je n'ai pas d'expérience concrète en mode Agile, donc en mode forfait ou Agile, ce projet reste difficile à appréhender pour moi...Selon le Standish Group (étude de 2009) : en moyenne, 38% des projets informatiques atteignent leurs objectifs initiaux. 33% aboutissent à un échec et 29% sont purement et simplement abandonnés.
Tu fonctionnes comment toi? Il t'arrive de bosser seul sur des projets en mode Agile? - [*:666707df89] Xebia: Pourquoi les projets Agiles ne peuvent pas vraiment être menés au forfait ?
- Contacter en MP
Hans
Nombre de posts : 515Nombre de likes : 0Inscrit : 5 mai 2008
C'est plus vraiment un forfait s'il n'y a pas d'obligation de résultat. Et dans un tel contrat, tu présentes le contexte global et l'objet du contrat est une enveloppe de XX jours pour travailler dans ce contexte mais sans obligation de résultat car le contexte n'est pas fixé pour l'instant.pacodoso a écrit : Mais ça existe donc un contrat en mode forfait sans obligation de résultat? J'ai un collègue freelance qui sur un projet similaire bosse en mode régie, avec un engagement reconductible chaque mois.
J'avais fait un portage IOS/Android vers Windows Phone/Store il y a 2 ans, il y avait 35 jours de prévus (pas mon chiffrage), pas mal d'intermédiaire. Mais moi, je n'ai vendu que 35 jours de travail, sans aucune obligation de résultat. Cela s'est bien passé au final mais le cahier des charges (sur lequel je n'étais pas engagé), c'était une application fonctionnelle sous Android/Ios, donc quelque chose de concret.
Je proposerais de faire 2 mois en régie chez lui pour faire une première version de démo. Tu va échanger au jour le jour avec lui et en fonction de l'avancement, vous allez cadrer sur ce qu'il sera possible de réaliser en 2 mois. N'ayant pas d'engagement de résultat, tu travailleras l'esprit tranquille. Tu avanceras à ton rythme, tu gères sans stress les problèmes de matériel et/ou maquette graphique qui n'arrive pas, etc. Et si cela n'avance pas assez vite, tu pourras lui expliquer facilement ou cela bloque et pourquoi et il ne pourra pas te dire grand chose car il te verra à l'oeuvre tous les jours.pacodoso a écrit : Oui le client est proche de chez moi : nous sommes dans la même ville.
Mais suite à l'analyse plus "réaliste", la durée serait plutôt de 105 jours : je ne sais donc pas si une régie de 5 mois est intéressante pour le client, surtout qu'il semble "pressé".
Du coup quelles seraient les alternatives?
- proposer de prendre 1 ou 2 freelances que je connais, et monter "une équipe" en mode régie?
- essayer de découper le projet en lots, et de rester sur un mode forfait plus classique? cela devrait permettre de limiter les risques pour moi, comme pour lui...
Oui, c'est la moins souple (pour lui comme pour toi) et la plus risquée (la aussi pour lui comme pour toi). Mais bon s'il veut absolument un engagement au forfait, je vois pas mieux. Mais c'est chiant car il va falloir prendre le temps de chiffrer, en fait d'écrire son cahier des charges. Attention, il pourrait alors récupérer ta proposition, en faire un cahier des charges et demander à d'autres prestataires de s'engager moins cher ...pacodoso a écrit :
D'accord, cela permet de cadrer le projet et les éventuelles demandes du client, mais c'est la solution la moins souple et la plus risquée non?Hans a écrit : Autre possibilité :
Après s'il veut un chiffrage et un engagement de résultat, il termine d'abord les maquettes (cela permettra de figer le visuel et un peu les fonctionnalités) puis vous vous rencontrez pour faire le tour des fonctionnalités. A part de cela, tu rédiges ta proposition en listant et détaillant précisément les fonctionnalités (avec visuels), l'environnement technique, etc. Tu donnes le chiffrage pour cela, en concluant que les modifications fonctionnellement par rapport à ce contrat/devis feront l'objet d'un avenant à définir mais dont le taux journalier est de XX€ HT. Cela prends du temps mais c'est nécessaire avant d'envisager un forfait. S'il veut un forfait mais ne veut pas cette démarche, c'est qu'il veut clairement que tu ne cadres pas le projet pour qu'il garde de la marge de manœuvre.
Le forfait ici, vu comme cela se présente est à abandonner, c'est tout. - Contacter en MP
Hans
Nombre de posts : 515Nombre de likes : 0Inscrit : 5 mai 2008
Je ne suis pas d'accord, pour une majorité de commerciaux/ingénieur d'affaire de SSII en France, ton dernier projet a été fait en Agile. Donc tu as une expérience concrète de l'Agile !pacodoso a écrit : il est vrai que je n'ai pas d'expérience concrète en mode Agile - Contacter en MP
pacodoso
Nombre de posts : 350Nombre de likes : 7Inscrit : 21 janvier 2016
Dans la manière de fonctionner oui, c'est vrai : je livrais une mise à jour toutes les 3 semaines une version, intégrant de nouvelles fonctionnalités ou corrigeant les bugs remontés.Hans a écrit :
Je ne suis pas d'accord, pour une majorité de commerciaux/ingénieur d'affaire de SSII en France, ton dernier projet a été fait en Agile. Donc tu as une expérience concrète de l'Agile !pacodoso a écrit : il est vrai que je n'ai pas d'expérience concrète en mode Agile
Mais par contre on était parti de spécifications fonctionnelles et techniques assez détaillées, ce qui semble être rarement le cas en mode Agile.
Et par contre, il n'y avait pas de Product owner, de Scrum Master, etc...
Par contre, il y avait (en théorie?) un chef de projet qui n'a pas été très utile. - Contacter en MP
Hans
Nombre de posts : 515Nombre de likes : 0Inscrit : 5 mai 2008Ce que je voulais dire, c'est que pour ces SSIIs la, ils parlent de méthodes Agiles pour cacher le fait qu'il n'y a plus de méthode. C'est ISO 1664, c'est tout.
Scrum n'est pas la seule méthode agile. Et elle est très rarement utilisé pour de vrai en France. Par exemple sur Grenoble, dans tout mon réseau de connaissances (et on en rencontre lorsque l'on est indépendant), j'en connais qu'un qui a bossé en Agile avec Scrum.
C'est comme les Ados et le sexe. Ils en parlent tous mais personne connait.
Une fois, une boite m'avait bien fait rire : ils disaient travailler en méthode Scrum mais pour le projet qu'ils proposaient, en fait le client (et donc le product owner mais aussi le scrum master) se trouvait à Toulouse, pour une mission à effectuer pour moi sur Montpellier. Il y aurait eu un "scrum master proxy" pour faire le lien avec les gars à Toulouse. Si on marche pas sur la tete la.
Il y a de moins en moins de méthode dans l'informatique. - Contacter en MP
phili_b
Nombre de posts : 536Nombre de likes : 12Inscrit : 8 octobre 2014
Ben ce n'était pas un projet Agile. Point à la ligne.pacodoso a écrit : Mais par contre on était parti de spécifications fonctionnelles et techniques assez détaillées, ce qui semble être rarement le cas en mode Agile.
Et par contre, il n'y avait pas de Product owner, de Scrum Master, etc...
Par contre, il y avait (en théorie?) un chef de projet qui n'a pas été très utile.
Les itérations ne suffisent pas à déterminer que c'est un projet Agile. En Agile les spécs sont remplacées par les User Stories. Il n'y a pas de notions de chef de projet en mode Agile. Si le Scrum Master peut quelque fois être porté par le Lead Dev ou le Product Owner, j'ai du mal à comprendre comment un projet en mode Agile peut fonctionner sans Product Owner puisque c'est lui qui retranscrit les demandes utilisateurs en User Story et qui est garant du contenu fonctionnelle du projet.
Comment peux-tu proposer un projet avec la méthode Agile alors que tu ne semble pas maitriser toutes les facettes d'un projet avec cette méthode ?
En plus même pour quelqu'un maitrisant la méthode Agile, il est très difficile de travailler avec un client ne la connaissant pas sans lui faire une explication détaillée du fonctionnement spécifique de cette méthode, puisque cette méthode est différente de la méthode traditionnel en V.
Il faut effectivement agir de cette façon.pacodoso a écrit : Je lui ai ainsi proposé de développer l'application suivant une méthode Agile, en priorisant les fonctionnalités, et en enrichissant l'application de manière progressive.
Certes, mais il faut absolument faire des étapes de livraisons intermédiaires avec enrichissement progressif en faisant valider ces fonctionnalités par le client à chaque étape, surtout en mode Agile. Et même en mode non Agile l'absence de cahier des charges rend impératif les lotissements de livraison avec validation à chaque livraison.pacodoso a écrit : Mais il souhaite que l'ensemble des fonctionnalités (création de compte utilisateur, géolocalisation de partenaires, réservation de prestations chez un partenaire, offres promotionnelles, etc...) soient disponibles dès la première version publique.
Le pompon est de rajouter à toutes ces difficultés le contrat au forfait.EURL / IR / BNC - Contacter en MP
phili_b
Nombre de posts : 536Nombre de likes : 12Inscrit : 8 octobre 2014
J'ai travaillé un peu plus d'un an en tant que Product Owner dans une entreprise complétement Agile: un Scrum Master répondrait de façon plus exacte que moi.pacodoso a écrit : Tu fonctionnes comment toi? Il t'arrive de bosser seul sur des projets en mode Agile?
Sans doute qu'on peut travailler seul sur des petits projets Agile, en cumulant les casquettes, mais a priori l'esprit de l'agilité c'est le travail en équipe. Mais même en cumulant les casquettes, il manque toute la relation avec les utilisateurs dans le projet dont tu parles: le Product Owner doit être en relation constante avec les gens du métier, et pas seulement au moment de la recette de chaque lots. Et les autres défauts dont on a parlé plus haut.
On dirait qu'à part l'aspect itératif de ton projet, il n'y a pas grand chose d'Agile dans ton projet. En fait, Agilité ou non, tu te créés tout les problèmes possibles : Forfait, pas de cahier des charges, méthode Agile suicidaire en mode forfait, pas assez d'itérations/validations.EURL / IR / BNC - Contacter en MP
jmolive
Nombre de posts : 2199Nombre de likes : 8Inscrit : 24 mars 2012
Enorme 8)Hans a écrit : ils parlent de méthodes Agiles pour cacher le fait qu'il n'y a plus de méthode. C'est ISO 1664, c'est tout.
Je suis d'accord.Gérant maj. EURL IS clot 30/09 - Contacter en MP
François1
Nombre de posts : 2526Nombre de likes : 9Inscrit : 4 avril 2008Bonjour,
Il y a ici confusion entre le mot forfait qui désigne une sorte de crime, dont l'origine est bien forfaire (faire du mal), et le terme de forfait pour le tarif d'une prestation, qui vient du vieux français fur (taux) et du verbe faire, autrement dit: taux fait ou taux fixé.pacodoso a écrit : J'ai bien aimé le cette phrase :
Forfait vient du vieux français fors faire qui signifie… faire du mal !
Ça ne change rien aux différentes explications données, mais c'était juste pour dire que le forfait, non, ce n'est pas le mal. 😉
Cordialement
--
FrançoisFrançois - Contacter en MP
pacodoso
Nombre de posts : 350Nombre de likes : 7Inscrit : 21 janvier 2016J'ai envoyé un mail assez détaillé au client, en lui faisant une estimation assez large en mode "forfait" : entre 100 et 150 jours. Je lui ai expliqué que pour affiner le chiffrage, il faudrait réaliser une analyse plus poussée, et rédiger un cahier des charges.
Du coup, je lui ai proposé de réaliser le projet en mode "régie", avec une approche Agile. Je lui ai expliqué en quelques mots en quoi consistait l'approche Agile, et quelles étaient les avantages pour une start-up. Je lui ai clairement dit que n'ayant pas d'expérience en méthode Agile, il faudrait que je me forme, ou qu'on fasse appel à une société intervenant en mode "coaching/conseil" sur cette problématique.
Enfin, je lui ai fait une proposition d'architecture pour la solution.
Voici sa réponse:
Bon, je comprends que je n'aurais peut-être pas dû être honnête sur la problématique "Agile", et encore...Merci pour votre analyse et pour ces informations
En conclusion j'aurais aimé que vous puissiez vous positionner en termes de délais et en terme de prix final
je comprends que vous deviez encore monter en compétence sur certains points mais vous comprendrez que je ne peux en tenir compte
Vous êtes à mes yeux un professionnel et en aucun cas quelqu'un en formation
En conclusion le professionnel que vous êtes doit pouvoir m'apporter la garantie d'une application fonctionnelle et efficace à un prix déterminé le tout livré dans des délais convenus
Je suis Persuadé que vous comprenez mes exigences
Je reste dans l'attente de votre offre finalisée afin que nous puissions envisager l'avenir
Mais au final, il attends une estimation chiffrée, sans cahier des charges!
Comment réagiriez-vous? Est-ce la peine de lui répondre?
Je précise qu'actuellement j'ai une opportunité beaucoup moins risquée (régie de 3 mois chez un client, sur la même techno), donc je ne compte pas me risquer sur ce projet.
