Коротка відповідь
Технічний due diligence — це не код-рев'ю, і саме ставлення до нього як до код-рев'ю призводить до неправильної оцінки угод. Код-рев'ю запитує, чи добре написаний код. Технічний due diligence ставить інше, складніше питання: чи здатна ця інженерна організація та її продукт витримати те, що ви збираєтеся з ними зробити? Якщо теза угоди — «масштабувати це в 10 разів за клієнтською базою», диліджнс має перевірити, чи здатні архітектура і команда справді туди дійти. Якщо теза — «інтегрувати це в нашу наявну платформу», диліджнс має перевірити, чи готові кодова база, модель даних і люди до інтеграції. Якщо теза — «придбати й експлуатувати практично як є», диліджнс має перевірити, чи достатньо стабільне те, що під капотом, щоб працювати без фаундера-інженера, який тримає все вручну.
Більша частина реального ризику в софтверній угоді придбання чи фінансування не проявляється на демо. Вона ховається в категоріях, які покупці регулярно пропускають, бо не знають, що там варто дивитися: накопичений технічний борг, який непомітний, доки хтось не спробує викотити нову функцію; єдиний інженер, який один розуміє, як насправді працює білінгова система; архітектура, яку ніколи не документували, бо двоє людей, що її створили, ніколи не звільнялися; прогалини в безпеці чи комплаєнсі, які виринають лише тоді, коли хтось просить докази, а не запевнення. Ретельний технічний due diligence знаходить усе це до закриття угоди, а не після — у цьому й уся суть.
Сім категорій, які справді мають значення
Фреймворки технічного due diligence відрізняються від фірми до фірми, але суть зводиться до одного й того самого набору питань. Нижче — каркас, яким користуємося ми, згрупований у практичні блоки.
1. Відповідність стратегії та дорожньої карти
Перш ніж торкатися хоч рядка коду, диліджнс має перевірити, чи справді технічна дорожня карта підтримує бізнес-план, на якому побудована угода. У ціль можуть бути чудові інженери й чиста кодова база, і все одно це може бути неправильна ставка, якщо їхня дорожня карта передбачає переписування, яке з'їсть вісімнадцять місяців саме тоді, коли покупцю потрібне зростання. Це означає читати реальні документи з дорожньою картою (а не версію з піч-деку), говорити з керівництвом інженерії про те, що реалістично можна викотити в наступні два-чотири квартали, і звіряти це з таймлайном виручки чи інтеграції, закладеним в угоду. Невідповідність тут — це не сам собою червоний прапорець, а вхідні дані для ціноутворення й таймлайну.
2. Команда та організація
Софт створюють і підтримують люди, а люди — найменш ліквідний актив у будь-якій угоді придбання. Ця категорія охоплює розподіл навичок у команді (чи є реальна глибина в мовах і системах, які мають значення, чи експертиза сконцентрована в одній-двох людях), залежність від ключових людей (хто піде — і продукт перестане розвиватися, або, гірше, зламається так, що ніхто не зможе полагодити), а також ризик відтоку, пов'язаний саме з транзакцією. Інженери, які приєдналися до стартапу заради опціонів і автономії, часто мають реальні причини піти після закриття угоди, а втрата двох-трьох людей, які тримають інституційні знання про незадокументовані системи, може тихо стерти суттєву частку вартості угоди вже протягом першого року. Серйозний диліджнс зіставляє оргструктуру не лише з чисельністю персоналу, а й із власністю на системи.
3. Архітектура ПЗ
Це категорія, про яку більшість людей думає, що диліджнс — це виключно вона, і вона справді важлива, але сама по собі недостатня. Тут йдеться про патерни проєктування, про те, чи система побудована для масштабування в напрямку, який справді потрібен покупцю (більше користувачів, більше обсягу даних, більше одночасних тенантів — це різні задачі масштабування), і, що критично, скільки технічного боргу накопичилося і де він сконцентрований. Борг є в кожній кодовій базі. Питання, на яке має відповісти диліджнс, — чи цей борг усвідомлений і керований, чи невидимий і зростаючий. Система з відомими, задокументованими спрощеннями — керований ризик. Система, де ніхто не може впевнено сказати, що станеться, якщо торкнутися модуля звірки платежів, — це вже зовсім інший тип ризику.
4. Зрілість інфраструктури та DevOps
Тут йдеться про співвідношення хмари та власних серверів, про те, як насправді відбуваються деплойменти (вручну, ситуативно і залежно від конкретної людини — чи автоматизовано й відтворювано), і про аварійне відновлення — не про те, чи існує план DR на папері, а про те, чи його хоч раз тестували. Диліджнс має вимагати доказів реальних навчань з відновлення, реальних логів деплойментів і реальних трендів витрат на інфраструктуру, а не лише архітектурних діаграм. Компанія, яка деплоїть, підключаючись по SSH до продакшн-сервера в п'ятницю ввечері, повідомляє вам дещо важливе про операційний ризик — незалежно від того, наскільки добре продукт виглядає на демо.
5. Якість продукту та тестування
Цифрами покриття тестами в дата-румах жонглюють постійно, і це один із найбільш оманливих показників у всьому процесі. Реальне питання не «чи є відсоток покриття», а який саме тип покриття існує і чи охоплює він шляхи, важливі для бізнесу. Беклог багів також розповідає свою історію: його розмір має менше значення, ніж вік і розподіл за критичністю. Беклог із 400 низькопріоритетних косметичних проблем — зовсім інший сигнал, ніж беклог із 40 задач, три з яких — баги цілісності даних, що висять відкритими вже рік, бо ніхто не хоче торкатися модуля, в якому вони живуть.
6. Безпека та комплаєнс
Ця категорія отримує дедалі більшу увагу в кожній угоді останніми роками, і не без причини. Диліджнс має розглянути реальні політики безпеки (а не документ політики, написаний один раз і ніколи не оновлюваний), історію вразливостей та інцидентів, а також те, чи має ціль — або чи потребує — комплаєнс-фреймворки, релевантні для її ринку — SOC 2, GDPR, PCI DSS, HIPAA, залежно від того, хто клієнти. Попередній злам не обов'язково дискваліфікує угоду, але прихований злам або злам без задокументованого усунення — це вже зовсім інша розмова. Покупці мають прямо запитувати, чи траплявся коли-небудь інцидент безпеки, і вимагати звіт про інцидент, а не просто усне запевнення, що «нічого серйозного не сталося».
7. Права власності на IP та готовність до carve-out
Це категорія, яку пропускають найчастіше і яка спричиняє найдорожчі несподіванки. Диліджнс має встановити, з реальною документацією, що компанія справді володіє кодом, який продає — що угоди про передачу прав на IP з підрядниками та колишніми співробітниками існують і підписані, що жодні зобов'язання з ліцензій відкритого коду (зокрема, copyleft-ліцензії) непомітно не «прилипли» до пропрієтарного коду так, щоб створювати обов'язки розкриття інформації, і що технологію справді можна відокремити самостійно, якщо її потрібно виокремити з материнської компанії чи платформи. Кодова база, глибоко переплетена з внутрішньою інфраструктурою продавця, яку неможливо розділити без місяців розплутування, — це реальна вартість інтеграції, яку потрібно закласти в ціну угоди, а не виявити вже після підписання.
Технічний борг — це важіль оцінки вартості, а не лише інженерне питання. Борг, знайдений під час диліджнса, отримує ціну — у вигляді коригування ціни угоди, ескроу-утримання чи пункту про усунення проблем після закриття, прописаного в угоді. Продавці, які самі проводять аудит до виходу на ринок і виправляють або хоча б документують знайдене, ведуть переговори з суттєво сильнішої позиції, ніж ті, хто дозволяє команді диліджнсу покупця знайти це першою.
Що покупці припускають — і що насправді виявляється
Розрив між тим, що показують у пітчі, і реальністю настільки стабільний від угоди до угоди, що його варто викласти прямо.
| Категорія | Що покупці зазвичай припускають | Що насправді виявляється |
|---|---|---|
| Покриття тестами | Покриття існує і відображає реальну впевненість у системі | Покриття високе на юніт-тестах і майже нульове на інтеграційних і наскрізних тестах, які справді могли б виявити продакшн-інцидент |
| Документація | Документація з архітектури та онбордингу десь є у вікі | Документація застаріла, описує попередню версію системи або ніколи не існувала, бо двом інженерам-засновникам вона була не потрібна |
| Стійкість команди | Будь-який компетентний інженер зможе розібратися в кодовій базі | Одна-дві людини тримають незадокументовані знання про критичні підсистеми, без плану наступності |
| Використання відкритого коду | Сторонній код незначний і добре контрольований | Десятки залежностей без відстежених ліцензійних зобов'язань, деякі — на умовах copyleft, які ніхто не перевіряв |
| Стан безпеки | Впроваджено стандартні практики | Немає формального процесу реагування на інциденти, а останній реальний перегляд безпеки був неформальним або відбувся роки тому |
| Технічний борг | Керований і приблизно такий, як у будь-якого стартапу | Сконцентрований у невеликій кількості ключових модулів, яких команда свідомо уникає торкатися |
SBOM і ланцюг поставок ПЗ: запит диліджнсу, який тепер став стандартним
Запит, який раніше залишали для оборонних підрядників і жорстко регульованих галузей, тепер став майже стандартом технічного due diligence: специфікація складу програмного забезпечення (SBOM). SBOM відповідає на питання, яке звучить просто, але таким не є — який саме опенсорсний і сторонній код насправді міститься в цьому продукті, аж до версії й ліцензії кожної залежності. Без нього покупець просто вірить продавцю на слово, а фраза «ми не впевнені, треба перевірити» — не та відповідь, яку хтось хоче почути за три тижні до закриття угоди.
Саме таку прогалину закриває наша робота з захисту ланцюга поставок ПЗ — як для продавців, що готуються вийти на ринок, так і для покупців, яким потрібна незалежна оцінка перед підписанням. Формування точного SBOM, виявлення конфліктів ліцензій та ідентифікація компонентів із відомими вразливостями — це обмежене, чітко окреслене завдання, і виконати його до угоди набагато дешевше, ніж виявити ліцензійну міну вже після того, як чорнило висохло. Якщо аудит виявляє кодову базу, яка справді застаріла або архітектурно зайшла в глухий кут, — це вже окрема, хоч і пов'язана розмова, і зазвичай саме тут у гру вступає модернізація legacy-систем: усунення того, що знайшов диліджнс, а не просто його документування.
Як проходить сам процес
Реальний технічний due diligence поєднує огляд документації, доступ до коду й інфраструктури, структуровані інтерв'ю з керівництвом інженерії та вибіркою окремих розробників, а також практичну перевірку — реальну спробу відтворити деплоймент, реальний перегляд вибірки кодової бази, а не довіру до підсумкового звіту, реальну перевірку того, чи тестувався план аварійного відновлення. Результатом має бути письмовий звіт із висновками, ранжованими за критичністю, і, в ідеалі, оцінкою вартості й часу усунення для всього, що суттєво впливає на тезу угоди. Цей звіт стає прямим вхідним параметром для ціни покупки, структури угоди або рішення відмовитися від неї — саме тому він має з'являтися достатньо рано в процесі, щоб реально впливати на будь-який із цих важелів.
Готуєтеся до раунду фінансування чи продажу?
Незалежно від того, ви покупець, який хоче побачити реальну картину, чи продавець, який хоче знати, що знайде диліджнс, перш ніж це знайдуть за вас, — незалежний технічний аудит змінює хід переговорів.
Часті запитання
Хто має проводити технічний due diligence — власні інженери покупця чи зовнішня компанія?
В ідеалі — обоє, але з різних причин. Внутрішні інженери розуміють, як ціль інтегруватиметься з наявними системами, і можуть помітити проблеми сумісності, які пропустить сторонній фахівець. Незалежна компанія приносить неупереджений погляд, досвід із багатьох попередніх диліджнс-проєктів і, що важливо, не має стимулу ні автоматично схвалювати угоду, яку хоче закрити її власне керівництво, ні захищати кодову базу, яку вона сама не створювала. У більшості серйозних угод залучають обох.
Скільки часу займає повноцінний технічний due diligence?
Для невеликої або середньої софтверної компанії ретельна перевірка зазвичай займає від двох до чотирьох тижнів після надання доступу до коду, інфраструктури та ключових людей. Більші або складніші цілі, або ті, що мають кілька продуктових ліній і власні придбані компоненти, можуть зайняти шість тижнів і більше. Стиснення цього терміну заради жорсткого дедлайну угоди — один із найпоширеніших способів пропустити серйозні проблеми.
Яка найпоширеніша знахідка, що зриває угоду?
Нерозкрита залежність від ключових людей у поєднанні з поганою документацією. Угоду рідко вбиває одна катастрофічна помилка в коді — частіше виявляється, що вся система залежить від інституційних знань однієї-двох людей, які не зобов'язані залишатися після закриття угоди, і ці знання ніде й ніколи не були записані.
Це стосується лише угод придбання чи також раунду Series A?
Це стосується набагато раніших етапів, ніж очікує більшість фаундерів. Інвестори раундів Series A та B дедалі частіше проводять полегшений технічний диліджнс перед переказом коштів, зосереджений на масштабованості архітектури, ризику ключової людини та тому, чи здатна дорожня карта підтримати план зростання, який фінансує раунд. Зазвичай це не так глибоко, як диліджнс на етапі придбання, але застосовуються ті самі категорії, просто з меншою інтенсивністю.