Технічна оцінка стартапу — це перевірка наявного програмного продукту та практик його зміни, розгортання й відновлення. Вона допомагає засновникам і CTO визначити, чи здатен продукт забезпечити запланований реліз, виконання корпоративного контракту або передачу іншій команді та чи виправдана його перебудова.
Цей посібник для засновників, які перебирають відповідальність за MVP, створений агенцією, CTO, які приймають наявний продукт, а також керівників продуктових і технічних команд, які готуються до нових вимог клієнтів.
Ключові висновки:
- Перш ніж визначати обсяг перевірки, сформулюйте рішення щодо контракту, релізу, перебудови або передачі продукту.
- Найглибше перевіряйте ті ділянки, де збій може змінити це рішення.
- Вимагайте докази, практичні варіанти дій, план роботи та перелік того, що залишилося неперевіреним.
- Порівнюйте рекомендацію перебудувати продукт із меншими виправленнями, враховуючи міграцію, збої в роботі та витрати на паралельну експлуатацію систем.
- Окремо погоджуйте обсяг оцінки й реалізації змін. Для кожного схваленого виправлення визначте відповідального та спосіб підтвердження виконання.
- Спочатку перевірте, чи однаково власник бізнесу, команда продажів та інженери розуміють, що має робити продукт. Навіть якісно розроблений продукт може не виконувати обіцянку, яку дали клієнту.
Технічна оцінка, аудит коду чи технічний due diligence?
Ці перевірки можуть охоплювати ті самі системи. Відрізняються рішення, для якого їх проводять, і погоджений із виконавцем обсяг роботи.
Обирайте формат перевірки за запитанням, на яке вона має відповісти:
| Формат перевірки | Основна мета | Типовий фокус |
|---|---|---|
Аудит коду | Дослідити окремі питання реалізації | Структура коду, дефекти, залежності, тести або проблеми безпеки |
Технічна оцінка стартапу | Визначити, чи здатні програмне забезпечення та командні практики перевірки, розгортання й відновлення забезпечити запланований контракт, реліз або передачу продукту | Будова системи, релізи, ризики відмов, експлуатаційні витрати та виправлення, які може виконати команда |
Технічний due diligence | Надати підстави для рішення щодо угоди або інвестиції | Заявлені можливості технології, зобов’язання, спроможність команди й системи, права на код і дані та припущення, на яких ґрунтується угода |
Тестування на проникнення | Перевірити визначені системи на вразливості, які можна використати для атаки | Дозволене тестування безпеки в погоджених межах |
Технічна оцінка кандидата | Перевірити, чи має претендент потрібні для посади навички | Завдання з програмування, розв’язання проблем і знання, необхідні для конкретної ролі |
Коли варто замовляти технічну оцінку стартапу?
Технічну оцінку стартапу варто замовляти, коли контракт, реліз, рішення про перебудову або передачу продукту залежить від технічних фактів, яких команда ще не перевірила.
У стартапі така потреба часто виникає, коли продукт має вийти за межі підходів, які допомогли запустити MVP:
- Перший корпоративний контракт: чи здатен продукт виконати обіцяні вимоги до інтеграції, безпеки, часу відгуку та відновлення?
- MVP, створеному агенцією, потрібна нова команда: чи має компанія доступ до репозиторіїв та облікових записів і чи можуть нові інженери зібрати й розгорнути продукт без початкового підрядника?
- Архітектура MVP досягає своїх меж: для наступної вимоги потрібно змінити один компонент чи перепроєктувати більшу частину системи? Стек, обраний для швидкого старту, не стає непридатним автоматично.
- Релізи витрачають обмежений фінансовий запас: які дефекти, ручні виправлення або затримки розгортання постійно відволікають невелику команду від запланованої роботи?
- Перебудова конкурує з виконанням клієнтських замовлень: що наявна команда може виправити в межах бюджету та які роботи затримає заміна системи?
- Інвестору потрібне підтвердження заявленої можливості продукту: чи може команда продемонструвати її за відповідних умов?
- Для одного збою розгортання з уже зрозумілою причиною може вистачити цільового усунення несправності. Вихід на регульований ринок або укладання угоди також можуть вимагати окремої юридичної перевірки, перевірки відповідності вимогам чи безпеки.
Чекліст технічної оцінки стартапу
Використовуйте цей чекліст, щоб визначити, чи готовий продукт до наступного контракту, релізу, рішення про перебудову або передачі іншій команді. Методика технічної оцінки Top Netics охоплює сім напрямів і спирається на наведені нижче методи. Погодьте, які компоненти й тести важливі для вашого рішення.
| Напрям | Основне запитання | Що перевірити | Тривожний сигнал |
|---|---|---|---|
Архітектура | Чи здатна система виконати наступну вимогу? | Зобов’язання перед клієнтами, фактична поведінка продукту, схема системи, виміряні обмеження | Обіцяна поведінка не відповідає роботі продукту |
Код і тести | Чи може команда безпечно змінювати код? | Інструкції зі збирання, тести критичних сценаріїв, повторювані дефекти, залежності | Звичайні зміни порушують оплату або вхід у систему |
Релізи | Чи може інший інженер розгорнути й відновити продукт? | Історія релізів, погодження, пробні розгортання та відновлення | Розгортати продукт може лише один підрядник |
Продуктивність і відновлення | Чи здатен продукт досягти погоджених показників? | Вимірювання навантаження, моніторинг, результати відновлення із зафіксованим часом | Гарантії, надані клієнтам, ніколи не перевіряли |
Безпека | Чи захищені доступ і чутливі дані? | Контроль доступу, потоки даних, робота із секретами, підтверджені результати перевірок | Спільні облікові дані або неперевірений привілейований доступ |
Експлуатаційні витрати | Скільки коштуватиме обслуговування наступного клієнта? | Рахунки за інфраструктуру та сторонні сервіси, їх використання, ручна робота підтримки | Не враховані витрати на підключення клієнтів і виправлення даних |
Знання та доступ до облікових записів | Чи може компанія працювати без конкретної людини? | Адміністраторський доступ компанії, записи про проєктні рішення, демонстрація передачі продукту | Підрядник контролює облікові записи або робочі процеси не задокументовані |
Кожен тривожний сигнал допомагає визначити наступну перевірку. Це привід для дослідження, а не готовий діагноз.
1. Чи здатна архітектура виконати наступну вимогу?
Перевірте, чи може наявна система виконати наступну вимогу клієнта, інтеграції, масштабування або відповідності правилам без заміни значної частини продукту.
Порівняйте погоджену вимогу, зобов’язання перед клієнтом і фактичну поведінку продукту. Простежте кожну невідповідність через сервіси, дані та інтеграції.
Перш ніж пропонувати масштабну заміну продукту, який уже пройшов етап MVP, перевірте, чи дозволить зміна однієї інтеграції підключати корпоративних клієнтів. Відрізняйте виміряні обмеження від припущень. Використовуйте такі методи, як ATAM Університету Карнегі — Меллона, щоб оцінювати компроміси з огляду на цільові характеристики якості.
2. Чи може команда безпечно змінювати код?
Перевірте інструкції зі збирання, тести оплати й входу в систему, повторювані дефекти та залежності, які заважають оновленням. Обирайте для перевірки код, який часто змінюють або в якому виникають збої, а не випадкову частину репозиторію. Сам по собі відсоток покриття тестами не доводить безпечність змін.
3. Чи може інший інженер розгорнути реліз?
Простежте шлях нещодавньої зміни через перевірку коду, тестування, розгортання та перевірку результату. Визначте, де робота чекає, від чиїх погоджень залежить і як виконується відновлення. Метрики постачання програмного забезпечення DORA допомагають досліджувати темп роботи та нестабільність.
Якщо розгортати продукт може лише один підрядник, перед зміною команди може знадобитися передати доступи та відпрацювати передачу продукту на практиці.
4. Чи здатен продукт досягти цільових показників продуктивності й відновлення?
Перевірте виявлення збоїв, відмови підключених сервісів і відновлення на практиці. Тестуйте з навантаженням найактивнішої години або очікуваним навантаженням від корпоративного клієнта. Зафіксуйте кількість запитів, типи транзакцій, час відгуку та тестове середовище.
Порівняйте результати з вимірюваними цілями, як описано в рекомендаціях Google з SRE. Те, що MVP обслуговує кількох перших користувачів, не підтверджує його продуктивності під навантаженням наступного клієнта.
5. Чи захищені доступ і чутливі дані?
Перевірте відповідні механізми контролю доступу, потоки чутливих даних, секрети, залежності та процедури реагування. Окремі вимоги OWASP ASVS можуть слугувати орієнтиром для перевірки вебзастосунку.
Зіставте важливі результати сканування з фактичним кодом і конфігурацією. Зафіксуйте, які засоби захисту перевірили, що залишилося неперевіреним і де потрібне спеціалізоване дослідження.
6. Скільки коштує експлуатація продукту?
Зіставте рахунки за інфраструктуру й сторонні сервіси з їх використанням, ручним підключенням клієнтів, виправленням даних і роботою підтримки. Перевірте мінімальні платежі та ліміти використання, які вплинуть на вартість обслуговування наступного клієнта.
Використовуйте рекомендації AWS з оптимізації витрат і рекомендації Microsoft з оптимізації витрат, щоб оцінювати економію разом з її впливом на надійність та продуктивність. У прогнозах зазначайте припущення щодо навантаження.
7. Чи має компанія доступ до облікових записів і знань, потрібних для передачі продукту?
Перевірте адміністраторський доступ компанії до хмарної інфраструктури, домену, репозиторію та платіжних облікових записів. Засновник може оплачувати рахунки, тоді як доступи все ще контролює підрядник. Право власності — окреме питання, яке може потребувати юридичної перевірки.
Знайдіть незадокументовані рішення та процеси, які розуміє лише одна людина. Якщо майже всі зміни в коді білінгу робить один інженер, перевірте, чи може інший безпечно змінювати та підтримувати роботу цієї системи. Сама історія комітів не доводить наявності проблеми.
Використовуйте ці результати, щоб спланувати передачу доступів і період спільної роботи команд. У посібнику про технічну відповідальність для нетехнічних засновників описано облікові записи й рішення, які слід контролювати безпосередньо.
Які результати має надати технічна оцінка стартапу?
Корисна технічна оцінка стартапу має надати шість результатів: підсумкову рекомендацію щодо рішення, схему системи, висновки з доказами, порівняння варіантів, план дій і опис меж перевірки.
- Підсумкова рекомендація: чи можна рухатися далі, чи спочатку потрібно усунути проблему.
- Схема системи: відповідні робочі сценарії, сервіси, залежності та зони відповідальності.
- Висновки: докази, наслідки для бізнесу, серйозність проблем і впевненість у висновках.
- Порівняння варіантів: здійсненні виправлення, витрати, порушення роботи та ризики, що залишаться.
- План дій: відповідальні, залежності, строки та перевірки виконання.
- Опис меж перевірки: що оглянули, протестували, перевірили вибірково, виключили з обсягу або не змогли отримати.
Передбачте спільний розбір висновків і можливість для інженерів виправити фактичні помилки або зафіксувати незгоду.
Як визначати пріоритетність виявлених проблем?
Пріоритетність слід визначати за наслідками для бізнесу, впливом на клієнтів, ризиком зриву строків і впливом на залежні роботи та системи. Для стартапу важливо відокремити те, що блокує наступний контракт або реліз, від поліпшень, які можуть зачекати.
Окремо фіксуйте впевненість у висновку: повідомлення про серйозну проблему ще не є підтвердженим дефектом. Для прийнятого ризику зазначте відповідального, строк дії рішення та подію, після якої потрібен повторний перегляд.
Приклад корисного висновку технічної оцінки стартапу
Уявімо SaaS-компанію, яка готується підписати контракт із цільовим часом відновлення (RTO) у чотири години та цільовою точкою відновлення (RPO) у 24 години. Це означає відновити сервіс протягом чотирьох годин і втратити не більше ніж 24 години даних. Самі лише щонічні резервні копії не підтверджують, що будь-якої з цих цілей можна досягти. До тестування визначте сценарій відмови й спосіб вимірювання обох показників.
Корисний висновок пов’язує докази з бізнес-рішенням, а не просто фіксує технічне спостереження.
| Елемент висновку | Приклад |
|---|---|
Докази | Щонічні резервні копії бази даних існують. Повне відновлення системи не виконували й не вимірювали його тривалість. Потрібна конфігурація не входить до резервної копії бази даних, а задокументованого й перевіреного способу відновити або відтворити її, включно з доступом до необхідних секретів, немає. |
Серйозність | Висока. Прогалина впливає на умову контракту, який компанія збирається підписати. |
Впевненість у висновку | Підтверджено: немає задокументованого й перевіреного способу відновлення необхідної конфігурації та секретів. Невідомо: фактичний час відновлення та обсяг втрати даних, оскільки повного відновлення не тестували. |
Наслідок | Компанія поки не може підтвердити виконання контрактних вимог: RTO — чотири години, RPO — 24 години. |
Наступна дія | Призначений інженер забезпечує безпечний спосіб відновити або відтворити конфігурацію та отримати доступ до необхідних секретів. Він відновлює систему в ізольованому тестовому середовищі, де заблоковані запис у виробничі системи та зовнішні побічні дії, а потім проходить сценарій від реєстрації до оплати, використовуючи тестові інтеграції. Потрібно зафіксувати час відновлення та втрату даних для погодженого сценарію відмови. Строк: до підписання контракту. |
Рішення | Не брати на себе зобов’язання щодо відновлення, доки погоджений тест не підтвердить досягнення обох цілей і не будуть розглянуті решта ризиків. |
Що вважається завершенням | Зафіксовані час відновлення та втрата даних, які відповідають обом цілям; інструкції, за якими може працювати інший фахівець; решта проблем або усунуті, або зафіксовані як ризики, прийняті відповідальним власником бізнесу. |
Конфігурація поза резервною копією бази даних — не обов’язково дефект: її можуть відновлювати за допомогою інфраструктури як коду або систем керування конфігурацією та секретами. Прогалина в цьому прикладі — відсутність задокументованого й перевіреного способу відновлення.
Коли перебудова продукту виправдана?
Перебудова виправдана, коли менші виправлення не дозволяють виконати вимогу або коли заміна дає кращий загальний результат з урахуванням затримки розробки, міграції, порушення роботи та експлуатаційних витрат.
Порівняйте варіанти, які вкладаються в бюджет: налагодити розгортання, додати тести оплати, замінити інтеграцію оформлення замовлення або перебудувати один сервіс. Для стартапу також врахуйте клієнтські завдання, які доведеться відкласти, поки невелика команда підтримує обидві системи та переносить користувачів і дані. У статті про технічний борг у стартапах пояснено, як накопичуються відкладені виправлення.
Запитайте: «Яку меншу зміну ви відхилили та які докази змусили б вас змінити рекомендацію?» Перевірте будь-яке невирішене припущення, від якого залежить рішення, перш ніж брати на себе зобов’язання. Сам по собі незнайомий стек не є бізнес-обґрунтуванням.
Обговоріть пропозицію перебудувати продукт із Top Netics. Підготуйте рекомендацію, вимогу, яку вона має забезпечити, і ваші строки, щоб обговорити відповідний обсяг оцінки.
Що підготувати перед зверненням до виконавця технічної оцінки
Коротко опишіть продукт, хто його розробляє, ваші строки й бюджетні обмеження. Підготуйте пропозицію або клієнтську вимогу, яку оцінюєте. Щоб пояснити проблему, не потрібні ані доступ до репозиторію, ані готове технічне завдання.
Після погодження обсягу зберіть потрібні матеріали, організуйте демонстрації та надайте погоджені доступи. Дозволи на тестування у виробничому середовищі погоджуйте окремо від доступу для читання.
Як обрати виконавця технічної оцінки
Обирайте виконавця за тим, як він визначає обсяг роботи, перевіряє докази, порівнює альтернативи та працює з невизначеністю, а не лише за переліком перевірок, які обіцяє провести.
Поставте запропонованим керівникам перевірки шість запитань:
- На яке бізнес-рішення відповість ваша оцінка?
- Що ви перевірите безпосередньо, а що — вибірково?
- Як ви відрізняєте повідомлення про проблеми від підтверджених фактів?
- Чи можемо ми побачити знеособлений приклад, що пов’язує докази з рекомендацією?
- Як ви порівнюватимете менші виправлення, що залишають більшу частину продукту без змін, із перебудовою?
- Що відбудеться, якщо доказів буде недостатньо або наші інженери не погодяться з висновками?
Якщо виконавець також продає послуги реалізації, запитайте, як він порівнюватиме варіанти, які наявна команда може виконати власними силами й у межах свого бюджету. Залучайте профільних фахівців, якщо головне питання потребує тестування на проникнення, юридичного висновку або іншої експертизи поза межами оцінки.
Від чого залежать обсяг, вартість і строки технічної оцінки?
Вартість і строки залежать від погодженого обсягу перевірки: кількості систем, необхідних тестів і вже наявних доказів. Перевірка одного сценарію відновлення та оцінка кількох сервісів із неперевіреною міграцією потребують різного обсягу роботи.
Цільова перевірка відновлення може охоплювати один застосунок, його базу даних, конфігурацію, доступ до секретів і тест відновлення під наглядом оцінювача. Результатом будуть виміряні показники й перелік необхідних виправлень.
Попросіть кошторис, який окремо визначає трудовитрати оцінювача, календарний строк виконання та роботи, які ваша команда має завершити заздалегідь. Пропозиція має містити:
- Компоненти й перевірки, включені до обсягу роботи.
- Вартість, принцип її розрахунку та зміни, що потребуватимуть перегляду кошторису.
- Необхідні доступи, участь клієнта й підготовку середовища.
- Дату надання висновків та їх спільного розбору.
- Уточнення, чи включені виправлення й повторне тестування у вартість, чи оплачуються окремо.
Порівнюйте виконавців за однаковим обсягом роботи. Нижча ціна може означати менше тестів, а коротший строк — припущення, що всі доступи й середовища вже готові.
Обговоріть наступне технічне рішення з Top Netics
Якщо вам потрібно оцінити рекомендацію перебудувати продукт, взяти на себе зобов’язання за вимогою клієнта або передати продукт новій команді, обговоріть технічну оцінку з Top Netics.
Підготуйте рішення, яке потрібно ухвалити, ваші строки та вже наявні докази. Готове технічне завдання не потрібне.
Перша розмова має допомогти визначити ймовірний обсяг перевірки, відсутні докази та доречний формат — цільову перевірку чи ширшу оцінку. До початку роботи погодьте керівника перевірки, способи підтвердження висновків, результати, вартість, строки та спільний розбір висновків.
