Наш процес discovery — як 2 тижні економлять 6 місяців

IT-проєкти не вмирають під час впровадження. Вони вмирають на етапі визначення — просто цього не видно одразу, бо смерть повільна. Перші місяці всі пишаються демо, команда спалює story points, а KPI-дашборд світиться зеленим. Проблема випливає лише на шостому місяці, коли система торкається реального бізнес-процесу і виявляється, що вона вирішує не ту проблему. Або правильну проблему хибним способом. Discovery — це антидот. За умови, що його роблять добре.

За останні вісім років ми провели кілька десятків процесів discovery для компаній від 20 до 500 працівників. Закономірності повторюються з математичною регулярністю. Цей текст — дистиляція цих закономірностей у форму, готову до впровадження. Не теорія з підручника, а фреймворк, який за 10 робочих днів продукує бізнес-рішення.

Чому проєкти вмирають на етапі визначення

Клієнт FMCG (виробник сухофруктів і горіхів, ~180 осіб, оборот 90 млн PLN) прийшов до нас із брифом на новий CRM, бо «конкурент впровадив Salesforce, і нам теж треба». Бриф мав 14 сторінок вимог, скопійованих один в один із вебінару постачальника. Перше питання на kick-off: «які KPI має покращити цей CRM?». Відповідь: тиша, потім «ну… диджиталізацію». Це архетип першої причини — бриф, скопійований у конкурента. Ви копіюєте рішення, а не розумієте проблеми, яку воно вирішує. У результаті отримуєте систему, що виглядає як у конкурента, але не генерує тієї самої цінності, бо ніколи не була адаптована до вашої реальності.

Друга причина менш помітна з рівня правління: бриф виникає виключно на основі розмов із керівниками. Керівник відділу описує, як процес «має працювати». Працівник, який виконує цей процес по вісім годин щодня, знає, як він працює насправді — з workaround’ами, таблицями shadow IT, tribal knowledge, що ніде не задокументоване. Системи, спроєктовані виключно на основі розмов із керівниками, завжди описують фікцію. Впровадження стикається з реальністю на четвертому місяці, коли кінцеві користувачі починають UAT і кажуть, що «ми так не працюємо».

Третя причина: бізнес-ціль, заслонена списком функцій. Бриф містить 87 вимог, але жодне речення не описує, навіщо ця система виникає в категоріях P&L. Функція — це засіб, а не мета. Коли discovery не ставить питання «на скільки відсотків має зрости маржа / впасти витрати / прискоритися cycle time?», команда впровадження не має критерію пріоритизації. Кожна функція однаково важлива, проєкт пробиває бюджет, а правління не може оцінити, чи отримало те, чого хотіло, бо ніколи не визначило, чого хоче.

Наше визначення discovery — чим воно НЕ є

Discovery — це не воркшоп зі стикерами. Два дні в кімнаті з фліпчартом генерують емпатію в команді, але не продукують бізнес-рішення. Бізнес-рішення потребує даних — інтервʼю з 12-18 людьми, мапи процесу as-is з часовими та вартісними метриками, порівняння трьох архітектурних сценаріїв. Стікер не замінить аналіз TCO.

Discovery — це не технічний аудит. Технологічний аудит стосується того, що вже існує — якості коду, технологічного боргу, масштабованості поточної архітектури. Discovery стосується того, що має виникнути і чи взагалі має виникнути. Аудит відповідає на питання «як є?». Discovery відповідає на питання «що будуємо, навіщо, за скільки і з яким поверненням?». Це два різні процеси, часто плутані в брифах клієнтів.

Discovery — це не список вимог. Документ із 87 функціональних вимог — це продукт фази впровадження, а не фази визначення. Discovery продукує щось твердіше: рішення go / no-go / pivot з прогнозованою бізнес-цінністю, моделлю витрат TCO та аналізом альтернатив. Список вимог є наслідком цього рішення, а не його входом.

DoMoreSoft Discovery Framework — 5 фаз пояснено

Ми назвали фреймворк не тому, що любимо давати назви речам, а тому, що названий процес є відтворюваним. Неназваний процес вмирає разом із однією людиною, яка вміє його «робити». Пʼять фаз, десять робочих днів, двоє сеньйорів з боку Do More Soft (системний архітектор плюс процесний консультант), визначені deliverable’и наприкінці кожної фази.

