Что обязательно должно быть в первой версии продукта?

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

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

Первая версия — не маленькая копия будущей системы

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

Полезнее думать не о размере системы, а о проверке. Что должно стать ясно после запуска? Что люди готовы оставить заявку без звонка менеджеру? Что руководитель доверяет данным в одном окне? Что клиенты готовы платить за доступ к сервису? Первая версия нужна, чтобы получить ответ на такой вопрос в реальной работе.

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

Что должно быть обязательно

Набор зависит от продукта, но у работающей первой версии почти всегда есть несколько вещей.

1. Конкретный пользователь и его ситуация. Не «малый бизнес» и не «все менеджеры», а, например, менеджер, который должен передать подтвержденный заказ в производство без трех сообщений в чате.
2. Одна работа, за которую продукт отвечает. Сформулируйте ее обычным глаголом: записать, согласовать, передать, рассчитать, увидеть, оплатить. Если в первом релизе пять таких глаголов, вероятно, их уже слишком много.
3. Путь от входа до результата. Пользователь должен понимать, с чего начать, что сделать дальше и как убедиться, что задача закончена. Кнопка без следующего шага — еще не функция.
4. Минимум надежности. Данные не должны исчезать, доступ не должен быть случайным, а ошибка должна быть заметна. Первая версия не обязана выдерживать любую нагрузку мира, но не может строиться на надежде.
5. Способ увидеть реальное использование. Не сложная аналитическая система, а хотя бы понятный сигнал: сколько людей дошли до результата, где остановились, что им пришлось уточнять вручную.

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

Как найти границу между необходимым и приятным

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

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

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

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

Чего в первой версии обычно не нужно

Отложить — не значит признать функцию плохой. Это значит не делать ставку до того, как появилась причина. Чаще всего в первый релиз преждевременно попадают:

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

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

Минимум не должен быть сырым

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

Если сервис принимает оплату, нельзя назвать минимальностью отсутствие понятного подтверждения. Если система хранит заявки, нельзя мириться с потерей данных. Если пользователю нужно выбрать тариф, нельзя прятать условия так, что он не понимает, за что платит. Скромный объем не отменяет ответственности за основной путь.

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

Как проверить первую версию до большого запуска

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

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

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

Что делать после первых результатов

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

Если клиенты регулярно упираются в подключение, следующий релиз может быть про него, а не про красивый новый раздел. Если команда вручную сверяет данные, вероятно, важнее договориться об источнике истины или настроить один обмен, чем добавлять еще один отчет. SaaS отличается от обычной программы не браузером, а постоянной ответственностью за работу сервиса, обновления и поддержку — об этом есть отдельный материал: «Чем SaaS отличается от обычной программы для компании?».

Короткий чек-лист перед запуском

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

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

Частые вопросы

Нужен ли в первой версии красивый дизайн?

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

Можно ли запускать продукт без интеграций?

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

Сколько функций должно быть в MVP?

Нет честного числа. Ориентир — не количество экранов, а один законченный путь. Иногда это три действия, иногда десять, если без них пользователь не получает результат.

Когда добавлять новые функции?

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