Календарь уже есть. Записи ещё нет
Представим сервис записи в мастерскую. На экране всё на месте: услуги, календарь, свободные часы. Посетитель выбирает вторник, нажимает кнопку и получает подтверждение. До этой минуты приложение выглядит законченным. Затем начинается вторник.
Мастер не видит новую запись. Или видит, но на это время уже договорился с другим клиентом по телефону. Или заказчику нужно перенести визит, а сделать это можно только через разработчика. Календарь работает. Работа мастерской — пока по-прежнему в переписке.
Это условный пример, но он помогает поставить точный вопрос к первой версии: какое действие теперь действительно можно завершить? Нужен предметный ответ: клиент записался, сотрудник получил запись, занятое время исчезло из выбора, обе стороны знают, что делать дальше.
С такого короткого рассказа и стоит начинать проект. Кто человек, зачем пришёл, что принёс с собой, какой результат забрал? Пока история не складывается в несколько предложений, подробное меню приложения скорее прячет неопределённость, чем устраняет её.
Что можно убрать, чтобы ничего не сломалось
У маленького продукта есть соблазн казаться большим. Личный кабинет придаёт солидность, рекомендации обещают заботу, сложный профиль выглядит как задел на будущее. Каждая функция по отдельности разумна. Все вместе они могут отодвинуть день, когда человек впервые воспользуется основной услугой.
В нашем сервисе запись можно начать без сложного профиля. Перенос нестандартного визита первое время может согласовывать сотрудник. А вот занятое время нельзя продолжать показывать свободным: это разрушает само обещание сервиса. Граница проходит через последствия для человека.
Ручная работа внутри первой версии допустима, если она предусмотрена и посильна. Нужно знать, кто принимает решение, где видит задачу и что происходит в его отсутствие. На экране при этом должно быть «Запрос принят, подтвердим время», если подтверждения ещё нет. Автоматизация может прийти позже; ясность нужна с первого дня.
Есть и работа, которую почти не видно на демонстрации: разграничение доступа, восстановление данных, обработка ошибок. Её объём зависит от продукта. Маленькая первая версия должна быть пригодна к той нагрузке и ответственности, которые вы ей поручаете.
Самое дорогое место — за пределами экрана
Допустим, мастерская уже ведёт расписание в другой системе. Тогда главный риск проекта может скрываться в одном вопросе: получится ли надёжно получать оттуда свободное время? Если нет, новый календарь создаст второе расписание. Кто-то будет обязан ежедневно мирить их между собой.
Такую неизвестность выгоднее проверить до большой разработки. Иногда достаточно получить тестовую запись через предусмотренный системой интерфейс обмена данными. Иногда выясняется, что нужная возможность есть лишь на другом тарифе или доступна с задержкой. Это уже меняет будущую работу и её стоимость.
Другая неизвестность — поведение клиентов. Готовы ли они выбирать время сами? Понимают ли названия услуг? Прототип позволяет увидеть, где человек останавливается, ещё до подключения настоящего расписания. Но даже безупречно пройденный прототип не подтверждает повторное использование и готовность платить.
Проверка полезна, когда после неё можно принять решение: продолжить, изменить правила, упростить замысел. Если любой результат ведёт к заранее запланированной разработке, это скорее репетиция презентации.
Неловкие минуты перед словом «готово»
Приёмка становится спокойнее, когда её сценарий известен до начала работы. Для мастерской это может выглядеть так: человек выбирает время; запись появляется у сотрудника; повторное нажатие не создаёт вторую; уже занятое время нельзя забронировать снова. Затем проверяется перенос.
После удачного прохода стоит намеренно помешать системе. Отключить тестовую интеграцию, ввести неверный контакт, попробовать открыть чужую запись. Пользователь должен получить объяснение и доступный следующий шаг, а ответственный — возможность разобраться. Хорошая ошибка тоже часть продукта.
Новые идеи к этому моменту почти неизбежны. Увидев работающий сервис, легче придумать абонементы, оплату, напоминания. Их стоит сохранить, оценить и выбрать очередность. Иначе приёмка незаметно превращается в начало ещё одной разработки, а первый выпуск всё время остаётся «почти готовым».
Первый вторник после запуска
Самый содержательный день проекта может наступить после демонстрации. Теперь видно, где люди бросают запись, какие вопросы задают по телефону и сколько раз сотрудник вынужден вмешиваться. Важно заранее назначить человека, который соберёт эти наблюдения, и время их разбора.
Сколько людей начали запись? Сколько завершили? Где потребовалась помощь? Вернулись ли те, кому услуга снова понадобилась? Небольшой набор связанных наблюдений полезнее огромной панели показателей. Число регистраций само по себе не отвечает на эти вопросы.
В бюджете должны остаться средства на исправления и спокойную передачу работы владельцу. Если всё ушло на демонстрацию, реальные пользователи первыми обнаружат, что проекту не хватило последнего, самого практического этапа.
Следующая версия заслуживает своего бюджета, когда понятно, какое препятствие она устранит или какую новую возможность проверит. До этого первая может оставаться скромной. Для начала достаточно, чтобы во вторник клиент пришёл, мастер его ждал, а разработчику не пришлось вмешиваться.