Faire face à de terribles estimations

Un projet récent sur lequel j'ai travaillé s'est avéré gravement sous-estimé par l'architecte. L'estimation était au moins 500%.

Malheureusement, j'ai été impliqué dans le projet après que le devis avait été signé avec le client. En tant que développeur senior, je me suis vite rendu compte que les spécifications fonctionnelles et techniques. contenait des lacunes et des incertitudes énormes.

En conséquence, je me suis senti obligé de convoquer une réunion d’urgence avec les directeurs techniques et commerciaux pour leur faire savoir la réalité. En tant que développeur, j'ai trouvé la situation très stressante et difficile. Le "business" a accusé IT d'être incompétent et d'être le messager, j'ai reçu quelques "balles".

Le client a menacé d'annuler le compte, mais à ce jour, le projet n'est pas encore terminé et je ne suis plus directement impliqué dans celui-ci.

L’architecte était un homme sympathique sur le plan social, mais sur la base de cet épisode, il était tout simplement incompétent ou de fortes pressions commerciales / commerciales avaient influencé son estimation.

Alors, en tant que programmeurs, quelle est votre expérience de ce genre de situation et que conseilleriez-vous de gérer?

Longue réponse, mais bon, j'ai un résumé à la fin, alors passez directement au résumé si vous ne voulez pas être dérangé de lire le tout!

En tant que développeur, j'ai dû gérer la situation à la lettre avec tous les autres projets, mais ce n'est que lorsque je suis entré dans la gestion de projet que j'ai appris à gérer efficacement cette situation. Pour moi, gérer efficacement consiste en deux choses: gérer les attentes et comprendre le fonctionnement de l'estimation.

Commencez par partir du principe qu'il est contraire à l'éthique de fournir une estimation, de vous engager dans une estimation ou de donner une autre indication de la précision de l'estimation sans pouvoir effectuer une vérification préalable. D’autres personnes comptent sur votre capacité professionnelle pour prévoir la quantité de travail requise. Donner une fausse indication leur nuirait, à eux et à leur entreprise.

Mais vous devez donner quelque chose. Dans la vie réelle, vous vous êtes traîné dans une réunion impromptue ou dans un projet en retard, et votre supérieur vous expliquera probablement qu'il s'attend à ce que vous fournissiez immédiatement un chiffre ou commentez l'estimation fournie. C’est là que la gestion des attentes entre en jeu.

Expliquez qu'il serait faux de votre part de donner un chiffre ou une indication sans comprendre le problème et sans calculer les chiffres pour vous-même. Dites que leurs chiffres sont peut-être tout à fait corrects, vous ne le savez pas avant de passer vous-même à l'estimation. Et même si vous avez une bonne idée de ce qui est nécessaire là-bas et à quel moment, disons que vous avez encore besoin d’un peu de temps pour calculer les chiffres. Ils peuvent s’attendre à ce que vous donniez une estimation: le moment où vous pourrez fournir une estimation. Par tous les moyens fournissent ce chiffre.

En tant que développeur, n'assume jamais la responsabilité (ou ne donne pas d'indication pouvant être interprétée comme une acceptation) des estimations faites par d'autres personnes sans pouvoir les consulter au préalable. En tant que chef de projet, la situation est totalement différente, car vous avez alors un certain contrôle sur le processus d’estimation: la manière dont une estimation est dérivée et révisée et vous devez vous fier à d’autres personnes pour effectuer le travail réel et vous devez effectuer des calculs. bien sûr qu'ils sont engagés.

Ne jamais même commenter des estimations sans pouvoir faire preuve de diligence raisonnable. C'est éthique. Un avocat ou un médecin vous indiquera clairement qu'ils ne peuvent donner aucun conseil tant qu'un client (ou un patient) ne respecte pas ses règles et ne passe préalablement par une procédure d'évaluation. De même, vous avez le droit de répondre à vos questions avant de donner votre avis professionnel.

