Как 3 агентства согласовали 79 фичей за 2 недели

Каждая компания приносит в обсуждение не только свою боль, но и весь накопленный список «когда-нибудь хотелось бы». Это естественно, но опасно для ядра.

Если не задать правила, скоуп превращается в компромиссный монолит без приоритетов. Три агентства на старте принесли суммарно 140+ пожеланий — почти вдвое больше, чем вошло в финальный scope.

Мы задавали один практический вопрос: влияет ли функция на типовой ежедневный контур нескольких агентств или это локальная оптимизация конкретной команды?

Проекты, задачи, канбан, тайм-трекинг, клиентский портал, CRM, аналитика маржи — всё это нужно каждому и вошло в ядро. Интеграция с конкретной ERP, специфический формат отчёта для одного клиента — ушло в кастом.

Так из 140+ пожеланий осталось 79 фич в 16 модулях ядра. Часть отвергнутых пожеланий перешла в индивидуальный слой кастомизации.

Обычно конфликт возникает не вокруг явных различий, а вокруг «почти общих» процессов: отчёты, этапы согласования, статусы задач, финансовая аналитика.

Одно агентство использовало 7 статусов задач, другое — 4, третье — вообще работало без статусов, заменяя их канбан-колонками. Решение: гибкая система с настраиваемыми статусами в ядре, а конкретные пресеты — в кастоме.

Именно поэтому роль оператора здесь не декоративная. Нужен кто-то, кто держит критерии и не позволяет совещанию превратиться в аукцион пожеланий.

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

Две недели на согласование 79 фичей — это быстро. Для сравнения: в Kuali (университетский консорциум) на согласование scope уходили месяцы. Разница — в размере группы (3 vs 20+) и в том, что оператор ведёт процесс, а не наблюдает за ним.

Для SplitBuild это один из главных operational tests модели. Если scope не согласуется за 2–3 недели — что-то не так с составом группы.