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

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

Выберите одного пользователя и повторяющуюся задачу

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

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

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

Нарисуйте путь от исходных данных до результата

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

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

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

Разделите продуктовый минимум и условия эксплуатации

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

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

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

Решите, что временно можно выполнять вручную

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

В учебном расчёте подключение занимает два часа, а помощь в первую неделю — ещё час на организацию. Для восьми клиентов потребуется 24 часа. Если свободно только десять, нельзя обещать одновременный запуск всем восьми без изменения процесса или команды.

Отдельно отмечайте действия, которые клиент должен делать самостоятельно. Иначе команда может успешно обслуживать людей вручную и ошибочно решить, что сам продукт уже удобен.

Восьми организациям нужно 24 часа на подключение и первую неделю. Свободно только 10, поэтому одновременный запуск всем не обещают.
Ручная помощь должна быть управляемой частью услуги. Вход в систему сам по себе данные организаций не изолирует.
Часы
Подключение 2 часа и помощь в первую неделю 1 час. Восемь организаций — 24 часа. Свободно только 10, поэтому одновременный запуск всех восьми не обещают.

Вход пользователя сам по себе не изолирует данные организаций.

Зафиксируйте условия допуска и остановки

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

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

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

Практическое задание

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