Фаза 1 (дні 1-2): Stakeholder map та артикуляція проблеми

Перші два дні проводимо на розвідці поля бою. Stakeholder map відповідає на чотири питання: хто платить за рішення, хто його використовує, хто є його жертвою, хто має право вето. Ці ролі майже ніколи не збігаються в одній людині, а ігнорування будь-якої — найчастіша причина провалу проєкту.

З цього випливає конкретне операційне рішення: паралельно сідаємо з правлінням над артикуляцією проблеми та примушуємо відповісти на питання «як ми розпізнаємо, що проєкт був успішним?» у категоріях метрики P&L, а не списку функцій. Якщо на це питання немає відповіді за 48 годин, наступні фази не мають сенсу — discovery зупиняється і повертається до правління по рішення.

Output фази 1: stakeholder map із позначеними конфліктами інтересів, problem statement в одному абзаці, затверджені спонсором проєкту метрики успіху із цільовим значенням.

Фаза 2 (дні 3-5): Інтервʼю з користувачами — 12-18 людей у щонайменше 3 ролях

Три дні на індивідуальні інтервʼю. Не групові. Групові інтервʼю продукують консенсус, а консенсус приховує правду. Щонайменше три ролі: кінцевий користувач (людина, яка щодня працює із системою), менеджер (людина, яка звітує на основі системи) та зовнішній стейкхолдер (клієнт фірми, партнер, регулятор). Кожне інтервʼю триває 45-60 хвилин, має структурований скрипт і продукує транскрипт, розмічений під кутом pain point’ів, workaround’ів і прихованих процесів.

Output фази 2: база з 12-18 транскриптів із таксономією проблем, список top-10 болючок за частотою, мапа shadow IT (таблиці, приватні макроси, WhatsApp-групи, що заміняють процеси).

Фаза 3 (дні 6-7): Мапування процесів та ідентифікація вузьких місць

На основі інтервʼю будуємо мапу процесу as-is з метриками — скільки кроків, скільки часу на кожен крок, скільки точок ручного переписування даних, скільки точок прийняття рішень, скільки трансферів між системами. У цьому проєкті мапа as-is мала 47 кроків, мапа to-be — 12. Різниця між as-is та to-be — це бізнес-цінність проєкту, виражена в людино-годинах та операційних витратах. Паралельно використовуємо нашу методологію ідентифікації вузьких місць — 5 типів вузьких місць, від ручного переписування до over-reporting.

Output фази 3: діаграма процесу as-is з метриками, мапа to-be з ідентифікованими вузькими місцями, реєстр вузьких місць з оціненою річною вартістю кожного.

Фаза 4 (дні 8-9): Скетч архітектури та модель витрат

Два дні на бізнесову та технічну архітектуру плюс модель TCO. Архітектор готує три сценарії: build (розробка custom), buy (впровадження готового продукту з конфігурацією) та hybrid (готовий core плюс custom-модулі). Кожен сценарій має трирічну модель TCO — вартість впровадження, вартість підтримки, вартість технологічного боргу та прогноз масштабованості. Це не оцінки зі стелі. Це моделі, бенчмаркнуті на наших попередніх проєктах того самого класу.

Output фази 4: три архітектурні сценарії з діаграмою компонентів, трирічна модель TCO для кожного сценарію, аналіз ризиків впровадження з планом мітигації.

Фаза 5 (день 10): Звіт рішення з трьома сценаріями

Останній день — консолідація та презентація правлінню. Звіт рішення має структуру: problem statement, діагноз (мапа as-is, вузькі місця), три сценарії з рекомендацією, модель ROI/TCO на три роки, roadmap 90-денний і 12-місячний. Презентація триває 90 хвилин — 30 хвилин звіту, 60 хвилин дискусії та запитань правління. Наприкінці сесії запроваджується рішення: go, no-go або pivot. Якщо go — розпочинаємо фазу scoping і планування впровадження, методологією якої ділимося в MVP за 8 тижнів.

Output фази 5: звіт рішення (30-50 сторінок PDF), презентація executive summary, задокументоване і підписане рішення правління.

Що клієнт отримує наприкінці 10 днів

Список deliverable’ів завжди однаковий, бо ми консолідували його після кількох десятків discovery:

