Корисні 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 презентацією, яка щодня обростатиме деталями на очах клієнта, а в останній день буде фіналізована.