The post has been translated automatically. Original language: Russian
- How long will it take?
"Three days.
A week later, the task is still in progress, and no one seems particularly surprised. Such dialogues are repeated so often in IT teams that they are already used to them. But it's not necessarily that developers are too optimistic. The reasons are usually much more prosaic.
The first and most common one is that we plan according to the best scenario.
Evaluating a task, a person often imagines the ideal course of work: he sat down, wrote, checked, and it's done. In reality, things almost never go so smoothly. You need to wait for a colleague's response, sort out the broken environment, clarify a sudden requirement, go through a review, and sometimes redo what already seemed ready.
Psychologists call this a planning error: we tend to underestimate the time for our own tasks, even if past experience has repeatedly shown the opposite.
There is another problem: the evaluation often includes only what is clearly visible at the beginning. For example, development seems like a three-day task, because only writing code is taken into account. And then the review and edits, testing, clarifications, deployment, integration and urgent questions that arise already in the process begin.
Finally, the assessment is influenced by the pressure of deadlines.
If the customer says in advance that they would like to receive the result in a week, the calculation gradually begins to approach this figure, even if the initial estimate was different.
This is how the assessment imperceptibly turns into a promise. And a promise is a future problem.
What helps in practice
First of all, it's worth stopping looking for one "correct" number.
Instead of saying "the task will take three days," you can name three options: how long it will take in an ideal scenario, how long in a normal situation, and what happens if problems arise.
A simple formula can be used for the calculation:
(optimistic + 4 × realistic + pessimistic) ÷ 6.
For example, imagine that:
- The optimistic estimate is 3 days.;
- realistic — 5 days;
- Pessimistic — 12 days.
We substitute these values into the formula:
(3 + 4 × 5 + 12) ÷ 6 = 35 ÷ 6 ≈ 5,8 of the day.
That is, the final estimate is about 6 business days, rather than the initial 3.
At the same time, the spread between estimates is also important. If the task can take from 3 to 12 days, it means that there is significant uncertainty in it. It is better to discuss where it comes from before starting work.
There is another useful effect. To give a pessimistic assessment, you have to ask yourself: "What exactly can go wrong?"
Then things come up that the team would otherwise have remembered too late: integration without proper documentation, an unfamiliar library, dependence on another team, or an unstable environment.
It's also better to talk to the customer in a range rather than a single number: "It will most likely take six days. But if there are problems with integration, the deadline may increase to twelve."
This answer may sound less confident. But later there will be fewer unpleasant surprises and arguments about who promised what exactly.
Look at your own statistics
Another useful technique is to compare estimates with actual deadlines.
This does not require a sophisticated analytical tool. It is enough to take the last ten completed tasks and see how much the initial estimates differed from the actual work time.
It often turns out that the team makes mistakes quite predictably: for example, it regularly evaluates tasks 20-30% less than the actual deadline. If this is repeated from time to time, the correction can be taken into account in the following estimates.
Evaluate tasks together
The third way is to involve several team members in the assessment.
If several people give their figures independently, the difference between them quickly shows exactly where the understanding of the task differs.
For one participant, it may look like "three days of development," while another will immediately notice the difficult integration or dependence on the neighboring team.
It is much cheaper to detect such discrepancies during planning than a week after the start of the sprint.
And one more important point: it is better not to hide the stock inside the estimate.
If the team says that the task will take five days, and there is already a two-day buffer hidden inside this estimate, there will almost certainly be work that will consume it. The task is usually expanded to the allotted time.
Therefore, it is more honest to lay down a separate reserve for the project as a whole — and inform both the team and the customer about it in advance.
Optimism in assessments is not a character flaw or a reason to look for someone to blame. This is a predictable feature of human thinking.
Therefore, it is better to deal with it not with reproaches, but with a structured process.
A team that analyzes its own statistics, names ranges, and discusses risks in advance is more likely to meet deadlines. Not because it works faster. But because he promises to be more honest.
- Сколько это займет?
- Дня три.
Через неделю задача все еще в работе — и, кажется, никого это особенно не удивляет. Такие диалоги в IT-командах повторяются настолько часто, что к ним уже привыкли. Но дело не обязательно в том, что разработчики слишком оптимистичны. Обычно причины гораздо прозаичнее.
Первая и самая распространённая — мы планируем по лучшему сценарию.
Оценивая задачу, человек часто представляет идеальный ход работы: сел, написал, проверил — готово. В реальности все почти никогда не бывает так гладко. Нужно дождаться ответа коллеги, разобраться со сломавшимся окружением, уточнить внезапно появившееся требование, пройти ревью, а иногда и переделать то, что уже казалось готовым.
Психологи называют это ошибкой планирования: мы склонны недооценивать время на собственные задачи, даже если прошлый опыт уже не раз показывал обратное.
Есть и другая проблема: в оценку часто попадает только то, что хорошо видно в начале. Например, разработка кажется задачей на три дня, потому что в расчет берут только написание кода. А затем начинаются ревью и правки, тестирование, уточнения, деплой, интеграции и срочные вопросы, которые возникают уже в процессе.
Наконец, на оценку влияет давление сроков.
Если заказчик заранее говорит, что хотел бы получить результат через неделю, расчет постепенно начинает приближаться к этой цифре — даже если первоначальная оценка была другой.
Так оценка незаметно превращается в обещание. А обещание — в будущую проблему.
Что помогает на практике
Прежде всего стоит перестать искать одну «правильную» цифру.
Вместо фразы «задача займет три дня» можно назвать три варианта: сколько времени потребуется при идеальном сценарии, сколько — в обычной ситуации и что произойдёт, если возникнут проблемы.
Для расчета можно использовать простую формулу:
(оптимистичный + 4 × реалистичный + пессимистичный) ÷ 6.
Например, представим, что:
- оптимистичная оценка — 3 дня;
- реалистичная — 5 дней;
- пессимистичная — 12 дней.
Подставляем эти значения в формулу:
(3 + 4 × 5 + 12) ÷ 6 = 35 ÷ 6 ≈ 5,8 дня.
То есть итоговая оценка — примерно 6 рабочих дней, а не первоначальные 3.
При этом разброс между оценками тоже важен. Если задача может занять от 3 до 12 дней, значит, в ней есть существенная неопределенность. Лучше обсудить, откуда она берется, еще до начала работы.
Есть и еще один полезный эффект. Чтобы назвать пессимистичную оценку, приходится спросить себя: «Что именно может пойти не так?»
Тогда всплывают вещи, о которых команда иначе вспомнила бы слишком поздно: интеграция без нормальной документации, незнакомая библиотека, зависимость от другой команды или нестабильное окружение.
С заказчиком тоже лучше говорить диапазоном, а не одной цифрой: «Скорее всего, потребуется шесть дней. Но если возникнут проблемы с интеграцией, срок может увеличиться до двенадцати».
Такой ответ, возможно, звучит менее уверенно. Зато впоследствии будет меньше неприятных сюрпризов и споров о том, кто и что именно обещал.
Смотрите на собственную статистику
Еще один полезный прием — сравнивать оценки с фактическими сроками.
Для этого не нужен сложный аналитический инструмент. Достаточно взять десять последних завершенных задач и посмотреть, насколько первоначальные оценки отличались от реального времени работы.
Часто выясняется, что команда ошибается довольно предсказуемо: например, регулярно оценивает задачи на 20–30% меньше фактического срока. Если это повторяется из раза в раз, поправку можно учитывать при следующих оценках.
Оценивайте задачи вместе
Третий способ — подключать к оценке нескольких участников команды.
Если несколько человек независимо называют свои цифры, разница между ними быстро показывает, где именно расходится понимание задачи.
Для одного участника она может выглядеть как «три дня разработки», а другой сразу заметит сложную интеграцию или зависимость от соседней команды.
Гораздо дешевле обнаружить такие расхождения на планировании, чем через неделю после начала спринта.
И еще один важный момент: запас лучше не прятать внутри оценки.
Если команда говорит, что задача займет пять дней, а внутри этой оценки уже спрятан двухдневный буфер, почти наверняка найдется работа, которая его поглотит. Задача обычно расширяется до отведенного ей времени.
Поэтому честнее закладывать отдельный резерв на проект в целом — и заранее сообщать о нем и команде, и заказчику.
Оптимизм в оценках — не недостаток характера и не повод искать виноватого. Это предсказуемая особенность человеческого мышления.
Поэтому бороться с ним лучше не упреками, а выстроенным процессом.
Команда, которая анализирует собственную статистику, называет диапазоны и заранее обсуждает риски, чаще укладывается в сроки. Не потому, что работает быстрее. А потому, что обещает честнее.
Share
