Comment répondre quand on vous demande un devis?

En tant que programmeurs, on nous demande constamment «combien de temps cela prendra-t-il»?

Et vous savez, la situation est presque toujours la suivante:

• Les exigences ne sont pas claires. Personne n’a procédé à une analyse approfondie de toutes les implications.
• La nouvelle fonctionnalité va probablement briser certaines hypothèses que vous avez faites dans votre code et vous allez commencer à penser immédiatement à tout ce que vous pourriez avoir à refactoriser.
• Vous avez d'autres tâches à accomplir dans le cadre de missions antérieures et vous devrez produire une estimation tenant compte de ces autres tâches.
• La définition du "fait" n'est probablement pas claire: quand sera-t-il terminé? 'Terminé' comme juste fini de le coder ou 'terminé' dans "les utilisateurs l'utilisent"?
• Peu importe votre degré de conscience de toutes ces choses, parfois votre "fierté du programmeur" vous fait donner / accepter des délais plus courts que vous ne le supposiez au départ. Surtout lorsque vous ressentez la pression des délais et des attentes de la direction.

Beaucoup d’entre eux sont des problèmes organisationnels ou culturels qui ne sont pas simples et faciles à résoudre, mais en réalité, on vous demande une estimation et ils s’attendent à ce que vous donniez une réponse raisonnable. Cela fait partie de votre travail. Vous ne pouvez pas simplement dire: je ne sais pas.

En conséquence, je finis toujours par donner des estimations que je réalise ensuite que je ne peux pas remplir. Cela s'est produit d'innombrables fois et je promets toujours que cela ne se reproduira plus. Mais c'est le cas.

Quel est votre processus personnel pour décider et livrer un devis? Quelles techniques avez-vous trouvé utiles?

Du programmeur pragmatique: De compagnon à maître :

Que dire lorsqu'on lui demande une estimation

Vous dites "je vais revenir à vous."

Vous obtiendrez presque toujours de meilleurs résultats si vous ralentissez le processus et passez un peu de temps à suivre les étapes décrites dans cette section. Les estimations données à la machine à café (comme le café) reviendront vous hanter.

Dans la section, les auteurs recommandent le processus suivant:

• Déterminez la précision dont vous avez besoin. En fonction de la durée, vous pouvez citer l'estimation avec une précision différente. Dire "5 à 6 mois" est différent de dire "150 jours". Si vous glissez un peu dans le 7ème mois, vous êtes toujours assez précis. Mais si vous passez au 180ème ou au 210ème jour, pas trop.
• Assurez-vous de comprendre ce qui est demandé. Déterminez la portée du problème.
• Modéliser le système. Un modèle peut être un modèle mental, des diagrammes ou des enregistrements de données existants. Décomposez ce modèle et construisez des estimations à partir des composants. Attribuez des valeurs et des plages d'erreur (+/-) à chaque valeur.
• Calculez l'estimation en fonction de votre modèle.
• Suivez vos estimations. Enregistrez des informations sur le problème que vous estimez, votre estimation et les valeurs réelles.
• Les autres éléments à inclure dans votre estimation sont le développement et la documentation des exigences ou des modifications apportées aux spécifications, la création ou la mise à jour des documents de conception et des spécifications, les tests (unité, intégration et acceptation), la création ou la mise à jour des manuels de l'utilisateur ou des fichiers README avec les modifications. Si 2 personnes ou plus travaillent ensemble, cela entraîne des frais de communication (appels téléphoniques, courriels, réunions) et la fusion du code source. Si la tâche est longue, prenez en compte des éléments tels que les autres tâches, les congés (vacances, congés maladie, congés de maladie), les réunions et les autres frais généraux lors du choix d'une date de livraison.

L'estimation de logiciel est la tâche la plus difficile en ingénierie logicielle, suivie de près par la détermination des exigences.

Il existe beaucoup de tactiques pour les créer, toutes basées sur l’obtention préalable de bonnes exigences. Mais quand ton dos est contre le mur et qu'ils refusent de te donner de meilleurs détails, Fake It:

1. Regardez bien les exigences que vous avez.
2. Faites des hypothèses pour combler les lacunes en fonction de votre meilleure estimation de ce qu'elles veulent
3. Notez toutes vos hypothèses
4. Faites-les asseoir, lisez et acceptez vos hypothèses (ou, si vous êtes chanceux, demandez-leur de vous donner et de vous donner de vraies exigences).
5. Vous avez maintenant des besoins détaillés à partir desquels vous pouvez estimer.

