КП на разработку 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 и полный продукт.

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

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

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

Если вводные стабильны, в КП можно дать оценку этапа. Если часть требований зависит от решений заказчика, внешних 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 или приемку.

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