Короткий ответ: сокращайте неподтверждённый объём, а не качество
Оставляйте функцию в первом выпуске, если без неё пользователь не завершит главный путь, нарушится обязательное требование, появится риск для денег или данных либо команда не сможет измерить результат. Остальное можно вернуть после первых наблюдений.
У лишней функции нет универсального ценника. Но у неё всегда появляется собственная работа: постановка, интерфейс, состояния, данные, разработка, тесты, аналитика и поддержка. Поэтому вопрос «сколько кнопок убрать» слабее другого: без какой функции ключевое обещание продукта всё ещё выполняется полностью?
Главная мысль: сильная первая версия не беднее идеи. Она точнее проверяет её главное обещание и не переносит цену неизвестности в код.
Почему «маленькая функция» редко остаётся одной строкой сметы
Допустим, команда добавляет чат. На макете это один экран. В рабочем продукте нужно решить, кто может писать, как хранить сообщения, что происходит без сети, как доставлять уведомления, нужны ли вложения, как жаловаться на контент и кто отвечает на обращение.
Та же логика работает для промокода, повторного заказа или отчёта. Чем больше ролей, состояний и внешних систем затрагивает идея, тем длиннее её хвост. Новая зависимость меняет не только разработку, но и последующие тесты, выпуск и поддержку.
Если сумма уже согласована, а новые детали появляются после старта, используйте отдельный разбор почему растёт смета на разработку. Здесь решаем предыдущий вопрос: что вообще должно попасть в оцениваемый объём.
Начните не со списка функций, а с одного пути пользователя
Сам по себе список «каталог, профиль, чат, уведомления» не показывает, выполнено ли обещание продукта. Путь показывает: человек приходит с конкретной задачей, делает несколько шагов и получает подтверждённый результат.
Допустим, приложение помогает записаться в салон. Главный путь звучит так: клиент выбирает услугу, мастера и свободное время, подтверждает запись и видит актуальный статус. Теперь у каждой идеи появляется полезный вопрос: какой шаг перестанет работать без неё?
- Пользователь и момент: кто открывает приложение и что произошло перед этим?
- Действие: что человек должен закончить?
- Результат: что подтверждает успех для пользователя и бизнеса?
- Отказ: что человек увидит и сможет сделать, если операция не прошла?
Руководство GOV.UK по пользовательским историям предлагает похожую проверку: назвать пользователя, действие и цель. Если цель функции трудно объяснить, стоит вернуться к самой потребности. Так разговор переходит от «мне нравится» к наблюдаемому результату.
P0, P1 и P2: важна не буква, а записанная причина
P0, P1 и P2 — наши рабочие обозначения, а не отраслевое правило. P0 нужно для главного пути или обязательного условия. P1 улучшает уже работающий путь. P2 проверяет другую гипотезу или добавляет полировку. Одна и та же функция меняет приоритет вместе с вопросом продукта.
| Приоритет | Когда ставить | Проверочный вопрос | Решение |
|---|---|---|---|
| P0 | Без функции ломается главный путь, обязательное требование или измерение результата | Что сломается для пользователя, денег, данных или безопасности? | Включить с критерием готовности |
| P1 | Функция снимает заметное трение в уже работающем пути | Как поймём, что улучшение действительно нужно? | Вернуть после проверки ядра |
| P2 | Новый сегмент, отдельная гипотеза или полировка без подтверждённой потребности | Можно ли проверить идею проще или вернуться после выпуска? | Отложить и записать условие возврата |
«Повторить запись» будет P2, если первая версия проверяет лишь способность клиента самостоятельно записаться. Та же функция станет P0, если команда проверяет повторное использование. Не храните одну букву без причины: через месяц никто не вспомнит, какой вопрос она решала.
Пример: что оставить в первой версии приложения записи
Продолжим условный пример с салоном. Это не универсальный список. Он показывает ход рассуждения; при другой модели бизнеса приоритеты изменятся.
| Функция | Связь с путём | Скрытая работа | Стартовый приоритет |
|---|---|---|---|
| Актуальные свободные слоты | Без них нельзя выбрать реальное время | Расписание, часовые пояса, блокировки, одновременная запись | P0 |
| Подтверждение и статус | Показывают, создалась ли запись | Статусы, повтор запроса, сбой сети, источник истины | P0 |
| События аналитики | Показывают, где путь прерывается | Схема событий, согласие, качество данных, проверка отправки | P0 |
| Напоминание о визите | Может снизить число пропусков, но запись завершается и без него | Разрешения, канал, расписание, переход из уведомления | P1 |
| Программа лояльности | Проверяет отдельную гипотезу о повторных визитах | Баланс, начисление, списание, спорные случаи | P2 |
| Чат с мастером | Не нужен для обычной записи, если вопросы решаются иначе | Доставка, модерация, вложения, уведомления, хранение | P2 |
В результате первая версия не выглядит бедной. Она позволяет выбрать время, зафиксировать запись и понять, что случилось после сбоя сети. Бедным был бы красивый каталог без актуальных слотов и подтверждения: экранов много, а обещание не выполнено.
Подробно границы первой версии разобраны в материале о разработке MVP. Здесь важна экономическая сторона: P1 и P2 не исчезают навсегда, а ждут наблюдения, которое оправдает следующую работу.
Метрика нужна до оценки функции, а не после релиза
Подход Google HEART предлагает простой порядок: цель → признак успеха → метрика. Начинать с числа на панели бессмысленно. Сам по себе клик не доказывает, что человек получил обещанный результат.
Для приложения записи цель может звучать так: «клиент сам выбирает и подтверждает доступное время». Признак успеха: запись получает подтверждённый статус без ручного исправления администратором. Метрика: доля начатых путей, завершившихся таким статусом. Рядом проверьте, не появились ли дубли записей, сбои синхронизации и обращения в поддержку.
При малом трафике не ждите ответа только от A/B-теста. Проверьте прототип с пользователями, проведите пилот и запишите, где прерывается путь. Заранее определите, какое наблюдение подтвердит гипотезу и какое заставит отложить функцию.
Редко используемая функция не обязательно лишняя
Удаление аккаунта вызывают редко. Но для приложений с созданием учётной записи Apple требует дать возможность начать удаление внутри приложения, а Google Play требует путь в приложении и ссылку для запроса вне его. На 10 августа 2026 года это правила площадок, а не улучшение удержания.
По той же причине нельзя переносить на потом защиту данных, доступность, восстановление после сбоя и проверку качества основного пути. Платёж не должен списаться дважды, а его статус не должен потеряться. Минимальный продукт может быть узким, но не опасным и не недоделанным.
Представьте маркетплейс: путь покупателя не работает без пути исполнителя. Здесь «один путь» означает одну связанную сделку, а не одну роль. Если главный риск технический, например неизвестно качество данных внешней системы, сначала нужен технический эксперимент. Фокус не отменяет необходимых связей.
Шаблон P0/P1/P2 для разговора с командой
Возьмите список функций и заполните для каждой восемь полей. Если ответы не помещаются в короткую карточку, функция, вероятно, скрывает несколько сценариев и её стоит разделить.
- Пользователь и момент: кто обращается к функции и что произошло перед этим?
- Результат: что получает человек или бизнес?
- Шаг пути: какой обязательный шаг перестанет работать без функции?
- Что нельзя нарушить: есть ли требования безопасности, закона, договора, данных или площадки?
- Зависимости: какие системы, роли, состояния и исключения добавятся?
- Как поймём, что функция помогает: какое поведение увидим?
- Более простая проверка: можно ли временно использовать прототип, ручной процесс или готовый инструмент?
- Решение: что команда сделает, если ожидаемого поведения не будет?
Сохраните шаблон перед обсуждением объёма. Начните с одной функции, по которой команда спорит чаще всего. Заполненная карточка полезнее списка аргументов «за» и «против»: она показывает, что нужно доказать и какое решение последует.
Как разобрать список функций за одну рабочую встречу
- Запишите главный вопрос продукта. Не «сделать приложение», а что нужно проверить в поведении пользователя или работе бизнеса.
- Нарисуйте один законченный путь. От ситуации входа до подтверждённого результата и понятного отказа.
- Разложите карточки функций. Сначала P0, затем P1 и P2. Не обсуждайте дизайн будущего модуля, пока не доказана его роль.
- Раскройте зависимости P0. Роли, данные, интеграции, ошибки, аналитика и критерии готовности.
- Зафиксируйте признак успеха. Что команда должна увидеть после выпуска и какие сбои нельзя допустить.
- Запишите условия возврата P1/P2. Какое наблюдение или изменение задачи вернёт функцию в план.
После встречи у вас останутся не три цветные колонки, а граница выпуска: законченный путь, обязательные зависимости, способ проверки и очередь идей с причинами. Именно этот набор можно отдавать команде для оценки.
Когда сокращения функций недостаточно
В регулируемом или договорном продукте состав задают не только пользовательские наблюдения. Требования закона, безопасности, доступности, отчётности и контракта могут сделать редкий сценарий обязательным. Их нужно вынести отдельным флагом, а не оценивать голосованием.
Иногда приложение вообще не лучший первый шаг. Если человек совершает действие раз в год по ссылке, достаточно адаптивной веб-формы. Если данные и статусы внутри бизнеса противоречат друг другу, новый интерфейс лишь скроет проблему. Сначала стабилизируйте процесс или проверьте идею прототипом.
Малые самостоятельные части помогают быстрее получить обратную связь, но не гарантируют спрос и не дают универсального процента экономии. Они уменьшают ширину первой ставки. Решение о продолжении всё равно принимают по фактическому поведению и ограничениям продукта.
Как мы в 13FOX готовим объём к оценке
На входе нам нужны список функций и один главный пользовательский сценарий. Мы связываем пункты со шагами, отмечаем обязательные правила, данные и интеграции, затем задаём критерий готовности и событие аналитики для ключевого результата.
На выходе получается черновая карта P0/P1/P2. В ней видно, что входит в первую версию, какие зависимости нужно проверить до оценки и при каком наблюдении вернутся отложенные идеи. Если появляется новая функция, она заменяет текущий приоритет, ждёт следующего этапа или осознанно расширяет объём.
Полный маршрут от замысла до поддержки описан в статье о структуре процесса разработки. Здесь мы останавливаемся на одном решении: что команде действительно нужно оценивать сейчас.
Официальные источники и дата проверки
Источники проверены 10 августа 2026 года. Правила площадок меняются, поэтому перед публикацией приложения сверяйте их текущие версии.
- GOV.UK: границы сервиса вокруг задачи пользователя.
- GOV.UK: пользователь, действие, цель и критерии приёмки.
- DORA: работа небольшими самостоятельными частями.
- Google Research: цель, признак успеха и метрика.
- Apple: удаление аккаунта внутри приложения.
- Google Play: требования к удалению аккаунта.
Частые вопросы
Как сократить стоимость разработки приложения без потери качества?
Сокращайте неподтверждённый объём, а не качество основного пути. Оставьте функции, без которых пользователь не завершит главный сценарий, нарушится обязательное требование, появится риск для денег или данных либо команда не сможет измерить результат.
Что означают P0, P1 и P2 для функций?
В этой статье P0 означает функцию ядра или обязательное требование; P1 — доказуемое улучшение уже работающего пути; P2 — отдельную гипотезу, новый сегмент или полировку, которую можно отложить. Это рабочая классификация 13FOX, а не отраслевой стандарт.
Сколько функций должно быть в MVP?
Универсального числа нет. Первая версия должна полностью проводить пользователя по выбранному сценарию, защищать деньги и данные, выполнять обязательные требования и собирать сигнал для решения о следующем шаге.
Можно ли удалить функцию, которой пользуются редко?
Только после проверки её роли. Редкая функция может быть обязательной для безопасности, закона, восстановления, целостности данных, поддержки или правил площадки. Низкая частота сама по себе не доказывает, что функция лишняя.
Как понять, что функция относится к P0?
Проверьте четыре условия: без функции ломается главный путь; нарушается обязательное требование; возникает риск для денег или данных; без неё нельзя получить сигнал о результате. Если ни одно условие не выполняется, функция не должна автоматически попадать в P0.
Нужно ли откладывать дизайн, тестирование и безопасность ради MVP?
Нет. Интерфейс, тесты, базовая безопасность, доступность и аналитика нужны в объёме, который делает ключевой путь надёжным и проверяемым. MVP уменьшает ширину первой версии, а не качество обещанного результата.
Получите первичную карту P0/P1/P2
Пришлите список функций и один главный пользовательский сценарий. Мы привяжем функции к шагам, отметим обязательные зависимости и вернём черновую карту P0/P1/P2 с объяснением, что можно отложить и почему. Эту карту можно обсудить с вашей текущей командой; оценку оставшихся P0 при необходимости сделаем отдельным шагом.