Comment répondre "Quand cela sera-t-il fait?"

Nous l'avons tous, des problèmes difficiles à résoudre et à résoudre un problème grâce à un code obscur et à des fonctionnalités inattendues bizarres. Lentement, vous travaillez logiquement en essayant de trouver des modèles, des erreurs, des erreurs. Ce processus prend du temps et les problèmes sont souvent difficiles à comprendre par le client.

Comment peut-on répondre à la question "Quand sera-t-il fait?", En particulier lorsque le client peut ne pas comprendre les complexités inhérentes au développement de logiciels?

Vous répondez honnêtement à la question.

Vous leur dites que c'est un problème difficile, la solution n'est pas évidente et vous ne savez pas combien de temps il faudra pour le résoudre. Promettez-leur de les mettre à jour sur votre progression chaque [laps de temps], afin qu'ils sachent que vous y travaillez, et bien sûr, envoyez-leur les mises à jour.

Les développeurs abordent un problème complexe en le décomposant en plus petits et en les résolvant séparément.

Dans un monde idéal , résoudre un problème serait un problème complexe A et vous seriez en mesure, en un temps donné, de le décomposer en une courte liste de petits problèmes A ₁ à A _n , pour chaque évaluation le temps est simple, étant donné que le temps requis pour résoudre le problème complexe initial serait:

avec D étant le processus lui - même de la décomposition.

Dans le monde réel , le seul problème est que t ( D ) serait en fait plus grand que le temps que vous passez à résoudre les petits problèmes. En d'autres termes, pour arriver à ce niveau de décomposition du problème, vous devez pratiquement résoudre le problème lui-même.

Vous pouvez toujours:

• Séparez la tâche donnée (résoudre le problème) en plus petits morceaux, chaque morceau étant toujours un problème complexe,

• Évaluez le temps prévu pour chaque morceau et le risque correspondant.

  Par exemple, la tâche 1 nécessite env. 5 heures, mais le risque d'être bloqué en le faisant est élevé, alors donnez 12 heures en tant qu'attente au client.

• Évaluez les dépendances et comment elles affectent le temps.

  Par exemple, la tâche 19 nécessite 2 heures, et le risque est si faible que vous pouvez dire que c'est 2 heures à coup sûr. Pas 1. Pas 3. Mais la tâche 19 repose sur la tâche 24: la tâche 24 peut affecter la tâche 19 d'une manière dont vous auriez besoin pour réécrire complètement le code de la tâche 19 en utilisant une approche différente.

• Donnez tous ces détails à votre client. Ne donnez pas la somme.

Le dernier point est important. Si vous donnez la somme, disons 192 heures, le client pense que c'est une mesure très précise, et le temps que vous passerez est, disons, de 189 à 195 heures.

Si, au lieu de cela, vous donnez les détails,

• Le client qui s'en soucie comprendra que ce n'est pas 192 heures. C'est 192 heures si tout va mal compte tenu du risque déterminé lors de l'évaluation. C'est aussi 238 heures si tout va encore pire. C'est aussi 85 heures si tout va bien.

• Quant au client qui s'en fiche, il ne lira pas votre réponse dans tous les cas. Tout ce qu'il veut, c'est un numéro, pour pouvoir te blâmer plus tard. En donnant une réponse très détaillée qu'il ne lira jamais, vous savez qu'il ne peut pas vous demander le temps que cela prendra encore: vous avez déjà répondu à cela. Il ne peut pas non plus vous blâmer plus tard, car il n'a pas lu la réponse pour calculer la somme.

Quoi que vous estimiez, n'oubliez pas d'inclure la loi de Hofstadter : cela prend toujours plus de temps que prévu, même si vous tenez compte de la loi de Hofstadter.

En règle générale, j'utilise une formule modifiée de CPM / PERT. C'est quelque chose comme ça:

