«Ещё одна фича» — обычно это не такая маленькая задача

После запуска проекта одна из самых часто звучащих фраз выглядит так:

«Давайте добавим ещё одну фичу».

Иногда это действительно небольшое изменение.

Но иногда за этой же фразой скрывается совершенно новый объём работы.

Проблема не в самом запросе.

Проблема в том, что «это же небольшое дополнение» часто не воспринимается как изменение стоимости, сроков или scope.

Новый запрос — это не плохо

Появление новых идей в процессе работы над проектом — абсолютно нормально.

Когда становится понятен пользовательский сценарий, проходят демо или появляются реальные данные, могут обнаружиться потребности, которых раньше просто не было видно.

Я не отклоняю такие запросы автоматически.

Но и не включаю каждый новый запрос в текущий scope проекта автоматически.

Потому что если принимать каждое «небольшое дополнение» без чётких границ, продукт постепенно превращается во что-то совсем другое по сравнению с тем, что было запланировано изначально.

Сначала я задаю три вопроса

Когда появляется новое требование, я сначала ищу ответы на три вопроса:

• Какую конкретную проблему это решает?
• Это входит в согласованную первую версию или расширяет текущий scope?
• Если не сделать это сейчас, продукт действительно не будет работать — или просто станет лучше, если эта функция будет?

Если ответ — «было бы неплохо», это не значит, что идея плохая.

Возможно, просто сейчас ей не место в текущей версии.

Почему «маленькая» задача становится большой?

Добавить одну кнопку, одно поле или один статус на экране может показаться очень простой задачей.

Но за этим часто стоят:

• новые бизнес-правила
• совместимость с существующими данными
• влияние на другие процессы
• дополнительное тестирование и работа по внедрению
• новое поведение пользователя, которому нужно обучиться

Поэтому вопрос на самом деле не в том:

«Сколько часов займёт написание этого кода?»

Главный вопрос:

«Меняет ли это границы системы?»

Поэтому, когда я слышу «давайте добавим ещё одну фичу», я сначала смотрю не на объём реализации, а на то, изменяется ли scope.

Что делать сейчас, а что потом?

Для меня хороший подход выглядит так:

• Сохранять обещание первой версии.
• Не нарушать основной рабочий процесс.
• Добавлять новые идеи в backlog, а не включать всё сразу в текущий релиз.

Некоторые запросы действительно нужно реализовать сейчас — без них продукт будет ощущаться незавершённым.

Другие относятся уже к следующему этапу.

Важно чётко видеть эту разницу.

Иначе проект на самом деле никогда не заканчивается.

Он просто продолжает становиться всё длиннее.

Сохранять границы — не значит говорить «нет»

Сохранение scope не означает остановить клиента или заблокировать команду.

Это означает завершить то, о чём договорились, а следующую задачу рассматривать как отдельное решение.

Иначе каждую неделю появляется новое «небольшое» дополнение, а первоначальная договорённость постепенно теряет своё значение.

Для меня хороший результат — это не как можно больше фич.

Хороший результат — выпустить рабочую версию, которая решает ту проблему, которую мы изначально обещали решить.

Всё остальное — отдельное решение.

Отдельный scope.