Что входит в скоуп-документ MVP

Большинство «скоуп-документов» это список функций с маркерами и цифра. Это не скоуп-документ. Это догадка с форматированием.

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

Короткий ответ

Восемь разделов. Пропустите два-три - и у вас предложение, а не план.

Постановка проблемы, а не список функций

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

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

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

Пользовательские сценарии до списка функций

Функции по отдельности не говорят, работает ли продукт. Сценарии говорят.

Документ должен картировать два-три основных пути, которые пользователь реально проходит от начала до конца - не каждый экран, а последовательность, которая заставляет продукт функционировать. Именно здесь вы обнаруживаете, что «добавить систему рейтингов» неявно требует «обрабатывать споры, когда рейтинг несправедлив», о чём никто не подумал спланировать отдельно.

Список функций, который реально приоритизирован

Не плоский список маркеров - список, отсортированный по тому, что ломает продукт при отсутствии, против того, что было бы приятно иметь. Мы уже писали о сокращении списка из 46 функций до 11 именно с помощью этого теста: если этого не будет, работает ли ещё основной цикл?

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

Техническая архитектура с обоснованием

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

Скоуп-документ должен указывать стек, подход к хостингу и два-три решения, которые дорого будет отменить - выбор базы данных для транзакционного продукта, идут ли уведомления через WhatsApp или только email, должна ли архитектура поддерживать несколько платформ позже, даже если запускается на одной сейчас.

Экраны или прототип, а не описание

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

Это не должен быть пиксель-идеальный финальный дизайн. Он должен быть достаточно конкретным, чтобы «админ-панель» перестала быть абстракцией и стала реальной, обсуждаемой вещью.

Смета по модулям, а не единая цифра

Единая цена скрывает каждое допущение, которое её породило. Разбивка по модулям - аккаунты и права, основной транзакционный поток, платежи, админ-панель и так далее - делает две вещи, которые единая цифра не может: позволяет увидеть, что дорого и почему, и позволяет урезать конкретный модуль, если бюджет не тянет, вместо пересмотра всего целиком.

Явно названные риски и зависимости

Общие формулировки рисков («технический риск», «риск сроков») бесполезны. Настоящий раздел рисков называет конкретную вещь, способную замедлить проект - график одобрения платёжного провайдера, стороннее API с неясными лимитами запросов, ещё не принятое решение основателя - и кто отвечает за его разрешение.

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

Что явно исключено

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

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

Как выглядит настоящий пример

Мы публикуем анонимизированный образец Blueprint, где все восемь разделов заполнены для реального проекта - не шаблон с заглушками, а настоящий скоуп-документ с реальными решениями и реальными цифрами. Прочитать его быстрее, чем читать его описание.

Тест на то, настоящий ли ваш

Отдайте документ инженеру, который никогда с вами не говорил, и попросите оценить график. Если он справится без уточняющего звонка - это скоуп-документ. Если вернётся с десятью вопросами, у вас список функций с прикреплённой ценой - и эти десять вопросов ровно то, что всплывёт как запросы на изменение, когда проект уже начнётся и отвечать на них будет намного дороже.

Хотите увидеть, как выглядит полный скоуп-документ на реальном проекте? Наш образец Blueprint - это полный документ, не отрывок. Или расскажите о проекте, и мы правильно определим его скоуп до того, как назовём цифру.