Від брифу до першого релізу: контрольні точки

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

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

0. Вхід у задачу

Починаємо не зі списку екранів, а з проблеми й першого користувача. Нам потрібні чотири відповіді:

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

1. Межі першого релізу

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

2. Вертикальний зріз

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

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

3. Перевірка головного ризику

На цьому кроці не поліруємо все однаково. Якщо ризик у зовнішньому API, перевіряємо його ліміти й помилки. Якщо у складній ролі, збираємо permission flow. Якщо у мобільній механіці, тестуємо керування на реальному пристрої.

Замовник отримує preview URL і список відкритих рішень. Коментар «подобається» корисний, але важливіше пройти сценарій і звірити його з критеріями.

4. Розширення до погодженого scope

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

5. Hardening

• loading, empty, error і permission states;
• mobile і keyboard flow;
• логування, аналітика та критичні алерти;
• резервні копії й план відновлення, якщо система зберігає важливі дані;
• перевірка основного шляху перед релізом.

6. Реліз і передача

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

Що змінює термін

• невідомий стан старого коду або даних;
• банки, ERP, store review та інші зовнішні сторони;
• security review, compliance або міграція;
• затримка рішень і зміна меж після старту;
• контент, до якого команда не має доступу.

Прогноз стає чесним, коли кожна дата прив'язана до scope, залежностей і конкретного стану продукту.