• Мапа процесів as-is і to-be з часовими та вартісними метриками кожного кроку.
• Реєстр вузьких місць з оцінкою річної вартості кожного.
• Три сценарії рішення (build / buy / hybrid) з трирічною моделлю TCO.
• Оцінка технологічного боргу існуючої системи, якщо клієнт уже має рішення.
• Аналіз прогалин у компетенціях команди — кого не вистачає для підтримки нового рішення.
• Рекомендована roadmap: 90-денний план (квартальні віхи) і 12-місячний план (стратегічні річні цілі).
• Звіт рішення з однозначною рекомендацією go / no-go / pivot.

Case: як 10 днів discovery врятували 6 місяців розробки

Клієнт із галузі FMCG — виробник і дистрибʼютор сушених фруктів та горіхів — прийшов до нас із брифом «нам потрібен новий CRM, поточний нас обмежує». Бриф мав 14 сторінок функціональних вимог. Замість того, щоб одразу оцінювати, ми запропонували 10 днів discovery. Інтервʼю з продавцями, працівниками складу та логістики виявили те, чого бриф не показував: справжня проблема була не в CRM, а в процесі потоку замовлень між відділом продажу, складом і логістикою. CRM працював — але кожне замовлення проходило через 4 ручних трансфери даних між системами, генеруючи затримки та помилки.

Рекомендація після discovery: pivot. Замість будівництва нового CRM за 6 місяців і 300 тис. EUR ми запропонували інтеграційний шар — модуль синхронізації між існуючими системами — за 8 тижнів і 85 тис. EUR. Впровадження описуємо в case study Terra та в наративній статті «Terra — від таблиць до системи». 10 днів discovery перевели проєкт з будівництва не того на розвʼязання правильної проблеми. Економія: шість місяців роботи команди і 215 тис. EUR нетто.

Чому 2 тижні, а не 2 місяці

Discovery може тривати як завгодно довго — знаємо компанії, що ведуть його по шість місяців. На практиці маргінальна цінність кожного додаткового дня падає експоненційно після десятого дня. У перші 10 днів ми відкриваємо 80% проблеми. Наступні 10 днів? Ще 15%. Це не думка — це закономірність із 50+ discovery, які ми провели в доменах від FMCG через automotive до SaaS.

Друга причина — культурна: закон Паркінсона каже, що робота розширюється до часу, який їй виділено. Розтягнуті на місяці дискусії продукують analysis paralysis, а не рішення. Жорсткі рамки 10 днів примушують до дисципліни пріоритизації — якщо щось не вміщується у 10 днів, воно не вміститься ніколи, бо не таке важливе, як здавалося. Команди, що мають два місяці на discovery, продукують 300-сторінкові звіти, яких ніхто не читає. Команди, що мають 10 днів, продукують 40-сторінковий звіт рішення, який правління читає за 45 хвилин і на основі якого приймає рішення.

ROI discovery — конкретна математика

Вартість discovery в моделі DoMoreSoft: 15-25 тис. EUR за 10 днів роботи двох сеньйорів. Вартість помилкового впровадження 6-місячного проєкту: 200-400 тис. EUR у бюджеті розгортання плюс opportunity cost — шість місяців, які бізнесова команда провела, спонсоруючи неправильний проєкт замість іншої ініціативи.

Break-even арифметика тривіальна. При проєкті впровадження з бюджетом 300 тис. EUR, discovery вартістю 20 тис. EUR окуповується, якщо дозволяє уникнути 6,7% помилкового scope. На практиці discovery скорочує scope на 15-30% (функції, що здавалися критичними, виявляються непотрібними після інтервʼю з користувачами) і знижує ризик повного провалу на порядки. Discovery завжди має позитивний ROI. Математика проти будь-якої альтернативи.

Наведені цифри можна перевірити на наших власних проєктах і case studies. Discovery Terra зекономило 215 тис. EUR. Discovery в проєктах для дилерських груп економило 120-380 тис. EUR на одне впровадження. Ми не знаємо жодного discovery, яке зрештою не окупило б себе в десяток разів.

Коли discovery непотрібне

Ми прихильники discovery, але не фанатики. Є три ситуації, в яких discovery є марнотратством грошей клієнта:

