Техдолг подождёт

Потом поправим

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

Проблема начинается, когда временные решения становятся постоянными, но последствия никто не учитывает. Но старый код не всегда = техдолг. Желание разработчика всё перепилить ещё не значит, что проекту нужен рефакторинг.

Где техдолг мешает

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

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

Сколько стоит техдолг

Например, рефакторинг модуля оценили в 24 часа, или 3 рабочих дня. Каждая новая фича тоже стоит 24 часа. Но из-за накопленного техдолга разработка каждой фичи требует дополнительных 8 часов, то есть день. В беклоге ещё 10 таких задач.

Рефакторинг окупится после трёх фич, если уберёт дополнительные затраты. Но клиент увидит ситуацию иначе: за те же 24 часа команда могла бы реализовать ещё одну нужную фичу. Ему предлагают потратить три дня на работы, результат которых нельзя показать пользователям или руководству. Возникает вопрос, почему он вообще должен за это платить.

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

Кто за это платит

В заказной разработке клиент согласовал фичсет и бюджет, команда просит допчасы на рефакторинг. Для клиента это выглядит как предложение оплатить исправление того, что мы сами же разработали. Бывает даже что он прав.

Смотрим дальше откуда взялся долг. Технический компромисс заранее обсудили и согласовали с клиентом, или команда самостоятельно выбрала быстрое решение, а теперь предлагает клиенту оплатить последствия? Бывает кстати так, что требования изменились, и прежняя архитектура перестала подходить. Во всех случаях смотрим на договорённости, причины возникновения долга и необходимость работ.

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

Как протащить задачу в спринт

Техзадачи регулярно проигрывают новым фичам. Клиент хочет функционал, который можно показать пользователям, а разработка просит три дня на рефакторинг. Аргумент «нам надо привести код в порядок» вообще никого никогда не впечатляет. Поэтому вместе с командой показываем, как долг влияет на следующие задачи: дополнительные часы, дефекты, риски релиза.

Если рефакторинг за 24 часа позволит сэкономить 80 часов на следующих 10 фичах — это уже аргументище. Определяем минимальный объём технических работ, пересматриваем приоритеты и согласовываем, что попадёт в спринт, а что придётся сдвинуть.

Можно резервировать часть ёмкости команды под техдолг или устранять его в рамках доработок проблемного модуля. Но эти часы должны учитываться в плане. В противном случае, техзадачу снова перенесут в следующий спринт, и команда продолжит тратить время на обход ограничений. Пока очередная «временная» реализация не станет слишком дорогой, чтобы её трогать.

А еще можно методично добавлять задачу в предварительный план каждого спринта с низким приоритетом, не включая в согласованный объём без одобрения. Возможно, в какой-то момент клиент сдастся и всё-таки согласует этот чёртов рефакторинг.

Об авторе статьи

Аня Каргина

Я менеджерка проектов. Пишу о работе с клиентами и командами, делюсь опытом и наблюдениями.

К началу статьи