Андрій керує логістичним бізнесом, що зростає. Таблиці працювали, поки не перестали. Він забронював discovery call зі software-командою — тридцять хвилин у календарі — і раптом зрозумів, що не впевнений, що казати. Чи варто приносити повну специфікацію? Mood board? Список конкурентів довжиною з роман?
Discovery calls провалюються тихо, коли обидві сторони йдуть ввічливо, але незрозуміло. Підрядник здогадується щодо скоупу; засновник відчуває, що його не почули. Ніхто не скаже, що дзвінок пройшов погано — не буде суперечки, не буде жодного red flag — але через три тижні пропозиція, що приходить у пошту засновника, звучить загально, оцінка — це широкий діапазон, а наступний дзвінок знову починається з нуля. Коротка підготовка вирішує більшість цього — і забирає менше часу, ніж здається більшості засновників.
Почніть з результату, а не зі списку функцій
Замініть «нам потрібен застосунок з дашбордами, сповіщеннями та AI» на одне речення про те, що має бути правдою за три місяці:
- «Диспетчери призначають маршрути менш ніж за дві хвилини замість двадцяти.»
- «Пацієнти клініки бронюють і платять без дзвінка на ресепшн.»
- «Торгові представники бачать актуальні залишки під час візитів до ритейлерів.»
Це речення стає якорем для кожного наступного питання. Якщо запропонована функція йому не служить — вона належить до пізнішого релізу або взагалі не потрібна.
Це має більше значення, ніж здається на перший погляд, бо саме списки функцій — те місце, де discovery calls найчастіше «вмирають». Список бажаної функціональності показує підряднику, що ви бачили в інших продуктах, а не те, що насправді потрібно вашому бізнесу. Двоє засновників можуть принести майже однакові списки — auth, dashboard, сповіщення, платежі — і при цьому будувати зовсім різні продукти під капотом, бо одному треба скоротити ручний процес з двадцяти хвилин до двох, а іншому — перестати втрачати клієнтів на checkout. Речення-результат одразу виводить цю різницю на поверхню, ще до того, як хтось витратить час на дизайн екрана, який насправді не вирішує реальну проблему.
Воно також дає підряднику привід посперечатися — і це корисно. Хороша інженерна команда має вміти подивитися на ваш результат і сказати «це реально за шість тижнів у тоншій версії» або «це вимагає інтеграції, яку варто спершу оцінити окремо». Список функцій рідко викликає таку прискіпливість — його просто оцінюють, фічу за фічою, і саме так засновники отримують кошторис на систему, яку насправді ніхто не просив будувати повністю.
Назвіть користувачів і їхній найгірший день
Загальні персони марнують час. Опишіть одного основного користувача та момент, коли ваш продукт його рятує:
Хто вони? Що сьогодні спричинило потребу? Що вони роблять зараз замість цього (WhatsApp, Excel, папір)?
Команди, які відповідають на це чітко, отримують реалістичні оцінки. Команди, які це пропускають, часто дізнаються в середині розробки, що «адмін» і «кінцевий клієнт» потребують зовсім різних флоу.
Пастка тут непомітна, але коштовна. Легко описувати свій продукт зсередини — як систему з ролями та правами доступу — і забути, що реальна людина, яка відкриє його у вівторок вдень, має проблеми з сигналом, три інші вкладки відкриті й тридцять секунд терпіння. Назвати найгірший день, а не ідеальний, — це те, що робить скоуп реалістичним. «Диспетчер призначає маршрут» — абстрактна вимога. «Диспетчер говорить по телефону з розлюченим клієнтом, треба перенаправити водія менш ніж за хвилину, стоячи на складі з однією вільною рукою» — це вже дизайн-обмеження. Друга версія змінює, що будується першим, а часто — і вибір платформи.
Варто також чесно сказати, якщо у вас є кілька типів користувачів, однаково важливих — наприклад, внутрішня операційна команда та зовнішній клієнт. Це нормально, але скажіть про це вголос, а не дайте підряднику припустити один флоу за замовчуванням. Мета точного опису користувачів — не створити відполіровану персону-документ, а не дати команді проєктувати продукт під уявного «середнього користувача», який ні на кого реального не схожий.
Принесіть обмеження на початку — це подарунок
Діапазон бюджету, цільове вікно запуску, обов'язкові інтеграції (Stripe, HubSpot, legacy ERP) та compliance (GDPR, PCI, медичні дані) — не незручні теми. Це фільтри, що запобігають марній дизайн-роботі.
Точні цифри не потрібні. «Нам потрібно щось live до конференційного сезону в Q4» або «Ми не можемо зберігати дані карток самостійно» — достатньо, щоб сформувати архітектуру вже на першому дзвінку.
Іноді засновники приховують обмеження з невиразного відчуття, що відкритий бриф отримає амбітнішу відповідь, або що названий бюджет спонукає підрядника оцінити роботу саме під нього. На практиці відбувається протилежне. Без обмежень підрядник змушений проєктувати під максимально можливу версію продукту, бо в нього немає сигналу, що можна відрізати. Ця максимальна версія довше оцінюється, дорожче кошторисується чесно, і зазвичай далі від того, що вам реально потрібно для першого релізу. Заявлене обмеження — навіть приблизне — дозволяє компетентній команді одразу відкинути цілі категорії архітектурних рішень і почати пропонувати те, що ви справді зможете запустити.
Те саме стосується compliance. Сказати «тут медичні дані» або «нам потрібен PCI-compliance для зберігання карток» на першому дзвінку, а не на п'ятому, змінює технічну форму всього білда — іноді це означає використання хостованого payment provider замість кастомного checkout, іноді — зовсім інший регіон хостингу. З'ясувати це вже коли дизайн наполовину готовий — один з найпоширеніших і водночас найлегше уникних джерел переробок у software-проєктах.
Покажіть те, що вже маєте
Наявні матеріали прискорюють discovery:
- Wireframes або посилання на Figma — навіть чернеткові
- URL поточного сайту або застосунку
- Експорт таблиці, на якій сьогодні тримається бізнес
- Список того, що зламалось минулого кварталу
Некрасива правда краща за відполіровану вигадку. Інженери дізнаються більше з неохайного операційного флоу, ніж зі слайду з написом «seamless experience».
Таблиця зокрема недооцінена як артефакт discovery. Робоча таблиця, якою б хаотичною вона не була, кодує реальну бізнес-логіку — стовпці, якими ніхто не користується, ті, що щомісяця отримують ручне перевизначення, вкладку, яку розуміє лише одна людина. Це інформативніше за документ з вимогами, бо показує, що бізнес насправді робить, а не те, що хтось пам'ятає чи хоче стверджувати. Якщо засновнику соромно за те, наскільки неохайно виглядає поточний процес, — це зазвичай ознака, що підряднику треба це побачити, а не привід це ховати.
Попросіть явні non-goals
Найкращі результати discovery включають те, чого v1 не робитиме. Без мультимовності, без конструктора кастомних звітів, без нативного десктопного застосунку — зафіксовано та погоджено.
Non-goals захищають обидві сторони. Засновники уникають розширення скоупу; підрядники уникають кошторису продукту, який ніколи не планувався до першої фази.
Non-goals — це також те місце, звідки насправді походить більшість пізніших суперечок у проєкті, бо спочатку це були зовсім не суперечки — а припущення, що тихо розійшлися. Засновник вважає, що мультимовність очевидно входить у «запуск», бо його ринок двомовний; підрядник вважав це приємним бонусом фази два, бо ніхто не сказав інакше. Жодна зі сторін формально не помилилася, але розрив виходить на поверхню на шостому тижні як розмова про скоуп, яку ніхто не хотів вести. Зафіксувати non-goals уже на першому дзвінку, навіть у чорновому вигляді, перетворює майбутню суперечку на рішення в теперішньому часі, яке обидві сторони можуть свідомо переглянути, якщо пріоритети зміняться.
З чим ви маєте піти
Корисний перший дзвінок завершується спільним розумінням, а не фіксованою ціною на місці. Очікуйте:
- Переформульовану проблему словами підрядника — ви маєте кивати, а не виправляти кожен рядок.
- Запропонований перший зріз — тонкий вертикальний шлях, а не весь roadmap.
- Відкриті питання — невідомості моделі даних, доступ до інтеграцій, відповідальність за дизайн.
- Наступний крок — follow-up воркшоп, письмове резюме або коротка письмова пропозиція з переліком припущень.
Якщо цих чотирьох пунктів немає — попросіть їх. Ясність — продукт discovery; код приходить пізніше.
До фіксованої ціни на тридцятихвилинному дзвінку варто ставитися радше з підозрою, ніж з полегшенням. Це зазвичай означає одне з двох: або підрядник видає шаблонну оцінку, яку використовує для будь-якого клієнта незалежно від того, що ви щойно описали, або суттєво накидає цифру, щоб покрити невідомі, про які ще навіть не встиг запитати. Обидва варіанти — погана ознака. Команда, яка натомість пропонує перший зріз — вузьку, реально будовану частину продукту, що перевіряє найризикованіше припущення, — показує, що має намір спершу навчитися на реальному використанні, перш ніж брати зобов'язання щодо решти roadmap. На дзвінку це звучить повільніше. На практиці — це швидший шлях до робочого продукту.
Поширені помилки, що гальмують перший дзвінок
Кілька патернів трапляються достатньо часто, щоб назвати їх прямо:
- Готуватися не до того. Специфікація на сорок сторінок — це не підготовка, а заміна розмови, для якої, власне, і потрібен дзвінок. Десять хвилин по чотирьох розділах вище дають більше, ніж години спекулятивної специфікації.
- Ставитися до дзвінка як до питчу. Засновники іноді презентують свою ідею як готову візію, а не як проблему, яку варто вирішувати разом. Корисніша позиція ближча до робочої сесії: принесіть реальні обмеження, включно з тими, що роблять продукт менш вражаючим на вигляд.
- Пропускати «чому саме зараз». Що змінилося, через що саме цей місяць став тим, коли треба це вирішити? Раунд фінансування, сплеск відтоку, ручний процес, який нарешті зламався на масштабі — тригер показує підряднику, скільки в реальності runway, а це впливає і на скоуп, і на послідовність робіт.
- Не називати, хто ухвалює рішення. Якщо дизайн-напрямок мають погодити три стейкхолдери — скажіть про це одразу. З'ясувати це на четвертому тижні набагато дорожче, ніж згадати на п'ятій хвилині.
Жодна з цих речей не вимагає додаткової роботи, щоб її уникнути — вони вимагають сказати вголос правдиву, іноді невигідну річ замість акуратної версії.
У Stereasoft ми сприймаємо discovery як частину delivery, а не sales-ритуал. Засновники, які готують один результат, одну user story та чесні обмеження, майже завжди рухаються швидше — незалежно від того, будують вони з нами чи ні.