Comment répondre lorsqu'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 fait 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 commencez à penser immédiatement à toutes les choses que vous pourriez avoir à refactoriser.
- Vous avez d'autres tâches à accomplir dans le cadre de missions antérieures et vous devrez fournir une estimation qui tiendra compte de ces autres travaux.
- La définition "terminé" n'est probablement pas claire: quand sera-t-elle effectuée? 'Fait' comme pour le coder, ou 'fait' comme pour "les utilisateurs l'utilisent"?
- Peu importe à quel point vous êtes conscient de toutes ces choses, parfois la "fierté de votre programmeur" vous fait donner/accepter des temps plus courts que vous ne le pensiez 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 fin de compte, la réalité est que l'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 plus tard que je ne peux pas remplir. Cela s'est produit un nombre incalculable de 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ées utiles?
De Le programmeur pragmatique: du compagnon au maître :
Que dire lorsqu'on lui demande une estimation
Vous dites "je vous répondrai".
Vous obtenez presque toujours de meilleurs résultats si vous ralentissez le processus et passez du temps à parcourir les étapes décrites dans cette section. Les estimations données à la machine à café reviendront (comme le café) pour 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 7e mois, vous êtes toujours assez précis. Mais si vous vous glissez dans le 180e ou 210e jour, pas tellement.
- Assurez-vous de bien comprendre ce qui est demandé. Déterminez l'étendue du problème.
- Modélisez le système. Un modèle peut être un modèle mental, des diagrammes ou des enregistrements de données existants. Décomposer ce modèle et construire 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.
- D'autres éléments à inclure dans votre estimation sont le développement et la documentation des exigences ou des modifications des spécifications des exigences, la création ou la mise à jour des documents et des spécifications de conception, les tests (unitaires, d'intégration et d'acceptation), la création ou la mise à jour des manuels d'utilisation ou des LISEZMOI avec les modifications. Si 2 personnes ou plus travaillent ensemble, il y a des frais généraux de communication (appels téléphoniques, e-mails, réunions) et la fusion du code source. S'il s'agit d'une tâche longue, tenez compte de choses comme d'autres travaux, des congés (vacances, vacances, congés de maladie), des réunions et d'autres tâches indirectes lors du choix d'une date de livraison.
L'estimation logicielle est la tâche la plus difficile en génie logiciel, suivie de près par la définition des exigences.
Il existe de nombreuses tactiques pour les créer, toutes basées sur l'obtention préalable de bonnes exigences. Mais quand votre dos est contre le mur et qu'ils refusent de vous donner de meilleurs détails, Fake It:
- Examinez bien les exigences que vous avez.
- Faites des hypothèses pour combler les lacunes en fonction de votre meilleure estimation de ce qu'ils veulent
- Notez toutes vos hypothèses
- Faites-les s'asseoir, lire et accepter vos hypothèses (ou, si vous êtes chanceux, faites-les céder et vous donner de vraies exigences).
- Vous avez maintenant des exigences détaillées à partir desquelles vous pouvez estimer.
C'est comme si ma mère menaçait quand j'étais enfant "Dépêchez-vous de choisir des vêtements ou je vais les choisir pour vous!"
J'ai fait du développement pour un gars qui était très résolu à vouloir des estimations précises. Ce sur quoi nous nous sommes installés, qui a très bien fonctionné, était le suivant:
- J'ai facturé tout le temps que j'ai passé à estimer. Cela représente environ 20-25% de ce que j'ai facturé.
- J'ai fait un examen extrêmement détaillé des tâches. Pas de tir de la hanche. Je suis entré dans le code, j'ai déterminé quelles lignes devaient être modifiées, quelles autres parties du programme cela affecterait, combien de tests je devrais faire pour m'assurer que les choses fonctionnent toujours. J'évaluerais 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éterminerais qu'il faudrait 8,5 heures. Il déciderait donc si cela valait 8,5 heures de salaire. Sinon, il a économisé 7,5 heures sur ce que cela lui aurait coûté si je l'avais fait sans estimation.
Et s'il voulait vouloir investir les 8,5 heures, le travail de détail que j'ai fait pour l'estimation était un travail que j'aurais dû faire de toute façon.
J'ai trouvé qu'avec cette méthode, je pouvais apporter la plupart des tâches à temps ou même tôt, sans avoir à surestimer fortement. Parce que le temps était tellement minutieux, je pouvais dire très tôt si je glissais. Si je franchis des barrages routiers pour qu'après 3 heures je puisse dire que ma tâche de 8,5 heures allait prendre 12 heures, je pourrais lui en parler avant que plus de temps ne passe afin qu'il puisse réévaluer et tirer sur la fonction s'il était préoccupé par le coût .
Était-il nickel et diming? Non, je l'ai regardé comme le laissant appliquer son argent là où il voyait le plus d'avantages. Et j'étais heureux d'acquérir de l'expérience dans l'estimation, ce qui m'avait toujours été terrible.
On nous demande souvent une "estimation approximative" lors des réunions où l'on nous donne des idées très générales et très précises 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 revoir, je peux affiner ces chiffres pour vous."
Ils obtiennent presque toujours le point.
Cela dépend à quoi sert l'estimation.
Pour une estimation initiale de haut niveau d'une analyse de rentabilisation, les éléments clés sont les suivants:
- La vitesse. Quelle que soit la méthode que vous utilisez, elle doit être rapide. Le fait 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 rentabilisation était solide, ils n'auraient pas besoin de vos estimations. La majeure partie de ces projets ne se poursuivra pas, il est donc important de ne pas consacrer trop d'efforts à fournir l'estimation.
- Donnez une gamme. Faites-le large. Vous n'avez pas eu le temps d'analyser les exigences, d'atelier avec les parties prenantes, 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 voulez une estimation correcte, vous devez me donner plus de détails et plus de temps". Le problème de donner un numéro unique ou une plage étroite est qu'il vous plonge dans un coin en définissant des attentes avant toute analyse réelle.
Je trouve la meilleure technique pour choisir un projet comparable qui "ressent" la même chose. "Feel" est complètement subjectif - mais avec ce genre d'estimation, mon expérience me dit que vous ne trouverez pas de mesures objectives. Fournissez ensuite une large gamme. J'ai lu quelques 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:
- Vous avez besoin d'une référence. Si la ligne de base n'est pas stable, l'estimation n'a pas de sens.
- De bas en haut, c'est mieux. 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.
- Documenter l'éventualité. Indiquez clairement où toute éventualité (le cas échéant) est ajoutée. Est-il ajouté à chaque élément de campagne? Ou à l'ensemble du devis? Ou à des risques spécifiques? Ou n'y en a-t-il pas?
- Énoncez vos hypothèses. Validez autant que possible compte tenu du délai.
- 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 fait une analyse approfondie de toutes les implications.
Ne faites pas d'estimation à ce stade. On n'évalue pas le nombre de soldats 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. C'est à moins que vous n'ayez déjà combattu cet ennemi.
La nouvelle fonctionnalité va probablement briser certaines hypothèses que vous avez faites dans votre code et vous commencez à penser immédiatement à toutes les choses que vous pourriez avoir à refactoriser.
Il est de votre responsabilité d'en tenir compte, sauf si vous vous attendez à ce que d'autres possèdent l'expertise dans ce domaine.
Vous avez d'autres tâches à accomplir dans le cadre de missions antérieures et vous devrez fournir une estimation qui tiendra compte de ces autres travaux.
Comme 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 fait que votre code glitch que vous ne pouvez pas parfaitement prédire à l'avance. C'est une météo.
La définition "terminé" n'est probablement pas claire: quand sera-t-elle effectuée? 'Fait' comme pour le coder, ou 'fait' comme pour "les utilisateurs l'utilisent"?
Comprenez l'exigence de l'utilisateur ici, pensez comme un utilisateur. Ne faites pas ce que font vos pairs s'ils estiment que quelque chose doit être "fait" simplement parce que certaines fonctionnalités de base avec un workflow barebones qu'aucun utilisateur ne peut tolérer sont ce qu'ils considèrent être "done". Pensez-y du point de vue de l'utilisateur, car c'est tout ce que le client pour lequel vous faites l'estimation comprend généralement. Estimation vers les exigences complètes de l'utilisateur, et non vers les exigences techniques barebone. Et réalisez que vos clients qui demandent des devis seront totalement inexacts ici sur la façon dont ils rédigent les choses et comprennent les aspects techniques de ce que vous dites.
Peu importe à quel point vous êtes conscient de toutes ces choses, parfois la "fierté de votre programmeur" vous fait donner/accepter des temps plus courts que vous ne le pensiez 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 peut-être quelqu'un qui cède facilement à la contrainte.
Le problème ici est le suivant: disons que vous et Joe avez fait des estimations de temps pour la même tâche (mais entre deux employés distincts, ignorant les deux estimations en même temps). Vous estimez vaillamment, "une semaine". C'est bien, vous pensez, vous travaillerez plus de 100 heures par semaine, des heures supplémentaires non rémunérées. Vous avez maintenant trois jours de retard.
Pendant ce temps, Joe estime 5 mois. Vous pensez que c'est ridicule, vous pensez que vous pouvez retirer cela 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, toi. Joe semble être un grand travailleur, vous semblez peu fiable maintenant. Peu importe que vous ayez pu obtenir un résultat encore meilleur dans ~ 7% du temps que Joe a pris. Ce qui compte, c'est que vous étiez à 3 jours de congé d'une estimation d'une semaine.
Ne vous trompez jamais du côté de l'estimation plus serrée. Err sur le côté de l'estimation plus lâche. Il y a une réputation à bâtir dans votre entreprise, et elle ne sera pas basée sur la longueur de vos estimations autant que sur l'exactitude de vos estimations. Il est facile d'être précis avec une estimation trop longue, vous obtenez simplement 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, soit vous la rencontrez désespérément, soit vous êtes foutu.
"Deux semaines!"
Sérieusement. Ma première estimation est toujours de deux semaines. Parce que j'ai une sorte de blocage mental bizarre qui me fait penser que tout ressemble à deux semaines.
J'essaye de contourner ça, j'essaye vraiment pense sur combien de temps je pense que quelque chose va prendre, en essayant d'identifier tous les points chauds potentiels et les bits qui semblent trop noirs pour que je puisse estimer avec précision. Et essayez de reconnaître que si ma réponse est "Deux semaines!", Je n'ai probablement pas réussi à le faire.
Presque tous les bons managers que j'ai eus ont appris à reconnaître "Deux semaines!" comme une réponse qui nécessite une légère gifle de souteneur verbal en réponse.
Il y a un entrée de blog qui décrit comment garder une trace de la précision de vos estimations précédentes, puis la prochaine fois que vous dites à quelqu'un "ça va faire deux semaines", vous pouvez regarder votre histoire précédente et voyez combien de temps cela a réellement pris la dernière fois que vous avez dit "ce sera deux semaines".
Je ne l'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 façon dont les estimations sont utilisées.
Si le devis est juste pour donner une idée générale du moment où il sera prêt, je peux généralement faire un devis rapide basé sur mon expérience. Souvent, je vais inclure toute incertitude ou variation possible avec l'estimation ainsi que la façon dont les changements peuvent avoir une incidence sur d'autres domaines du système et l'étendue des tests de régression requis.
Si le devis est utilisé pour quelque chose de contractuel ou dans un scénario où un calendrier plus précis est requis, je fais une ventilation complète du travail. C'est plus de travail et nécessite une réflexion plus approfondie sur la conception et les modifications du système, mais c'est beaucoup plus précis, en particulier pour les gros travaux.
Dans les deux cas, la communication continue est essentielle. Si vous rencontrez quelque chose d'inattendu, faites-le savoir à ce moment-là 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. Cela est également utile pour toutes les hypothèses que vous faites. Et en ce qui concerne les priorités concurrentes, lorsqu'un travail en dépasse un autre, soyez clair sur la façon dont cela affectera le calendrier.
Des estimations pour quoi? Petites tâches ou solutions complètes.
Ce dernier, je le fais rarement, mais juste devinez, ajoutez un peu, demandez au gestionnaire d'ajouter un peu et d'en faire une plage, avec une petite note à côté indiquant que ce qui précède est une supposition.
Petites tâches - Planification du poker J'ai trouvé que ça fonctionnait très bien (pas parfait, certaines tâches de 1 pt ont pris beaucoup plus de temps et certaines tâches de 5 pt ont pris des minutes, mais tout se termine finalement).
Présentez une gamme basée sur ce que vous savez aujourd'hui. Utilisez le Cone of Uncertainty pour fournir la plage autour de vos estimations initiales.
Calculez chaque semaine ce qui reste à faire, réestimez en fonction de ce que vous savez. Une fois que vous avez assez d'un échantillon de la quantité de travail que vous effectuez chaque semaine, fournissez un intervalle de confiance de 90% pour ce qui reste pour donner une plage de dates (généralement) toujours plus étroite à mesure que le projet progresse et la quantité de travail restant (espérons ) rétrécit.
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 d'un devis. Même si vous faites exploser des chiffres, assurez-vous de toujours garder une estimation. Cela dit, faites attention à ne pas vous estimer dans un trou. Différentes choses prennent différentes quantités de temps, d'efforts et de ressources à assembler. Voici une bonne façon de procéder:
Eux: Combien cela coûtera-t-il?
Moi: Cela dépend de ce que vous voulez que je fasse. Généralement, je démarre ce genre de projet à environ $ X.
Parfois, l'estimation devient un énorme défi 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 et défini quatre types d'estimations distincts :
- chiffre approximatif
- estimation de service
- estimation de fonctionnalité
- estimation composante
Bien sûr, ces types sont distincts. Ballpark est ce qu'on appelle souvent un "estimation de la valeur". C'est donc un nombre approximatif ou une fourchette qui donne une idée générale du coût et qui peut aider un prospect à décider s'il souhaite poursuivre 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 pour recevoir une estimation composante (qui est flexible, on peut utiliser estimation de type composant pour l'ensemble du processus de développement. Pas besoin de réestimer à partir de zéro lorsque vous souhaitez ajouter, supprimer ou remplacer des fonctionnalités, des services, etc.).
Tout le monde doit garder à l'esprit les risques qui accompagnent le développement de logiciels: sous-estimation, surestimation, scénario de défaillance totale épique, etc.
Vous pouvez en lire plus sur notre blog!
http://blog.lemberg.co.uk/project-management/software-estimation-process/
J'espère que ces informations vous aideront!
Je finis toujours par donner des estimations que je réalise plus tard que je ne peux pas remplir. Cela s'est produit un nombre incalculable de fois, et je promets toujours que cela ne se reproduira plus.
Il semble que l'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, cela contribuera vraiment à votre crédibilité et à votre carrière.
Quelques conseils basés sur mes ~ 10 ans d'expérience:
- Fournissez toujours une plage (c.-à-d. 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 1 jour pour faire l'analyse, puis fournissez une plage plus étroite)
- Si la tâche est trop grande, brisez-la et fournissez une plage pour chaque pièce
Tout d'abord, si une tâche m'était assignée, je la décomposerais en sous-tâches, j'estimerais le temps pour chaque sous-tâche et probablement avec des sous-tâches, je serais en mesure de trouver la zone problématique et donc je serais en mesure de prévoir combien de temps cela prendrait prendre dans une certaine mesure.
Mais 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'estimer en larges traits de 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 puis demandez-vous: à quel projet cela ressemble-t-il? Et puis au lieu de répondre avec "2 mois", vous pouvez répondre avec "sonne comme un L pour moi" (ou quel que soit votre calibrage pour le 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 fait ressembler davantage à un XL".
Un peu tard, mais quand j'étais dans l'armée, on nous a demandé d'utiliser le PERT pour déterminer les estimations. Cela nécessite une certaine expérience dans votre domaine et la tâche à accomplir. Il était étonnamment précis lors de la détermination du temps estimé d'achèvement lors de la maintenance et de la réparation des appareils électroniques (radios complexes et équipements de communication par satellite), où un certain nombre de choses peuvent être erronées ou trouvées et devaient être réparées lors de l'entretien de routine. Les estimations étaient importantes parce que d'autres unités peuvent ne pas fonctionner jusqu'à ce qu'elles aient récupéré leur équipement de communication. Celui que j'ai utilisé est ceci Calculateur PERT en ligne gratuit