Que faire lorsque l'estimation du temps tourne mal?


26

Supposons que le temps estimé pour une affaire soit de 3 jours. Le deuxième jour, vous remarquez que le cas se développe et que de nouveaux scénarios surgissent qui n'ont pas été comptés lorsque l'estimation du temps a été effectuée. La nouvelle découverte conduit à 2 jours supplémentaires (total 5 jours). C'est un problème typique auquel vous serez confronté tôt ou tard en tant que développeur.

  • Quelle stratégie peut-on utiliser lorsque vous allez informer le chef de projet du nouveau délai de livraison?
  • Souvent, vous obtenez la question pourquoi? Comment motivez-vous le nouveau délai de livraison?

Le fait est que de nombreux projets ne mettent pas beaucoup de temps sur l'analyse et la conception pendant SDLC.

EDIT: Dans les projets très complexes, peu importe le temps raisonnable que vous consacrez à Analysis & Design, il y a toujours des surprises car les règles métier sont trop complexes. Cependant, dans de tels cas, je crois que le chef de projet doit être conscient de la complexité et avoir la bonne attitude lorsque des surprises inattendues se présentent. La question est de savoir comment aborder les chefs de projet qui ne comprennent pas la complexité.


1
Je pense que la meilleure question est, que faites-vous lorsque l'estimation était correcte ? La plupart du temps, ce ne sera pas le cas.
Tim Post

@Tim Post Vous avez raison: "La plupart du temps, ce ne sera pas le cas", je voulais réserver.
Amir Rezaei

1
+1 - Merci pour l' EDIT qui contient des paroles de sagesse. Le fait que vous ayez souligné ("" Dans les projets très complexes, peu importe le temps raisonnable consacré à Analysis & Design, il y a toujours des surprises car les règles métier sont trop complexes.) "" Est très vrai.
Karthik Sreenivasan

Réponses:


17

Fournir de mauvaises nouvelles

Vous devez absolument soulever la question rapidement, mais si vous pouvez le faire dans un délai raisonnable (c'est-à-dire quelques heures, pas plus), vous devriez faire une petite analyse d'impact avant de le faire.

Comme pour toutes les mauvaises nouvelles, il est préférable de fournir des informations détaillées (plutôt que de simplement laisser échapper "il va être tard"), alors fournissez autant / beaucoup de:

1) Estimations / délais révisés pour les tâches qui ont glissé.

2) Estimations / échelles de temps révisées pour les tâches futures qui, selon vous, compte tenu du fait que certaines choses sont déjà dépassées, peuvent prendre plus de temps.

3) Très brèves raisons pour lesquelles le glissement s'est produit (ne tournez pas, juste la vérité, mais ne donnez pas l'impression que vous faites des excuses). Dans ce cas, vous déclarez "Nous avons estimé sur la base des règles X et Y mais ils ont maintenant inclus Z qui n'a jamais été mentionné". Il pourra peut-être l'utiliser pour expliquer le retard aux clients et les éduquer sur l'importance d'être minutieux en premier lieu.

4) Si possible, des alternatives pour remettre les choses sur les rails (réduisant généralement la portée mais il peut y avoir d'autres options - d'autres parties du projet peuvent être en avance et il peut être possible de déplacer les tâches).

N'oubliez pas qu'avec les dérapages, l'impact psychologique / de crédibilité est culminant. Vous pourrez peut-être vous en tirer avec un, mais le second sera beaucoup plus difficile et le troisième encore plus difficile.

C'est pourquoi le point 2 est important - révisez non seulement ce qui a déjà glissé, mais aussi les tâches futures qui, selon vous, peuvent prendre plus de temps que prévu. Le glissement se produit dans les TI, ne pas apprendre de ses erreurs est un plus grand péché.

Empêcher d'avoir à livrer de mauvaises nouvelles

Il y a deux scénarios ici: premièrement, vous n'avez pas fait les estimations vous-même, auquel cas vous ne pouvez pas faire grand-chose d'autre que de pousser à participer aux estimations la prochaine fois.

Deuxièmement, vous avez fait les estimations vous-même, auquel cas vous devez voir comment faire de meilleures estimations. Pour moi, la phrase clé de la question est "il y a toujours des surprises car les règles métier sont trop complexes" .

Avec égards, si cela arrive toujours, cela ne devrait pas être une surprise . Si vous n'obtenez jamais que la moitié des règles métier, vous devez supposer cela dans vos estimations et autoriser le fluage des fonctionnalités.

