У вас есть идея SaaS, CRM или интернет-магазина. Где-то уже лежит список функций, может быть презентация, может быть смета, завязанная на этот список. Впереди решение о том, что именно станет первым релизом.
Обычно на столе два варианта. Первый: весь продукт по плану, со всеми ролями, экранами и интеграциями, которые приходят вместе в конце. Второй: один рабочий сценарий, который живой человек проходит от первого экрана до результата, за который платят, и который уже работает в production.
Первый вариант выглядит завершённым, но оценить его нельзя: пока не работает всё, не работает ничего. Второй выглядит скромно и уже в первый месяц даёт измеримые факты. Ниже аргументы за второй вариант и перечень того, без чего первый релиз остаётся демо.
1. Чего стоит план всего продукта
У плана всего продукта есть свойство, которое редко записывают: несколько месяцев подряд нечего попробовать. Каждый экран ждёт следующий. Управление ролями ждёт оплаты, оплата ждёт договора с платёжным провайдером, а договор ждёт юридической проверки, которую ещё никто не начинал.
Поэтому совещания разбирают макеты, а не поведение. Разрыв между обещанием слайда и работой сценария виден только перед человеком, который реально пользуется системой, а в проекте такой формы он появляется последним, когда основная часть сметы уже потрачена.
CRM, собранная таким способом: воронку нарисовали раньше, чем кто-то увидел живую продажу. Пять этапов, ответственный на каждый, поле вероятности. Первый реальный продавец использовал два этапа, вероятность игнорировал, а следующий шаг записывал в личный блокнот. Исправлять это придётся блоком: экраны, права и отчёты спроектированы как одно целое.
Обратная связь приходит в самый дорогой момент: продукт почти готов, а смена направления стоит денег. Именно тогда выясняется, что одна запись клиента должна была быть двумя, а вторую вкладку никто не открывает.
Есть и более тихая цена: никто не может сказать, идёт ли работа хорошо. План даёт статус: шестьдесят процентов, по графику. Рабочий сценарий даёт факты: на этой неделе путь записи прошли три реальных пользователя, двое из них остановились на одном шаге и искали телефон.
2. Один сценарий, пройденный до конца
Первый релиз не бывает урезанной версией готового продукта. Урезанная версия сохраняет все экраны и делает каждый тоньше: так получается демо, где есть каждая кнопка, но ничего не доводится до конца.
У среза другая форма. Он берёт единственный сценарий, ради которого человек платит, и доводит его до результата: запись на визит, счёт и деньги, сделка со следующим шагом.
Выбор сценария деловое решение, а не техническое. Берите тот путь, где появляются деньги или следующее обязательство. Для продукта записи это сама запись, а не страница настроек. Для CRM это момент, когда сделка получает следующий шаг с датой.
До написания кода запишите путь одним предложением: кто что делает и какой получает результат. Если в предложении появляются слова «и ещё», вырежьте их. Если никто не может назвать человека, который пройдёт этот путь, перед вами список функций, а не сценарий.
Путь должен быть проходим для человека, который не из вашей команды. Основатели принимают за рабочие пути, которые работают только потому, что они знают тестовые данные, внутренние правила и то, какое поле можно оставить пустым. Посадите на путь постороннего и смотрите, где он остановится.
Всё, что идёт после конца пути, может быть незнакомым или ручным. Счёт можно отправить вручную, отчёт собрать в таблице. Ручная работа на краях честно откладывает решение, пока реальный пользователь не заставит его принять.
3. Модель данных следует за сценарием
Модель данных самая дорогая в изменениях часть, и её определяет именно первый сценарий. Таблицы стройте вокруг него, а не вокруг будущего списка функций.
На практике это три привычки. Существительные сценария становятся сущностями с владельцами: аккаунт, пользователь, запись, которую создаёт путь. Состояния, через которые проходит запись, хранятся как данные, а не как один флаг, который кто-то правит руками. И каждая строка знает своего тенанта с первой миграции, даже когда тенантов пока один.
Историю тоже держите в данных. Смена состояния это новая строка со временем и автором, а не перезаписанное значение. Полгода спустя такая разница определяет, ответите вы клиенту одним запросом или будете выяснять, что произошло.
С тенантами дешевше разобраться сейчас, границу описывает статья о том, как в общем продукте перемешиваются данные клиентов. Не меньше значит и то, что срез оставляет за бортом.
Никакой общей таблицы событий для случаев, которые ещё не придуманы. Никаких полиморфных связей ради будущих миграций. Схему, которую можно объяснить за один вечер, можно менять без страха, и первый релиз это то место, где такое право появляется.
4. Релиз, который повторяется
Срезу нужен повторяемый путь релиза: репозиторий, одна команда или один конвейер, который кладёт код туда, где он работает, и способ увидеть, что произошло. Не ноутбук, где шаги деплоя живут в чьей-то голове.
Проверка повторяемость, а не автоматизация. Если один и тот же релиз можно выполнить дважды по одним и тем же записанным шагам и не автором, путь есть. Если второй релиз требует звонка тому же человеку, есть только демо-окружение, и продукт вырастет вокруг этой дыры.
Первый срез оплачивает старт, который повторно используют все следующие: окружение без клиентов, конвейер и короткий список проверок после каждого релиза. Нужно и место, где изменение пробуют раньше, чем его увидит клиент, это предмет отдельной статьи о том, почему боевой сайт не годится как единственное место для проверок.
Оставьте один способ увидеть неполадку: журнал ошибок, который открывается, упавшую задачу, которую можно найти, состояние последнего релиза. Дашбордов пока не нужно. Нужно знать, не спрашивая никого, работает ли путь прямо сейчас. Каждый следующий сценарий после этого становится приращением, а не новым проектом.
5. Срез это не демо
Эту границу не проходят большинство первых релизов. Демо должно выглядеть завершённым для одного показа, срез должен выдержать рабочую неделю. Разница не в полировке, а в том, что происходит, когда вас нет рядом.
Если чего-то из пяти не хватает, у вас всё ещё демо. На второй неделе это нормально. Но это не первый релиз, и называть его первым значит лишь прятать оставшуюся работу.
6. Что остаётся на потом и когда нужен разработчик
Всё вне пути ждёт, и записать этот список честная половина плана. Роли и права, отчёты, уведомления, вторая интеграция. Договоритесь сейчас, что следующий срез рождается из первой реальной недели работы, а не из презентации.
Разговор об объёме происходит до старта разработки, и на столе лежит одна цифра: сколько стоит срез, когда он выходит в production и что он сознательно оставляет за бортом. Чек-лист заморозки объёма до начала работ набор для такого разговора.
Путь, набросок модели и список исключений можно написать без разработчика. Подключайте его, когда срез касается денег, когда базой делятся несколько клиентов или когда на вашей стороне никто не умеет выполнять релиз. Эти три случая определяют то, что дорого переделывать.
Услуги как раз и закрывают такой старт: первый сценарий согласован, собран и выведен в production, а модель данных и путь релиза вырастают из него. Избранные работы показывают результат рядом с операцией, которая его дала, в том числе продукты, выросшие из одного сценария в несколько. Если идея есть, а кода ещё нет, начните с разработки продукта с нуля; напишите мне с одним сценарием, за который заплатил бы ваш первый клиент. Пароли и клиентские данные в письмо не добавляйте.