C'est comme si ma mère menaçait quand j'étais enfant "Dépêche-toi de choisir des vêtements, ou je les choisis pour toi!"

J'ai fait du développement pour un gars qui tenait beaucoup à vouloir des estimations précises. Ce sur quoi nous avons décidé, qui a très bien fonctionné, était ceci:

• J'ai facturé tout le temps que j'ai passé à estimer. Cela représentait environ 20-25% de ce que j'avais facturé.
• J'ai fait un examen extrêmement détaillé des tâches. Pas de tir de la hanche. Je suis allé dans le code, j'ai découvert quelles lignes devaient être changées, quelles autres parties du programme cela affecterait, combien de tests il faudrait faire pour s'assurer que tout fonctionnait toujours. Je pense chaque pièce en unités de 0,1 heure (6 minutes).
• Je lui ai envoyé mon estimation pour chaque tâche avec cette ventilation détaillée.

20-25% de la facturation semble beaucoup.

Mais il me demandait de changer XYZ, pensant que cela prendrait environ 2 heures. En 1 heure d'estimation détaillée, je déterminais que cela prendrait 8,5 heures. Alors, il déciderait si cela valait 8,5 heures de salaire. Sinon, il a économisé 7,5 heures par rapport à ce qu'il lui aurait coûté si je l'avais fait sans estimation.

Et s'il ne voulait investir les 8,5 heures, le travail de détail , je l'ai fait pour l'estimation était le travail que je l' aurais dû faire de toute façon.

J'ai découvert qu'avec cette méthode, j'étais capable de réaliser la plupart des tâches à temps ou même tôt, sans avoir à surestimer fortement. Comme le temps était si minutieusement décomposé, je pouvais dire très tôt si je glissais. Si je franchissais les barrages routiers de façon à pouvoir dire après trois heures que ma tâche de 8 heures et demie en prenait 12, je pourrais lui en parler avant qu'il ne se soit écoulé plus de temps, de sorte qu'il puisse réévaluer et retirer la fonctionnalité s'il était préoccupé par le coût. .

Était-il nickel et diming? Non, j'ai considéré que le laisser utiliser son argent là où il voyait le plus d'avantages. Et j'étais heureux d'avoir de l'expérience en estimation, pour laquelle j'avais toujours été terrible.

On nous demande souvent une «estimation approximative» lors de réunions où nous avons une idée très large et très large de ce qu’ils aimeraient faire. Je dis toujours: "Si vous voulez une réponse aujourd'hui, c'est un an et un million de dollars. Si vous souhaitez me donner beaucoup plus de détails et un peu de temps pour les examiner, je peux alors les affiner pour vous."

Ils obtiennent presque toujours le point.

Cela dépend de ce que l'estimation est pour.

Pour une estimation initiale de haut niveau pour une analyse de rentabilisation, les éléments clés sont les suivants:

1. La vitesse. Quelle que soit la méthode utilisée, elle doit être rapide. Le problème est que les parties prenantes ne savent pas si cela vaut la peine de faire le projet - c'est pourquoi elles ont besoin des chiffres pour l'analyse de rentabilisation. Si l'analyse de rentabilité était solide, ils n'auraient pas besoin de vos estimations. La majeure partie de ces projets ne se concrétisera pas. Il est donc important de ne pas consacrer trop d’efforts à l’estimation.
2. Donner une gamme. Faites-le large. Vous n'avez pas eu le temps d'analyser les exigences, d'organiser des ateliers avec les parties prenantes et de valider les hypothèses. Un large éventail indique au destinataire de l'estimation "Les projets logiciels sont naturellement complexes et risqués - si vous souhaitez une estimation correcte, vous devez me donner plus de détails et plus de temps". Le problème avec l'attribution d'un nombre unique ou d'une plage étroite est que cela vous tracasse en définissant les attentes avant toute analyse réelle.

Je trouve la meilleure technique pour choisir un projet comparable qui "se sent" la même chose. "Feel" est totalement subjectif - mais avec ce type d'estimation, mon expérience me dit que vous ne trouverez pas de mesures objectives. Ensuite, fournissez une large gamme. J'ai lu des livres qui disent qu'une plage de -50% à + 100% est bonne, mais cela dépend de nombreux facteurs.

