Discussion :

[Garvelienn]

Bien le bonjour,

Aujourd'hui, je souhaiterais lancer une discussion qui aurait pour issue aucune bonne ou mauvaise réponse. Le but est juste de partager son expérience sur un sujet qui fait souvent peur/râler/fuir les développeurs : la création de devis et estimer des tâches.

Peut-être que ce type de discussion a déjà été lancé auparavant. Si oui, modérateurs, faites-vous plaisir.

Pour commencer, je vous présente ma manière de calculer aujourd'hui. Pour être honnête, elle change très régulièrement.

Mon contexte est que je dois effectuer un devis pour toute une équipe de développeurs.

----

Définition du besoin avec le client

La première chose que je fais est que je pars à la recherche d'informations auprès du client.

Ma stratégie est donc qu'une fois que le client exprime son point de vue, je le transforme avec plus détails que je lui repropose. Ce n'est pas une spécification mais on s'y approche. Cela permet de stimuler le client sur son idée/sa réflexion. Ici, déjà, beaucoup de développeurs râlent déjà du fait que ce n'est pas à eux de définir le besoin mais au client. Personnellement, je pense que c'est naïf de penser cela. N'hésitez pas à réagir là-dessus.

La durée de cette échange ne doit pas être trop long. Il ne sert à rien de rédiger des spécifications dès maintenant. Ça crame du temps potentiellement pour rien si le client n'en veut finalement pas.

Ensuite, à partir des éléments retenus, je commence la phase estimation.


Manière de calculer

Pour une demande, j'identifie généralement 4 types d'activités : dev, test, doc, autre.

Pour chaque activité de type dev, j'y rajoute 75% de temps en plus pour les tests unitaires.
Pour chaque activité de type doc, j'y rajoute 20 à 30% de temps d'aller-retour avec le client.

Avec le total de tout ça (dev + test + doc + tests unitaires + échange doc), je rajoute :

• 20% de temps de maintenance (correction, support interne, support CI, etc) ;
• 15% de temps de gestion (Product Owner, préparation des tickets, etc) ;
• 30% de temps d'incertitude (mauvaise estimation, imprévus, montée en compétence, etc) ;

Au total de tout cela, du fait que l'équipe fonctionne en Agile avec la méthode SCRUM en sprint de 2 semaines, je rajoute 25% de temps de réunions.
Ce chiffre comporte les cérémonies Scrum (Sprint planning metting, Sprint review, Sprint retro, dailys = ~1j / personne tous les 4 jours) et toutes les autres réunions & discussions de l'équipe (~1j /personne tous les 4 jours). Ce chiffre a été confirmé par l'expérience sur plusieurs sprints.

Donc au final, pour une activité de type :

• dev = dev * (1 + 0.75) * (1 + 0.20 + 0.15 + 0.3) * (1 + 0.25) = dev * 3.61
• doc = doc * (1 + 0.30) * (1 + 0.20 + 0.15 + 0.3) * (1 + 0.25) = doc * 2.68
• test = test * (1 + 0.20 + 0.15 + 0.3) * (1 + 0.25) = test * 2.06
• autre = autre * (1 + 0.20 + 0.15 + 0.3) * (1 + 0.25) = autre * 2.06

On constate un facteur entre 2 et 3 pour chaque estimation de réalisation. Pour le moment, ce chiffre est confirmé par l'expérience. Mais en fonction des projets, des équipes, du client, ça peut changer.

Par ailleurs, à tous cela, je rajoute des temps de livraison (freeze du code, validation, livraison).

Manière d'estimer

Lorsque j'estime une activité dev, test, doc, autre, je prend en compte ma connaissance, ce que j'imagine, l'expérience des imprévus (même sur les tâches faciles), que quelqu'un avec un niveau différent s'y collera, etc.

Une fois que j'ai estimé tous les besoins du client, je vais embêter l'équipe avec une réunion dédiée afin qu'ils stressent mes chiffres. Ainsi, du fait des expériences et des connaissances différentes de chaque, nous obtenons des chiffres plus réaliste. Le fait de faire une première estimation de mon côté en premier permet de stimuler l'équipe lorsque nous en parlons. Sinon, on risque d'avoir des réactions du type "bof", "c'est impossible", "je ne sais pas", "ça dépend", etc.

