КП на разработку MVP: что должно входить

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

КП не должно заменять полное ТЗ, договор, методичку по разработке или описание всего будущего продукта. Если в документе приходится долго объяснять, что такое MVP, бюджетный коридор, FTE или change request, лучше вынести эти объяснения в справочные материалы и оставить КП коротким.

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

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

Обычно это ситуация, когда:

• заказчик хочет проверить гипотезу или первый рабочий сценарий;
• есть ограниченный бюджет или срок;
• часть функций планируется на будущие релизы;
• требования еще уточняются;
• нужно показать несколько вариантов состава MVP;
• перед договором нужно согласовать рамку работ и следующий шаг.

Если неясна даже цель первой версии, сначала нужен brief, discovery или предпроектная проработка.

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

Оно не обязано подробно обучать методологии разработки. Хорошее КП не спорит с будущим договором и не обещает больше, чем зафиксировано в scope.

Внутри КП должны быть понятны:

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

Минимальная структура:

1. Цель проекта и ожидаемый результат.
2. Состав MVP или первой очереди.
3. Основные сценарии пользователей.
4. Этапы работ и календарный ориентир.
5. Команда или роли.
6. Бюджет или бюджетный коридор.
7. Допущения, зависимости и исключения.
8. Порядок изменения scope.
9. Критерии готовности и приемки.
10. Следующий шаг.

Если КП длинное, методологические объяснения лучше заменить короткими ссылками на справочные страницы RB Tech.

Если КП описывает MVP через набор задач, рядом со scope полезно зафиксировать, как описать задачи MVP для оценки и приемки: что входит сейчас, что остается за рамками и по каким критериям результат будет принят.

В КП важно не смешивать текущий MVP и полный продукт.

Практичный формат:

• Входит в текущий этап.
• Опции.
• Будущие релизы.
• Не входит в текущую оценку.

Такой подход помогает сохранить контекст будущего продукта, но не превращать будущие идеи в обязательство текущего этапа.

Если вводные стабильны, в КП можно дать оценку этапа. Если часть требований зависит от решений заказчика, внешних API, состава MVP или качества данных, честнее дать бюджетный коридор.

Рядом с бюджетом нужно указать:

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

Если в КП есть FTE-месяцы, нужно объяснить, что это емкость команды, а не календарный срок.

В КП достаточно 3-5 точечных ссылок.

Например:

• если оценка дана диапазоном - ссылка на материал про бюджетный коридор;
• если нужно отделить MVP от полного продукта - ссылка на материал про scope;
• если проект будет меняться - ссылка на change request;
• если есть FTE-месяцы - ссылка на FTE-оценку;
• если проект итерационный - ссылка на приемку по этапам.

Ссылки должны помогать читателю понять конкретный пункт КП. Они не заменяют сам scope и не меняют договорные условия.

• Превратить КП в учебник по методологии.
• Обещать полный продукт под видом MVP.
• Не показать исключения.
• Смешать текущий объем, опции и будущие релизы.
• Дать бюджет без допущений.
• Не описать порядок изменений.
• Оставить следующий шаг расплывчатым.
• Включить в КП слишком много внутренних объяснений команды.

КП на MVP личного кабинета может выглядеть так:

1. Цель: сократить ручную обработку заявок дилеров.
2. MVP: вход дилера, создание заявки, статус, очередь менеджера.
3. Не входит: автоматический расчет сложных скидок, претензии, BI, мобильное приложение.
4. Зависимости: API ERP, справочник товаров, правила ролей.
5. Бюджет: диапазон с условиями пересчета.
6. Приемка: по согласованным сценариям и критериям готовности.
7. Следующий шаг: подтвердить состав MVP и материалы для оценки интеграции.

Чем КП отличается от ТЗ?

КП предлагает состав работ, бюджет, сроки и следующий шаг. ТЗ подробно фиксирует требования к системе и результату. В раннем MVP-проекте КП может идти до полного ТЗ.

Нужно ли в КП описывать всю методологию?

Нет. КП должно быть коротким и проектным. Методологические объяснения лучше вынести в справочные материалы.

Можно ли дать бюджет коридором?

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

Как показывать будущие релизы?

Отдельным блоком: опции или roadmap. Они не должны автоматически входить в текущий бюджет.

Какие ссылки добавить в КП?

Только те, которые объясняют конкретные места документа: бюджет, scope, изменения, FTE или приемку.

Если в MVP есть непроверенная технология, интеграция, нагрузочная модель или алгоритм, КП не должно прятать это внутри обычной разработки. Такой риск лучше назвать отдельно: что проверяется, каким PoC или R&D-этапом, какой критерий успеха и какое решение будет принято после проверки.