Blog
Un projet au forfait en mode agile : l’équation impossible des Startups ?

Partager

L’écosystème des Startups du numérique

En France

L’essor des startups depuis quelques années, porté par une politique Française ambitieuse, n’est plus à démontrer.

A BigInt

Nous recevons de nombreuses sollicitations pour développer tel site web ou telle application mobile comportant toujours des innovations technologiques, fonctionnelles ou d’usage.

Elles représentent assurément l’idée du siècle pour leurs porteurs qui ont des étoiles pleins les yeux quand ils en parlent. Nourris de grandes ambitions, ces projets arrivent avec un cahier des charges souvent léger, en plein chantier voir parfois inexistant. Coté budget, il est souvent fixé d’avance, étroitement lié aux levées de fonds déjà réalisées ou en cours.

Ces startups fonctionnent de nos jours en mode “Lean”. Elles évoluent, sont à l’écoute de leur clients, de leurs investisseurs et donc changent de périmètre, pivotent. Le développement de leurs produits ou services impliquent donc la mise en place de méthodes de travail dites “Agile” pour nos équipes de développement.

Partenariat

Aussi cet article va modestement aborder les problématiques de contractualisation et de partenariat qu’impliquent ce genre de projet. En particulier, nous aborderons l’aspect financier au travers des estimations de temps ainsi que la partie organisationnelle par les méthodes de développement en continue.

Définition: Lean Startup
Une “Lean Startup” est une entreprise qui à une idée mère, et qui s’adapte pour suivre son marché, améliorer son taux de pénétration, et augmenter son chiffre d’affaire. Pour cela, elle se transforme, les postes de travail s'adaptent, l’offre change, le service évolue en permanence.
Le Lean Startup a été élaboré par Eric Ries, entrepreneur aguerri, mais aussi ancien développeur qui a beaucoup utilisé l’agilité. On le retrouve dans des principes Agile dont on peut ainsi résumer les principaux objectifs :
  • permettre de monter une société très rapidement (important dans un monde devenu ultra concurrentiel)
  • être en adéquation le plus possible avec les besoins du marché (avec une approche terrain active)
  • développer un produit avec des cycles itératifs très courts
  • réduire (ou maximiser) les investissements nécessaires
  • valider l’accroche au marché et aux clients par des expérimentations utilisateurs mesurables
Développement Agiles : Un développement Agile va être réalisé à travers des “sprints” ou “itérations” où l’on va délivrer en continu de la valeur.
On part d’une feuille blanche, on commence à développer tout en définissant à chaque sprint les évolutions à apporter. Le client va challenger chaque livrable, apporter des modifications ou entamer un nouveau cycle. Cela permet de produire un maximum de valeur en un minimum de temps.

De la régie ou du forfait ?

Au forfait

Historiquement, dans le domaine du développement informatique, on contractualise les projets au forfait : pour un objectif préalablement défini par le client, le prestataire s’engage sur un prix, avec une deadline fixée et donc un temps limité.

→ Le forfait est intéressant pour le client car il n’y a aucun risque: c’est la garantie que le projet sera livré conforme et à l’heure

Pour le prestataire, cela implique d’avoir des spécifications fonctionnelles les plus détaillées possible en amont pour faire une bonne estimation, puis il a une flexibilité très limitée une fois les développements démarrés.

Pour les Lean Startup, les spécifications viennent au fur à mesure de leur vie, il n’est donc pas possible d’estimer ce que le projet sera capable de devenir. Les choix sont donc délicats au début d’une startup dont le business à court et moyen terme est encore assez incertain.

☆ Le forfait est risqué pour le prestataire car son estimation en début de projet conditionne la rentabilité. Il porte tout le risque financier.

Au temps passé

Mais il est également possible pour le prestataire de travailler en mode régie. Dans ce cas, il défini ses objectifs, demande des estimations mais quelque soit la durée pour réaliser une tâche, on facture le temps passé par chaque personne de l’équipe.

→ La régie est intéressante pour le prestataire car quelque soit le temps ou les ressources mises à disposition, le client assume leurs coûts

Pour une startup, l’aspect Lean est un fondement, il n’est donc pas possible de détailler un cahier des charges en début de projet. Il faut donc adapter les objectifs constamment, néanmoins, le budget doit être maitrisé initialement et la deadline ne doit pas être reportée de manière irraisonnable.

