Как оценивать задачи и сроки так, чтобы потом не было мучительно больно
Знакомый сценарий? Команда бодро оценила проект в 3 месяца. Через полгода и три срыва дедлайна все - и заказчик, и разработчики, и вы, как менеджер - чувствуете себя измотанными и обманутыми. Виноваты «непредвиденные обстоятельства», «изменившиеся требования» или просто «программисты всегда оптимисты».
Правда в том, что оценка задач - это не гадание на кофейной гуще, а навык, который можно и нужно развивать. Плохая оценка ломает доверие, репутацию и психическое здоровье команды. Хорошая - создает предсказуемость, а это самая твердая валюта в управлении.
Давайте разберемся, как оценивать так, чтобы смотреть в глаза заказчику без стыда, а команде - без укора.
Правда в том, что оценка задач - это не гадание на кофейной гуще, а навык, который можно и нужно развивать. Плохая оценка ломает доверие, репутацию и психическое здоровье команды. Хорошая - создает предсказуемость, а это самая твердая валюта в управлении.
Давайте разберемся, как оценивать так, чтобы смотреть в глаза заказчику без стыда, а команде - без укора.
Почему мы так часто ошибаемся: 3 главные ловушки
Прежде чем учиться оценивать, поймем, где мы спотыкаемся.
- Ловушка оптимизма (или «Эффект студента»). Мы оцениваем идеальный сценарий: «Ну, если сесть и просто писать код, то за 2 дня...». Но мы забываем про встречи, ревью кода, написание тестов, правки после тестирования, внезапные совещания и тот факт, что коллега, у которого нужно что-то уточнить, в отпуске.
- Проклятие знаний. Эксперт, который уже знает систему вдоль и поперек, подсознательно занижает оценку. Он забывает, сколько времени сам потратил на изучение этой темы когда-то. Задача, тривиальная для старожила, для новичка в команде может занять втрое больше.
- Оценка «с потолка» и давление. «Мне нужна хотя бы примерная цифра!» - звучит как начало конца. Такие оценки, данные под давлением, становятся железобетонными обещаниями. Или оценку дают не те, кто будет делать работу.
Практическая методология: Как оценивать правильно
Забудьте про одну магическую цифру. Оценка - это процесс.
1
Разделяй и властвуй (Декомпозиция)
Нельзя оценить «Сделать личный кабинет». Это черная дыра неизвестности.
Что делать: Разбейте эпик на самые мелкие задачи, которые можно взять в работу. Чем меньше и конкретнее задача, тем точнее оценка.
Пример:
Эпик: «Личный кабинет пользователя» ❌
Задачи: «Сверстать страницу профиля по макету», «Реализовать API для изменения email», «Интегрировать блок с историей заказов», «Написать модульные тесты для сервиса профиля» ✅
Правило: Если задача оценивается больше, чем на 2-3 «идеальных» рабочих дня (16-24 часа), ее нужно дробить дальше.
Что делать: Разбейте эпик на самые мелкие задачи, которые можно взять в работу. Чем меньше и конкретнее задача, тем точнее оценка.
Пример:
Эпик: «Личный кабинет пользователя» ❌
Задачи: «Сверстать страницу профиля по макету», «Реализовать API для изменения email», «Интегрировать блок с историей заказов», «Написать модульные тесты для сервиса профиля» ✅
Правило: Если задача оценивается больше, чем на 2-3 «идеальных» рабочих дня (16-24 часа), ее нужно дробить дальше.
2
Используйте относительные единицы, а не часы (Story Points)
Оценка в человеко-часах - опасная иллюзия точности. Вместо этого используйте Story Points (сторипоинты) - это баллы сложности, объема и неопределенности задачи.
Как работает: Выбираете эталонную задачу средней сложности (например, «Добавить поле в форму и сохранить в БД») и даете ей условное значение 3. Все остальные задачи оцениваете относительно нее.
Плюсы:
Как работает: Выбираете эталонную задачу средней сложности (например, «Добавить поле в форму и сохранить в БД») и даете ей условное значение 3. Все остальные задачи оцениваете относительно нее.
- Задача в 2 раза проще = 1
- Задача чуть сложнее = 5
- Задача в 2 раза сложнее и непонятнее = 8
- Необъятная задача = 13 (и это сигнал, что ее нужно дробить!)
Плюсы:
- Уходит ложная точность («17,5 часов»).
- Учитывается не только время, но и сложность/риск.
- Оценка становится командной, а не индивидуальной.
3
Проводите покер планирования (Planning Poker)
Не позволяйте самому громкому или опытному диктовать свою оценку.
Как проходит: Вся команда разработки (те, кто будет делать) собирается. Обсуждается задача. Каждый тайно выбирает карту со своим значением story points (1, 3, 5, 8...). Затем все одновременно открывают карты.
Если разброс большой (один сказал 3, другой — 13), это победа! Те, кто дал высокую и низкую оценку, аргументируют свою позицию. Часто выясняются скрытые риски или, наоборот, упрощения. Обсуждение повторяется, пока оценки не сойдутся.
Результат: Вы получаете не просто цифру, а общее понимание задачи командой.
Как проходит: Вся команда разработки (те, кто будет делать) собирается. Обсуждается задача. Каждый тайно выбирает карту со своим значением story points (1, 3, 5, 8...). Затем все одновременно открывают карты.
Если разброс большой (один сказал 3, другой — 13), это победа! Те, кто дал высокую и низкую оценку, аргументируют свою позицию. Часто выясняются скрытые риски или, наоборот, упрощения. Обсуждение повторяется, пока оценки не сойдутся.
Результат: Вы получаете не просто цифру, а общее понимание задачи командой.
4
Учитывайте полный цикл работы (Definition of Done)
Ошибка - оценивать только время на написание кода. Что значит «готово»?
Готово (Done) = Код написан + Протестирован (QA) + Отрецензирован (Code Review) + Прошел сборку (CI) + Задеплоен + Документирован.
Оценка должна включать все эти этапы. Обычно на непрограммистские активности закладывается 30-50% от времени «чистого кода».
Готово (Done) = Код написан + Протестирован (QA) + Отрецензирован (Code Review) + Прошел сборку (CI) + Задеплоен + Документирован.
Оценка должна включать все эти этапы. Обычно на непрограммистские активности закладывается 30-50% от времени «чистого кода».
5
Добавляйте буфер и управляйте ожиданиями
Даже самую точную оценку нужно защитить от реальности.
Правило Хофштадтера: «Любая задача всегда требует больше времени, чем ожидается, даже если учитывать правило Хофштадтера». Это шутка, но в ней правда.
Что делать: На уровне проекта (эпика, версии) к общей оценке команды добавляйте буфер 20-30% на совершенно непредсказуемые вещи: болезни, срочные баги, проблемы с инфраструктурой.
Как говорить с бизнесом: «Наша команда оценила объем работы в 40 story points. Наша текущая скорость (velocity) — 20 points за спринт. Значит, на выполнение нужно 2 спринта. С учетом рисков, которые мы пока не видим, закладываем на весь блок 2.5 спринта. Мы будем стараться уложиться в 2, но так мы защищаем срок релиза от срыва».
Правило Хофштадтера: «Любая задача всегда требует больше времени, чем ожидается, даже если учитывать правило Хофштадтера». Это шутка, но в ней правда.
Что делать: На уровне проекта (эпика, версии) к общей оценке команды добавляйте буфер 20-30% на совершенно непредсказуемые вещи: болезни, срочные баги, проблемы с инфраструктурой.
Как говорить с бизнесом: «Наша команда оценила объем работы в 40 story points. Наша текущая скорость (velocity) — 20 points за спринт. Значит, на выполнение нужно 2 спринта. С учетом рисков, которые мы пока не видим, закладываем на весь блок 2.5 спринта. Мы будем стараться уложиться в 2, но так мы защищаем срок релиза от срыва».
Главный секрет: Измеряйте скорость команды (Velocity)
Story points обретают смысл, когда вы знаете скорость команды (Velocity) — сколько points команда стабильно делает за спринт.
- После 2-3 спринтов вы увидите тренд: например, команда стабильно делает 25-30 points.
- Это волшебная метрика! Теперь, оценив новый эпик в 100 points, вы можете предсказать срок: 100 / 25 = 4 спринта.
- Это не магия, а данные. И это самый сильный аргумент в диалоге с бизнесом.
Чего делать НЕЛЬЗЯ: Токсичные практики
- Оценивать за команду. Оценку дает тот, кто будет делать.
- Превращать оценку в обязательство. Оценка - это прогноз, основанный на текущих знаниях. Если требования изменились - оценка должна пересматриваться.
- Наказывать за просрочку. Если команда систематически не укладывается в свои же оценки - это не их вина, а системная проблема (неверный процесс оценки, постоянные срочные задачи, мешающие работе). Нужно разбираться с процессом, а не с людьми.
Идеальной оценки не существует. Но существует предсказуемость.
Ваша цель - не угадать срок с точностью до часа, а создать надежный процесс, который:
Ваша цель - не угадать срок с точностью до часа, а создать надежный процесс, который:
- Основан на данных (velocity), а не на интуиции.
- Включает в себя всю команду.
- Учитывает полный цикл и риски.
- Позволяет уверенно говорить с бизнесом на языке вероятностей: «С вероятностью 85% мы сможем выпустить это в течение 3 спринтов».
“
А по каким методикам оцениваете задачи вы? Сталкивались ли с ситуацией, когда удачная оценка спасла проект? Делитесь опытом в комментариях!
© Все права защищены