Как избежать разрастания объёма работ в IT-проекте
Практика3 минРедакция Innovialabs
Коротко
Объём работ разрастается, когда новые идеи попадают в проект без оценки. Зафиксируйте исходный объём, пропускайте каждое изменение через запрос с оценкой и решайте, что вы готовы отложить ради нового.
Что такое разрастание объёма и почему оно опасно
Scope creep — это ситуация, когда в проект постепенно добавляются функции и правки, которых не было в согласованном плане, а сроки и бюджет остаются прежними. Каждая отдельная просьба кажется мелкой: «добавим ещё один фильтр», «а пусть уведомления приходят и в Telegram». Вместе они съедают недели.
Опасность не в самих изменениях — продукт и должен уточняться по ходу работы. Опасность в том, что изменения принимаются без оценки и без решения, чем за них заплатить: деньгами, временем или отказом от другой функции.
Почему это происходит
- Размытое техническое задание. Если в документе написано «удобный личный кабинет», каждый понимает «удобный» по-своему.
- Нет зафиксированной базы. Не с чем сравнить новую просьбу, поэтому непонятно, новая это задача или часть старой.
- Много голосов. Директор, маркетинг и отдел продаж передают пожелания напрямую разработчикам.
- Подрядчик боится сказать «это сверх плана». Он соглашается, а потом срывает сроки.
- Идеи появляются, когда люди видят продукт. Это нормально, но для таких идей нужен процесс.
Как держать объём под контролем
1. Зафиксируйте базовый объём
Перед стартом разработки согласуйте baseline: список функций, критерии приёмки и то, что в проект явно не входит. Раздел «вне рамок» часто важнее основного списка — он снимает споры заранее.
2. Введите запрос на изменение
Любая новая просьба оформляется как change request — короткая запись:
- что нужно изменить и зачем;
- кто инициатор;
- оценка подрядчика: часы, влияние на срок, риски;
- решение: принять, отложить или отклонить.
Это не бюрократия, а способ увидеть цену решения до того, как работа начата.
3. Назначьте одного владельца продукта
Со стороны заказчика должен быть один человек, который принимает решения по объёму. Остальные передают пожелания через него. Так подрядчик не получает противоречивых задач.
4. Приоритизируйте, а не только добавляйте
Когда появляется важная новая функция, задайте вопрос: что мы убираем или переносим взамен? Помогает простая схема MoSCoW:
| Категория | Смысл |
|---|---|
| Must have | Без этого запуск невозможен |
| Should have | Важно, но можно выпустить чуть позже |
| Could have | Приятно, если хватит ресурсов |
| Won't have (now) | Осознанно откладываем |
5. Держите бэклог для следующих версий
Хорошие идеи не нужно отвергать — их нужно записать в бэклог следующей итерации. Люди спокойнее соглашаются отложить идею, когда видят, что она не потерялась.
6. Регулярно сверяйте план и факт
Короткий еженедельный созвон с демонстрацией результата помогает рано заметить, что работа ушла в сторону. Чем раньше видно отклонение, тем дешевле его исправить.
Частые ошибки
- Правки «на словах» в мессенджере без записи и оценки.
- Фиксированная цена без детального объёма — споры неизбежны, потому что стороны по-разному понимают, что входит в цену.
- Полный отказ от изменений. Жёсткая заморозка приводит к продукту, который устарел к запуску. Цель — управлять изменениями, а не запрещать их.
- Решения без владельца продукта. Подрядчик вынужден угадывать, чьё мнение важнее.
Как выбрать модель работы
Если продукт ещё ищет свою форму, удобнее оплата по времени (Time & Materials) с короткими итерациями: изменения встроены в процесс. Если требования стабильны и хорошо описаны, подходит фиксированная цена, но тогда процесс запросов на изменения обязателен.