Оценка задачи — это всегда диапазон, а не точка: «от трёх до пяти дней», а не «3,5 дня». Точная цифра на старте — иллюзия, и конус неопределённости это объясняет: в начале проекта оценка врёт в разы и сужается только по мере прояснения деталей. Поэтому команды часто оценивают не в часах, а в story points — относительных единицах сложности: проще сказать «эта задача вдвое больше той», чем угадать абсолютное время. Инструменты оценки: Planning Poker (все вскрывают карты одновременно, чтобы не якориться на старшем) и T-shirt sizing (S/M/L для грубой прикидки). Роль аналитика в оценке — не назвать срок, а дать команде контекст и декомпозицию, без которых «сколько займёт» — это просьба угадать.
Однажды на статусе меня спросили в лоб: «сколько займёт интеграция с платёжкой?». Я, чтобы не выглядеть тормозом, ляпнул: «дня три». Через три дня оказалось, что у платёжки три способа оплаты, две среды, вебхуки, которые надо обрабатывать, и возвраты, про которые никто не подумал. Заняло три недели. Я не ошибся в оценке — я дал точную цифру там, где честным ответом был широкий диапазон и десяток вопросов. С тех пор я понял: называть точку вместо диапазона — не точность, а самообман, за который потом платит вся команда.
Оценка — болезненная тема, потому что её путают с обещанием. Оценка — это прогноз при текущем знании, а знания на старте мало. И первое, что должен делать аналитик, — не угадывать срок, а превращать туман в вопросы. Зачем вообще считать сроки и почему это всегда про деньги, я разбираю в записи про бизнес-контекст.
Почему оценка — это диапазон
Точечная оценка («3,5 дня») создаёт ложное чувство уверенности. На старте задачи вы не знаете половины деталей — и не можете знать. Честная оптимистичный сценарий и пессимистичный сценарий расходятся в разы. Диапазон «3–8 дней» — не признак того, что вы плохо оценили; это признак того, что вы оценили честно и видите риск. Точка скрывает риск, диапазон его показывает.
Когда у вас просят одну цифру «для плана» — давайте её как верхнюю границу диапазона или говорите «с вероятностью 80% уложимся в N». Это спасает от ситуации, когда оптимистичную оценку записали в дедлайн, а потом удивляются.
Конус неопределённости
Это главная картинка про оценку. В начале проекта (на этапе идеи) оценка может врать в 4 раза в обе стороны: то, что вы назвали «месяцем», реально займёт от недели до четырёх месяцев. По мере того как требования проясняются, дизайн готов, архитектура выбрана — конус сужается, и к концу оценка совпадает с фактом (потому что факт уже почти случился).
flowchart LR A["Идея
±4x"] --> B["Требования
±2x"] --> C["Дизайн
±1.5x"] --> D["Реализация
±1.25x"] --> E["Готово
факт"]
Схема показывает, как точность оценки растёт по ходу проекта. На этапе идеи разброс огромный — плюс-минус в разы; после выявления требований сужается примерно вдвое; после проектирования ещё уже; к реализации почти совпадает с фактом. Вывод практический: оценку, данную на старте, нельзя записывать в дедлайн как обещание — её надо переоценивать по мере прояснения. И второй вывод — лучший способ сузить конус быстрее это убрать неизвестность, то есть выявить требования и декомпозировать.
Story points против часов
Почему команды оценивают в абстрактных «попугаях», а не в честных часах? Потому что человек плохо угадывает абсолютное время, но хорошо сравнивает. «Сколько часов займёт эта задача» — сложно. «Эта задача примерно вдвое больше вон той, которую мы делали» — легко и точнее.
| Story points | Примерный смысл |
|---|---|
| 1 | Тривиально: поправить текст, добавить поле. Всё понятно. |
| 2–3 | Небольшая задача, всё ясно, без сюрпризов. |
| 5 | Средняя: есть нюансы, но команда делала похожее. |
| 8 | Крупная: много неизвестного, стоит насторожиться. |
| 13+ | Слишком большая — не оценивать, а декомпозировать. |
Числа обычно идут по Фибоначчи (1, 2, 3, 5, 8, 13) — нарочно, чтобы не спорить «6 или 7»: чем больше задача, тем грубее шкала, потому что точность всё равно теряется. Points не переводятся в часы напрямую — у разных команд свой «курс», и это нормально. Их смысл — относительная сложность, а скорость команды (velocity, сколько points закрывают за спринт) выводится из практики, а не назначается.
13+ — это не оценка, а сигнал
Если задача тянет на 13 и больше story points — её нельзя нормально оценить, внутри слишком много неизвестного. Это не повод геройски назвать число, а повод вернуть задачу в декомпозицию: разрезать на куски, каждый из которых команда понимает. Большая оценка — симптом, что задача не разобрана, а не что она «просто большая». Как резать — в записи про декомпозицию.
Planning Poker и T-shirt sizing
Planning Poker — командная оценка, где каждый одновременно вскрывает карту с числом story points. Одновременность — главное: если сначала высказывается сеньор, остальные якорятся на его цифре и не думают сами. Когда оценки сильно разошлись (один сказал 2, другой 8) — это не повод усреднять, а повод обсудить: значит, люди видят задачу по-разному, и в разговоре всплывает то, что один знал, а другой нет. Расхождение оценок ценнее самой оценки — оно вскрывает непонимание.
T-shirt sizing (S, M, L, XL) — ещё более грубая прикидка для раннего этапа, когда числа давать рано. Полезно, чтобы быстро рассортировать большой бэклог: что мелочь, что крупное. Точность низкая, зато быстро и без ложной уверенности.
Пример: оценка фичи в story points
Фича: «добавить вход через Госуслуги». Команда собралась на Planning Poker. Аналитик заранее декомпозировал и принёс контекст — без него оценивать нечего.
Фича: вход через Госуслуги (ЕСИА)
Декомпозиция и оценка:
Кнопка "Войти через Госуслуги" + редирект — 2 SP (всё ясно)
Обработка callback, обмен кода на токен — 5 SP (делали похожее с OAuth)
Маппинг данных ЕСИА на наш профиль — 5 SP (есть неизвестность по полям)
Связывание с существующим аккаунтом по email — 8 SP (много веток: email занят, не совпал)
Обработка ошибок и отказа пользователя — 3 SP
Итого: 23 SP. При velocity ~20 SP/спринт — около 1.5 спринтов.
Диапазон с учётом конуса: 1–2 спринта.Обратите внимание на три вещи. Первое — кусок «связывание по email» получил 8 SP, потому что в нём много веток; это сигнал присмотреться, не разрезать ли его ещё. Второе — итог дан не точкой, а диапазоном «1–2 спринта», потому что часть неизвестности ещё не снята. Третье — аналитик не называл цифры сам: он принёс декомпозицию и контекст («с OAuth уже делали», «по полям ЕСИА есть вопрос»), а оценивала команда. Это и есть правильное разделение: оценивает тот, кто будет делать, а аналитик даёт почву для оценки.
«Сколько займёт?» без контекста — просьба угадать
Когда у вас просят оценку «навскидку, прямо сейчас», без декомпозиции и деталей — вас просят не оценить, а угадать. Честный ответ: «грубо — порядок такой-то, точнее скажу, когда проясним вот эти три вопроса». Это не уклонение, а профессионализм. Цифра, выданная без контекста, всё равно неверна — только теперь её запишут в план как обещание.
Откуда это взялось
Конус неопределённости описал Барри Боэм (Barry Boehm) в 1981 году в книге «Software Engineering Economics», а популяризировал Стив Макконнелл — он же дал ему нынешнее имя. Story points и Planning Poker пришли из гибких методологий: относительная оценка выросла в Extreme Programming в конце 1990-х, а Planning Poker как формат с картами предложил Джеймс Греннинг в 2002 году и популяризировал Майк Кон. Общая идея у всех одна и старая как индустрия: люди катастрофически плохо угадывают абсолютные сроки разработки, поэтому надёжнее сравнивать задачи между собой и честно показывать диапазон, чем делать вид, что знаешь точную цифру.
Как это спрашивают на собесе
«Почему оценивают в story points, а не в часах?» — ждут: человек плохо угадывает абсолютное время, но хорошо сравнивает относительную сложность; points не переводятся в часы напрямую.
«Что такое конус неопределённости?» — проверяют понимание, что на старте оценка врёт в разы и сужается по мере прояснения, поэтому стартовую оценку нельзя записывать в дедлайн.
«Тимлид просит оценить фичу навскидку, деталей нет. Ваши действия?» — ждут не случайную цифру, а «дам порядок диапазоном + назову вопросы, которые надо снять, чтобы уточнить».
Частые вопросы
Чем story points лучше оценки в часах?
Story points — относительная мера сложности, а не абсолютное время. Люди плохо угадывают «сколько часов это займёт», но хорошо сравнивают: «эта задача примерно вдвое больше той, что мы делали». Поэтому относительная оценка стабильнее и меньше провоцирует ложную точность. Points не переводятся в часы напрямую — у каждой команды свой «курс» (velocity), который выводится из практики. Ещё плюс: points не путают с обещанием времени, как путают часы.
Что такое конус неопределённости?
Это модель, показывающая, что точность оценки растёт по мере продвижения проекта. На этапе идеи оценка может врать в 4 раза в обе стороны, после выявления требований разброс сужается примерно вдвое, после проектирования — ещё, а к реализации почти совпадает с фактом. Практический вывод: стартовую оценку нельзя записывать в дедлайн как обещание — её надо переоценивать, когда снимается неизвестность. А быстрее всего конус сужает выявление требований и декомпозиция.
Должен ли аналитик оценивать задачи?
Аналитик не называет срок сам — оценивает тот, кто будет делать задачу руками (разработчики), потому что только они знают реальную трудоёмкость в своём стеке. Роль аналитика — дать команде то, без чего оценка невозможна: декомпозицию (разбить фичу на понятные куски) и контекст (что уже делали похожее, где есть неизвестность, какие ветки и ошибки учесть). Без этого «сколько займёт» превращается в просьбу угадать. Хорошая декомпозиция и контекст сужают конус неопределённости ещё до того, как команда возьмёт карты Planning Poker.