☆ La régie présente un inconvénient pour le client qui va porter l’intégralité du risque financier.

Et qui pilote ?

De l’importance du “product owner” et du “project manager”

Lorsque les spécifications sont posées d’avance et que le risque de dérapage est trop grand, s’il y a une problématique, le prestataire prend la décision la plus appropriée au regard du budget initial.

Dans une approche lean, le chef de projet communique avec le chef de produit pour s’accorder sur la marche à suivre. Cette relation est indispensable à l’adaptabilité du produit tout en respectant un budget.

Ces deux rôles sont devenus la clé de la réussite d’un projet pour une startup :

→ D’un côté on doit avoir un product owner qui se charge de définir les éléments constitutifs du produit. Il doit cumuler un savoir faire technique dans la conception et la définition des caractéristiques et apporter un maximum de valeur métier aux utilisateurs (tout en ne faisant pas fi du temps et du budget imparti par le client)

→ Côté prestataire, le chef de projet (technique le plus souvent) se charge de piloter les équipes de développement afin d’apporter l’adéquation entre la demande et la réalisation (tout en respectant l’ordre de grandeur de budget accordé par le client)

Lorsque ces deux rôles sont bien tenus de part et d’autre, ils ont un bénéfice inestimable : celui de développer la collaboration et l’engagement entre l’équipe et le client. Tous se retrouvent dans le même bateau et se mettent naturellement à ramer dans le même sens. Le contrat d’une équipe agile devrait être compatible avec cette intention de solidarité.

