Lorsqu'on vous demande d'estimer des dates d'échéance, y a-t-il une façon particulièrement polie ou intelligente de dire “ce sera fait quand ce sera fait” ?
Est-ce la seule façon de dire “je ne peux pas le dire maintenant, vérifiez avec moi à [heure donnée]” ?
J'ai été un manager qui a reçu le message “ce sera fait quand ce sera fait”, et il s'agit de la réponse la moins utile qu'il soit possible de donner+. En disant cela et rien d'autre, vous risquez fort d'être considéré comme non coopératif. Vous devez absolument donner plus d'informations.
Pour expliquer un peu plus le “pourquoi” de tout cela, dans un projet de logiciel, il y a souvent des actions qui ne peuvent être faites que lorsque vous avez terminé, mais qui doivent être planifiées et programmées à l'avance. Si vous ne pouvez pas dire quand vous aurez terminé, le projet finit par être encore plus tardif et coûte souvent plus cher.
Cela dit, “Quand aurez-vous terminé ?” ne signifie pas toujours “Dépêchez-vous”. Souvent, la personne qui demande veut savoir afin de pouvoir planifier. Il vaut mieux le supposer, sauf si vous avez une raison de penser autrement.
Voici quelques circonstances possibles dans lesquelles vous pourriez vous trouver :
**Vous avez un autre travail à faire qui a une plus grande priorité :
Dites-le. Si c'est possible, dites aussi à la personne qui vous demande “Si je commençais le travail maintenant et sans interruption, je serais fini par…”. Si vous savez également quel est le travail qui vous attend et qu'aucun autre travail n'est susceptible d'arriver, dites “Je pense que je pourrai commencer à travailler sur votre projet le [date], auquel cas il sera terminé pour le [date]”. Si la situation est compliquée, adressez la demande à votre patron, qui fixera vraisemblablement votre emploi du temps. C'est à la personne qui vous demande de négocier avec elle la priorité du travail dont elle a besoin.
Vous êtes dépendant du travail de quelqu'un d'autre qui ne s'est pas engagé à respecter une date d'achèvement. Si vous le savez, vous pouvez dire “si tel ou tel s'engage à terminer son travail pour le [date], je peux le faire pour le [date]”. Cela serait utile.
**Vous n'avez pas assez d'informations sur ce qui est nécessaire pour faire des estimations du travail. (Sentez-vous un schéma ?). Assurez-vous que vous avez dit à la personne chargée de vous fournir les informations que vous avez besoin de ce dont vous avez besoin.
*Si vous travaillez déjà sur le projet, le fait de ne pas savoir quand il sera terminé est un problème, et vous devriez essayer de faire en sorte que cela ne vous arrive plus. Si vous n'avez pas pu faire d'estimation parce que vous avez d'autres choses à faire, consultez le point 1. Si l'estimation des dates d'achèvement est importante pour votre organisation (et si l'on vous demande d'en faire une, cela signifie généralement qu'elle l'est), il est souvent utile de prendre le temps de mieux comprendre le problème afin de pouvoir faire une estimation précise, même si cela implique de retarder légèrement la date d'achèvement réelle. Une date d'achèvement prévisible est parfois préférable à une date d'achèvement courte. Si aucune des trois premières conditions ne s'applique, la meilleure réponse que vous pouvez donner est * “Pas avant [cette date], pas après [cette date]”. La date “pas plus tard que” devrait être votre meilleure estimation dans le pire des cas, plus un grand facteur de sécurité.
Parfois, bien sûr, vous vous rendez compte soudainement, au cours d'un travail, que cela va prendre beaucoup plus de temps que vous ne le pensez. Si le calendrier de votre travail est important, il est généralement préférable de vous asseoir et d'essayer de déterminer le temps qu'il vous faudra réellement, plutôt que de vous contenter de labourer. Parfois (ou en fait toujours, à cause de la loi de Murphy), on vous demandera un devis alors que vous êtes encore en train de le calculer. Dans ce cas, il est tout à fait normal de dire “J'aurai une meilleure estimation pour vous dans [un certain temps]”
Au fait, toutes les réponses ci-dessus supposent que vous êtes un travailleur “de haut niveau” responsable de son propre planning. Si ce n'est pas le cas, ou en cas de doute, impliquez votre patron.
+_Pas techniquement la réponse la moins utile. Un mensonge ou un rendez-vous que vous n'avez pas l'intention de tenir serait pire. Mais “ce sera fait quand ce sera fait” n'est qu'une étape de plus par rapport à ces derniers.
Quand on vous demande d'estimer des dates d'échéance, y a-t-il une façon particulièrement polie ou intelligente de dire “C'est fait quand c'est fait” ?
J'ai toujours aimé “une fois que les gens arrêtent de m'interrompre”, mais je ne suis pas particulièrement poli.
La seule façon de dire “Je ne peux pas le dire maintenant, vérifiez avec moi à [heure donnée]” ?
Certainement pas. Il y a des entreprises/cultures où “Quand c'est fait” est une réponse acceptable Blizzard par exemple , au moins à l'extérieur), et je vous encourage à travailler et à changer votre culture dans ce sens.
** “Je ne suis pas sûr, cela dépend d'Alice et de Bob et… ”** est une réponse assez passive-agressive qui peut être utilisée dans certains domaines pour détourner la personne qui pose la question et qui, si elle est bien faite, peut transformer cette personne en un atout qui vous aide à lever les obstacles.
** “Je ne suis pas sûr, quand allez-vous m'avoir X ? ”** est une réponse plus clairement agressive lorsque quelqu'un se mêle de vos affaires mais ne s'occupe pas des siennes. Il peut être utile de souligner que vos estimations ne seront pas meilleures que les leurs, et il est idiot de vous imposer des normes plus élevées. Non recommandé.
** “Je ne suis pas sûr, je dois vérifier avec mon équipe” peut être une réponse solide qui vous donne du temps pour réfléchir, ainsi que de vous présenter comme quelqu'un qui s'en remet aux connaissances des experts. Il est également utile de vérifier avec votre équipe, car elle peut généralement fournir de bons commentaires et se rallier à l'échéance que vous lui imposez. Mais attention, cette réponse peut être mal utilisée et vous faire passer pour quelqu'un qui ne fait rien d'autre qu'être un intermédiaire.
“Cela dépend, que doit-elle faire ? ” Une autre réponse solide qui peut être passive-agressive, mais qui peut parfois déboucher sur une belle séance improvisée de collecte d'exigences. Cela permet également de maintenir l'honnêteté des affaires. Si vous vous engagez à travailler, alors ils doivent s'engager sur le champ d'application (et les ressources).
“Cela dépend, dans quelle mesure cela doit-il fonctionner ? ” Comme la dernière question, cela aide à affiner le champ d'application et remplit le troisième côté du triangle .
“Je ne sais pas. Ce sprint est XYZ ” Une réponse limitée pour les personnes utilisant des sprints (souvent des ingénieurs en informatique). Ce qui est bien ici, c'est que l'entreprise a probablement décidé de faire de l'Agile avec des sprints, donc vous avez ce soutien. Dans un environnement idéal, les seules choses prévues sont les ~2 semaines de votre sprint actuel. Tout le reste est volontairement non planifié pour que vous puissiez être bien… …sur ce qui est prioritaire. Dans un monde non idéal, les choses sont probablement planifiées au Nième degré, puis brisées en morceaux de deux semaines, mais la question vous donne une bonne occasion de commenter cette absurdité de façon sournoise.
En bref, il y a beaucoup de mauvaises façons d'esquiver la question. Vous feriez mieux de donner un chiffre pour le pire scénario et de vous remettre au travail.
J'aime bien “il n'y a pas encore d'estimation pour cela”
Il donne la réponse que vous voulez, il est assez factuel et de ton neutre, et il suggère qu'une estimation pourrait être faite à un moment donné, mais certainement pas maintenant ici à la machine à café sans une image claire de ce que cela signifierait réellement de faire la chose qu'il demande.
Vous devez vous préparer à la question “de quoi auriez-vous besoin pour faire une estimation”, car cela doit être pris au sérieux.
Lorsqu'on vous demande d'estimer les dates d'échéance, y a-t-il une façon particulièrement polie ou intelligente de dire “C'est fait quand c'est fait” ? Vous ne pouvez généralement pas vous permettre d'être intelligent et de dire “Ce sera fait quand ce sera fait”, quelle que soit la façon dont vous le présentez. Lorsqu'on vous demande d'estimer les dates de réalisation, ce n'est généralement pas ce que le demandeur veut entendre.
Vous pouvez plutôt transmettre votre estimation, et donner un degré de précision à votre estimation.
Quelque chose du genre “Selon ma compréhension actuelle du projet, mon estimation est de 3 mois. Mais, comme les exigences ne sont pas encore écrites, je pourrai fournir un devis plus précis une fois que je les aurai lues”. Si votre environnement de travail nécessite quelque chose de plus formel que ce genre d'estimation spontanée par téléphone ou par e-mail, assurez-vous d'inclure toutes vos hypothèses dans votre estimation formelle, ainsi que votre évaluation de la précision avec laquelle vous êtes en mesure d'estimer à ce moment-là. Vous pouvez faire mieux, si on vous accorde plus de temps pour préparer votre estimation et si on vous donne plus de données sur lesquelles vous pouvez vous baser. Une fois que vous avez fourni vos estimations (quelle que soit la manière dont elles ont été établies), tenez vos parties prenantes informées de tout événement susceptible de modifier votre estimation, en particulier à l'approche des échéances.
Je suppose que vous êtes la personne responsable du projet ou de la tâche qui fait l'objet de la demande. Dans ce cas, pourquoi ne pouvez-vous pas le dire ? Vous attendez que les obstacles s'estompent avant de progresser. Il y a trop d'inconnues ou de dépendances futures dans la tâche pour pouvoir l'estimer raisonnablement. La tâche qui vous est confiée est mal définie. “Fait quand c'est fait” donnera simplement l'impression que vous ne savez pas et que vous ne faites rien pour le découvrir. Cela empêche donc votre responsable de planifier la situation dans son ensemble.
D'après vos réponses aux commentaires et aux questions, je pense que votre question devrait vraiment être :
Mon travail consiste en de nombreuses petites tâches, que je peux recevoir dans n'importe quel ordre, et qui ont des priorités variables. J'ai une file d'attente constante de tâches de moindre priorité que je ne peux effectuer que lorsqu'il n'y a pas de tâches plus prioritaires à accomplir.
On me demande souvent de donner une estimation de la date à laquelle les tâches de moindre priorité seront terminées. Ma réponse actuelle, “Ce sera fait quand ce sera fait”, n'est pas bien reçue.
Que dois-je faire ?
De ce point de vue, la réponse est évidente - vous devez améliorer le suivi et la gestion des tâches. Cela n'impliquera pas de modifier votre processus/queue/priorité - juste un peu de travail supplémentaire dans le suivi temporel de chaque tâche.
Numéro 1 est probablement assez facile à deviner. “Entre 6 et 10 heures” est très bien, vous n'avez pas besoin de vous efforcer d'être précis ici, juste une estimation approximative. Il y a de fortes chances que vous ayez une assez bonne compréhension de la tâche pour pouvoir donner ici une estimation décente avec un minimum et un maximum probable.
Numéro 2 va demander un peu plus de travail chaque semaine. Si vous suivez déjà les tâches et le temps, cela ne devrait pas être difficile, mais même si vous ne vous contentez pas de tenir un bloc-notes, et chaque fois que vous terminez une tâche, notez le niveau de priorité et le nombre d'heures que vous y avez consacrées. À la fin de la semaine, vous pouvez additionner le temps consacré à chaque priorité et, après quelques semaines, vous devriez avoir une moyenne décente.
Lorsque quelqu'un vous demande une date d'achèvement, additionnez toutes les heures consacrées à sa tâche et aux tâches qui la précèdent à un niveau de priorité donné pour obtenir le temps minimum et maximum, puis divisez-le par le nombre moyen d'heures disponibles à ce niveau de priorité par semaine. Ne leur dites pas combien d'heures vous avez attribuées à chaque tâche, ni combien d'heures vous avez attribuées par semaine, ils doivent juste savoir le jour où cela n'aura pas lieu avant, et le jour où cela doit être fait. Il y a 3 tâches avant celle-ci, et il semble que le meilleur cas soit le vendredi suivant, et le pire le mercredi suivant. Vérifiez avec moi dans quelques jours et j'aurai une meilleure estimation" _
S'il y a des tâches à faire qui ne sont jamais faites, vous pouvez envisager d'augmenter le niveau de priorité en fonction du temps. Les tâches de faible priorité, si elles ne sont pas effectuées dans les N semaines, passent au niveau de priorité suivant.
Vous pouvez ainsi fournir des estimations qui permettront de gérer les attentes de vos collègues et supérieurs.
Pas d'information, “Ce sera fait quand ce sera fait” est pire qu'une information indésirable, _“Les tâches de plus haute priorité nous submergent. Il faudra 8 semaines avant que cela ne soit automatiquement mis à jour, et il faudra ensuite une semaine ou deux dans cette file d'attente jusqu'à ce que cela soit terminé”.
C'est une chose qu'il ne faut jamais dire. Tout ce que cela fera, c'est irriter votre supérieur et vous faire passer pour incompétent.
Dites-lui ce que vous pensez qu'il faudra (si vous ne pouvez pas définir les étapes et en gros ce qu'elles prendront, alors vous devez probablement demander à quelqu'un de faire un meilleur travail sur les exigences, alors dites-lui que les exigences ne sont pas claires et que vous ne pouvez donc pas déterminer ce qu'il faudra), quels sont les retards que vous avez généralement en raison de travaux plus prioritaires et donnez-lui ensuite une date. Les clients n'acceptent pas de date d'échéance et vous ne devez donc pas la leur donner. Lorsque la priorité change et que d'autres éléments sont avancés, envoyez un courriel au responsable et fixez une nouvelle date en fonction du retard. Souvent, lorsque vous signalez un changement de date, les éléments les plus prioritaires sont déplacés vers le bas. Lorsque des événements font que le travail prend plus de temps que prévu, assurez-vous que le responsable est immédiatement informé de l'impact que cela a sur la date d'échéance.
Tout responsable devrait être en mesure de fournir des estimations de temps. Cela fait partie de ce pour quoi vous êtes payé, alors arrêtez de vous contenter de “quand”. Si vous n'êtes pas doué pour cela, améliorez-vous en gardant une trace de ce que vous avez estimé et de ce qu'a été le temps réel. Incluez dans votre estimation le temps de retard et le temps nécessaire pour les réunions, la communication par courrier électronique, les besoins de raffinage, les tests unitaires, les tests de qualité de soutien, etc. pour obtenir un meilleur chiffre. Si on vous demande une date directe, supposez que vous n'avez pas plus de 6 heures productives par jour lorsque vous convertissez les heures que vous pensez qu'il faudra en jours et ajoutez quelques jours pour les retards inévitables.
D'après les commentaires sur les autres réponses, il semble que votre problème ne soit pas d'estimer le temps mais de communiquer les retards en fonction des changements de priorités. Ce dont vous avez besoin, c'est d'être plus, et non moins communicatif lorsque cela se produit. Vous devez faire savoir aux gens quand leur tâche est tombée dans la liste des priorités (et à quoi) et sera retardée et combien de temps vous pensez qu'elle le sera avant que vous n'y reveniez. Laissez-les aller se battre sur les priorités avec les responsables. Dites-leur qu'ils peuvent parler au manager s'ils ne sont pas d'accord avec les priorités actuelles.
Mais vous avez l'obligation absolue de leur faire savoir quand les choses changent et que vous allez travailler sur quelque chose en amont de leur projet. Cela ne doit pas attendre qu'ils vous demandent pourquoi ce n'est pas encore fait. En tout état de cause, “quand” n'est pas une réponse acceptable. Prétendre que vous êtes trop occupé pour répondre n'est pas acceptable non plus.
Vous devez comprendre que les rapports d'avancement, les estimations de temps, etc. sont tous votre travail et sont aussi importants ou plus importants que les parties de développement proprement dites. Il ne s'agit pas d'une interruption inutile, cela fait partie de votre travail. Ces personnes paient votre salaire avec leurs projets. Commencez à les traiter avec respect et à respecter leurs besoins. Une fois qu'ils sauront qu'ils peuvent vous faire confiance pour leur dire quand les choses seront retardées, ils vous embêteront moins.
Vous devriez répondre par une distribution, et non par un numéro unique : quelque chose du genre “Cela pourrait être fait la semaine prochaine, si nous avons de la chance. Si nous sommes malchanceux, dans six semaines. La meilleure estimation est d'environ deux semaines”. Cette réponse suscitera souvent une mauvaise réaction. Si c'est le cas, vous pouvez citer un certain nombre de traités d'estimation des coûts de logiciels qui montrent qu'une telle incertitude est courante et réaliste.
J'ai travaillé sur un projet similaire. Une tâche que je pensais prendre deux semaines a fini par prendre un mois et demi.
Heureusement, je savais que je n'avais pas bien saisi le temps qu'il fallait y consacrer. Donc, lorsque mon patron me demandait en face à face (nous travaillons avec le développement Agile), je lui donnais ma meilleure estimation et lui expliquais pourquoi je pensais cela. Bien que mes estimations se soient finalement révélées inexactes, je lui ai donné ce que je pensais qu'il faudrait par demande, mais je me suis assuré qu'il savait que cela pouvait changer. En général, l'honnêteté est la meilleure chose à faire, soyez franc et tenez-le au courant. Il arrive qu'il n'y ait pas de réponse claire et tout ce que nous pouvons faire est de tenir nos patrons aussi informés que possible sur la question.