Жизнь после релиза MVP, или как не утонуть в доработках

Что будет, если после релиза MVP (первой рабочей версии сайта, онлайн-сервиса или приложения) оставить его доработку без контроля? Как показал наш опыт, список желаемых фич будет пополняться каждый день. Маркетинг попросит добавить фильтр, служба безопасности — разграничить права доступа, отделу продаж понадобится интеграция с CRM.

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

Почему список доработок растет, как снежный ком

Распространенный сценарий: руководитель проекта на стороне заказчика узнает о доработках на демонстрации промежуточного результата. При этом разработчики уже неделю заняты задачей, которой не было в исходном ТЗ. Отменить ее сложно — работа начата, деньги потрачены. Оставить — значит молча признать, что скоуп проекта (границы доработок) определяет не документ, а то, кто последним написал в чат с разработчиком.

Разработчик не останавливает работу сам, потому что у него нет для этого инструментов. Если границы работ не зафиксированы в договоре, у команды не будет формального повода сказать «это уже не MVP» — только неформальное «давайте обсудим на созвоне», которое ничего не решает. Подрядчик заинтересован закрыть заявку заказчика, а не спорить с ним о границах первого релиза, поэтому частый исход — молчаливое согласие на новую задачу.

Проблема усугубляется тем, что запросы на доработку приходят из разных отделов заказчика в разное время, а не одним списком. Пока идет обсуждение с маркетингом, команда разработки уже начала писать первую версию личного кабинета. Через две недели приходит требование о разделении ролей от службы безопасности, и его добавляют поверх, потому что откладывать «уже начатое» кажется нелогичным. В итоге из MVP вырастает полноценный продукт. Но рост неконтролируемый: бюджет раздут, релиз сдвинут, а команда третий раз за месяц переписывает техническое задание. О продуманной архитектуре в таких условиях речь, конечно, не идет.

Как найти границы MVP

Мы уже публиковали в блоге статьи о том, что такое MVP, а также о том, как спланировать переход от «минимально жизнеспособного продукта» к версии 1.0.

MVP отвечает на один вопрос бизнеса, при этом предполагается, что ответ будет «да» или «нет». Например, «станут ли дилеры оформлять заказ в личном кабинете без звонка менеджеру». Любая функция, которая не помогает ответить на этот вопрос, — кандидат на вторую волну разработки, а не часть первого релиза.

Граница MVP выстраивается вокруг гипотезы. Если руководитель проекта не может сформулировать, что именно проверяет запуск, спор о том, что обязательно, а что можно добавить потом, может продолжаться до бесконечности. Каждый департамент (маркетинг, служба безопасности, отдел продаж) будет опираться на свое ощущение важности, и все будут по-своему правы.

Поэтому разделение на MVP и следующие пункты дорожной карты проекта стоит фиксировать не в техническом задании, которое готовит проектная команда, а в отдельном документе с приоритетами (приложении к ТЗ). Этот документ подписывает руководитель проекта до старта разработки. Он дает формальное основание отклонять доработки без личного конфликта с командой: не «я так решил», а «это не отвечает ни на один вопрос из зафиксированного списка».

Документ с приоритетами отвечает на вопрос, что входит в MVP. Он не отвечает на другой вопрос: что происходит с доработкой, которая появляется на третьей неделе разработки, — когда часть работы уже сделана, и просто сослаться на документ недостаточно, нужно понять, когда команда физически может взять правку в работу и сколько дней это добавит к сроку. Здесь решает не документ с приоритетами, а то, как организован сам процесс разработки.

Куда уходит доработка: как Scrum и Kanban ограничивают её скорость

В разработке применяются разные методики, у каждой есть свои плюсы и минусы. Различают «гибкий» метод Agile с направлениями Scrum и Kanban и «негибкий» — Waterfall, он же каскадный или водопад.

Разница между методиками — в том, где именно стоит точка, где доработку нужно остановить и явно решить, брать её в работу или нет. В Scrum эта точка — начало нового спринта: новая доработка попадает в бэклог и обсуждается на планировании следующего цикла, который обычно длится одну-две недели. Это физически ограничивает скорость, с которой скоуп «утекает» за пределы плана.

В Kanban ограничение работает иначе — через лимит work in progress. Если команда одновременно ведет не больше 3–4 задач, любая новая доработка требует явно вытолкнуть что-то из работы. Руководителю проекта приходится решать, что важнее сейчас, а не молча добавлять задачу поверх текущих.

