Я бачив, як троє різних людей неправильно поводилися з одним і тим самим тридцятисекундним екраном — карткою плану, яка з'являється між вашим запитом і побудовою — і кожен заплатив за це різною валютою. Один заплатив переробкою. Інший — витраченим на набір текстом часом. Третій — продуктом, який не міг робити те, що йому насправді було потрібно. Картка плану — найдешевший момент у всьому процесі, щоб передумати, і саме тому її так легко проскочити.
Помилка перша: сліпе схвалення
Це найпоширеніша. Каркас виглядає правильно, натискаєш "підтвердити", рухаєшся далі — я так робив тижнями, поки це мене не підвело. Побудова, яка нарешті зламала цю звичку, повернулася з підключеною Stripe-оплатою до статичного сайту, якому не було де зберігати стан облікового запису, необхідний Stripe. У плані відкритим текстом було написано тип продукту: статичний сайт, прямо на картці, і я проскочив це поглядом, бо список сторінок виглядав нормально, а я поспішав.
Наслідки цієї помилки завжди однакові за формою: усе, що йде після плану, правильне відповідно до плану, тому збій не проявляється як помилка — він проявляється як робоча побудова, яка структурно неправильна. Ніхто не позначає це, бо нічого не зламано — статичний сайт із кнопкою оплати просто мовчки робить не те, або відмовляє саме в той момент, коли реальний користувач натискає "оплатити". Ви дізнаєтеся про це під час перегляду, а це найдорожче місце, щоб дізнатися.
Помилка друга: надмірна деталізація, щоб уникнути другого раунду
Протилежна помилка виглядає відповідальніше, але такою не є. Деякі люди, обпікшись на першій помилці, надмірно компенсують це, пишучи цілий абзац точних вимог на етапі планування — точний текст, налаштування відступів, які функції обов'язково мають і не мають бути, сформульовані як технічне завдання. Я теж так робив — через невиразну тривогу, що пропуск деталей зараз означає "витратити даремно" наступний раунд побудови.
Це навпаки, і ось чому: план все одно буде переглянуто ще раз, коли ви побачите реальні сторінки, незалежно від того, наскільки уважним ви були першого разу. І коли його переглянуть, ви не отримаєте перелік змін — ви отримаєте нову картку, яка вже враховує вашу правку, крапка, без нотаток про зміни. Тож точність, яку ви ввели в першому раунді, все одно не переходить незмінною в другий раунд — вам доведеться перечитувати все заново в будь-якому разі. Два-три раунди "ні, ось так" дають кращий результат, швидше в реальному часі, ніж вичерпний бриф — навіть якщо написання брифу здається ефективнішим у момент його написання.
Правки простою мовою, які справді працюють, короткі:
- "Прибрати блог, додати сторінку з цінами" — чисто замінює список сторінок.
- "Зробити двокористувацьким замість однокористувацького" — більше, ніж здається. Це може торкнутися моделі даних, яка тепер відстежує двох учасників замість одного, і оновлений план покаже цей вплив, а не приховає його.
- "Це потребує облікових записів користувачів" — якщо поточний план є статичним сайтом, це те речення, яке прямо змушує вирішити питання типу продукту.
Помилка третя: ставлення до типу продукту як до м'якого поля
Це дорога помилка, і вона дорога, бо все інше на картці по-справжньому виправне. Сторінки, виведені функції, більшість розгалужень питань — усе це можна виправити ітерацією версії після завершення побудови. Тип продукту — ні. Є чотири категорії:
| Тип продукту | Що це означає |
|---|---|
| Статичний сайт | Простий, без серверної логіки. |
| Встановлюваний застосунок | У стилі PWA — працює офлайн, можна додати на головний екран, все ще без серверної логіки. |
| Збірка на фреймворку | У стилі React/Next, більш насичена клієнтська інтерактивність, все ще без постійного бекенду. |
| Застосунок із серверним бекендом | Єдиний з чотирьох з реальною базою даних та системою облікових записів за ним. |
Затвердьте план статичного сайту, а через три версії вирішіть, що хочете вхід у систему — це не оновлення версії, це переробка з іншого типу продукту, і ви втрачаєте безперервність, яку історія версій давала для всього іншого.
Люди помиляються тут двома способами. По-перше, вони не звіряють власний запит із полем — якщо у вашому запиті є "облікові записи", "вхід", "зберегти", "панель, що оновлюється", "платежі" або "кілька користувачів редагують одне й те саме", а картка не вказує на серверну підтримку, це та правка, яку варто зробити перед підтвердженням, без винятків. По-друге, вони плутають встановлюваний застосунок з побудовою на фреймворку, тому що обидва відчуваються як "застосунок" у побутовому розумінні. Вони не взаємозамінні: встановлюваний застосунок підходить для інструменту, де весь стан зберігається на пристрої користувача — калькулятор чайових, таймер тренувань. Побудова на фреймворку означає більше інтерактивності та компонентної структури, але все ще нічого не зберігається на сервері між сеансами чи пристроями. Жоден з них не є "застосунком" у сенсі наявності облікових записів і даних, які супроводжують вас на різних пристроях — тільки серверна підтримка це забезпечує. І надмірне забезпечення серверною підтримкою "про всяк випадок" для сайту-портфоліо чи сторінки документації теж не безпечний вибір — пониження пізніше є такою ж переробкою, як і підвищення.
Що залишається, коли ви перестанете робити ці три речі
Коли ви перестанете проглядати рядок типу продукту побіжно, писати технічне завдання на етапі планування і ставитися до формулювань про облікові записи/дані/платежі у власному запиті як до необов'язкових, залишається швидка, вузька перевірка:
- Прочитайте тип продукту.
- Звірте його з вашим запитом.
- Перегляньте список виведених функцій на предмет чогось, що ви б відразу відхилили.
Цей список існує саме тому, що запит на кшталт "інструмент запису для перукарень" підтягує речі, які ви не вводили — вигляд календаря, SMS-нагадування та список клієнтів, деякі з яких ви мали на увазі, а деякі — розповзання обсягу, додане моделлю, бо ці функції статистично поєднуються. Обріжте зайве одним реченням тут, замість того щоб робити це після побудови.
Усе інше — текст, відступи, який відтінок акцентного кольору, чи каже кнопка "Почати" чи "Спробувати безкоштовно" — взагалі не на картці, навмисно. Це дешево побачити й виправити на робочій побудові, тому картка не витрачає на це вашу увагу, і вам також не варто. Це, можливо, п'ятнадцять секунд реального рішення в межах тридцяти секунд, потрібних для прочитання картки.