Vous pouvez soit le faire en augmentant les estimations des règles que vous avez (cela fonctionne mais vous n'informez personne de ce qui se passe réellement), mais il vaut mieux dire avec vos estimations "Historiquement, les règles que nous obtenons sont une version simplifiée de ce qu'ils veulent vraiment. Les règles qu'ils ont énoncées prendront 3 jours à mettre en œuvre, mais nous devons prévoir 3 jours supplémentaires pour les règles qui n'ont pas été mentionnées mais qui seront probablement découvertes pendant le développement et les tests. "

Si le PM remet cela en question, vous devez lui rappeler toutes les fois où cela a été vrai (avec des exemples - il est difficile de discuter des exemples) et suggérer doucement qu'il est dans son intérêt de livrer à temps ainsi que le vôtre, n'est-ce pas? vaut mieux être conservateur?

Mais l'essentiel: si vous sous-estimez toujours en raison d'un facteur spécifique (dans ce cas, le fluage des caractéristiques), intégrez-le dans vos estimations.


2
+1 "Comme pour toutes les mauvaises nouvelles, il est préférable de fournir des informations détaillées" Cependant, tout le monde ne comprend pas les détails / la complexité du problème.
Amir Rezaei

@Amir - J'en ai ajouté un peu plus, mais en tant que personne qui comprend la complexité, la simple vérité est qu'il est de votre responsabilité de l'expliquer. Ils n'apprendront pas autrement.
Jon Hopkins

Bons points! "avec des exemples - il est difficile d'argumenter des exemples" & "suggère doucement qu'il est dans son intérêt de livrer à temps". En ce qui concerne "si cela arrive toujours, cela ne devrait pas être une surprise", le problème est que le temps supplémentaire pour la surprise n'est pas constant. Vous ne pouvez donc même pas prendre une moyenne sur eux, car ils ont tendance à avoir de grandes variations.
Amir Rezaei

+1 "N'oubliez pas qu'avec les dérapages, l'impact psychologique / de crédibilité est cumulatif."
Karthik Sreenivasan

16

Les estimations basées sur le temps sont des suppositions sur l'avenir, et cela échouera toujours à long terme. C'est une bataille inutile que vous ne pouvez pas gagner.

Arrêtez d'estimer en jours et utilisez plutôt une estimation relative . Voici un exemple simple:

  1. Attribuez un numéro à chaque tâche. La tâche la plus difficile peut être 10 et la tâche la plus simple 1.
  2. Commencez à programmer pour terminer vos tâches.
  3. Après une semaine, arrêtez votre travail et additionnez le nombre de toutes les tâches terminées. Disons que vous vous retrouvez avec 14. C'est votre vitesse hebdomadaire.

La semaine prochaine, répétez le processus à nouveau. Je parie que votre vitesse changera, mais pas beaucoup. Après quelques semaines, votre vitesse devrait être assez stable et c'est ce que nous visons. Vous pouvez maintenant commencer à planifier en toute confiance. Choisissez des tâches qui résument votre vitesse et votre PM peut être certain qu'il sera terminé comme promis. C'est ainsi que vous devez aborder vos chefs de projet.


Pouvez-vous donner un exemple de la façon dont vous gardez une trace de la taille des tâches? Créez-vous un tableau avec des types de tâches (comme "créer un nouveau formulaire", "ajouter une méthode au webservice X") ou est-ce plutôt une intuition?
grincer des dents

Comparez simplement les tâches que vous avez estimées et accomplies plus tôt.
Martin Wickman

+1 - "Les estimations basées sur le temps sont des suppositions sur l'avenir, et cela échouera toujours à long terme. C'est une bataille inutile que vous ne pouvez pas gagner." C'est la première fois que j'apprends des estimations relatives et c'est certainement un sujet de réflexion. Merci.
Karthik Sreenivasan

Quelle brillante idée! J'explorerai certainement cela plus loin.
meetpd

3

Dès que vous voyez que l'estimation est fausse, vous devez sonner l'alarme. Informez ceux qui attendent la livraison du retard.

Si possible, demandez l'aide de vos coéquipiers. Assurez-vous de toujours fournir des logiciels de la plus haute qualité possible.

Un raccourci fera probablement plus de mal à la fin, et toutes les personnes impliquées devraient le savoir. Ou du moins devrait-il être possible de leur expliquer.


3

Cela arrive si souvent qu'aucun gestionnaire de projet expérimenté n'en fera grand cas. Soyez honnête et ne faites pas de nouvelles estimations trop optimistes; quand vous le verrez, cela prendra beaucoup plus de temps, dites-le. Ne dites pas «j'ai besoin d'un peu plus de temps» au quotidien.

Vous devrez expliquer au responsable: est-ce que l'estimation était erronée en premier lieu ou est-ce que des circonstances défavorables (passé une journée à chasser un bug) étaient la raison du retard? Dans le premier cas, quelque chose ne va pas avec le processus d'estimation, c'est peut-être trop optimiste ou naïf. Dans le deuxième cas, il s'agit du tampon qui, espérons-le, a été inclus dans le plan de projet.


2

Gardez toujours les parties prenantes concernées au courant de vos progrès, y compris (surtout!) Du fait que vos estimations étaient trop optimistes. Ils ne seront pas contents, mais ils sauront où en est réellement le projet et pourront planifier en conséquence.

Idéalement, votre liste de fonctionnalités aura été MoSCoWed - Must, Should, Can't, Won't.

Lorsque vous vous dirigez vers un dépassement, coupez les Puissances, puis les Épaules. Coupez les fonctionnalités pour pouvoir livrer à temps: votre projet ne vit généralement pas de manière isolée, et le dépassement de la date de sortie signifie que les projets en aval dépasseront également leur calendrier.

Idéalement, vous n'aurez que 60% de moûts. Si vous devez couper ceux que vous avez des problèmes très profonds (ayant un dépassement très grave), dans ce cas, vous devrez couper les coins ronds.

Assurez-vous de vous donner suffisamment de temps après la sortie pour nettoyer le gâchis créé en coupant les coins!


4
+1 @Frank Bon point concernant les "fonctionnalités de coupe afin que vous puissiez expédier à temps". Le problème ici est que je ne suis pas le chef de projet.
Amir Rezaei

@Amir Dans ce cas, votre client est (gentiment) votre chef de projet. Vous dites "Je suis en retard. Je peux soit couper cette fonctionnalité, soit cette fonctionnalité. Que dois-je faire?"
Frank Shearar

@Frank Depuis que nous faisons Scrum, et que l'affaire est déplacée du backlog dans le sprint, il semble être écrit dans la pierre pour que PM réduise les cas. Cependant, un PM d'expérience peut ne pas avoir ce genre de problème.
Amir Rezaei

Je n'aime pas MoSCoW. Le seul astucieux est l'acronyme. Gardez simplement vos tâches dans un backlog priorisé.
Martin Wickman

1
@Martin hausser les épaules "Must" signifie "si vous ne livrez pas cette fonctionnalité, vous n'avez rien du tout". Ce sont des informations différentes d'un backlog priorisé, qui est "quelle fonctionnalité préférez-vous en premier?" Vous auriez toujours un backlog priorisé avec MoSCoW.
Frank Shearar

2

L'estimation du projet est un jeu d'argent, simple et clair. Il n'y a pas de récompense sans risque.

Si le manager ne comprend pas cela, c'est la première chose que j'explique.

La question est de savoir qui couvre le risque?

Si vous avez un contrat à prix fixe, vous couvrez le risque.

Si le temps et les matériaux, alors il couvre le risque.

Ainsi, lors de l'estimation, il est important de comprendre que vous devinez et que vous devez avoir une idée de l'incertitude de l'estimation et de la personne qui couvre le risque.


1

Je pense que la meilleure stratégie consiste à affiner constamment votre estimation . Je sais, je dis: votre question est en quelque sorte mal placée.

En lisant Introduction à la découverte délibérée de Dan North, je suis arrivé à la conclusion que placer l'effort d'estimation dans la phase de démarrage équivaut à faire une prédiction exactement lorsque votre ignorance du problème et du domaine est au niveau maximum. Avouons-le, vous ne pouvez pas prédire ce qui est incertain, surtout s'il est encore inconnu .

Les méthodologies agiles résolvent ce problème en divisant la durée de vie du projet en plusieurs morceaux (sprints, dans Scrum) et en répétant l'estimation (dimensionnement des histoires) chaque semaine. Chaque semaine, ce que vous savez du problème est affiné, de même que l'estimation.

Pour moi, une estimation ne peut pas être vraie ou fausse. Il peut simplement être de plus en plus raffiné . Une estimation n'est pas un engagement. C'est pourquoi cela s'appelle estimation.

Le mieux que vous puissiez faire lorsque vous êtes en retard (et aussi lorsque vous "risquez de livrer à l'avance", car le problème est le même: vous avez mal évalué) est de remonter le niveau et de le signaler au client dans les meilleurs délais. Cela s'appelle la gestion des risques. Plus tôt vous donnez votre avis, plus la contre-erreur sera efficace. Habituellement, cela signifie que, si vous avez des preuves que vous ne pouvez pas tout livrer , vous devez parler à votre client, lui dire que vous ne pouvez livrer que les 70% de l'engagement et lui laisser décider ce qui a plus de valeur commerciale pour elle et doit être déployé en premier .

J'ai écrit à ce sujet ici Mauvaise estimation, aide! Je suis en retard! Coupez les fonctionnalités et arrêtez la cascade!


1

Cela s'appelle une estimation parce que c'est une supposition éclairée. Ce n'est pas une description infaillible de l'avenir, et j'ai peu de patience pour les gens qui traitent les estimations de logiciels de cette façon. En fin de compte, beaucoup de choses prendront plus de temps que prévu, dans de rares cas, elles peuvent prendre un ordre de grandeur plus long. Cela arrive même aux meilleurs programmeurs du monde. Comment un manager peut-il s'attendre à ce que cela ne vous arrive pas? Si votre manager ne comprend pas cela, elle n'a pas beaucoup d'expérience. Si elle fait semblant de ne pas le comprendre afin de faire pression sur son horaire, elle est déraisonnable.

La meilleure approche est la plus évidente. Dès que vous avez une idée claire qu'une fonctionnalité va prendre plus de temps que prévu, discutez-en avec votre responsable. Il existe souvent des façons de procéder qui résoudront à la fois vos problèmes et ceux de votre manager. C'est-à-dire que la partie de la fonctionnalité qui ralentit les choses peut être relativement peu importante ou facile à modifier de manière à permettre des progrès plus rapides. Quoi qu'il en soit, ne vous laissez pas intimider par une deuxième estimation optimiste.


0

Faites-le savoir à toute l'équipe et essayez de trouver une solution. Je recommande 3 solutions, de haut en bas en priorité:

une. Essayez de trouver un correctif temporaire ou une solution rapide

b. Le travail que vous pouvez le faire, faites-le mieux. Après avoir montré votre excellente partie de travail au client, demandez-lui son aide: nous pouvons le faire, mais il y a un problème, et cela peut ralentir la productivité de votre travail ... Peut-être que vous pouvez lui demander s'il y a une demande inutile / fonction qui peut être supprimée ou réduite.

Proposer une approche alternative pour leur problème peut être une bonne idée.

c. Heures supplémentaires


J'ai mis à jour ma question. C'est le chef de projet qui sera averti.
Amir Rezaei

Je ne comprends pas très bien. Vous êtes chef de projet ou seulement programmeur?
Hoàng Long

0

Options:

  • Caractéristiques de coupe
  • Qualité de coupe (laissez les corrections de bugs pour plus tard)
  • Augmentation de la productivité
    • Rechercher et supprimer les bloqueurs
    • Pause / repos
    • Réduction du temps personnel / sommeil
    • Obtenez plus de main-d'œuvre
    • Obtenez de meilleurs outils
    • Formation
    • Accroître la motivation
      • La nourriture gratuite
      • [Promesse de] augmentation / promotion / vacances / bonus / etc.
      • Des menaces
      • Améliorer les conditions de travail (meilleure quincaillerie, mobilier, etc.)
      • Changer l'environnement - travailler dans un café ou déplacer toute l'équipe dans un endroit frais - un chalet de montagne ou une maison au bord du lac?

1
Il convient de noter que chaque mot est une réponse à COURT TERME à la question «que faire lorsque l’estimation du temps ne va pas». Plus particulièrement, les menaces augmentent brièvement la motivation , puis ont l'effet contraire.
Dan Ray

Je suis d'accord pour dire que les menaces sont nulles, même si je suis sûr qu'elles fonctionnent pour certaines personnes et dans certaines situations, surtout si vous prévoyez de les laisser partir de toute façon.

0

C'est un problème commun :)

L'une des approches les plus simples consiste à ajouter un tampon à toute estimation que vous faites, car des problèmes imprévus se produisent toujours. La taille de la mémoire tampon dépend de la taille de l'équipe et de l'incertitude de la technologie et du problème lui-même.

Les plus grandes équipes comptent plus de personnes susceptibles de tomber malades et moins de personnes qui savent «tout».

Les nouvelles technologies sont toujours plus risquées que celles que vous connaissez déjà.

Et lorsque vous voyez que vous n'aurez pas terminé à la date estimée, communiquez tôt avec les parties prenantes. Vous pouvez peut-être redéfinir les priorités ou retarder certaines fonctionnalités après avoir parlé avec le client / l'intervenant.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.