💭 «Сейчас сделаем по-быстрому, потом переделаем»

Наверное, это одна из самых опасных фраз в IT, которую я слышал сотни раз. Почти всегда человек говорит это искренне, он действительно планирует вернуться к решению позже. Но проблема в том, что это «потом» очень часто не наступает: появляются новые задачи, меняются приоритеты, команда переключается на другой проект. Через год уже никто не помнит, почему это было сделано именно так и временный костыль становится частью архитектуры. А через пару лет новый сотрудник приходит в проект и искренне считает, что это была чья-то продуманная архитектурная идея.

При этом технический долг редко появляется из-за плохих инженеров. Чаще его создают хорошие специалисты, которые в конкретный момент принимают вполне рациональное решение: нужно быстрее запустить продукт, проверить гипотезу или успеть к дедлайну. И это нормально.

Сама проблема начинается тогда, когда команда постоянно откладывает работу с этим долгом. Поэтому я считаю важным не просто фиксировать технический долг, но и заранее выделять на него время. Например, договориться, что определенный % емкости каждого спринта команда тратит на технические задачи, рефакторинг, улучшение инфраструктуры и устранение накопившихся проблем.

Тогда технический долг становится такой же частью работы, как разработка новых функций. Не нужно ждать момента, когда система начнет разваливаться и половина команды будет занята ее спасением.

❗️И, наверное, главное - не стоит бояться сознательно идти на компромиссы. Иногда быстрое и неидеальное решение действительно лучше идеального, которое будет готово через полгода. Важно только понимать, что это компромисс, зафиксировать его и действительно выделить время, чтобы однажды к нему вернуться.

Кто я | Навигация | Спасибо