Mn + Mx + C(T) / 2 + C, where
Mn is the minimum number of hours you think it will take,
Mx is the maximum number of hours you think it will take,
T is the typical number of hours it takes,
and C is a confidence factor from 1 - 3 based on how much you've done similar things.

(Je ne sais pas comment faire tout le formatage mathématique sophistiqué; si quelqu'un veut modifier cela pour cela, alors n'hésitez pas.)

So, if you think:
Mn = 60  hours
Mx = 180 hours
T  = 100 hours
C  = 2
Then: 60 + 180 + 2(100) / 4 = 110 hours.

J'insiste sur le fait que cela peut varier considérablement, selon la façon dont le projet se déroule. Si vous réévaluez votre projet tous les quelques jours, vous pouvez même fournir une mise à jour hebdomadaire. Cela contribue grandement à satisfaire les clients irritables. :)

Il est difficile d'expliquer des délais vagues aux utilisateurs non techniques. Cela est vrai à la fois dans les phases créatives d'un projet et lors de la recherche d'un bug embêtant. Dans les deux cas, le traditionnel «décomposer le travail en morceaux plus petits» ne fonctionne pas aussi bien.

La tâche d'origine se concentre sur ce dernier cas, nous allons donc nous attarder sur cela. Si vous ne pouvez pas donner de chronologie, dites à l'utilisateur ce que vous allez essayer et quand vous y reviendrez. Lorsque vous atteignez le point à mi-chemin du calendrier auto-imposé, faites une mise à jour par e-mail courte et honnête. Au moins une heure avant la date limite, donnez votre réponse officielle. Vous avez maintenant de la crédibilité. Si le problème n'est pas résolu, vous éclairez au moins un peu. Cela peut sembler une perte de temps, mais ce n'est pas le cas.

Comme vous ne pouvez pas tenir compte des barrages routiers inconnus et des surprises imprévues, il peut être difficile d'estimer avec confiance. Idées:

• Essayez une gamme - "Je suis sûr que cela prendra au moins N jours (par exemple 3), mais pourrait prendre jusqu'à 4N."
• Recherchez le soutien d'ingénieurs plus expérimentés dans l'estimation et la défense des estimations.
• Travaillez dans des itérations plus courtes (style Agile / Scrum) pour produire un code minimum qui ajoute de la valeur commerciale (gagner en confiance), puis répétez.
• Apprenez les techniques de négociation d'un livre comme le classique Getting to Yes (http://www.amazon.com/gp/aw/d/0143118757).

Pour les nouveaux développements, en particulier le développement Agile:

"La perfection est atteinte, non pas quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à emporter." - Antoine de Saint-Exuper

Si vous estimez l'effort et le temps nécessaires pour corriger des erreurs presque impossibles à reproduire dans un système affreusement trop complexe avec très peu ou pas de développeurs ayant une connaissance du domaine intime du système, la seule bonne réponse est "Quand il est corrigé".

En général, je leur disais juste la vérité. Je leur dirais qu'ils ne me connaissent pas en ce moment, et j'aurais peut-être une meilleure idée d'ici une semaine. Je leur donnerais ensuite un parc de balles avec autant de gribouillis devant que vous pouvez en tenir sur le papier pour indiquer qu'il s'agit d'une supposition basée sur le sentiment de l'intestin. S'ils commencent à vous mettre en boule, commencez simplement chaque phrase par "C'est possible ..." Habituellement, quiconque pour qui je fais quelque chose est satisfait du "Revenez dans une semaine environ, mais maintenant tout ce que je peux dire est d'environ 2 mois" ou quelque chose comme ça.

Le Personal Software Process (PSP) se concentre sur l'amélioration des estimations. Ceci est réalisé par une journalisation disciplinée des tâches. Cela, en substance, "accélère" quelque peu la partie "expérience" de l'estimation, car vous aurez des données réelles sur les tâches typiques. Bien sûr, cette profession nécessite toujours des solutions uniques à de nombreux problèmes, mais d'après mon expérience, les estimations sont meilleures après avoir utilisé PSP.