Как зафиксировать границы: что точно НЕ делаем в этом релизе

Границы релиза — это ваша страховка. Без них проект превращается в “ремонт квартиры”, который никогда не заканчивается.

Почему границы постоянно размываются

Потому что:

• в процессе вы лучше понимаете, что нужно
• каждый отдел хочет свои функции
• подрядчик хочет “угодить” и соглашается
• никто не хочет быть тем, кто говорит “нет”

В итоге вы платите за бесконечные изменения и теряете дату запуска.

Как зафиксировать границы просто и понятно

Сделайте документ “Состав релиза” на 1 страницу, где есть 3 блока:

1) Делаем в этом релизе (обязательно)
Короткий список функций и сценариев, без деталей.

2) Делаем, если успеем (желательно)
То, что улучшит, но не критично для запуска.

3) Не делаем в этом релизе (точно)
Самый важный блок. Туда честно пишем всё, что “хочется”, но не влезает.

Это снимает половину конфликтов: вы не спорите “почему не сделали”, вы смотрите в согласованный список.

Правило управления: новый пункт входит только через обмен

Чтобы сроки не ломались, используйте простую механику:

• добавляем новую функцию → убираем что-то равное по приоритету/объему
  или
• добавляем новую функцию → двигаем срок/бюджет

Третьего не дано. И это нормально.

Как собственнику не стать “врагом команды”

Границы — не про запреты, а про управление:

• вы фиксируете, что важно для запуска
• вы обещаете “вот это — в следующем релизе”
• вы не теряете идеи, вы складываете их в список “после запуска”

Люди спокойнее воспринимают “не сейчас”, если видят, что “не забыли”.

Что именно полезно фиксировать в блоке “точно не делаем”

• дополнительные отчеты и “красивые графики”
• сложные роли и тонкие настройки доступа
• автоматизация редких исключений
• дополнительные интеграции
• “идеальный интерфейс” и косметика
  Это часто съедает недели, но не всегда нужно, чтобы начать работать.

Границы релиза дают вам главное: управляемый запуск. А дальше улучшения идут итерациями — быстро, дешево и без драм.