Why everyone gets it wrong
When estimating, people picture things going well: sit down, write it, it works. What the work actually consists of doesn't make it into that picture.
Missing: chasing an incomprehensible error, setting up the environment, digging through documentation, redoing things after the first approach turned out wrong, and the evenings you never managed to sit down at all.
Hence the stubborn coefficient: the real duration is usually three times the first estimate.
Estimating more reliably
Break it into one- or two-evening pieces. A task you can't estimate is too big. Keep splitting until every piece is comprehensible.
Side effect: splitting usually surfaces what you hadn't thought about. That's the missing time.
Estimate each piece and add them up. A sum of small estimates lands closer to the truth than one large one.
Multiply by two. Not three — two, because the splitting already absorbed part of the error.
Count in evenings, not hours. "Three evenings" is more honest than "six hours": you won't sit for six hours straight anyway.
What eats time invisibly
- Setup. Deploying, connecting the database, sorting out access. Half a day minimum, and never in the plan.
- First contact with the unfamiliar. A new library isn't "install it", it's "understand how its author thinks".
- The small stuff at the end. Error handling, empty states, behaviour on bad data. Always more of it than expected.
- Waiting for each other, in team work.
Using this
You calculated, doubled, got ten weeks, and realised that's a lot. Good: that means cut the scope rather than hope for luck.
Trim to six or eight weeks. Projects planned for longer rarely survive: that's roughly how long interest holds.
If it still doesn't fit
Don't move the finish line — cut the scope. Remove everything outside the main scenario and finish what's left.
A finished project missing half the plan is more use than the full plan abandoned halfway. The first can be shown; the second can't.
And record how long it actually took. After two or three projects you'll have your own correction factor: you'll know by how much you personally are out. That's one of the most useful skills separating people with experience from people without.
Открытые роли по теме статьи
Читать полезно, а делать — ещё полезнее. В эти команды можно написать прямо сейчас:
- iOS-разработчик — MAIBO - MedTech-пилот для клиник
- Контент-маркетолог / комьюнити — CohortX — платформа командных пет-проектовмаркетингtelegramseoконтент
Похожие статьи
- Study Tools Season: two weeks, a team, and a finished projectCohortX launches its first season: September 7–21, teams of 2–4 build one study tool each — from schedules to progress trackers. How to join and what it adds to your portfolio.
- Сезон инструментов для учёбы: две недели, команда и законченный проектCohortX запускает первый сезон: с 7 по 21 сентября команды по 2–4 человека делают по одному инструменту для учёбы — от расписания до трекера прогресса. Как участвовать и что это даёт портфолио.
- A portfolio without commercial experience: what belongs in itHow many projects you need, which ones carry weight, how to present a repository, and what to do with coursework.