La deuxième partie concerne le fonctionnement de l’estimation. Je suggère de rechercher différentes méthodes de calcul des estimations et le fonctionnement du processus d'estimation, y compris des industries autres que le développement de logiciels (fabrication, marchés financiers, construction). Cela vous donnera une idée de ce que votre patron ou client peut raisonnablement attendre de vous et, étrangement, vous aidera à faire des prévisions plus précises quant à la quantité de travail. Cela améliorera votre capacité à défendre vos estimations et vous devrez défendre les chiffres à chaque fois qu’ils sont différents de ceux fournis par un architecte ou un vendeur.

Normalement, la façon dont cela fonctionne est que votre estimation est d'abord analysée pour rechercher des éléments étranges ou relativement volumineux. Par conséquent, soyez prêt à défendre n'importe quoi avec un nom «non standard». Séparez également les tâches plus volumineuses de manière à ce que toutes les tâches aient le même ordre de grandeur, c'est-à-dire si la plupart des tâches prennent 2 jours et qu'une tâche unique dure 10 jours, préparez-vous à s'exercer.

Soyez clair sur ce qui est inclus dans chaque tâche, son mieux est de diviser les tests de dev et d'unités plutôt que d'avoir simplement dev et de laisser quelqu'un supposer que cela inclut également la documentation. Évidemment, de cette façon, vous devrez produire une estimation assez fine.

Ensuite vient le forage. Puisqu'il est assez difficile de passer en revue une longue période de travail, votre client ou votre patron adoptera probablement une stratégie différente: concentrez-vous sur une partie aléatoire de la tâche et laissez-vous guider jusqu'à ce qu'ils parviennent à discréditer toute l'estimation ou soient satisfaits de votre réponse. réponses. La crédibilité de l'ensemble de l'estimation peut dépendre d'un échantillon aléatoire! Par conséquent, encore une fois, vous avez besoin de temps pour le préparer avec soin, n'inclure que les éléments pertinents, exclure tous les extras ou les déplacer dans une section "sympa pour ceux qui en ont" et réfléchir à la manière dont vous allez défendre les personnages.

Évidemment, vous pouvez être cohérent dans votre approche, c'est-à-dire estimer sur la base des caractéristiques, du nombre d'écrans, etc., ou utiliser une combinaison d'approches, mais dans tous les cas soyez prêt à défendre pourquoi vous avez choisi une certaine méthode d'estimation. Soyez également prêt à expliquer pourquoi vos chiffres sont différents de ceux de quiconque tente de prédire la quantité de travail requise.

Découvrez les signes évidents d'estimations faibles:

• Rempli de tâches courantes, copié à partir du modèle (les bonnes estimations sont spécifiques à la tâche à exécuter).

