Есть одна классическая фраза, после которой у проекта обычно начинается веселая жизнь:
"Сейчас сделаем побыстрому, потом нормально перепишем".
Обычно это звучит в первом же спринте. На этапе, когда все бодрые, сроки горят, хочется показать результат и никто не хочет быть тем самым душнилой, который тормозит запуск.
Проблема в том, что именно в этот момент закладывается будущая боль. Не через год. Не когда команда вырастет до 20 человек. А прямо в начале.
1. Техдолг не появляется внезапно
Техдолг — это не "разработчики ленивые" и не "кодеры накосячили".
Чаще это серия маленьких решений под давлением:
- "валидацию потом добавим";
- "тесты сейчас не нужны, потом покроем";
- "архитектуру не трогаем, нам бы релизнуть";
- "вынесем в отдельный модуль как-нибудь позже";
- "пока захардкодим, чтобы работало".
По отдельности каждое решение выглядит безобидно. Вместе они превращают код в кредитную карту с высоким процентом.
Первые пару недель кажется, что все отлично: фичи едут, релиз живет, все молодцы. А потом на каждую правку приходится тратить кратно больше времени (а заказчику денег).
2. Почему это начинается именно в первом спринте
Потому что в первом спринте почти всегда побеждает скорость.
Бизнесу нужен результат "вчера". Команда еще не разогналась. Контекст сырой. Требования плавают. Никто до конца не понимает, что из этого MVP станет постоянной системой.
И появляется опасная иллюзия:
"Сейчас главное быстрее запуститься, потом аккуратно доведем".
Почти никогда не доводят. Потому что после запуска приходят новые задачи, новые дедлайны, новые обещания, и "потом" превращается в "никогда".
Важно: не всегда это вина команды.
Чтобы было честно: не каждая "кривая" реализация рождается из безответственности команды.
Иногда выбор реально жесткий: либо сделать рабочий минимум в ограниченный бюджет и срок, либо проект отдадут тем, кто пообещает "дешево и быстро", а на выходе получится продукт, который тяжело поддерживать. И всё это в сложное для команды время.
Поэтому проблема не в самом компромиссе. Проблема в том, что компромисс часто не фиксируют как временный и управляемый. Его подают как "нормальную архитектуру", и вот это уже прямой путь в технический ад.
3. Как выглядит яма, которую роют с первого спринта
Она редко выглядит как катастрофа сразу. Сначала это просто "чуть кривовато".
А потом:
- простая фича начинает требовать 4 согласования и 12 файлов;
- любой баг чинится через страх что-то сломать рядом;
- новому разработчику нужен не онбординг, а археологическая экспедиция;
- релизы превращаются в лотерею;
- команда боится трогать "тот самый модуль", потому что он проклят.
Снаружи кажется, что "разработка тормозит". Внутри команда просто платит проценты по старым решениям.
4. Самые дорогие "временные" решения
Есть вещи, которые особенно больно выстреливают, если сделать их на отвали с самого начала:
- Отсутствие нормальной структуры кода. Когда все в одном месте и без границ, любая правка расползается по системе.
- Игнор обработки ошибок. Пока демо работает — всем ок. В проде внезапно начинается квест "почему упало и где лог".
- Хардкод и магические значения. Быстро сегодня, больно каждый следующий релиз.
- Отсутствие базовых тестов на критичный флоу. Экономия пары часов в спринте превращается в регулярные откаты.
- Кривые интеграции "на один раз". Один раз почти всегда живет годами.
И самое любимое: "давайте пока без нормальной авторизации, потом докрутим". Спойлер: потом это докручивается дольше, чем если бы сделали сразу хотя бы базово правильно.
5. Почему это бьет не только по коду, но и по деньгам
Техдолг — это не только техническая проблема. Это бизнес-расход, который просто не всегда виден в таблице.
Он съедает:
- скорость команды;
- предсказуемость сроков;
- качество релизов;
- нервную систему всех участников проекта.
На бумаге кажется, что команда "медленная". По факту команда постоянно разгребает последствия вчерашней спешки.
И чем дольше это игнорировать, тем дороже обходится любая новая задача.
6. Как не закопать проект в самом начале
Идеальный старт бывает крайне редко. Компромиссы будут в любом случае.
Вопрос не в том, делать ли техдолг вообще. Вопрос в том, делать ли его осознанно.
Рабочий минимум на старте:
- фиксировать, где вы сознательно идете на упрощение;
- сразу ставить срок возврата этих решений;
- держать базовую архитектурную дисциплину (границы модулей, именование, структура);
- не экономить на критичных вещах: ошибки, безопасность, ключевые тесты;
- закладывать в спринты время на техдолг, а не ждать "когда-нибудь потом".
Если команда говорит "это временно", у этой фразы должен быть дедлайн и ответственный. Иначе это не временно, это новый стандарт проекта.
7. Главная мысль
Большинство проектов не разваливаются от одного большого провала.
Они умирают от сотни маленьких "пока так сойдет", принятых, в том числе, в самом начале.
Первый спринт — это не просто старт разработки. Это момент, когда вы делаете выбор: строить систему и придерживаться определенной планки качества или сразу же на старте старте начинаете копить проценты по техдолгу.
Подписывайтесь на SkylinnTime — https://dzen.ru/skylinntime. Здесь будем говорить про IT, разработку и игровую индустрию без сказок про лёгкие деньги, но и без лишнего нытья. Пишет практикующий Senior Fullstack web developer и teamlead, который всё это видит не только со стороны красивых вакансий.