Pour une estimation détaillée de bas niveau:

1. Vous avez besoin d'une base. Si la base de référence n'est pas stable, l'estimation n'a pas de sens.
2. Bottom up est le meilleur. Obtenez une ventilation détaillée du travail, estimez chaque composant, puis regroupez-le en un plus grand nombre. Je trouve que la planification du poker est une excellente technique ici.
3. Document contingence. Indiquez clairement où une éventualité (le cas échéant) est ajoutée. Est-il ajouté à chaque élément de campagne? Ou à l'ensemble de l'estimation? Ou à des risques spécifiques? Ou n'y en a-t-il pas?
4. Énoncez vos hypothèses. Valider autant que possible en fonction du délai.
5. Indiquez explicitement ce qui est inclus et exclu dans l'estimation. Par exemple, la révision est-elle incluse? Les retards techniques sont-ils inclus?

Quelques conseils du côté obscur de celui qui a appris à la dure.

Les exigences ne sont pas claires. Personne n’a procédé à une analyse approfondie de toutes les implications.

Ne faites pas d'estimation à ce stade. On n’estime pas combien de soldats sont nécessaires pour gagner une bataille sans avoir la moindre idée du nombre d’ennemis. L'estimation est faite après le dépistage. Ceci est sauf si vous avez déjà combattu cet ennemi.

La nouvelle fonctionnalité va probablement briser certaines hypothèses que vous avez faites dans votre code et vous allez commencer à penser immédiatement à tout ce que vous pourriez avoir à refactoriser.

C’est à vous qu’il incombe d’en tenir compte, sauf si vous vous attendez à ce que les autres possèdent l’expertise nécessaire dans ce domaine.

Vous avez d'autres tâches à accomplir dans le cadre de missions antérieures et vous devrez produire une estimation tenant compte de ces autres tâches.

Idem que ci-dessus, même pour un travail imprévu créé par un coéquipier slob à côté de vous avec une procédure de test quasi inexistante qui provoque un problème de code que vous ne pouvez pas prédire à l'avance. C'est une météo.

La définition du "fait" n'est probablement pas claire: quand sera-t-il terminé? 'Terminé' comme juste fini de le coder ou 'terminé' dans "les utilisateurs l'utilisent"?

Comprenez les besoins de l'utilisateur ici, pensez comme un utilisateur. Ne faites pas ce que font vos pairs s’ils estiment qu’une tâche doit être "exécutée", simplement parce qu’une fonctionnalité de base avec un flux de travail barebone qu'aucun utilisateur ne peut tolérer est ce qu’ils considèrent être "réalisée" . Pensez-y du point de vue de l'utilisateur, car c'est tout ce que le client pour lequel vous faites une estimation comprendra généralement. Estimez en fonction des besoins complets de l'utilisateur, et non des besoins techniques barebone. Et réalisez que vos clients demandant des estimations seront totalement inexacts sur la façon dont ils formulent les choses et comprennent les aspects techniques de ce que vous dites.

Peu importe votre degré de conscience de toutes ces choses, parfois votre "fierté du programmeur" vous fait donner / accepter des délais plus courts que vous ne le supposiez au départ. Surtout lorsque vous ressentez la pression des délais et des attentes de la direction.

Ne fais pas ça! Vous parlez comme un travailleur acharné et motivé, et peut-être même quelqu'un qui cède facilement à la contrainte.

Le problème ici est le suivant: supposons que Joe et vous avez fait une estimation de temps pour la même tâche (mais entre deux employés distincts ne connaissant pas les deux estimations à la fois). Vous estimez vaillamment, "une semaine" . Ce n'est pas grave, pensez-vous, vous travaillerez plus de 100 heures par semaine, en heures supplémentaires non rémunérées. Maintenant, vous avez trois jours de retard.

Pendant ce temps, Joe estime 5 mois. Vous pensez que c'est ridicule, vous pensez pouvoir retirer ceci en une semaine. Combien travaille Joe? 10 heures par semaine? ... sauf qu'il termine à temps dans exactement 5 mois.

Devinez qui est perçu comme le crétin? C'est vrai, vous. Joe semble être un excellent ouvrier, vous ne semblez pas fiable maintenant. Peu importe que vous ayez pu obtenir un résultat encore meilleur dans environ 7% du temps que Joe a pris. Ce qui compte, c’est que vous disposiez de 3 jours de congé par rapport à une estimation d’une semaine.

