Le Calibrateur d’Estimation de Tâches : transformez votre historique de mauvaises estimations en facteur de correction personnalisé
Pourquoi ce prompt est important
Chronic estimation errors compound into missed deadlines, scope-creep resentment, and clients who stop trusting your quotes — eventually pricing in a personal "padding tax" or walking away entirely. Most people respond to bad estimates by vaguely resolving to "pad more next time," which either overcorrects on tasks that didn't need it or fails to catch the specific category actually causing the blowouts, since the real bias is rarely uniform across all types of work.
À quoi nous l'utilisons
A freelance web developer has blown three consecutive project deadlines, each time because "one more round of client revisions" ran long, and has a new project proposal due tomorrow where the client is specifically asking for a firm time-and-cost estimate broken down by task.
Prompt
ROLE: Act as a project estimation analyst who specializes in finding personal estimation bias patterns from historical data — not generic time-management advice, but a quantified correction based on someone's actual track record. CONTEXT: Historical task log: [PASTE A LIST OF PAST TASKS WITH: TASK NAME, CATEGORY/TYPE, ESTIMATED TIME, ACTUAL TIME TAKEN — AT LEAST 10-15 ENTRIES ACROSS AT LEAST 3 DIFFERENT TASK CATEGORIES] Upcoming tasks needing estimates: [PASTE A LIST OF NEW TASKS WITH THEIR CATEGORY AND YOUR INITIAL GUESS AT TIME REQUIRED] TASK: 1. Group the historical tasks by category. For each category with at least 3 data points, calculate the average ratio of actual-time to estimated-time (e.g., a ratio of 1.4 means tasks in that category typically take 40% longer than estimated). 2. Identify the DIRECTION and MAGNITUDE of bias per category — do not just say "you underestimate" — state the specific multiplier and how consistent it is (tight clustering vs. wide variance). 3. Flag any category with fewer than 3 data points as insufficient sample size — do not generate a correction factor for it, note that more data is needed instead. 4. Apply the calculated correction factor to each upcoming task's initial guess, producing a corrected estimate. For categories with insufficient data, apply the single highest-confidence correction factor as a conservative fallback and say so explicitly. 5. Identify if there's a task type that shows a DIFFERENT bias direction than the person's overall average (e.g., someone who generally underestimates but actually overestimates a specific category) — this is the most useful signal and must be called out separately if present. CONSTRAINTS: - Do not moralize about poor planning skills. Treat this as a calibration exercise, not a character critique. - If the historical data shows no consistent pattern in a category (high variance, ratios ranging wildly), say so rather than forcing a correction factor onto noisy data. - Round corrected estimates to a practical unit (nearest half hour, or nearest day for multi-day tasks) rather than false-precision decimals. OUTPUT FORMAT: ## Bias Analysis by Category [Table: Category | Avg Actual/Estimate Ratio | Consistency (tight/wide) | Sample Size | Confidence] ## Notable Exception [Any category bucking the overall trend — call this out even if the rest of the report is brief] ## Corrected Estimates for Upcoming Tasks [Table: Task | Category | Original Guess | Correction Factor Applied | Corrected Estimate] ## One Rule of Thumb [A single, memorable takeaway the person should apply mentally before their next estimate, even without rerunning this analysis]
Résultat
Bias Analysis by Category
| Category | Avg Actual/Estimate Ratio | Consistency | Sample Size | Confidence |
|---|---|---|---|---|
| Client revisions | 1.8x | Tight (1.6-2.0x) | 6 | High |
| New feature builds | 1.3x | Moderate (1.1-1.6x) | 5 | Medium |
| Bug fixes | 0.9x | Tight (0.8-1.0x) | 4 | High |
| Documentation | — | — | 2 | Insufficient data |
Notable Exception
Bug fixes are the one category where you consistently OVER-estimate, finishing in 90% of the time quoted — the opposite direction from your overall pattern. This is likely because you're padding bug-fix estimates out of anxiety about unknown scope, when in practice your diagnostic speed is faster than you give yourself credit for.
Corrected Estimates for Upcoming Tasks
| Task | Category | Original Guess | Correction Factor | Corrected Estimate |
|---|---|---|---|---|
| Homepage redesign revisions round 2 | Client revisions | 3 hours | 1.8x | 5.5 hours |
| Add CSV export feature | New feature builds | 8 hours | 1.3x | 10.5 hours |
| Fix checkout race condition | Bug fixes | 4 hours | 0.9x | 3.5 hours |
| API documentation update | Documentation | 2 hours | 1.3x (fallback, insufficient category data) | 2.5 hours |
One Rule of Thumb
Before quoting any client-revision-round estimate, silently double it — your gut number for this category specifically is off by nearly 2x, more than any other type of work you do.
La plupart des conseils sur les mauvaises estimations de temps se résument à « gonflez vos chiffres », ce qui est à peu près aussi utile qu’un cendrier sur une moto : ça ne dit ni de combien, ni où. Certaines catégories de travail sont estimées avec une précision correcte ; d’autres sont complètement à côté, souvent dans un sens que la personne ne remarque même pas consciemment. Ce prompt existe pour remplacer une vague intuition d’être mauvais en estimation par un vrai facteur de correction quantifié, tiré des données historiques de la personne elle-même.
Pourquoi la correction doit être par catégorie, pas globale
Un chiffre unique du type « vous sous-estimez de 30 % » cache plus qu’il ne révèle, car le vrai schéma n’est presque jamais uniforme. Quelqu’un peut chroniquement sous-estimer les cycles de révisions client de près du double tout en surestimant les corrections de bugs — appliquer un facteur de correction global à tout soit surcorrige les catégories déjà justes, soit laisse le pire contrevenant sous-corrigé. Découper l’analyse par catégorie, c’est ce qui transforme un lieu commun d’auto-amélioration en quelque chose d’actionnable la prochaine fois qu’on fixe un champ d’estimation vide.
Pourquoi le prompt refuse de générer un chiffre à partir de données maigres
Un modèle à qui on demande de toujours produire un facteur de correction va volontiers en générer un à partir de deux points de données — et ce chiffre sera du bruit déguisé en insight. L’instruction explicite de signaler les catégories avec moins de trois points de données comme insuffisantes, plutôt que de forcer un calcul, c’est ce qui garde la sortie honnête — un facteur de correction à fausse précision est pire que d’admettre que les données ne sont pas encore là, parce que ça crée de la confiance dans un chiffre qui ne la mérite pas.
Pourquoi la section « exception notable » compte plus que les moyennes
La sortie la plus utile de cet exercice est souvent la catégorie qui casse le schéma global — quelqu’un qui sous-estime généralement tout sauf un type de tâche spécifique, pour des raisons généralement liées à une anxiété ou une méconnaissance particulière. C’est le détail qu’un framework générique de gestion du temps ne ferait jamais remonter, parce qu’il n’apparaît que quand on regarde les chiffres précis de la personne plutôt que d’appliquer une règle universelle de productivité.
Où ça prend tout son sens
C’est le plus utile pour quiconque facture au projet ou à l’estimation — freelances, consultants, chefs de projet — juste avant un nouveau devis, et comme exercice mensuel récurrent à mesure que les données historiques s’accumulent. Chaque passage gagne en précision à mesure que le journal de tâches sous-jacent grandit, ce qui est l’inverse de la plupart des conseils de productivité qui donnent la même astuce générique, peu importe la quantité de données existante sur la personne qui l’utilise réellement.