Pour moi, la personne qui gère le devis doit faire partie de l'équipe de réalisation. Sinon, c'est sûr que ce sera faux/truqué.

Validation du devis

Si une activité est détectée comme trop imprécise en l'état, hop, je vais embêter le client. Mais toujours en lui proposant des solutions/actions. Sinon, il ne saura pas répondre/statuer.

Ensuite, je vais proposer ces chiffres au client. On en parle, discute, défend nos idées. Normalement, le client sélectionnera des idées et d'autres non.

Je refais un devis en enlevant les idées non-retenues. Le client, normalement, signe. Et seulement là, j'écris les mini-spec pour que l'équipe sache où aller. Celles-ci sont indicatives. Autrement dit, elles peuvent évoluer en fonction des événements dans l'équipe ou du client => Agile.


A vous

Cela peut paraître complexe comme cela. Mais au final, cela répond plutôt bien à la réalité de mon équipe. Peut-être que cela pourrait être simplifié et/ou amélioré.

Le sujet est très complexe, et aucune méthode ne sera générique. Voici donc mon partage d'expérience.

J'espère que le sujet intéressera.

A vous !

[Mat.M]

Pour une demande, j'identifie généralement 4 types d'activités : dev, test, doc, autre.

bonsoir et concernant la partie analyse, conception quid ?

[Garvelienn]

L'analyse et la conception rentrent dans la catégorie "autre".

En effet, la conception est généralement présente dans les devis. Une première phase de conception est "devisée" avant les "devs". Comment j'estime le temps de conception ? C'est de la magie noire. Plus sérieusement, je me fie à mon expérience pour essayer de deviner le temps nécessaire pour obtenir une première base d'architecture et conception du produit. Mais cette phase ne doit pas avoir en sortie une architecture finie. A mes yeux, il est illusoire de croire qu'on peut sortir une architecture et qu'elle fonctionne telle quelle. Il y a toujours des oublis, des inconnues et changements de cap qui la mettront à mal. En gros le cycle en V sur du logiciel, c'est risqué. Attention, je ne dis pas que l'Agile c'est mieux.

Pour l'analyse, cela va dépendre du sujet et du client.

Certains clients sont OK pour payer une phase d'analyse permettant après de faire un devis plus précis. Dans ce cas, l'estimation en temps de cette phase d'analyse a un budget max. Cela tourne en général autour de 1 à 2 semaines homme-jour. Le but de l'analyse étant de se rassurer sur la faisabilité et pas de faire un développement. Il y a donc généralement une petite phase état de l'Art allégé qui fait ressortir deux-trois pistes à explorer. Et en fin d'analyse, on définit quelle piste est la plus prometteuse.

Si le client ne veut pas payer en deux fois, alors dans le devis, j'inclus la phase d'analyse avec les mêmes chiffres. Mais j'augmente le facteur "incertitude" à 40-50%, en étant très transparent là-dessus. Généralement, il revient sur sa décision et veut la phase d'analyse à part.

Il est évident qu'en fonction de la prestation, la phase d'analyse peut ne pas être présente (ex: techno déjà connue).

[Mat.M]

bonsoir si la phase de conception ne rentre pas en ligne de compte et est mise de côté, bon ben je pense que c'est assez simple par contre il faut faire ça de manière empirique.
Si vous travaillez sur un écran qui sort un bilan comptable par exemple eh bien il faut saisir dans un outil de reporting voire dans une feuille Excel que cela a pris 10heures pour produire ce genre d'écran + les requêtes SQL + les tests etc...

mais encore une fois oui il faut faire cela de façon empirique à moins que la complexité du projet ne change et que le client demande par exemple des calculs d'ingénierie pointus

Pour l'analyse, cela va dépendre du sujet et du client.

eh bien si le cahier des charges est fait en amont eh bien il faut prendre un éditeur de workflow qui va générer du code automatiquement et il n'y aura plus grand chose à faire

[yento]

Certains clients sont OK pour payer une phase d'analyse permettant après de faire un devis plus précis. Dans ce cas, l'estimation en temps de cette phase d'analyse a un budget max. Cela tourne en général autour de 1 à 2 semaines homme-jour. Le but de l'analyse étant de se rassurer sur la faisabilité et pas de faire un développement. Il y a donc généralement une petite phase état de l'Art allégé qui fait ressortir deux-trois pistes à explorer. Et en fin d'analyse, on définit quelle piste est la plus prometteuse.