• Estimations à gros grains (c'est-à-dire des tâches plus longues que quelques jours).

• Estimations effectuées au début d'un projet ou par une personne qui n'a peut-être pas une connaissance réelle des exigences ou du travail requis.

• Estimations établies par des personnes autres que les auteurs effectifs

• Estimations vagues (pas clair ce qui est inclus et, tout aussi important, exclu).

• Différence substantielle dans l'ordre des ordres de grandeur.

Entraînez-vous à évaluer les autres personnes et à forer les chiffres sans connaître réellement les détails de la mise en œuvre. Cela vous aidera à appuyer votre demande plus longtemps lorsque vous aurez la demande de confirmer l'estimation de quelqu'un d'autre lorsque vous ne disposez d'aucune preuve tangible.

Pour résumer:

• Ne vous engagez pas dans une estimation horrible ou quelconque avant que vous n’ayez eu l’occasion de faire preuve de diligence raisonnable.

• Soyez clair dès le départ, ne laissez personne présumer que c'est une autre façon et interprétez votre silence comme un signe d'accord.

• Connaître le fonctionnement des différentes méthodes d’estimation, leur application pratique et leurs avantages, y compris en dehors du développement de logiciels.

• Soyez prêt à défendre votre estimation.

• Apprenez à évaluer les estimations des autres personnes afin de ne pas avoir à vous engager dans des chiffres très erronés.

Il est impossible de prédire l'avenir. Exiger une prédiction ("estimation"), c'est simplement demander des ennuis. Tout le monde le fait et tout le monde se trompe.

Votre jugement sur "500%" est probablement aussi faux que l'estimation de l'architecte. Après tout, "... à ce jour, le projet est encore inachevé ..." Il n'y a pas de faits disponibles ici.

Personne ne connaît la réponse "correcte". Et jusqu'à ce que cela soit fait, personne ne le saura.

Et même après que ce soit fait, l'estimation "originale" (avec ou sans contrôle de changement) peut ne pas être en corrélation avec tout ce qui a été réellement accompli.

L'estimation est un piège - c'est un jeu truqué. vous ne pouvez pas gagner, vous ne pouvez pas atteindre le seuil de rentabilité et vous ne pouvez même pas sortir du match.

Modifier

Faire face à de mauvaises estimations; Une estimation "héritée" qui semble fausse .

Le voilà. Vous n'êtes pas d'accord avec les estimations de quelqu'un d'autre. Soit ils ont omis quelque chose que vous jugez nécessaire. leur travail était différent de celui que vous aviez ou leur taux de productivité était différent. En outre, si l’estimation dépasse le simple effort, leur base de coûts est différente. Tous sont contestables. Alors contester les détails qui ont conduit à l'estimation. Ne contestez pas le nombre total - il n'y a pas d' informations réelles dans un résumé. Contester les détails individuels qui sous-tendent l'estimation. Découvrez ce qu'ils pensaient.

Il est tout aussi probable que vos hypothèses soient aussi fausses que leurs hypothèses. Également probable.

Lorsque demandé d'estimer .

1. Vous allez avoir tort.

   1. Ils mentent sur la portée du travail.

   2. Vous ne connaissez pas la productivité de l'équipe.

   3. Quelle que soit la nouvelle technologie utilisée, elle a été mal représentée.

2. Vous ne pouvez pas simplement utiliser un rembourrage pour couvrir ces choses au hasard. En fait, vous ne savez pas et n'avez pas de base pour "estimer". C'est juste deviner. Passer à autre chose.

Règle 1: Puisque vous ne faites que deviner, devinez par petits incréments.

La question fondamentale dans toute situation "d'estimation" n'est pas de prédire l'avenir. Vous ne pouvez pas faire cela avec une précision sur des périodes beaucoup plus longues qu'une semaine ou deux. Limitez vos prévisions à un horizon temporel sur lequel vous disposez de connaissances détaillées directes et immédiates. Par exemple, la prochaine version.

La question fondamentale est - généralement - la prise de décision de la part de vos acheteurs ou clients. La question n'est pas "que va coûter?" - c'est incomplet. La question est "est-ce que l'investissement en vaudra la peine?" La vraie question est plutôt de savoir "quel est le rapport coûts / avantages" et "quand devrions-nous arrêter de dépenser parce que plus d'investissement ne créera pas plus de rendement?" Ce sont les vraies questions.

Règle 2: Soutenir le décideur avec des informations factuelles.

La plupart des gens sont mieux servis par une approche agile. La première version - dans un mois - prendra 5 personnes × 4 semaines et donnera la fonctionnalité X qui corrige les pertes d’un million de dollars / jour et la fonctionnalité Y qui corrige les opportunités manquantes de 200 000 $ / semaine. Vous avez une connaissance détaillée de ce que vous faites, cette prédiction est donc logique. La sortie qui suit est un peu floue.

La parution dans un an est si lointaine dans l’avenir que toute prédiction n’est qu’un nombre aléatoire. Ne pas transpirer les détails de plus de 6 mois dans le futur, utilisez simplement des règles simples.

Quand ils demandent ce que le coût total de possession est, vous devez être honnête. "Le coût total intervient lorsque vous arrêtez de payer pour le développement. Jusqu'à ce que vous cessiez de payer, vous aurez toujours des coûts."

La vraie question est "quels problèmes essayez-vous de résoudre?" ou "quelle nouvelle opportunité poursuivez-vous?" et "qu'est-ce que ça vaut?"

Règle 3: Rendre le logiciel moins coûteux que le problème qu’il est censé résoudre.

Si vous ne connaissez pas très bien le problème, l'estimation sera ajustée pour correspondre à la perception. Essayez d'éviter cela.

Sur la probabilité . À l’exception d’une maladie débilitante ou d’un accident, aucune partie du développement logiciel n’est régie par les probabilités réelles. Les "risques" sont simplement une mauvaise gestion. De manière générale, la forme "nous n’avons pas tenu compte de la complexité du besoin commercial A ou de la technologie B". Le plus souvent de la forme "alors que nous en apprenions plus sur le problème ou sur la technologie, nous avons modifié l'horaire" qui est puni en tant que "champ d'application".

Il n'y a aucune probabilité d'apprendre des choses et de changer la portée. C'est une certitude.

Sur la planification . Il y a "planification" et "estimation". La planification de ce qu'il faut construire est une chose, mieux représentée sous la forme d'une liste de contrôle ou d'un graphique de dépendance. "L'estimation" de l'effort requis est basée sur des facteurs inconnus.

"Planifier" est une bonne gestion ordinaire.

"Estimer" nécessite des connaissances inconnues. Pour "estimer l'effort" avec précision, vous devez avoir un niveau de connaissance du produit du code source et savoir quelle personne va taper ce code source et quelles erreurs il va commettre. Comme vous ne pouvez pas le savoir, toute estimation doit être fausse. Et souvent faux le point de tromper et donc inutile.

Si l'estimation avait été dépassée de 500% et que le projet avançait toujours, quelle valeur a une estimation?

Aucun. Cela ne faisait que rendre les gens malheureux. Mais le projet a quand même avancé.

Puisque personne ne peut voir l’avenir, obtenir un devis correct ne veut rien dire. Rendez-le utile, aidez les gens à prendre des décisions.

Gardez l'horizon court. Offrir de la valeur aussi rapidement que possible. Créez un plan qui permet au client d’annuler le projet à tout moment et qui a toujours de la valeur.

Ne laissez pas le plan devenir la seule "vérité sacrée" du projet. La fonctionnalité livrable est sacrée. Tout le reste devrait changer à mesure que les produits livrables changent.

Ne laissez pas le plan aller au-delà de la valeur qu'il crée.

S'il n'y a pas assez de temps, il n'y en a pas assez. De toute façon, il n’ya pas de solution magique pour terminer le projet. À mon avis, vous avez fait ce que vous pourriez dire. Il s'est avéré qu'ils devaient le découvrir à la dure. C'est comme ça que ça se passe habituellement. J'espère que l'architecte et la direction ont appris de leurs erreurs et ne le font plus. Si les choses se passent normalement lorsque la direction est trop ignorante pour écouter vos arguments et prendre les mesures qui s'imposent, il pourrait être judicieux de rechercher d'autres projets ou une autre société.

"Les développeurs sont des artisans, et la pire chose à faire à un artisan est de lui faire livrer un produit de merde." Citation célèbre de quelque part mais je ne me souviens pas d'où.

L'honnêteté devrait toujours être honorée. J'étais sur le point de recevoir une "vision d'architecte", et lorsque le développeur m'a annoncé avec la terrible nouvelle que la solution ne fonctionnerait pas, nous sommes allés dans les unités fonctionnelles et avons eu une conversation affreuse. Le développeur a ensuite présenté une nouvelle estimation comprenant 80% de la fonctionnalité, mais il a respecté les délais et le budget impartis.

Les développeurs ont été convaincus par le fait que le développeur leur a parlé franchement, a reconnu les lacunes de son entreprise et a agi comme un chien. Cela fait 7 ans que ce gars travaille pour nous parce qu'il a toujours été honnête.

Le scénario dans son ensemble est si rare - la plupart des unités d'affaires pensent que vous êtes idiot de ne pas être en mesure de livrer. Vous devez rechercher les clients qui ne fonctionnent pas de cette façon, car vous gagnerez plus avec eux à long terme que d'essayer de faire plaisir aux crétins qui veulent simplement vous traiter comme un imbécile.

Pour les architectes qui ne connaissent pas leur domaine, évitez-les comme la peste. J'avais un mentor qui avait l'habitude de renforcer avec moi d'une manière dure - "Ceci. Ce n'est pas. Pour. Pratiquez!" Il ne tolérerait les erreurs que si vous les commettiez tôt, si vous les corrigiez et que vous ne les commettiez plus jamais. Les entreprises qui autorisent des personnes non techniques et inexpérimentées à occuper des postes avec des clients parce qu'elles peuvent "communiquer" méritent de cesser leurs activités.

J'avais une fois fait face à cette situation. Un projet a dépassé les délais prévus parce que l'entreprise a modifié ses exigences, qu'il existait un déficit de communication et que la haute direction souhaitait que le projet soit exécuté dans les délais. Pour aggraver les choses, un type travaillant sur ce projet a été recruté pour combler une autre lacune prioritaire.

Mon équipe passait des nuits pour terminer le projet. Tard dans la nuit vers 3 heures du matin (je travaillais 19 heures de suite), j'ai envoyé un courrier électronique à mes responsables pour qu'ils fassent quelque chose.

Le lendemain, nous avons eu une réunion (juste les gars de dev). Toute l'équipe est arrivée un week-end et a testé le projet avant même son achèvement. Peu d’autres se sont joints à l’équipe pour apporter des solutions rapides. Enfin, nous avons pu mener à bien le projet grâce aux efforts de l’ensemble de l’équipe (pas seulement de l’équipe du projet). Nous avons suivi le même processus pour d'autres projets.

Toute l'équipe (même si elle n'est pas impliquée dans le projet) a testé l'application et a aidé à la résolution rapide des bugs.