Для проектов с фиксированным бюджетом (типичная ситуация для тендеров и госсектора) Kanban с явным лимитом задач в работе проще в управлении, чем Scrum с постоянно меняющимся бэклогом. Это стоит обсуждать с подрядчиком на старте проекта, а не в его середине, когда бюджет уже наполовину потрачен.

Тот же принцип работает и за пределами веба — там, где цена ошибки выше, чем на сайте. Например, однажды мы проектировали интерфейс киоска самообслуживания для компании «Авиакод» (дочерняя организация холдинга «Аэропорты регионов», разрабатывает оборудование и цифровые сервисы для аэропортов). В первой версии киоска мы зафиксировали три сценария: регистрацию пассажира на рейс (сканирование паспорта, подтверждение брони, выбор места), сдачу багажа на отдельной стойке drop-off (взвешивание чемодана на платформе, печать и наклейка бирки) и оплату дополнительных услуг с получением посадочного талона.

Мы всегда строим работу по методике Scrum, используя спринты длительностью в одну неделю. За два месяца, или девять спринтов, удалось реализовать и протестировать все сценарии, не отвлекаясь на доработки. Что у нас получилось, читайте в кейсе.

Четыре принципа контроля скоупа в Uplab

Эти правила мы применяем при любом масштабировании MVP.

1. Модульность в архитектуре. Мы закладываем этот принцип в самом начале проекта. Публичная часть, личный кабинет и админка — отдельные слои. Доработка одного модуля не требует пересборки всей системы и не сдвигает сроки остальных частей проекта.

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

3. Переиспользуемые компоненты. По возможности закладываем их на этапе дизайна и проектирования. Это делает UX/UI лаконичнее и предсказуемее, снижая стоимость каждой следующей доработки: компонентная база может позже применяться в новых функциях.

4. Непрерывная интеграция и доставка (CI/CD) и модульная миграция данных — части контроля скоупа. Они позволяют выкатывать доработки маленькими партиями без остановки всей системы. Заказчик не сталкивается с ситуацией, когда одна фича блокирует весь релиз.

При разработке сайта для Алюминиевой Ассоциации мы применяли именно такой подход. Публичную часть собрали на 1С-Битрикс, Twig и Tilda, личный кабинет — на Vue.js с REST API, админку выделили в третий независимый слой. Такое разделение позволило перенести 2000+ единиц контента без потери структуры и ссылок — модульная миграция шла частями, а не одним рискованным переносом всей базы разом. Ролевая модель с шестью ролями и десятки справочников дали возможность добавлять новых участников и типы контента без изменения кода, а CI/CD превратил релизы из редкого и тревожного события в рутинную операцию: доработки выкатывались часто и безопасно, пользователи не потеряли доступ к привычным функциям.

Важно учитывать: если бюджет и сроки жестко ограничены, а функциональность в будущем не изменится — модульность не окупится и будет выглядеть как переплата. Модульность имеет смысл, если заказчик заранее знает, что после запуска придут новые требования. Тогда выгоднее заплатить на 10–15% больше на старте и не платить кратно больше на каждой следующей доработке.

Саммари

Доработки не исчезнут — бизнес меняется быстрее, чем идет разработка. Главный вопрос: кто решает, какая из них войдёт в MVP, а какая дождётся версии 1.0.

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

1. Зафиксированная гипотеза: одна проверяемая идея, а не список фич.
2. Подписанный документ с приоритетами, который дает формальное основание отклонять запросы без личного конфликта.
3. Архитектура, разделенная на независимые модули, чтобы изменение одной части не тянуло за собой пересборку всей системы.

Ни одна из них не работает по отдельности так же хорошо, как все три вместе, и ни одна не гарантирует, что доработок не будет вовсе. Они лишь дают руководителю проекта основание отвечать на них осознанно, а не постфактум.

Модульность в архитектуре проекта сложнее всего оценить заранее: на бумаге любая архитектура выглядит достаточно гибкой, а узкие места вскрываются только на конкретном продукте с конкретной логикой роста. Пришлите описание своего продукта через форму «обсудить проект» — разберем, какая часть архитектуры выдержит рост MVP без пересборки, а какую стоит перепроектировать сразу.