Si le client ne veut pas payer en deux fois, alors dans le devis, j'inclus la phase d'analyse avec les mêmes chiffres. Mais j'augmente le facteur "incertitude" à 40-50%, en étant très transparent là-dessus. Généralement, il revient sur sa décision et veut la phase d'analyse à part.

En ce qui me concerne, tous les projects suivent le meme deroulement:

Analyse des besoins. On etablit l'objectif, les fonctionalites critiques et une ebauche d'architecture (decoupage en composants et specialites).
On commence par travailler sur les composants les plus risqués/inconnus, pour determiner si ils sont realisables ET le sont dans des delais/couts raisonable (sinon le projet tombe a l'eau).
Un projet commence avec 80% de recherche et peu de developpement, et la proportion de recherche diminue progressivement sur les premieres semaines (ou mois si long projet).

Une fois qu'on a le MVP et les principaux composants, c'est beaucoup plus simple, on peut montrer au client et discuter.
Rencontrer avec le client toutes les deux semaines pour montrer l'avancement, obtenir un retour et determiner sur quoi se concentrer ensuite.
Une fois le milieu du projet atteint, on est en vitesse de croisiere et a normalement une bonne idee de la ou on va (meme si le developpement est loin d'etre complete). On sait si le projet apporte quelque chose au client et qu'il va payer.

Petite pause d'un mois. Surprise, les employes ont 20+ jours de vacances a prendre, donc il y doit bien y avoir un vide quelque part.
J'aime bien insister la dessus. C'est tres important de prevoir des semaines de trou en ete, a noel, et ailleurs, sinon on rate le planning/gant completement

En SSII, on bloque le dernier mois pour la recette, transfert du projet, transfer du materiel, formation chez le client, etc...


Bref, unified process.
https://fr.wikipedia.org/wiki/Processus_unifi%C3%A9

Tous mes projets sont systematiquement en unified process meme si personne ne le sait. Et parfois j'arrive meme a glisser des diagrammes UML. http://www.plantuml.com/



Maintenant passons au devis,
Si on parle de devis, toujours sur du projet long (6 mois et plus avec plusieurs developpeurs):

On a 1-2 semaines de discussion et de recherche avec le client. Meme principe.
Le devis, c'est simple, c'est l'art de penser en ressource alors que le client (et le vendeur inexperimente) pensent en resultat.

On essaye de comprendre le besoin et de decouper en composants (base de donnees, site web, API, hardware, etc...).
A la louche, on determine l'ordre de grandeur de chaque piece et ce qui est le plus risque (par exemple un site web de pizzeria, c'est de l'ordre de semaines, un site web qui doit gerer des paiments en 5 devises et etre traduit en 5 langues, ca va prendre des mois).
Toujours a la louche, On determine les competences demandes. Combien de personnes et de specialites sont necessaire? et peuvent travailler en paralllele?
On voit qu'il y a de l'UI complexe ca peut prendre plusieurs developpeurs front, du hardware, ca demande des ingenieurs hardware, de la base de donnees, peut etre un DBA (ou un ticket avec 3 mois d'attentes).

A noter que lorsque l'on vend une equipe (ce qui est ton cas), on vend l'equipe qu'on a. C'est a dire que le devis est relativement restraint en fait (ce serait bob et ou alice? pour combien de temps? ca depend combien de temps le client est pret a payer).
L'equipe a des competences diverses et divers niveaux d'experiences (et sans doute des lacunes), quand on connait bien l'equipe, on peut prevoir telle personne sur telle tache.

Ensuite c'est de la negotiation. On met X personnes disponibles sur les 3-12 prochain mois. On rajoute un chef de projet tous les 2 developpeurs (#SSII).
Ca fait un pack, tant de personnes a tant d'euros par jours. On decoupe par specialite et par niveau parce que c'est un prix different et voila le devis detaille.

Au final ce qu'on vend réellement au client, c'est de mettre quelques personnes sur leur projet a plein temps, et ca devrait bien aboutir a quelque chose au bout de 6 mois!
C'est pas sorcier.