Як полагодити зламане MVP (не починаючи з нуля)

Майже кожен засновник зі зламаним MVP питає, чи не переписати його. Майже щоразу відповідь — ні, і причина в арифметиці, а не в сентиментах.

Зламане MVP зазвичай проявляється одним із трьох способів: воно падає під реальним навантаженням, кожна зміна ламає щось інше, або початкові розробники пішли і ніхто його не розуміє. Інстинкт каже почати заново. Цей інстинкт дорогий і зазвичай хибний.

Чому переписування — це пастка

Переписування виглядає привабливо, бо нова система уявна, а в уявних систем немає багів. Насправді:

• Наявний код кодує роки крайніх випадків, яких ніхто не задокументував — їх перевідкриють як продакшн-інциденти
• Ви заморожуєте розробку фіч на місяці, поки конкуренти цього не роблять
• Переписування впирається в ту саму складність, бо складність у домені, а не в коді
• Оцінки переписувань хибні з великим запасом, послідовно, у кожній організації

Крок 1: зупинити кровотечу

Перш ніж щось покращувати, зробіть систему спостережуваною і відновлюваною. Не можна полагодити те, чого не бачиш, і не можна експериментувати без шляху назад.

1. Трекінг помилок, щоб про збої знали ви, а не повідомляли клієнти
2. Моніторинг доступності та ключових транзакцій — оплата, реєстрація, покупка
3. Відкат, який працює і був протестований
4. Резервні копії і відновлення, яке справді хоч раз проводили

Крок 2: тріаж, а не інвентаризація

Утримайтеся від бажання перелічити все, що не так. Відсортуйте проблеми за наслідком:

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

Крок 3: лагодити в порядку, що дає накопичувальний ефект

1. Спершу цілісність даних — пошкоджені чи втрачені дані невідновні так, як не є невідновним простій
2. Потім шлях розгортання — доки випуск не стане безпечним і частим, кожне інше виправлення їде повільно і ризиковано
3. Потім головне джерело збоїв — зазвичай один-два ендпоінти чи запити спричиняють більшість інцидентів
4. Потім блокатор змін — зв'язаність або відсутність тестів, через які команда боїться щось чіпати
5. І лише тоді продуктивність та шліфування

Крок 4: не допустити рецидиву

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

Порятунок — це не прибирання. Це невелика кількість точкових змін, що переводять систему з небезпечної в нудну, а нудна — саме та, у якій команда знову починає випускати.

Визначте межу ремонту до переписування

Доведіть, що один зламаний шлях можна стабілізувати. За результатом оцінюйте наступний етап і альтернативу заміни.

1. Напишіть регресійний тест для спостереженого дефекту.
2. Виправте обмежену ділянку й перевірте суміжну поведінку.
3. Порівняйте ремонт і заміну з міграцією та паралельною роботою.

• відновлення MVP →
• технічний аудит MVP →