Ne vous trompez jamais du côté de l'estimation la plus serrée. Err du côté de l'estimation la plus souple. Votre entreprise doit se faire une réputation et ne sera pas basée sur la longueur de vos estimations mais sur l’exactitude de vos estimations. Il est facile d’être précis avec une estimation trop longue, vous avez juste plus de temps pour travailler sur le problème et le résoudre mieux. Une estimation trop courte ne laisse aucune marge de manœuvre, vous la rencontrez désespérément ou vous vous faites avoir.

"Deux semaines!"

Sérieusement. Ma première estimation est toujours deux semaines. Parce que j'ai une sorte de blocage mental bizarre qui me fait penser que tout sonne comme si ça allait durer deux semaines.

J'essaie de contourner le problème , d'essayer de réfléchir vraiment au temps qu'il faudra, de tenter quelque chose, d'essayer d'identifier tous les points chauds potentiels et les éléments qui semblent trop noirs pour que je puisse effectuer une estimation précise. Et essayez de reconnaître que si ma réponse est "Deux semaines!", J'ai probablement échoué.

Pratiquement tous les bons managers que j'ai eu ont appris à reconnaître "Deux semaines!" comme une réponse qui nécessite une légère gifle verbale en réponse.

Une entrée de blog explique comment garder une trace de la précision de vos estimations précédentes, puis la prochaine fois que vous direz à quelqu'un "ça fera deux semaines", vous pourrez consulter votre historique et voir combien de temps il durera. effectivement pris la dernière fois que vous avez dit "ça va être deux semaines".

Je n'ai pas essayé moi-même, mais j'aimerais bien voir à quel point mes estimations sont précises.

Cela dépend de l'organisation et de la manière dont les estimations sont utilisées.

Si l'estimation a simplement pour but de donner une idée générale du moment où elle sera prête, je peux généralement faire une estimation rapide en fonction de mon expérience. Souvent, j'inclus toute estimation d'incertitude ou de variation possible avec la manière dont les modifications peuvent affecter d'autres zones du système et l'ampleur des tests de régression requis.

Si l'estimation est utilisée pour quelque chose de contractuel ou dans un scénario où un timing plus précis est requis, je décompose le travail en entier. Cela demande plus de travail et nécessite une réflexion plus approfondie sur la conception et les modifications du système, mais il est beaucoup plus précis, en particulier pour les travaux plus volumineux.

Dans les deux cas, la communication continue est la clé. Si vous rencontrez un événement inattendu, faites-le-lui savoir au lieu d'attendre la date limite. Si les exigences ne sont pas claires, assurez-vous de documenter votre compréhension et les fonctionnalités que vous prévoyez de fournir. Ceci est également utile avec toutes les hypothèses que vous faites. Et en ce qui concerne les priorités concurrentes, quand un travail en impose un autre, expliquez clairement en quoi cela affectera le calendrier.

Des estimations pour quoi? Petites tâches ou solutions complètes.

C’est ce dernier cas que je fais rarement, mais je suppose qu’il faut ajouter un peu, demander au responsable d’en ajouter un peu et en faire une plage, avec une petite note à côté indiquant que ce qui précède est une estimation.

Petites tâches - Je trouve que la planification du poker fonctionne très bien (pas parfait, certaines tâches à 1 point ont pris beaucoup plus de temps et certaines tâches à 5 points prenaient des minutes, mais tout finit par s’égarer).

Présentez une gamme basée sur ce que vous savez aujourd'hui. Utilisez le cône d’incertitude pour définir la plage autour de vos estimations initiales.

Chaque semaine, calculez combien il vous reste à faire, ré-estimez-le en fonction de vos connaissances. Une fois que vous avez obtenu un échantillon de la quantité de travail que vous effectuez chaque semaine, donnez un intervalle de confiance de 90% pour le reste, afin de donner une plage de dates (généralement) toujours plus étroite au fur et à mesure de l'avancement du projet et du volume de travail restant (espérons ) diminue.

Avec confiance. Je ne peux pas vous dire combien de fois j'ai raté une première rencontre avec un client en ne faisant pas preuve de professionnalisme lors de l'estimation. Même si les chiffres vous échappent, assurez-vous de toujours garder une estimation. Cela dit, veillez à ne pas vous estimer dans un trou. Différentes choses prennent différentes quantités de temps, d'efforts et de ressources à assembler. Voici un bon moyen de le faire:

