Как вы управляете scope creep в проекте?

Question

Accepted Answer

**Scope creep**, постоянное накопление «ещё одного», — это то, как проекты, идущие по плану, тихо соскальзывают. Решение не в том, чтобы отказывать всем; это означает сделать **каждое добавление видимым, явным компромиссом** против времени, вместо молчаливого поглощения.

## Как контролировать объём

```text
✓ Define DONE up front — written, agreed scope
✓ Make the cost of every addition VISIBLE ("yes, and that pushes us a week")
✓ Track changes — a changelog of what got added/cut
✓ Protect a core MVP — defend the must-haves fiercely
✓ Use a PARKING LOT — capture good ideas for "later," don't reject them
✓ Escalate trade-offs to whoever owns priority — let them choose
```

## Ключевой ход

Не отказывайте в новых запросах сразу, это делает вас блокировщиком. Вместо этого вынесите компромисс на поверхность: «Мы можем это добавить. Это означает, что либо дедлайн смещается на неделю, либо мы отменяем функцию X. Что вы выбираете?» Теперь это *бизнес-решение*, принятое нужным человеком, с открытыми глазами.

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

В середине проекта PM постоянно добавляет «небольшие» изменения. Вы запускаете общий лог изменений области. Внезапно все видят, что исходный двухнедельный проект поглотил три недели добавлений, и разговор о дедлайне становится очевидным и простым.

## Почему это важно

Неконтролируемый scope creep — это тихий убийца дедлайнов: ни одно изменение не кажется большим, но вместе они приводят к срыву.

Оявление компромиссов защищает команду, информирует заинтересованные стороны и снимает ответственность с инженеров, когда причиной является объём работ, а не усилия.