Краткий ответ
Расползание объема работ (Scope Creep) возникает, когда отсутствует очевидная разница между обещанным и реализованным. Эту проблему решают три механизма: задокументированный и общедоступный базовый план (Baseline), полустраничный бланк запроса на изменение с оценкой трудозатрат и правило замещения, согласно которому любое дополнение вытесняет что-то сравнимого размера или потребляет заранее выделенный бюджет на изменения. Без этих трех механизмов каждый «незначительный запрос» исчезает внутри спринта и обнаруживается лишь к дате завершения проекта.
Почему это особенно актуально для Salesforce
Salesforce достаточно гибка, чтобы почти любой запрос казался недорогим. Добавление поля занимает две минуты, поэтому трудно объяснить заинтересованному лицу, почему это невозможно. Однако поле влечет за собой валидацию, права доступа, колонку в отчете, маппинг при миграции, строку в обучении и тестирование в UAT. Фактическая стоимость в пять-десять раз превышает время на реализацию, и именно эта разница остается незамеченной при поступлении запроса.
Рамки контроля из четырех компонентов
| Компонент | Содержание | Ответственный | Результат |
|---|---|---|---|
| Зафиксированный базовый план | Список функциональных возможностей, сценарии и явные исключения (Out of Scope) | Владелец продукта | Подписанный документ по завершении Discovery |
| Запрос на изменение (Change Request) | Описание, бизнес-обоснование, оценка трудозатрат, влияние на сроки | Инициатор + Технический лид | Полустраничный бланк |
| Совет по изменениям | Еженедельное 30-минутное обсуждение всех открытых запросов | Спонсор, ВП, Технический лид | Решение: одобрено / отклонено / на следующий этап |
| Бюджет на изменения | 10–20% от общего объема работ, выделяется в начале проекта | Спонсор | Еженедельный мониторинг остатка |
Сила явного исключения (Out of Scope)
Самым важным разделом в документе базового плана является не то, что включено, а то, что явно не включено. Фразы вроде «Интеграция с системой расчета заработной платы не включена в первый этап» или «Миграция данных до 2022 года не включена» экономят недели споров. Правило: все, что заинтересованное лицо может по ошибке посчитать включенным, должно быть указано в списке исключений под своим полным названием.
Как сказать «да», не платя за это
Безоговорочное отклонение приводит к проекту, который завершается в срок, но не используется никем. Эффективный подход — принимать каждый запрос в бэклог, прозрачно оценивать его стоимость и предоставлять заинтересованному лицу выбор: включить сейчас за счет другого пункта, отложить до следующего этапа или использовать бюджет на изменения. Когда выбор прозрачен, обсуждение переходит из эмоциональной плоскости в экономическую, и на практике около трети запросов отпадают, как только становится видна цена.
Более подробная информация об определении базового плана доступна в статьях Определение MVP Salesforce и Discovery для CRM.
Распространенные риски и меры предотвращения
Основной риск — слишком жесткий контроль. Процесс, требующий трех форм и двухнедельного ожидания, заставляет команды обходить его, и изменения продолжаются, но без документации. Полстраницы и еженедельное обсуждение — это практический потолок.
Второй риск — техническое расползание: архитектурные решения, принимаемые внутри спринта и расширяющие объем работ без того, чтобы кто-либо называл это изменением. Поэтому любое значительное архитектурное изменение должно проходить через тот же совет. Третий риск — отсутствие спонсора: когда нет того, кто авторитетно скажет «нет», каждый запрос получает ответ «мы рассмотрим» — а это то же самое, что «да».
Как измерять успех
Еженедельно отслеживаются четыре показателя: количество открытых запросов, процент одобренных, накопленное изменение объема работ относительно базового плана и остаток бюджета на изменения. Здоровый проект демонстрирует накопленное изменение до 15% и положительный остаток бюджета на этапе UAT. Накопленное изменение более 30% — это признак того, что Discovery был слишком поверхностным, а не того, что команда недисциплинирована.