Почти всеки основател със счупено MVP пита дали да го пренапише. Почти винаги отговорът е не — и причината е аритметика, а не сантимент.
Счупеното MVP обикновено се проявява по един от три начина: пада при реално използване, всяка промяна чупи нещо друго, или първоначалните разработчици са си тръгнали и никой не го разбира. Инстинктът казва да се започне отначало. Този инстинкт е скъп и обикновено грешен.
Защо пренаписването е капан
Пренаписването изглежда привлекателно, защото новата система е въображаема, а въображаемите системи нямат бъгове. В действителност:
- Съществуващият код кодира години гранични случаи, които никой не е документирал — те ще бъдат преоткрити като продукционни инциденти
- Замразявате разработката на функции за месеци, докато конкурентите не го правят
- Пренаписването опира до същата сложност, защото сложността е в областта, а не в кода
- Оценките за пренаписвания грешат с голяма разлика, последователно, във всяка организация
Стъпка 1: спрете кръвотечението
Преди да подобрявате каквото и да е, направете системата наблюдаема и възстановима. Не можете да поправите това, което не виждате, нито да експериментирате без път назад.
- Проследяване на грешки, за да са известни отказите, вместо да ги съобщават клиентите
- Мониторинг на достъпността и на ключовите транзакции — плащане, регистрация, покупка
- Rollback, който работи и е тестван
- Резервни копия и възстановяване, което наистина е било извършено поне веднъж
Стъпка 2: триаж, а не инвентаризация
Устоите на подтика да изброите всичко нередно. Подредете проблемите по последица:
| Категория | Определение | Действие |
|---|---|---|
| Кървящо | Губи пари, данни или клиенти точно сега | Да се поправи тази седмица |
| Блокиращо | Пречи да се достави пътната карта за тримесечието | Да се поправи това тримесечие |
| Натрупващо се | Забавя всяка промяна | Да се планира съзнателно |
| Козметично | Дразни вкуса, не струва нищо | Никога |
Повечето спасителни проекти намират две или три точки в първата категория и шепа във втората. Това е управляема програма от работа — съвсем различна от смазващото впечатление, което екипът е имал преди подреждането.
Стъпка 3: поправяйте в реда, който се натрупва
- Първо целостта на данните — повредените или изгубени данни са невъзстановими по начин, по който престоят не е
- После пътят на разгръщане — докато пускането не стане безопасно и често, всяка друга поправка излиза бавно и рисково
- После основният източник на откази — обикновено един-два ендпойнта или заявки причиняват повечето инциденти
- После блокиращото промените — свързаността или липсата на тестове, заради които екипът се страхува да пипа
- И едва тогава производителност и полиране
Стъпка 4: предотвратете рецидива
- Тестове по пътищата, които болят — пари, автентикация и точно това, което се счупи
- Писмен дневник на решенията, за да наследи следващият инженер разсъждения, а не само код
- Процес на разгръщане, който всеки в екипа може да изпълни
- Изрично правило, че пътната карта включва капацитет за поддръжка — иначе дългът се връща
Спасяването не е разчистване. То е малък брой прицелени промени, които извеждат системата от опасна към скучна — а скучното е онова, което позволява на екипа отново да пуска.
Определете граница за ремонт преди пренаписване
Покажете, че един повреден път може да се стабилизира. Използвайте резултата за следващия етап и сравнение със замяна.
- Напишете регресионен тест за наблюдавания дефект.
- Поправете ограничена област и проверете съседното поведение.
- Сравнете ремонт и замяна с миграция и паралелна работа.
Често задавани въпроси
Да пренапишем ли нашето MVP, или да го поправим?
Поправете го, освен ако платформата не е неподдържаема, продуктът не се е променил фундаментално или цялата система не може да се построи наново за няколко седмици. Пренаписванията замразяват продуктовата работа за месеци, преоткриват забравени гранични случаи като продукционни инциденти и последователно надхвърлят оценките си.
Колко време отнема спасяването на MVP?
Триажът отнема дни. Стабилизирането на критичните проблеми обикновено отнема две до шест седмици според тежестта. Пълното отстраняване на натрупания дълг е тримесечие или повече — но се случва успоредно с продуктовата работа, а не вместо нея.
Първоначалните ни разработчици ги няма. Кодът все още ли е спасяем?
Почти винаги. Загубата на авторите прави работата по-бавна, но не невъзможна: първата задача е да се възстанови как системата всъщност се държи — чрез четене, инструментиране и характеризиращи тестове — преди да се променя каквото и да било.
Как да разберем дали MVP-то ни наистина е счупено, или просто несъвършено?
Попитайте дали губи пари или данни, дали пречи да се достави пътната карта и дали екипът се страхува да разгръща. Ако нищо от това не е вярно, имате несъвършено MVP — което е нормално и не заслужава намеса.
Кога да спрем новите функции временно?
Когато промените пречат на диагнозата или увеличават съществени рискове за данни и достъпност. Определете обхват на паузата и доказателства за подновяване.
MVP в беда?
Триажираме за дни и честно казваме дали е нужно спасяване, пренаписване, или нищо.
Още по темата
Технически одит на MVP: какво проверяваме през първите 48 часа
Повечето одити на MVP произвеждат документ. Полезният произвежда решения: какво гори, какво може да чака и колко струва поправката.
Технически дълг в стартъп: колко е твърде много?
Всеки стартъп има технически дълг и по-голямата част от него е било правилното решение. Въпросът не е как да го премахнете, а кои части начисляват лихва, която вече не можете да си позволите.