Расскажите о проекте, где начал разрастаться scope. Как вы удержали управляемость?

Суть вопроса

Интервьюер проверяет scope management: как вы распознаёте scope creep на ранней стадии, какие инструменты и переговорные техники используете, чтобы не допустить потери контроля над проектом.

Признаки scope creep

• Стейкхолдеры добавляют «небольшие» просьбы вне официального процесса изменений.
• Sprint backlog растёт быстрее, чем команда завершает задачи.
• Требования меняются без обновления сроков/бюджета.
• Разработчики начинают работать над «пока мы здесь, сделаем и это» задачами.

Конкретный пример по STAR

Ситуация: 4-месячный проект по редизайну личного кабинета клиента (финтех). На 6-й неделе заказчик начал добавлять «мелкие» дополнения: нотификации, экспорт PDF, интеграция с внешним API партнёра.

Действия для удержания управляемости:

1. Явный Change Log

Каждый новый запрос фиксировался в таблице изменений с полями: описание, инициатор, влияние на сроки (дни), влияние на бюджет, решение (принято/отложено/отклонено). Таблица отправлялась стейкхолдерам еженедельно.

2. Change Request процесс

Любое изменение scope требовало письменного CR (Change Request) с подписью product owner. Устные просьбы в Slack не принимались без последующего CR. Это создавало паузу для обдумывания реальной необходимости.

3. Trade-off переговоры

Модель «добавить что-то новое — убрать что-то старого же размера» (Scope Triangle). Заказчику предложили: «Интеграция с API партнёра занимает 3 дня, что из текущего плана переносим на следующую итерацию?»

4. Scope Buffer

Изначально заложили 15% capacity спринта как buffer для неизбежных мелких изменений. Прозрачно показывали, когда buffer исчерпан.

5. Definition of Done для фаз

Каждая фаза имела явный Definition of Done и дату freeze требований. После freeze — изменения только в следующую фазу.

Результат: проект сдан на 5 дней позже исходного срока (вместо прогнозируемых +4-6 недель без контроля). Заказчик принял 3 из 7 дополнительных запросов, остальные — в roadmap v2.

Подводные камни

• Говорить «нет» без объяснения влияния на сроки — вызывает ощущение, что команда просто не хочет работать.
• Не фиксировать scope в начале проекта документально — тогда любое «мы всегда это имели в виду» невозможно оспорить.
• Принимать все изменения молча «чтобы не конфликтовать» — команда выгорает, дедлайн срывается, виновных ищут в разработке.
• Отсутствие спонсора со стороны бизнеса с полномочиями приоритизировать — без него каждый стейкхолдер лоббирует своё.
• Слишком жёсткий freeze требований без механизма экстренных изменений — при реальном критическом баге или регуляторном изменении процесс превращается в бюрократический барьер.
• Не информировать команду об изменениях scope — разработчики работают по старым требованиям и обнаруживают расхождение поздно.
• Не разделять scope creep от уточнения требований (clarification) — уточнение нормально и бесплатно, добавление нового функционала — нет.
• Игнорировать технический scope creep: «пока мы здесь, рефакторим всё» — съедает ресурсы незаметно для стейкхолдеров.

• Принимать все изменения без пересчёта плана.
• Отказывать без объяснения бизнес-стоимости.
• Не обновлять stakeholders о последствиях scope changes.

• Контролирует scope через критерии.
• Умеет торговать объёмом, сроком и качеством.
• Делает последствия изменений видимыми.