Всем привет! Меня зовут Анастасия, я Lead Delivery Manager в Lenta tech (ИТ-бренд «Группы Лента»). Знакома ли вам ситуация: у вас есть задача, команда её оценила, все необходимые данные собраны. Вы складываете оценки и получаете вполне разумную цифру. Но в реальности эта работа никак не помещается в ваш дедлайн.
Или бывает ещё интереснее: команда начинает работу и обнаруживает большой объём задач, который невозможно было увидеть на старте. А в конце отчётного периода вы понимаете, что успели сделать меньше половины запланированного.
И возникает логичный вопрос: почему так? Мы же всё заранее посчитали. Проблема в том, что оценка трудоёмкости задачи и планирование — это не одно и то же.
В этой статье я разберу пошаговый подход, который помогает превратить оценки отдельных задач в реалистичный план и обещать бизнесу сроки, которые команда действительно может выдержать.
Оглавление
Оценка отвечает на один вопрос, а планирование — на несколько
Оценка трудоёмкости отвечает на один вопрос: Сколько усилий потребуется, чтобы выполнить эту задачу?
Но планирование должно ответить на гораздо большее количество вопросов:
сколько реально доступного времени есть у команды;
какие задачи зависят друг от друга;
есть ли зависимости от других команд;
сколько времени займут тестирование, code review и исправление багов;
есть ли технический долг;
какие риски могут повлиять на сроки;
какие задачи действительно критичны для релиза;
где нужны буферы.
Например, задача оценена в 8 часов. Это не значит, что разработчик закончит её за рабочий день: часть времени уйдёт на встречи, code review, помощь коллегам, баги и переключение контекста.
То же самое работает на уровне команды. 100 часов задач при capacity в 120 часов ещё не означают, что всё поместится в план: часть ресурса уже занята обязательными активностями, а на календарный срок влияют ещё и зависимости между задачами.
Поэтому нам нужен не набор оценок, а план, учитывающий реальные ограничения команды. Разберём по шагам.
Шаг 1. Честно рассчитать capacity команды
Ключ к адекватному планированию — понять, сколько времени команда действительно может потратить на работу над задачами.
В предыдущей статье я рассказывала, как мы пересобирали роль Delivery менеджера в условиях ограниченных ресурсов и почему стали внимательнее смотреть на метрики и реальную загрузку команд. Здесь остановлюсь подробнее на том, как учитывать эту загрузку при планировании сроков.
И здесь важно отказаться от цифр, которые мы используем просто потому, что «так исторически сложилось».
Например:
15% на встречи;
10% на поддержку;
ещё какой-то процент «на всякий случай».
Если эти цифры появились несколько лет назад и с тех пор просто кочуют из одного плана в другой, самое время проверить, насколько они соответствуют реальности.
Посмотрите на фактические данные
Если в компании ведётся time tracking, стоит посмотреть исторические данные. Например, мы привыкли считать, что встречи занимают 10% времени. Но календарь с дейли, планированиями, ретро, review и синками с другими командами может показать совсем другую цифру.
То же касается code review, поддержки, дежурств и исправления багов. В capacity нужно закладывать фактическое потребление времени, а не проценты, которые однажды появились в шаблоне и с тех пор переходят из плана в план.
И считать стоит не идеальные восемь рабочих часов, а реальную продуктивную capacity команды.
Шаг 2. Декомпозировать большие задачи
Теперь переходим непосредственно к оценке задач.
Когда команда начинает прорабатывать большую фичу, далеко не всегда возможно сразу точно оценить её целиком.
Поэтому полезно заранее определить порог декомпозиции.
Например, можно договориться: всё, что оценивается больше чем в три рабочих дня, декомпозируем.
Допустим, на груминге задача получила оценку 10 дней. Разбиваем её на этапы:
этап A — 2 дня;
этап B — 5 дней;
этап C — 5 дней.
Этапы B и C снова декомпозируем, потому что они превышают установленный порог. И не удивляйтесь, если итоговая сумма перестанет совпадать с первоначальными 10 днями: именно так часто обнаруживается работа, которая была скрыта внутри большой задачи.
В результате вместо одной большой оценки мы получаем набор небольших задач, которые гораздо проще планировать.
Шаг 3. Учесть зависимости
В реальном продукте редко бывает так, что команда может полностью автономно реализовать большую фичу.
Особенно если продукт уже давно существует.
Появляются зависимости от:
соседних команд;
backend-сервисов;
интеграций;
аналитики;
инфраструктуры;
внешних систем.
На этапе декомпозиции важно не просто обнаружить эти зависимости, но и зафиксировать их в плане.
Например:
интеграционная команда должна расширить набор передаваемых данных;
после этого наша команда может реализовать обработку этих данных;
затем ещё одна команда должна изменить свой сервис, который использует полученные данные.
Получается цепочка:
A → B → C
Если A задерживается на три дня, B не сможет начаться вовремя, а значит, сдвинется и C.
Поэтому зависимости нужно обсуждать заранее. Если требуется работа другой команды, стоит согласовать scope, получить оценку, определить владельца и зафиксировать связь в трекере или на дорожной карте.
И главное — не хранить зависимости только в голове. План должен позволять быстро ответить на вопрос: что должно произойти раньше, чтобы следующая задача вообще могла начаться?
Шаг 4. Не забыть про Tech Debt
Технический долг часто откладывают на потом: «Разберёмся, когда будет свободное время». Но иногда перед новой фичей сначала приходится привести в порядок участок системы, с которым предстоит работать.
Поэтому на этапе планирования я задаю Team Lead и разработчикам вопрос: сколько времени нам понадобится дополнительно, чтобы привести этот участок кода в состояние, в котором с ним можно нормально работать?
Если такая работа действительно нужна, её стоит оформить отдельной задачей и включить в план. Так вместо «чистой» разработки фичи мы увидим реальный объём работ, который потребуется команде.
Шаг 5. Заложить время на тестирование
Одна из распространённых ошибок — тестирование по остаточному принципу: «Сначала разработаем, а сколько останется до дедлайна — столько и будет на тестирование».
В итоге разработка заканчивается почти перед дедлайном, QA получает несколько часов на полноценные проверки, команда работает в цейтноте, а качество продукта страдает.
Поэтому тестирование я предпочитаю выделять в плане отдельным этапом. Например, если разработка фичи занимает 10 рабочих дней, можно предварительно заложить ещё около 3 дней на тестирование.
Это не универсальная формула: срок зависит от продукта, команды и типа изменений. Важнее сам принцип — тестирование должно быть частью плана с самого начала, а не остатком времени перед дедлайном.
E2E и интеграционное тестирование
Отдельно стоит учитывать end-to-end testing, когда фича проходит через несколько команд и сервисов.
Здесь вероятность дополнительных проблем выше:
разные команды могут по-разному интерпретировать требования;
интерфейсы между сервисами могут не совпасть;
изменения могут работать отдельно, но ломаться при интеграции;
часть проблем обнаруживается только после объединения всех компонентов.
Поэтому после того, как все команды закончили свои изменения, стоит отдельно заложить время на общую интеграционную проверку.
Шаг 6. Найти критический путь и определить scope
Теперь, когда мы добавили в план зависимости, технический долг и тестирование, он, скорее всего, стал больше. И здесь полезно сделать шаг назад.
Посмотреть на план целиком и задать себе несколько вопросов: что действительно нужно для релиза? Что находится на критическом пути? Что можно перенести, делегировать или переиспользовать?
В результате у нас должно появиться как минимум два уровня:
Это не означает, что второстепенные задачи нужно выкинуть. Они просто становятся управляемым scope, который можно сдвинуть при необходимости.
И это очень полезно в момент, когда сроки начинают сокращаться. Вместо того чтобы приходить к команде с вопросом: «Как нам сделать всё быстрее?»
Мы можем спросить: «Что из запланированного мы готовы перенести?»
Это гораздо более здоровый способ управления сроками.
Шаг 7. Проанализировать риски
Риск-анализ — стандартная часть project management, но при планировании отдельных фич его часто упускают.
Кажется: «Это же небольшая задача. Какие тут могут быть риски?»
Но даже небольшая фича может зависеть от внешних систем, других команд, новых технологий или недостаточно проработанных требований.
Поэтому стоит хотя бы быстро пройтись по основным рискам:
что может задержать разработку;
где есть внешняя зависимость;
какие требования недостаточно проработаны;
где используется незнакомая технология;
какие задачи могут оказаться сложнее первоначальной оценки.
Для первоначального брейншторма рисков можно использовать AI, но получившийся список всё равно нужно валидировать вместе с командой. Если работа с конкретным риском требует отдельной задачи, её лучше сразу добавить в план.
Сделать план прозрачным
После всех предыдущих шагов у нас наконец появляется не просто сумма оценок, а план, основанный на реальной capacity, зависимостях, scope и рисках. И теперь этим планом нужно поделиться с бизнесом и другими заинтересованными сторонами.
Здесь вполне можно получить неприятную обратную связь: «А почему так долго?» И это нормально.
Задача Delivery Manager или Project Manager — не сделать срок красивым, а сделать его реалистичным и управляемым. Лучше сразу назвать честные 20 рабочих дней, чем пообещать 12, а через две недели сообщить, что срок вырос до 25.
Поэтому если для качественной реализации фичи требуется существенное время, об этом лучше говорить сразу.
Почему сумма оценок создаёт ложное ощущение контроля
Давайте разберем на примере.
Небольшая задача, которая не поместилась в квартал
На первый взгляд задача казалась достаточно простой: сократить расходы на печать бумажных чеков. Клиенту предлагалось оставить e-mail и согласиться получать электронные чеки вместо бумажных.
Для реализации требовалось участие трёх команд:
команда рассылок должна была настроить отправку чеков;
моя команда — реализовать пользовательский сценарий и окно для ввода email;
команда поддержки — получить возможность видеть, дал ли клиент согласие на получение электронных чеков, чтобы разрешать спорные ситуации.
Мы подготовили макеты, провели груминги со всеми командами и получили предварительные оценки. Каждая часть занимала от двух до пяти рабочих дней. В сумме получилось около 10 рабочих дней разработки.
Казалось бы, небольшая задача, которую вполне реально сделать за квартал. Тем более в начале квартала у всех трёх команд была необходимая capacity.
Но у задачи была последовательная зависимость: сначала доработки должна была выполнить команда рассылок, затем — моя команда, а после этого подключалась команда поддержки.
В течение квартала у команды рассылок появились новые, более приоритетные задачи. Наша доработка опустилась в бэклоге и к моменту, когда она дошла до разработки, значительная часть квартала уже прошла.
Когда зависимость наконец была закрыта, ситуация изменилась уже у моей команды. В начале квартала у нас было достаточно свободной capacity, но теперь команда была занята другими, более приоритетными задачами. Наша доработка снова сдвинулась в бэклоге.
В итоге задача с суммарной оценкой около 10 рабочих дней не была завершена за целый квартал.
При этом проблема была не в неправильной оценке. Сами оценки были вполне реалистичными. Просто оценка отвечает на вопрос, сколько времени потребуется на выполнение работы, а не на вопрос, когда работа будет завершена.
На итоговый срок повлияли зависимости между командами, изменение приоритетов и доступная capacity в конкретный момент времени.
Если бы мы просто сложили оценки и пообещали бизнесу срок в две недели, этот прогноз оказался бы невыполнимым.
Но понимание зависимостей, очередности работ и приоритетов в каждой из команд позволило построить более реалистичный прогноз и не создавать ложных ожиданий.
Поэтому оценка отдельных задач сама по себе не создаёт план. Это только часть входных данных для планирования.
Мини чек-лист перед тем, как сказать бизнесу «успеем»
Перед тем как обещать бизнесу срок, я бы проверила:
Все ли задачи действительно готовы к разработке?
Достаточно ли детально декомпозирован scope?
Какая реальная capacity команды?
Учтены ли встречи, поддержка, code review и другие обязательные активности?
Есть ли зависимости от других команд?
Все ли зависимости зафиксированы в плане?
Есть ли tech debt, который нельзя игнорировать?
Учтено ли тестирование?
Нужен ли E2E/integration testing?
Какие задачи находятся на critical path?
Что можно вынести из critical scope?
Какие риски могут повлиять на сроки?
Есть ли в плане разумный буфер?
Если на эти вопросы есть ответы, вероятность неприятных сюрпризов существенно снижается.
А что делать, если план уже начинает «ехать»?
Даже если вы всё сделали правильно, планы иногда будут сдвигаться. Это нормальная часть работы любого Project Manager или Delivery Manager.
Главное — не пытаться решать проблему исключительно за счёт команды.
То есть первая реакция не должна быть: «Давайте быстрее. Мы не успеваем. Может, поработаем в выходные?»
Сначала стоит остановиться и посмотреть на план.
1. Пересмотреть scope
Мы заранее определили critical и secondary scope. Значит, сейчас самое время посмотреть, что можно вынести за рамки текущего релиза.
2. Пересмотреть capacity
Можно ли временно отказаться от каких-то необязательных активностей? Например, перенести ретроспективу или отложить обсуждение новых фич до завершения текущей работы.
Важно: это не должно превращаться в систематическую практику. Мы не «выжимаем» из команды больше производительности, а временно перераспределяем доступное время.
3. Актуализировать план
Теперь у нас уже есть новые данные. Мы лучше понимаем задачи, обнаружили скрытый scope, получили дополнительную информацию о зависимостях. Значит, план нужно пересчитать. План — ничто, планирование — всё.
Хороший план не тот, который никогда не меняется. Хороший план — тот, который актуализируется по мере появления новой информации.
4. Разобрать причины
И наконец, нужно понять, почему план начал сдвигаться.
Что мы не предусмотрели?
Какая оценка оказалась неточной?
Какая зависимость появилась слишком поздно?
Какой риск реализовался?
Что мы можем изменить в следующем цикле планирования?
Так мы превращаем срыв срока не просто в проблему, а в данные для улучшения процесса планирования.
Что в итоге
Оценка нужна, чтобы понять размер работы. Планирование — чтобы понять, как эта работа реально попадёт в календарь команды.
Если команда регулярно не укладывается в сроки, не стоит автоматически делать вывод, что разработчики плохо оценивают задачи или ленятся.
Сначала я бы посмотрела на всю систему: capacity → декомпозиция → зависимости → tech debt → тестирование → critical path → риски → buffers → актуализация плана.
Хорошее планирование не гарантирует, что сроки никогда не сдвинутся. Оно помогает понять, почему план начал «ехать», где есть пространство для манёвра и что можно изменить, чтобы минимизировать влияние на бизнес.
Тогда команда продолжает работать в устойчивом ритме, а Delivery Manager управляет не постоянными «пожарами», а изменениями scope, capacity и сроков.
В итоге команда продолжает работать в устойчивом и продуктивном ритме, а Delivery Manager управляет не постоянным «пожаром», а изменениями scope, capacity и сроков.
Друзья, поделитесь, какое в вашем опыте было самое большое ожидание / реальность в управлении? И как решали последствия суровой реальности?:)