Eux: Combien cela coûtera-t-il?

Moi: Cela dépend de ce que vous voulez que je fasse. Généralement, je commence ce genre de projet à environ X $.

Parfois, l'estimation représente un défi énorme pour vous et votre équipe, en particulier lorsque nous parlons d'estimation de projet logiciel.

Une fois que nous avions décidé de partager notre expérience et nos connaissances sur le processus d’estimation logicielle, nous avions défini quatre types d’estimations distincts :

• chiffre approximatif
• estimation de service
• estimation des fonctionnalités
• estimation composite

Bien sûr, ces types sont distincts. Ballpark est ce qu'on appelle souvent une "estimation". Il s’agit donc d’un nombre ou d’une fourchette approximatif qui donne une idée générale du coût et qui peut aider un prospect à décider s’il souhaite approfondir la discussion.

En règle générale, les clients ont besoin d'un chiffre approximatif au début du projet. Et notre conseil est le suivant: discuter du projet et fournir des chiffres approximatifs ne devraient être que des étapes bien à franchir pour recevoir une estimation composite (qui est flexible, on peut utiliser une estimation de type composite pour l’ensemble du processus de développement). vous souhaitez ajouter, supprimer ou remplacer des fonctionnalités, des services, etc.).

Tout le monde devrait garder à l'esprit les risques inhérents à l'estimation du développement logiciel: sous-estimation, surestimation, scénario d'échec total, etc.

Vous pouvez en lire plus sur notre blog!

http://blog.lemberg.co.uk/project-management/software-estimation-process/

J'espère que cette information vous aidera!

Je finis toujours par donner des estimations que je réalise plus tard que je ne peux pas remplir. Cela s'est produit d'innombrables fois et je promets toujours que cela ne se reproduira plus.

On dirait qu'on vous demande un engagement, pas une estimation. Ce sont des choses différentes, mais si vous pouvez gérer vos engagements de manière fiable, votre crédibilité et votre carrière en bénéficieront vraiment.

Quelques conseils basés sur mes ~ 10 ans d'expérience:

• Toujours fournir une plage (c.-à-limite inférieure et supérieure). Cela communiquera votre niveau d'incertitude
• Si vous avez une très grande incertitude, demandez un report (par exemple, une journée d'analyse et ensuite une plage plus étroite)
• Si la tâche est trop volumineuse, divisez-la et fournissez une plage pour chaque pièce.

Tout d’abord, si une tâche m’était assignée, je la diviserais en sous-tâches. J’estimerais le temps pour chaque sous-tâche et probablement avec des sous-tâches, je serais capable de trouver le domaine problématique et donc de pouvoir prédire combien de temps prendre dans une certaine mesure.

Cependant, toute la planification n’aiderait que dans une certaine mesure. Ce n'est que lorsque vous commencez à coder que vous pouvez trouver les problèmes exacts

Si vous réalisez de nombreux projets pour le même patron ou client, vous pouvez essayer d’évaluer en complexité au lieu de semaines ou de mois, éventuellement en tailles de t-shirt. Identifiez quelques projets antérieurs et attribuez-leur les tailles S, M, L, XL.

Et ensuite, demandez-vous: à quel projet cela ressemble-t-il? Et puis, au lieu de répondre avec "2 Mois", vous pouvez répondre avec "ça sonne comme un L pour moi" (ou quel que soit le calibrage de votre projet).

C'est assez facile à comprendre, et il est également clair qu'il y a beaucoup d'incertitude dans ces suppositions.

Ensuite, lorsque les exigences changent, vous pouvez dire "ce changement donne l'impression que cela ressemble davantage à un XL".

Un peu tard, mais lorsque j'étais dans l'armée, on nous avait demandé d'utiliser le PERT pour établir des estimations. Cela nécessite une certaine expérience dans votre domaine et dans la tâche à accomplir. Il était étonnamment précis lors de la détermination du temps d’achèvement estimé lors de l’entretien et de la réparation de dispositifs électroniques (radios complexes et équipements de communication par satellite), où un certain nombre de choses peuvent être erronées ou trouvées et doivent être réparées au cours de l’entretien courant. Les estimations étaient importantes car d’autres unités pourraient ne pas fonctionner jusqu’à ce qu’elles aient reçu leur équipement de communication. Celui que j'ai utilisé est cette calculatrice PERT en ligne gratuite