Корисні discoveries про discovery-фазу проєкту: як її продати та ефективно провести

На зв’язку Андрій Сильчук, Delivery Director і голова центру розробки DataArt в Одесі, автор телеграм-каналу «Затишна Галера». Сьогодні поговоримо про discovery phase у проєкті.

Рекомендую почитати (та, сподіваюсь, вам буде корисно!), якщо ви берете чи плануєте взяти участь у sales-активностях або цікавитеся продажами в IT.

Time and material чи fixed price, і до чого тут discovery

Мої особисті спостереження: сьогодні дедалі менше клієнтів готові працювати у форматі T&M (Time and Material), коли вони оплачують роботу розробників погодинно за фіксованим рейтом. Здебільшого такі проєкти не несуть додаткових ризиків для виконавця, а залишають їх на стороні клієнта. Мрія, а не проєкти для delivery-менеджера!

Але останніми роками рейти українських IT-фахівців суттєво збільшились, плюс, через війну багато IT-фахівців мігрували до Європи і тепер доступні для найму в місцеві компанії на досить вигідних умовах — тому причин для подібних типів контрактів у клієнтів, зокрема європейських, залишається все менше.

Дедалі більше клієнтів хочуть працювати за fixed price, fixed scope, project with price cap, fixed budget та іншими fixed-проєктами, де клієнт має фіксований параметр, вихід за який є неприйнятним. Це може бути фіксований бюджет, строки виконання, обсяг робіт чи навіть комбінація кількох фіксованих параметрів.

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

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

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

Щоб зменшити ймовірність відвертого факапу, потрібно заздалегідь обмірковувати, як знизити ризики для себе й водночас зробити клієнту добре. Одним з таких інструментів, про який ми сьогодні й поговоримо, є discovery phase.

Що таке discovery phase і коли вона потрібна

Спроба підняти хайповість теми нашої розмови: запитаймо у 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-поїздки

Головне для вас з цієї події — отримати повне розуміння чотирьох речей:

  1. Бізнес-проблеми клієнта.
  2. Обсяг роботи.
  3. Часові й технічні обмеження.
  4. Потенційний бюджет на проєкт.

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

  • хочете максимально ефективно розв’язати проблему клієнта, а для цього вам потрібна відправна точка;
  • можете запропонувати декілька варіантів проведення проєкту — одразу повний, що покриває всі потреби, або розбитий на фази, як-от 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 презентацією, яка щодня обростатиме деталями на очах клієнта, а в останній день буде фіналізована.
👍ПодобаєтьсяСподобалось72
До обраногоВ обраному30
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Я маю 12 років досвіду участі в пресейлі, і більшість проектів були саме по fixed price моделі, із базових важливих ньюансів можу додати ще декілька пунктів =>

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

Є категорія клієнтів, коли для них звичайним є дуже наполегливо просити знижку, наприклад, це може бути знижка 5%, але потрібно бути готовим аргументувати чому це забагато та пропонувати нижку (наприклад 2-3%), ... для першого разу може бути win-win підхід, але для наступних потрібно враховувати, якщо це просто таке внутрішнє полісі в компанії для працівників, що працюють із підрядниками, то для такого клієнта закладувати певний % зверху для майбутніх торгів.

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

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

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

Дякую за додаток, та ви абсолютно праві, що однією статтею усі нюанси тут не розбіреш.

По такій моделі взаємовідносин деякі ризики гостріше вас повинні турбувати чим по T&M, а велика частина взагалі майже не турбувала у випадку T&M, але в підсумку від ефективності процесів буде залежати реальна маржинальність проекту, або загалом чи буде він прибутковим, .... тому якщо у вашому портфоліо дуже суттєво розростеться частина проектів по fixed pricе контрактах, то враховуючи, що ви відповідальні за делівері в крупній компанії, цікаво буте також прочитати, які зміни ви вносили в процеси, мається на увазі => ріпортінг, робота з ризиками, оформлення документації, а також комплектування команд і найм, etc. ...

Запропонуйте 50 000 із цих 500 000 витратити на те, щоб переконатись у можливості розв’язання бізнес-проблеми клієнта та фіналізувати, що саме буде у скоупі та в який термін ви вкладетесь.

Але ж по факту, це ніяк не вирішує біль клієнта, яка озвучена вище, а саме:

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

Чому ж не вирішує? Можливо домовитись з клієнтом за такий аналіз які фічі більш пріорітетні, що ми вкючемо у ці 500к, а що не включемо. Я вважаю, що сказати клієнту реальну картинку, що можливо зробити за 500к, можливо потасувати скоуп, можливо щось спростити, але запропонувати вирішення бізнес проблеми клієнту стоїть ціх коштів, а ніж підписатися просто під усі хотілки клієнта, а у кінці залишити його ні з чим та розчарованим. Але це тільки один із варінтів, я також казав про можливі інвестиції наприклад, якщо потецнійно це крутий клієнт. У IT нема алгоритму — роби так и будет круто, потрібно підстраюватись та знакодити win-win шляхи вирішення проблем.

Discovery вирішує багато проблем. наприклад, дозволяє зробити go / no go decision — так бувало. і краще клієнту витратити 50к та не йти далі, ніж витратити 250к і стопнути проект. Або дозволяє побачити різні опції і вибрати оптимальну згідно обмежень. Головне це своєчасно пояснити клієнту і бути максимально прозорим

Розчарувала стаття і показала прірву між продуктом і бадішопом. Discovery phase продукту дуже не проста штука по аналізу ринку, розуміння target customer і product design. І чесно кажучи хотів саме про них почитати

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

ДатаАрт давно не бодішоп. І ми маємо великий досвід в діскавері різного типу. Але ми все же сервіс компанія, клієнт в першу чергу відповідає за результати бізнесу. Тому далеко не завжди наше діскавері торкається аналізу ринку. При цьому ми завжди вимагаємо результати такого аналізу якщо вони релевантні. Так само про customer research. Є певні випадки, коли ми приймаємо участь в ціх активностях.
По-суті статті. Андрій, я би додав, що діскавері це продук в собі і його варто продавати як продукт, бо результат діскавері є певні deliverables, як наближають клієнта до розробки (були кейси передачі цих результатів іншому вендору).
В останні роки ми все ближче до продуктових активностей, і це піднімає вимоги до команди.
Андрій Сильчук, як ко-лід діскавері групи додам, що бажано на діскавері брати не звичайного аналітика, а діскавері експерта — людину з фокусом на такі активності і трохи іншою експертизою

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

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

Якраз на етапі Діскавері, можна довести рівень «невизначеності» проекта і конвертувати його в T&M, бо там менше фін ризиків.
Але з точки зору розвитку скілів управління проектами Fixed price — топ.

Діскавері, напевно, найцікавіший етап проекту, конкурентом йому може стати лише акцептанс стадія фіксед прайсу.

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

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

Підписатись на коментарі