Перший реліз: один сценарій чи весь продукт

Є ідея SaaS, CRM чи інтернет-магазину, і десь уже лежить перелік функцій: можливо презентація, можливо кошторис, який спирається на цей перелік. Попереду рішення про те, що саме стане першим релізом.

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

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

1. Чого коштує план усього продукту

У плані всього продукту є властивість, яку рідко записують: кілька місяців поспіль немає нічого, що можна спробувати. Кожен чекає на наступний. Управління ролями чекає на оплату, оплата чекає на договір із платіжним провайдером, а договір чекає на юридичну перевірку, яку ще ніхто не починав.

Тому наради розбирають макети, а не поведінку. Розрив між обіцянкою слайда і роботою сценарію видно лише перед людиною, яка справді користується системою. У проєкті такої форми ця людина з’являється останньою, коли більша частина кошторису вже витрачена.

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

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

Є й тихіша ціна: ніхто не може сказати, чи робота йде добре, бо план дає лише статус, шістдесят відсотків за графіком. Живий сценарій дає факти: цього тижня шлях запису пройшли три реальні користувачі, двоє зупинилися на одному кроці й шукали телефон.

2. Один сценарій, пройдений до кінця

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

Зріз має іншу форму. Він бере єдиний сценарій, ради якого людина платить, і доводить його до результату: запис на візит, рахунок і гроші, угода з наступним кроком.

Вибір сценарію це рішення бізнесове, а не технічне. Беріть той шлях, де з’являються гроші або наступне зобов’язання. Для продукту запису це сам запис, а не сторінка налаштувань. Для CRM це момент, коли угода отримує наступний крок із датою.

До написання коду запишіть шлях одним реченням: хто що робить і який отримує результат. Якщо в реченні з’являються слова «і ще», обріжте їх. Якщо ніхто не може назвати людину, яка пройде цей шлях, перед вами перелік функцій, а не сценарій.

Шлях має бути прохідним для людини не з вашої команди. Засновники приймають за робочі шляхи, які працюють лише тому, що вони знають тестові дані, внутрішні правила і те, яке поле можна лишити порожнім. Посадіть на шлях сторонню людину і дивіться, де вона зупиниться.

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

3. Модель даних іде за сценарієм

Модель даних найдорожча в змінах частина, і її визначає саме перший сценарій. Таблиці будуйте навколо нього, а не навколо майбутнього переліку функцій.

На практиці це три звички. Імена сценарію стають сутностями з власниками: акаунт, користувач, запис, який створює шлях. Стани, через які проходить запис, зберігаються як дані, а не як один прапорець, який хтось править руками. І кожен рядок знає свій тенант від першої міграції, навіть коли тенантів поки один.

Історію теж тримайте в даних. Зміна стану це новий рядок із часом і автором, а не перезаписане значення. За пів року така різниця вирішує, відповісте ви клієнту одним запитом чи будете з’ясовувати, що сталося.

З тенантами дешевше розібратися зараз, межу описує стаття про те, як у спільному продукті перемішуються дані клієнтів. Не менше значить і те, що зріз лишає за бортом.

Жодної спільної таблиці подій для випадків, які ще не придумані. Жодних поліморфних зв’язків заради майбутніх міграцій. Схему, яку можна пояснити за один вечір, можна змінювати без страху, і перший реліз це те місце, де таке право з’являється.

4. Реліз, який можна повторити

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

Перевірка повторюваність, а не автоматизація. Якщо той самий реліз можна виконати двічі за тими самими записаними кроками і не автором, шлях існує. Якщо другий реліз потребує дзвінка тій самій людині, існує лише демо-середовище, і продукт виросте навколо цієї діри.

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

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

Кожен наступний сценарій після цього стає прирістом, а не новим проєктом.

5. Зріз це не демо

Цю межу не проходять більшість перших релізів. Демо має виглядати завершеним для одного показу; зріз має витримати робочий тиждень. Різниця не в поліруванні, а в тому, що відбувається, коли вас немає поруч.

• Справжні акаунти: реєстрація, вхід, відновлення пароля і хоча б один акаунт, який не ваш.
• Спосіб прийняти роботу: реальна оплата або підписаний заказ, щоб шлях закінчувався грошима чи зобов’язанням.
• Місце для перевірки: друге середовище, де невдала спроба нічого не коштує.
• Дані, які можна повернути: одна команда, що повертає тестовий акаунт у відомий стан.
• Людина поза командою, яка проходить шлях без ваших підказок.

Якщо чогось із п’яти бракує, у вас досі демо. На другому тижні це нормально. Але це не перший реліз, і називати його першим лише ховає роботу, що залишилась.

6. Що чекає на потім і коли залучати допомогу

Усе поза шляхом чекає, і записати цей перелік чесна половина плану. Ролі й права, звіти, сповіщення, друга інтеграція. Домовтеся вже зараз, що наступний зріз народжується з першого реального тижня роботи, а не з презентації.

Розмова про обсяг відбувається до старту розробки, і на столі лежить одна цифра: скільки коштує зріз, коли він виходить у production і що свідомо лишає за бортом. Перелік для заморожування обсягу до початку робіт набір для такої розмови.

Шлях, начерк моделі та перелік винятків можна написати без розробника. Залучайте його, коли зріз торкається грошей, коли базою діляться кілька клієнтів або коли на вашому боці ніхто не вміє виконувати реліз. Ці три випадки визначають те, що дорого переділювати.

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