Чеклистът е полезен само ако към всяка точка има закачена последица. Този е подреден по онова, което наистина променя сделката.
Собственост и зависимости
Продукт и експлоатация
Поправка и решение
Използвайте това като работен документ по време на проверката. Всеки раздел казва какво да поискате, какво да проверите и — най-важното — какво означава търговски един лош отговор. Точките са подредени по цена на грешката, а не по удобство на проверката.
Преди да започнете: какво да поискате
- Достъп за четене до всички хранилища, включително infrastructure-as-code
- Пълна история на комитите (не сплескана снимка — историята показва кой наистина е построил това и колко бързо)
- Преглед на архитектурата с инженера, който я е строил, 1-2 часа
- Достъп до тракера на задачи и до всякакви записи за инциденти
- Списък с услуги на трети страни и договорните им условия
- Договори с изпълнители и документи за прехвърляне на IP
Раздел 1 — Цялост на парите и данните (ниво сделка)
| Проверка | Лош отговор означава |
|---|---|
| Салдата се извеждат от журнал само за добавяне? | Парите може да са беззвучно грешни и невъзстановими — финансирайте отстраняване или се откажете |
| Ключове за идемпотентност по всеки платежен път? | Повторенията може да задължат два пъти; загуби вече може да съществуват незасечени |
| Парите се пазят като цели числа в минорни единици? | Аритметиката с плаваща запетая натрупва грешка при всяка транзакция |
| Равнение спрямо сетълмента на доставчика? | Разминаванията излизат наяве чрез оплаквания на клиенти |
| Неизменна одитна следа вкл. административните действия? | Няма как да се отговори на регулатор или при спор |
Раздел 2 — Сигурност и многонаемателност (ниво сделка)
- Оторизацията се налага на сървъра при всяка заявка, а не чрез скриване на елементи от интерфейса
- Изолацията на наематели е потвърдена с тест, а не предположена от четене на кода
- Тайните са в мениджър и липсват от историята на git (проверете историята, не само HEAD)
- Какви регулирани данни се съхраняват, къде и дали изобщо е нужно
- Разстояние до сертификацията, която изисква go-to-market (SOC 2, ISO 27001, PCI DSS)
Раздел 3 — Собственост и правни въпроси (ниво сделка)
- Подписано прехвърляне на IP от всеки изпълнител и основател
- Преглед на лицензите на open source — копилефт замърсяване в затворен продукт
- Код, копиран от предишни работодатели (питайте директно; случва се)
- Обвързаност с доставчик: какво се чупи, ако ключов доставчик промени цените или затвори
Раздел 4 — Архитектура и мащаб (висок)
- Къде системата се чупи при растежа от финансовия модел — конкретно число, а не успокоения
- Таванът на слоя данни: единствен master за запис, неограничени заявки, покритие с индекси спрямо реалните модели на заявки
- Изолация на отказите: прераства ли една бавна зависимост в пълна авария
- Крива на инфраструктурните разходи при 10× — оцелява ли unit economics
- Архитектура, съответстваща на размера на екипа (разпределени системи при малък екип са разход, а не заслуга)
Раздел 5 — Способност за доставяне (висок)
| Сигнал | Здравословно | Тревожно |
|---|---|---|
| Честота на разгръщанията | Няколко пъти седмично | Месечно, по график, със страх |
| Време за доставяне на малка промяна | Часове до един ден | Седмици |
| Rollback | Една команда, репетирана | Никога не е тестван |
| Откриване на инциденти | Вътрешен мониторинг | Сигнали от клиенти |
| Тестове по пътищата на парите/auth | Налични | Липсват независимо от общото покритие |
Раздел 6 — Екип и риск от ключов човек (висок)
- Bus factor на всяка критична подсистема — ако някъде е 1, това е риск за сделката, който изисква смекчаване
- Дали знанието съществува писмено, или само в главите
- Експозиция по задържане: чиято загуба през следващите 12 месеца би била катастрофална
- Реализъм на плана за наемане, който пътната карта предполага
Оценяване: последица, а не вкус
Оценявайте всяка констатация по това какво ще стане, ако не бъде поправена, и оставете това да определи реакцията по сделката:
- Ниво сделка — цялост на парите, изтичане на данни, неясно IP. Условие за приключване или финансирано отстраняване.
- Висок — таван на мащабиране под плана, зависимост от един човек, липса на безопасност при разгръщане. Остойностено в 90-дневния план след приключване.
- Среден — натрупващ се дълг, който забавя доставянето. Отбележете и наблюдавайте.
- Шум — стил, предпочитание за фреймуърк, обем на документацията. Изключете напълно от доклада.
Ако констатация не може да бъде вързана към пари, време или правна експозиция, тя няма място в инвестиционен меморандум.
На какво да настоявате във финалния доклад
- Едностранично резюме, по което нетехнически партньор може да действа
- Всяка констатация с доказателство, което екипът на целта може да провери самостоятелно
- Оценки за отстраняване в инженеро-седмици, за да се превръщат в пари
- Изрично посочване какво НЕ е било изследвано — за да не приема никой покритие, което не е имало
Превърнете списъка в основа за решение
Всеки отговор трябва да сочи доказателства и последици за сделката. Договорете граници, достъпи и въпроси предварително. Разделете проверени находки, твърдения на ръководството и липсващи материали. Празна клетка не доказва нисък риск.
| Направете решението измеримо | Доказателства, които да договорите предварително |
|---|---|
| Собственост и зависимости | Поискайте история на хранилището, договори с участници и списък на зависимости. Правата се проверяват от юрист. |
| Продукт и експлоатация | Проследете важен път, проверете внедряване и възстановяване, сравнете архитектурата с допусканията за растеж. |
| Поправка и решение | Добавете отговорник, труд, зависимости и проверка. Отделете условията преди сделката от плана след нея. |
Докладът посочва провереното, неизвестното и последиците. Самият преглед на документи не доказва ефективни производствени контроли; техническият преглед не е правна сертификация.
Често задавани въпроси
Какво трябва да включва чеклистът за технически due diligence?
Шест области по ред на последицата: цялост на парите и данните, сигурност и изолация на наемателите, собственост върху IP, архитектура и запас за мащабиране, способност за доставяне и риск от ключов човек. Всяка точка трябва да има заявена търговска последица — чеклист без последици произвежда доклади, по които никой не действа.
Коя точка се пропуска най-често?
Прехвърлянето на IP от изпълнителите. Не е технически въпрос, затова техническите проверяващи го прескачат, а юристите приемат, че инженерството го е покрило. Освен това има най-дълъг срок за оправяне, затова трябва да се проверява в първите дни, а не в последните.
Могат ли основателите сами да ползват този чеклист?
Да, и преди набиране е добра идея. Констатациите, които откриете сами, се превръщат в план за отстраняване, който контролирате; същите констатации, открити от съветника на инвеститор, се превръщат в преговорна позиция срещу вас.
Искате това да го проведе някой, който го прави всяка седмица?
Доставяме diligence с констатации, подредени по бизнес последица, и отстраняване, остойностено в инженеро-седмици.
Още по темата
Технически due diligence за инвеститори: пълното ръководство
Техническият due diligence не е code review. Той е отговор на един въпрос: колко ще струва тази технология да стигне там, където инвестиционната теза я иска?
Какво всъщност търсят VC при технически due diligence
Инвеститорите не оценяват кода ви. Те остойностяват риска технологията да спре плана, който финансират — а основателите, които разбират това, се подготвят съвсем различно.