Технічний аудит MVP: що ми перевіряємо в перші 48 годин

Більшість аудитів MVP закінчуються документом. Корисний закінчується рішеннями: що горить, що може почекати і скільки коштує виправлення.

Технічний аудит MVP відповідає на одне питання: чи витримає ця кодова база наступні дванадцять місяців бізнесу, а якщо ні — що саме має змінитися? Усе інше — уподобання щодо інструментів, суперечки про стиль, вибір фреймворка — це шум.

Ось чекліст, який ми проходимо в перші 48 годин. Він свідомо впорядкований за ціною помилки: те, що зверху, здатне вбити компанію, те, що знизу, коштує швидкості.

1. Цілісність грошей і даних (найвища ціна відмови)

Якщо продукт рухає гроші або зберігає регульовані дані, це йде першим. Помилки тут — не інциденти, а зобов'язання. Ми шукаємо:

• Чи виводяться баланси з журналу лише-на-дозапис, чи зберігаються як змінне число, яке код може перезаписати
• Ідемпотентність на кожному платіжному шляху та вебхуці — чи може повторений запит списати або зарахувати двічі?
• Використовуйте точні десяткові або цілі мінімальні одиниці за правилами валюти.
• Транзакційні межі: чи може часткова відмова залишити гроші подвоєними або ніде
• Звірка: чи існує процес, який виявить розбіжність, чи ви дізнаєтесь про неї від клієнта?

2. Безпека та контроль доступу

• Авторизація перевіряється на сервері при кожному запиті, чи припускається, бо інтерфейс ховає кнопку
• Секрети у змінних середовища та менеджері секретів, а не в історії репозиторію
• PII і дані карток: що зберігається, де і чи взагалі має зберігатися
• Реально досяжні вразливості залежностей, а не просто червоне число у звіті
• Ізоляція мультитенантності: чи може підроблений запит прочитати дані іншого клієнта?

3. Архітектура та межі масштабування

Ми не шукаємо елегантності. Ми шукаємо конкретну стіну, в яку вдариться система, і як далеко вона.

• Єдині точки відмови — база, черга, сервіс, до якого звертаються всі
• Патерни запитів, коректні на 1 000 рядках і фатальні на 1 000 000 (N+1, відсутні індекси, необмежені сканування)
• Чи можна розгорнути без простою і чи хтось коли-небудь пробував
• Зв'язаність, що не дає випустити фічу без правок у п'яти модулях
• Чи відповідає архітектура розміру команди — мікросервіси на чотирьох інженерів це проблема масштабування, а не рішення

4. Доставка та експлуатація

Кодові бази не псуються самі; швидкість визначає процес. Що ми вимірюємо:

5. Технічний борг: відсортований, а не перелічений

Борг є в кожній кодовій базі. Його список марний. Важлива класифікація на три кошики:

1. Блокуючий — унеможливлює роадмап або ставить під ризик гроші/дані. Виправляти зараз.
2. Накопичувальний — уповільнює кожну майбутню зміну. Планувати свідомо.
3. Косметичний — ображає смак, нічого не коштує. Залишити в спокої.

Мета аудиту — не знайти все, що не так. Мета — знайти ті кілька речей, які достатньо погані, щоб мати значення, і точно сказати, скільки вони коштують.

Що ви маєте отримати наприкінці

• Пріоритезований перелік знахідок із рівнем критичності та бізнес-впливом — не каталог
• До кожної знахідки: виправлення, реалістичну оцінку роботи і що станеться, якщо нічого не робити
• Послідовний роадмап: цей квартал, наступний, пізніше
• Докази — запит, ендпоінт, конкретний рядок — щоб ваша команда могла перевірити, а не повірити

Перетворіть перший огляд на перевірюваний беклог

Обмежений часом огляд описує покриття, а не відсутність усіх дефектів. Кожен висновок має перевірятися незалежно.

1. Пов'яжіть уражений шлях, докази та умови відтворення.
2. Відокремте спостережені дефекти, можливі ризики й недоступні ділянки.
3. Призначте відповідального та регресійну перевірку для кожного виправлення.

• відновлення MVP →
• як виправити MVP →