Accessoirement, cette solidarité pourrait être traduite financièrement par les deux propositions suivantes :

  • Le client et le prestataire partagent financièrement les succès
  • Le client et le prestataire assument financièrement la responsabilité d’un retard
    • Méthodes agiles : laquelle choisir ?

      Je ne me risquerai pas à donner une réponse toute faite à cette question. cela dépend d’un nombre de facteurs importants, et aucune solution miracle n’existe. Quelque soit la méthode, c’est surtout une garantie de visibilité pour le client et une méthode d’organisation pour l’équipe. Laquelle adapte la méthode à ses propres contraintes.

      A BigInt, nous pratiquons Scrum et Kanban, en fonction des fonctionnalité à réaliser :

      • Scrum pour le côté “atomique” d’un besoin : définition, réalisation, test, livraison (lorsque le développeur est full-stack, sur un besoin bien spécifique)
      • Kanban pour la “dépendance” entre les tâches : lorsque le besoin fait intervenir plusieurs compétences / technologies et que les ressources sont débordées
        • De mon expérience, une chose est sûre : les méthodes Agiles sont seulement des outils pour vous aider dans la gestion de votre projet. Une méthode type Scrum peut très bien fonctionner avec une équipe de développement et être totalement contre productive avec une autre. Il en va de même pour Kanban. Cela dépend des tâches que vous avez à gérer et de leurs dépendances.

          D'ailleurs si votre équipe est trop “Junior” ou a peur de s’engager, souvent par manque d’expérience ou de visibilité, il est inutile d’essayer d’estimer chaque tâche que vous allez leur confier.

          Certains coachs agile prônent aujourd’hui le mouvement “no estimates”, je les rejoins car je considère que nous perdons beaucoup de temps à estimer l’inestimable, je vous conseille cet article. L’équipe devra prendre dans le Sprint le nombre de demande qu’elle pensera faisable sans aucune pression de résultat final. Ainsi les plannings poker, le burndown chart et autres outils souvent considérés comme indispensables par les coachs Agile en deviennent totalement désuets, car dénués de sens.

          Visibilité sur objectif & budget

          Malgré les outils et méthodes de travail, le temps de réalisation est souvent assez éloigné des estimations. Dans ce contexte de développement incertain, on ne peut que faire des estimations vagues avec des marges d’erreur très large, surtout à +4 mois (8 sprints).

          Le seul outil qui reste indispensable à mon sens est un bon board de suivi des tâches prêtes à être lancées / en cours ou en démo. Idéalement, ce sont des “macro” tâches mais quelques fois, des innovations technologiques de plus grosse importance.

          Également, le daily meeting permet de savoir qui fait quoi, qui a besoin de quelle info, et si les choses avancent à un rythme convenable dans leur ensemble.

          La vision de la Startup est toujours plus rapide que la capacité d’exécution, ce n’est donc pas à vos équipes de développement de supporter une pression toujours grandissante sous prétexte de sprints comprenant un nombre intenables de stories à réaliser. Cela n’engendre que frustration pour le prestataire et perte de confiance pour le client.

          A ce sujet, un des gourous des méthodes agiles dit aujourd’hui que leur but a été détourné, je vous invite à lire un des articles dont j’ai pu m’inspirer et qui traite de la question ici !

          Livraison sous 2 semaines

          Un point important que je souhaitais aborder est le concept de livraison ou plutôt de “démo” ainsi qu’une communication de planning transparente. Dans une phase initiale de projet, penser que vous allez obtenir quelque chose de “relevant” au bout de 2 semaines est un peu prématuré.

          Dans cet article, on parle de contruction d’un produit pour une “Lean Startup”: il va donc falloir aborder le projet à travers une longue phase de réflexion et de considération des besoins actuels et à venir potentiels de la startup.

          Mettre en place des spécifications précises (ce qui inclut le travail de définition des workflow, d’UX associée) ainsi que de l’architecture de la base de données et des frameworks que l’on va utiliser (tant coté Back-End que Front-End) demande du temps, de la réflexion, de l’anticipation.

          Aussi pour un projet avec un minimum d’envergure, proposer une première “démo” de son futur site ou application à votre client avant un bon mois de travail n’est pas très rationnel.

          Une fois que les choses sont mises en place, que les premiers écrans fonctionnels sont prêts à être présentés, alors on peut passer à un rythme de démos clients plus soutenu.

          L’équation

          Développements variable à coût fixe

          De nos jours, le challenge consiste donc à résoudre l’équation suivante : comment mettre en place une cellule agile en régie, avec un périmètre variable, mais à un coût fixe ?

          Pour un périmètre et une deadline fixe, il est bien évidemment possible de mettre plus de ressource, mais cela a un coût pour le prestataire, ce qui est incompatible avec le forfait.

          Pour un budget fixe, il est possible de limiter le nombre de fonctionnalité, mais cela n’est pas à l’avantage du client qui devra assumer son manque voir pour une fonctionnalité indispensable, être rédhibitoire.

          Autrement dit, comment on fait de l’agile au forfait ?

          Un contrat “hybride”, cohérent avec une méthode de développement Agile et un fonctionnement Lean Startup, pourrait représenter le compromis idéal.

          Cette approche nécessite une définition des ambitions initiales du projet, que l’on va d’abord traduire en une charge en nombre de personnes et en durée. Puis une mise en oeuvre agile pour compenser l’éventuel ajout de fonctionnalités conséquentes par le retrait de fonctionnalités de même poids par rapport au backlog initial.

          A l’issue des sprints le client peut soit décider de stopper les développements, car il jugent ceux-ci suffisants à la mise en oeuvre de son service, soit il décide de continuer sur des sprints supplémentaires.

          Si la finalisation du projet se termine en avance par rapport aux prévisions, le client ne paie qu’une partie du montant restant sur le contrat initial. Les bénéfices (pour le prestataire) ou économies (pour le client) sont ainsi partagés.

          Si au contraire le projet n’est pas terminé à l’issue de la date estimée lors de l’établissement du contrat, le client paie le restant des développements au prestataire à un tarif réduit, voir à prix coûtant, ainsi les deux parties assument financièrement les débordements / retards dûs à un périmètre de fonctionnalités qui a généralement été revu à la hausse par rapport aux premières estimations.

          On allie ainsi les bénéfices de la régie et du forfait pour les deux parties, les risques sont partagés et la souplesse nécessaire à ce type de développement est conservée.

          Agile au forfait

          Conclusion

          Développer une plateforme Web ou une application mobile pour une StartUp n’est pas compliqué, c’est notre métier. Mais mettre en adéquation un objectif et un budget entre 2 parties qui n’ont pas les mêmes impératifs est un challenge. Avec une bonne relation et des méthodes adaptées, il est possible de délivrer de la valeur dans des coûts et des délais raisonnables.

          A partir de l’instant où le client et le prestataire travaillent main dans la main, ils peuvent intelligemment arbitrer les choix et les décisions pour produire ce qui a le plus de valeur. Quitte à savoir reporter à une date ultérieure ce qui pourrait être idéal mais n’est pas réalisable dans le budget et les délais initialement définis.

comments powered by Disqus