Що таке discovery phase і коли вона потрібна
- Oleh Voroniak
- 18 січ.
- Читати 5 хв
Спроба підняти хайповість теми нашої розмови: запитаймо у ChatGPT, що таке discovery phase у розрізі розробки ПЗ.
Отже, версія ChatGPT:
«Discovery phase — це початковий етап у розробці програмного забезпечення, що полягає у вивченні потреб клієнта, визначенні вимог до проєкту, виробленні концепції та оцінці технічної реалізації проєкту.
Основна мета цієї фази — отримання повнішого розуміння того, що саме має бути розроблено, як це має бути зроблено та скільки часу й ресурсів знадобиться для цього».
Якщо чесно, це досить повний і непоганий опис. Дякую, ChatGPT. А тепер поділюсь реальним досвідом роботи з discovery phase.
Я дуже рекомендую спробувати домовитися з клієнтом про discovery phase у таких випадках:
Клієнт запитує чіткі таймлайни та вартість проєкту, але поточного рівня розуміння проєкту командою недостатньо для правильної оцінки з адекватним рівнем похибки.
Обсяг робіт, заявлений клієнтом, або запропонований ним спосіб виконання бізнес-завдання виглядають ненадійно, і вам бачиться потенціал простішого й релевантного рішення.
Проєкт буде розроблятися на основі великої кількості легасі-коду та вже розроблених систем і застосунків, досвіду роботи з якими команда не має.
Клієнт сам не цілком розуміє, що йому потрібно.
Якщо в якомусь із цих випадків команда підпишеться на виконання запитів клієнта без попереднього вивчення проєкту, ми ризикуємо не вкластись у дедлайн чи бюджет, завалити проєкт чи видати клієнту не те, що йому потрібно.
Хто є учасником discovery team
Для проведення discovery-фази проєкту витрати на неї мають бути якомога нижчими (про це — трохи згодом), тому й команда має бути мінімальною. Майже завжди потрібні:
Solution Architect або Technical Architect — людина-оркестр. І проаналізувати поточний код із застосунками допоможе, і roadmap з естімейтами складе, і технічне рішення запропонує, і обґрунтувати його зможе.
Business Analyst — колега, здатний вловити та стисло законспектувати суть величезного потоку інформації від команди клієнта за обмежений термін, та допомогти команді з правильним формулюванням і розумінням бізнес-проблеми замовника.
Delivery Manager — досвідчений колега, який вміє правильно поводитися з клієнтом, підтримати діалог і красиво сформулювати продаж. Виконує роль драйвера команди, може направити (або повернути) колег на конструктивну роботу. Має досвід роботи з контрактами, грошовою складовою проєкту та може відповідати за фінальні домовленості з клієнтом.
За потреби можна розширити команду додатковими ролями, пов’язаними зі специфікою запиту від клієнта:
UX/UI Designer, якщо проєкт більше пов’язаний з зоною відповідальності UX/UI.
QA Lead, якщо проєкт має велику потребу в тестуванні або пов’язаний виключно з цією сферою.
DevOps Expert, якщо суть проєкту — про інфраструктуру.
Project Manager — корисне доповнення до будь-якої команди, майстер на всі руки. Він візьме на себе координацію, комунікацію та рутинні завдання. Плюс, зуміє і повернути архітектора на правильний шлях, якщо щось піде не зовсім за планом, і підтримати BA, коли зайде мова про бізнес, і про компанію загальну інформацію розповість.
Формати discovery-фази
Discovery phase можна провести в одному з двох форматів:
Цілком remote — простіше, дешевше, швидше, але за моїм досвідом, набагато менш продуктивно.
З onsite-поїздкою до клієнта — завжди, у будь-якому випадку набагато продуктивніше за remote. Вся команда 100% часу занурена в роботу з клієнтом, а особисте знайомство з ним і, можливо, кілька годин разом у неформальних обставинах значно підвищують його прихильність до команди.
Тому за інших рівних, я б наполегливо рекомендував використовувати onsite. На ньому й зупинюся детальніше.
Цілі та етапи onsite-поїздки
До самої поїздки важливо добре підготуватися.
Вивчіть максимально можливу кількість доступних матеріалів про потенційний проєкт і бізнес-клієнта.
Підготуйте список питань для поїздки та адженду — її важливо побудувати так, щоб отримати від клієнта і його команди максимальну кількість інформації у стислий термін. Найкраще спланувати мітинги так, щоб на якихось із них максимально активною була команда клієнта, а на інших — ваша команда проявила себе і справила незабутнє (тільки позитивне!) враження на клієнта.
Переконайтеся, що всі люди, необхідні для цього, будуть доступні та з ними призначені мітинги.
Вивчіть усіх стейкхолдерів — запам’ятайте їхні імена, позиції всередині структури, зони відповідальності. Буде дуже незручно, якщо ви розшарите екран, де будуть неправильно написані чиїсь імена або посади.
Забронюйте й затвердіть з клієнтом дати приїзду, від’їзду, готелі та інші важливі для подорожі моменти.
Завчасно вивчіть і обміркуйте культурні особливості. Іноді можна ідеально провести технічну частину, але потрапити в халепу на останній вечері з клієнтом, сказавши або зробивши щось зовсім недоречне.
Мета onsite-поїздки
Головне для вас з цієї події — отримати повне розуміння чотирьох речей:
Бізнес-проблеми клієнта.
Обсяг роботи.
Часові й технічні обмеження.
Потенційний бюджет на проєкт.
На жаль, останній пункт не завжди можна здійснити (найчастіше клієнт спочатку чекатиме пропозиції від вас), але іноді найпростіший і найправильніший спосіб — чесно запитати клієнта про його бачення бюджету. Запитання важливо правильно сформулювати, пояснивши, що ви:
хочете максимально ефективно розв’язати проблему клієнта, а для цього вам потрібна відправна точка;
можете запропонувати декілька варіантів проведення проєкту — одразу повний, що покриває всі потреби, або розбитий на фази, як-от POC, MVP та інші.
У моїй практиці дуже часто за правильної постановки запитання клієнти чесно озвучували свої бюджетні очікування.
Onsite-поїздка — ще не кінець discovery. Після поїздки потрібно фіналізувати всі знахідки та надати клієнту обіцяні delivery. Тому далі продовжуємо тісне співробітництво з клієнтом вже в онлайн-форматі.
На цьому етапі важливо:
не втратити напрацьований зв’язок із клієнтом;
показувати прогрес demo;
вести переговори, підтримуючи рівень зацікавленості;
та, звісно, підготувати зі свого боку все обіцяне клієнту.
Як продати discovery phase
Клієнти мають дві основні версії відмови від купівлі discovery phase:
Навіщо платити за те, щоб мені зробили робочу пропозицію? Хочете зі мною працювати — чекаю на вашу пропозицію, але платити за її підготовку я не буду.
А що як зараз я заплачу кілька десятків тисяч, а потім мені скажуть, що проєкт триватиме роки й коштуватиме мільйони? Або, ще гірше, — що не візьмуться його робити.
Обидва ці страхи є цілком валідними, але з ними можна працювати.
Якщо клієнт точно має гроші та готовий вкласти їх у проєкт, може, така discovery phase варта невеликих інвестицій з вашого боку? Наприклад, ваша компанія може сама цілком або частково покрити discovery, а клієнт принесе в рази більше грошей та окупить цю інвестицію.
Якщо клієнт не готовий на повну оплату discovery, спробуйте запропонувати йому зробити такий проєкт із мінімальною маржею або за собівартістю. Це покаже клієнту, що ви зацікавлені у співпраці та знизить рівень його тривоги.
Іноді можна домовитись, що discovery phase буде частиною основного проєкту. Наприклад, клієнт приходить і каже: «Я маю 500 000, зробіть мені добре». Запропонуйте 50 000 із цих 500 000 витратити на те, щоб переконатись у можливості розв’язання бізнес-проблеми клієнта та фіналізувати, що саме буде у скоупі та в який термін ви вкладетесь.
У моїй практиці така змішана система продажу дуже часто приносить плоди. Зазвичай discovery не займає великий шматок бюджету проєкту, а ви відразу працюєте з клієнтом у парадигмі великого проєкту та у підсумку отримаєте досить структурований обсяг роботи на бюджет, що залишився.
Скільки триває discovery phase
Тривалість залежить лише від здорового глузду і складності досліджуваних вхідних даних. Найчастіше це 2–6 тижнів.
Нагадаю, що ця фаза не має обходитися клієнту або вам задорого, але водночас, що більше на неї буде витрачено, то детальніші підсумки можна буде отримати й точніше спланувати основну фазу проєкту.
На що ще звернути увагу
Насамкінець хочу поділитися кількома порадами стосовно onsite-частини discovery- фази, якими користуюсь і сам.
Починайте кожен день onsite-візиту із закріплення пройденого за минулий день. Можливо, в когось за ніч виникнуть додаткові запитання.
Закінчуйте кожен день невеличким summary. Затверджуйте з клієнтом, що ваше і його бачення пройденого є однаковим.
Використовуйте якнайбільше інтерактиву з клієнтом: брейншторм-сесії на задану тему з білою дошкою, побудова роадмапів і пріоритезація завдань, демо та воркшопи. Більше залучення до спільних активностей — сильніший зв’язок.
Намагайтеся дивувати. Наприклад, привезіть із собою готові напрацювання, щодо яких клієнт наперед буде не в курсі. Протягом дня оновлюйте та готуйте презентації, наприклад, плани на наступний день і summary поточного, а наприкінці та на початку дня шарте їх на екрані для клієнта. Буде круто, якщо ви спочатку приїдете з якоюсь work-in-progress презентацією, яка щодня обростатиме деталями на очах клієнта, а в останній день буде фіналізована.
Джерело:
Коментарі