Remarque: Mon équipe est composée d'environ 25 personnes, qui ont également eu des sous-équipes travaillant sur différents projets.

Mon seul conseil serait "Parlez à la responsable. Dites-leur fermement que le projet ne pourra pas être livré à temps. Donnez-leur également une alternative. Le responsable s'attend toujours à ce que le bébé soit livré à l'heure, quoi qu'il arrive :)"

Bien que les entreprises n’apprécient pas souvent le fait que les choses prennent beaucoup plus de temps que prévu, elles préfèrent être encore moins entraînées. Plus tôt vous informez quelqu'un du temps que cela va vraiment prendre, plus vite tout le monde pourra planifier en fonction des circonstances. Même si au début, cela peut être difficile, à la longue, ce sera plus facile. Il suffit de bien faire les choses pour la deuxième fois et de prévoir des imprévus.

Permettez-moi de souligner un point clé lorsque vous traitez avec votre direction: les responsables apprécient les solutions.

Si vous devez vous adresser à votre direction avec un problème (par exemple, l'estimation est extrêmement irréaliste), travaillez dur à l'avance pour inclure des solutions de rechange permettant de remédier à la situation. Par exemple, vous pouvez effectuer une analyse de Pareto (règle des 80/20) pour comprendre la valeur du système, vous pouvez également hiérarchiser les fonctionnalités de coupe (au moins à partir d'une première version) afin de vous concentrer sur celles ayant une valeur commerciale maximale, vous pouvez rechercher des alternatives (projets open source, etc.) qui remplacent adéquatement les composants personnalisés du système, etc.

Il ne fait aucun doute qu'un sac de cinq livres ne contiendra pas vingt-cinq livres de sable, mais aider votre direction à assimiler votre message déplaisant consiste à prouver que vous êtes un allié engagé.

Vous pourriez être intéressé par cet article de l'IEEE sur lequel j'ai déjà écrit un blog . Voici les faits saillants.

• Les estimations trop optimistes sont l’un des facteurs les plus importants de l’échec du projet.
• Une des principales raisons pour lesquelles les estimations sont trop basses est la pression excessive exercée par les dirigeants pour que les choses soient livrées tôt.
• L'autre est le fluage de la portée lors de la mise en œuvre, sans nouvelle consultation des estimations.

Premièrement, je voudrais parler à l’architecte en question, de manière informelle, et passer en revue une liste de vos problèmes avec son estimation, et essayer de le convaincre de la nature des problèmes et de la différence de temps qu’ils prendraient pour les résoudre.

Ensuite, j'essaierais de parler à votre supérieur hiérarchique / responsable de projet et d'en discuter avec lui / eux.

À la fin de la journée, l’architecte a donné ESTIMATES, afin qu’ils soient sujets à modification, et parfois de manière très importante, aussi longtemps qu’ils en sont informés, ils peuvent donc élaborer des plans alternatifs, comme déployer un produit phases, en réduisant sa fonctionnalité ou d'autres moyens.

À la fin de la journée, une fois que vous avez fait ce qui précède, ce n'est plus votre responsabilité.

Vous ne devez absolument pas aller directement chez le client, ni chez le chef de l’architecte, cela ne ferait que susciter des sentiments négatifs, et presque toujours, vous serez blâmé.

La meilleure chose à faire est d’apprendre de vos mauvaises estimations (et non de la vôtre personnellement, dans ce cas-ci). Une chose à apprendre est de ne jamais laisser quelqu'un d'autre que la personne qui met en œuvre les idées à estimer le temps que cela prendra. Les vitesses des programmeurs peuvent varier d'un ordre de grandeur. Il est donc pratiquement impossible d'estimer pour quelqu'un d'autre.

Je ressens votre douleur ... Je ne sais pas comment gérer toute cette frustration :(

https://stackoverflow.com/questions/541873/developing-on-for-a-moving-tarming-target

Dans le passé, je devais traiter avec des chefs de projet qui réduisaient leurs estimations pour obtenir un chiffre que le service commercial pensait que le client paierait. Le responsable était d’avis qu’il valait mieux demander pardon que demander la permission.

C'est pourquoi les développeurs ont appris à étoffer leurs estimations, car ils savent qu'ils seront coupés par leurs gestionnaires. Donc, si vous doublez l'estimation et ajoutez 30%, vous avez une bonne chance d'obtenir un calendrier raisonnable.

Les clients le veulent toujours moins cher, et si vous leur présentez une estimation raisonnable, ils hésiteront et vous demanderont de réduire les coûts ou de marcher. Mais, si vous montez trop haut, ils marcheront simplement sans discussion ("Nous allons y réfléchir et nous reviendrons vers vous").

C'est un jeu d'attentes gérées.

Le problème n'était pas que les estimations initiales avaient été publiées - mais que la direction ne vous croyait pas.

Le meilleur moyen d’amener la direction à prendre une décision consiste à:

1. Décrivez le problème avec des preuves pour le sauvegarder; et
2. Proposez-leur plusieurs solutions (du moins préférable au plus préférable).

Pour (1), l’implémentation de Scrum et le suivi des données réelles par rapport aux estimations aléatoires s’avèrent utiles pour sauvegarder vos demandes.

Pour (2) une de mes options serait de "Développer une liste de fonctionnalités prioritaire avec le client (aka Product Backlog en termes Scrum)". Cela serait délicat dans des organisations à prix fixe ou très bureaucratiques, mais c'est possible .

J'espère que ça t'as aidé!

Je (comme j'en suis sûr à peu près tout le monde qui code) sympathise. Ma dernière entreprise était plutôt terrible à ce sujet: les vendeurs allaient vendre un projet, puis vous entrez, consultez le budget et vous riez.

Comme Tomh l'a mentionné - il n'y a pas beaucoup de temps dans une journée. Même si tu ne dors pas.

Trois choses, je pense.

La plupart du temps, il vous suffit de gérer les attentes du client et d’ être transparent . Soyez franc avec ce que vous pouvez faire et montrez ce que vous avez fait - tout cela. Cela est particulièrement vrai si vous avez des exigences beaucoup trop grossières (comme Totophil l'a mentionné). S'ils peuvent voir la quantité de travail que vous avez eu à faire, ils peuvent voir à quel point l'estimation était mauvaise. S'ils voient la productivité et les progrès réalisés, c'est plus important que tout dans mon expérience.

Je pense que, outre la gestion des attentes et la transparence de votre charge de travail, l’autre grand problème est la gestion de la portée . Il y a une grande marge entre être anal / offensif en tant que nazi et couvrir sa propre queue. Quand quelqu'un veut cette fonctionnalité supplémentaire, acceptez-le! Et ensuite, donnez-leur une estimation relativement précise du temps que cela va ajouter au projet (ou à la prochaine version). L'avantage de ceci est non seulement de ne pas vous entasser dans une autre semaine de 80 heures - vous obtenez également une note dans cette estimation pour éventuellement rattraper l'autre.

Bonne chance!

Ne jamais rien entreprendre sans le voir ou le comprendre. Si le client ou votre propre entreprise ne sont pas disposés à vous payer autant, ils ne vous préparent pas pour réussir.

C'était (et souvent) un manque de compréhension des détails, des données et de la manière dont ils interagissent au sein de l'application en cours de construction. Des hypothèses sont faites au lieu de poser des questions, de trouver des réponses et de tout casser.

Une chose que je dis souvent à mes clients est que, si vous voulez me pendre, laissez-moi au moins me pendre avec ma propre corde ou me tirer avec mon propre fusil et des balles, pas quelqu'un d'autre.

Avoir une porte tournante de personnes qui tentent de résoudre ce problème sera bien pire à la fin pour elles.

L'absence de réalisme, une planification médiocre et un manque de prévoyance peuvent être le signe d'un problème à l'échelle de l'organisation, auquel cas vous feriez mieux de vous y habituer ou de passer à autre chose.

Premièrement, considérez la possibilité que vous surestimiez la portée du projet. Les vendeurs et les architectes ont tendance à exagérer leurs solutions. Ne les prenez pas au pied de la lettre; ils s'attendent probablement à ce que vous obteniez moins que ce qu'ils ont promis au client.

Ce que je ferais ici, c’est prendre le temps que j’ai et le dépenser le plus judicieusement possible. Déterminez les priorités du client et respectez-les. Neuf fois sur dix, le client sera heureux que ses principales priorités aient été respectées et qu’il néglige les 80% du travail qui n’a pas été effectué.

La dernière chose que vous voulez faire est d'organiser des réunions d'urgence et d'accuser les gens d'être pervers. Vous dites:

"leur faire connaître la réalité"

mais la réalité n'est qu'un avis! Détendez - vous, faites votre travail, et passer votre capital politcal sur les choses qui comptent pour vous . Comme, promotion, plus d'argent, plus de vacances.

Votre patron qui négocie une promotion pour laquelle vous travaillez très dur pour le client a du sens. Ce n'est pas ce que vous allez faire pour le compte d'un client.

Une chose à garder à l'esprit est que les estimations n'incluent pas les pertes de temps ni les retards inévitables (ou des problèmes dus au fait que le client ne vous a pas indiqué ce qu'il aurait dit, par exemple un fichier d'informations dans un format particulier).

Nous avons appris à repousser l'estimation et / ou la date d'échéance chaque fois que l'une de ces choses se produit. Ajoutez une nouvelle fonctionnalité, obtenez un nouveau devis et une nouvelle date d'échéance. Si vous ne fournissez pas les informations nécessaires à la date convenue, obtenez une nouvelle date d'échéance. Donnez les informations, mais rendez-les incomplètes ou incorrectes ou autrement que ce qui a été promis, envoyez une nouvelle estimation et une date d'échéance, modifiez les exigences des fonctions convenues, obtenez une nouvelle estimation et une date d'échéance. Arrêtez de travailler sur le projet car le client souhaite que vous travailliez sur une priorité plus élevée, envoyez une nouvelle date d'échéance (et éventuellement une nouvelle estimation car il y aura un temps de rattrapage si le projet est en attente pour longtemps).

Si l’estimation initiale provient de l’extérieur du groupe de développement et que ceux-ci n’ont pas été consultés, préparez-la vous-même (à un niveau détaillé de toutes les tâches que vous pensez avoir à accomplir - à un niveau beaucoup plus élevé). de détail que l’estimation qui vous a été donnée) et fournissez-la immédiatement dans la chaîne et demandez ce que vous devriez découper afin de respecter l’estimation qui vous a été donnée.

Si la réponse est non, insistez pour que le client soit informé de la nouvelle estimation, maintenant que nous avons examiné la question de manière plus approfondie. Si la direction insiste pour que le client paie pour seulement X heures, demandez-lui qui paiera pour le reste des heures de développement, car le travail décrit ne peut pas être effectué à une valeur inférieure à votre estimation. Il se peut que la société soit prête à prendre le risque et à payer les heures elle-même.

S'ils ne sont pas disposés à utiliser leurs bénéfices et ne disent pas au client qu'ils ont besoin de plus d'heures, la société n'approuvera pas les estimations détaillées du personnel de développement par rapport aux ventes. "Ce que nous pensons que le client va faire. Afin de gagner le projet "estimation, vous êtes sur un projet de la mort marche et votre meilleur pari est de sortir le plus tôt possible. Vous pouvez faire remarquer que le client sera plus heureux de savoir que le projet prendra plus longtemps que possible après avoir passé les 50 heures qu’il a accepté de payer et qu’il n’est même pas près d’avoir terminé avec les 500 que vous aviez réellement besoin. Rappelez-leur que des estimations trop optimistes sont l’un des plus grands prédicteurs de l’échec d’un projet. Cela ne fonctionnera pas avec ces types d’entreprise, mais peut-être qu’il finira par s’y intégrer si vous le répétez suffisamment de fois.

Je prendrais également en compte le raffinement des estimations. Je veux dire "comme je le vois maintenant, ce projet prendra X heures-homme". Après 20-30%, je vais ré-estimer et ainsi de suite.

Après tout, comment un téléchargeur de fichiers effectue-t-il son estimation? Il le raffine constamment.

Je pense que pas assez d'estimateurs ne mettent pas assez d'emphase sur les faits de "L'estimation, c'est que vous me demandez de faire des calculs et devine pour prédire l'avenir de manière utile" et "L'engagement que nous prenons est complètement séparé du calcul que nous faisons pour faire l’estimation; nous pouvons accepter de faire des quantités stupides de travail, d’accepter des choses que nous voyons et que nous ne pouvons probablement pas terminer, mais rien de tout cela ne change vraiment le calcul de la solution "et" nous pouvons faire des méthodologies de développement qui ne sont pas gigantesques le lot de fonctionnalités A sera effectué d'ici la date B, ce qui réduira considérablement les risques d'échec "

De nombreuses estimations sont formulées dans le langage de la négociation. Ils doivent être exprimés dans le langage mathématique et parler des incertitudes inhérentes au calcul .

L'estimateur ne peut rien faire pour que la réalité tienne compte de la volonté des hommes d'affaires de le négocier. Son seul travail est de leur faire arrêter d'essayer.