Перша: у вас уже є працюючий прототип із реальними користувачами та валідованою проблемою. Якщо ваш прототип має 200 активних користувачів, які платять за продукт, проблема вже валідована ринком. Наступна фаза — scoping і масштабування, а не discovery. Спроба зробити discovery після фази прототипу — дорога і надлишкова.

Друга: scope проєкту — одна послуга на існуючій платформі. Додавання звітного модуля до системи, яку ми вже знаємо, не потребує discovery. Потребує 2-3-денної сесії scoping та оцінки. Discovery — інструмент для складних проблем, а не для кожного тікета.

Третя: ви будуєте щось, що вже двічі будували в тій самій домені. Якщо як Do More Soft ми впровадили три CRM для automotive, четвертий впровадимо без discovery — маємо патерни процесів, патерни архітектури та патерни інтеграції. Discovery має цінність у дослідженні. Коли дослідження вже зроблено, наступне discovery — це театр.

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

Робимо це самі — наші власні продукти пройшли discovery

Легко казати клієнтам пити воду, а самому пити вино. Тому, будуючи власні продукти в моделі Venture Builder, кожен із них проходив внутрішнє discovery, перш ніж ми написали рядок коду. MoreSales — наш CRM/ERP для e-commerce — виник після трьохтижневого discovery з десятьма e-commerce-компаніями, які билися з тією ж проблемою. MyCarApp — платформа для automotive — виник після шести тижнів інтервʼю з дилерами, заводською логістикою та кінцевими клієнтами.

Кожен із наших 12 продуктів є доказом того, що discovery працює і на власному P&L. Якби ми пропускали discovery, сьогодні мали б 4 продукти замість 12 — бо решта впала б у перші шість місяців після запуску, не знайшовши ринку. Це не лицемірство «казати пити воду, а пити вино». Це skin in the game — використовуємо ту саму методологію, якої навчаємо клієнтів, і показуємо, що вона працює на нас.

Discovery як найвищий важіль ROI

Якщо ви CTO або founder, який планує проєкт вартістю 200 тис. EUR чи більше, питання не «чи робити discovery?», а «коли?». Відповідь: на самому початку, перш ніж буде написано перший рядок коду, перш ніж архітектор почне малювати діаграми, перш ніж PM почне складати backlog. Discovery — це 5-8% бюджету проєкту, які захищають решту 92-95% від помилкового розподілу.

Не знаєте, чи потрібне discovery вашому проєкту? Напишіть на office@domoresoft.com з темою «Discovery check» — 30 хвилин розмови достатньо, щоб разом вирішити, чи виправдається discovery, чи це один з трьох випадків, коли його можна пропустити. Якщо віддаєте перевагу структурованому формату, скористайтеся нашим конфігуратором — займе 4 хвилини. Обидва шляхи ведуть до тієї самої розмови, на якій вирішується, чи є сенс іти далі. Це перше рішення, яке варто прийняти свідомо, бо наступні вже залежать від нього.

FAQ — discovery в пігулці

Що означає процес discovery у software development?

Структурована фаза перед впровадженням, мета якої — не записати вимоги, а ухвалити бізнес-рішення: go, no-go або pivot. У моделі DoMoreSoft триває 10 робочих днів, охоплює 12-18 інтервʼю зі стейкхолдерами, мапування процесів as-is/to-be, три архітектурні сценарії і трирічну модель TCO.

Скільки коштує discovery порівняно з усім проєктом?

5-8% бюджету проєкту впровадження. При проєкті вартістю 300 тис. EUR discovery коштує 15-25 тис. EUR і окуповується, якщо дозволяє уникнути 6,7% помилкового scope. На практиці скорочує scope на 15-30%.

Чому 90% IT-проєктів падають без discovery?

Бо без discovery команда впровадження працює над хибною проблемою або над правильною проблемою хибним способом. Три архетипи: бриф, скопійований у конкурента, розмови лише з керівниками, бізнес-ціль, замінена списком функцій.

Чим discovery відрізняється від технічного аудиту?

Технічний аудит відповідає на питання «як є?» в існуючій системі. Discovery відповідає на питання «що будуємо, навіщо, за скільки і з яким поверненням?». У проєкті, що потребує і одного, і іншого, аудит є одним із входів до фази 3 discovery, а не його замінником.