В последнее время в сообществах архитекторов и разработчиков часто фигурирует тема технического долга. Техдолг – неотъемлемая часть продуктовой разработки. Ведь для быстрого получения бизнес-результатов, тестирования продуктовых гипотез или закрытия каких-то срочных бизнес-проблем командам часто приходится реализовывать нецелевые MVP решения или откладывать на потом автоматизацию тестирования. Здравый смысл, а кому-то и жизненный опыт финансового долга подсказывают, что лучше не влезать в долги, а если взял, то их своевременно возвращать. Но так ли это в случае с техдолгом?

В своей практике я встречаюсь с противоречивым отношением к техническому долгу в компаниях.

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

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

Как подружить техдолг и продуктовый подход?

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

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

Техдолг на чаше весов

Затратная часть работы с техдолгом очевидна – это время, которое команда потратит на исследование проблемы, поиск решения и его реализацию. Самая сложная задача – монетизировать выгоды от закрытия техдолга.

Накопление технического долга увеличивает сложность системы и порождает две критичные проблемы: падение стабильности систем и рост time-to-market. Выгода от решения техдолга – предотвращенные финансовые потери от этих проблем.

Как монетизировать риск нестабильности системы?

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

Сколько стоит непродуктивный час команды?

Используя продуктовый подход, компании стремятся повысить скорость выпуска изменений на продуктивную среду за счет короткого релизного цикла и постепенных итераций по обратной связи от пользователей. Скорость команды очень важна, сколько задач команда в среднем берет в спринт, сколько времени занимает путь задачи от заведения до деплоя – все это отслеживается по отчетам в Jira.

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

Фокус на регулярной работе с техдолгом

Формирование единого понимания между командой и владельцем продукта, что есть техдолг, почему он может иметь такой же приоритет как и продуктовые фичи – половина успеха. Важную роль в превращении работы с техдолгом в практику управления им занимает формирование единого понимания, что это не одноразовая акция (завел-закрыл-молодец), а регулярный процесс, который необходимо встроить в ежедневные активности команды.

Команда и владелец продукта должны не только оценивать задачи техдолга и продуктовые фичи в одних и тех же единицах, но и работать с задачами техдолга аналогично продуктовым: заводить их в единый бэклог команды сразу после выявления на любом из этапов продуктовой разработки (анализ, проектирование, разработка, QA, поддержка), оценивать трудозатраты на грумминге бэклога и брать в спринт для реализации в соответствии с приоритетом задачи.

Заведение техдолга для его «выплаты»

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

Если на первом этапе РО сложно принять полное «равноправие» продуктовых задач и техдолга, то можно в рамках команды принять решение о выделении фиксированного процента времени в спринт на его закрытие. Однако такой подход полезен как «учебный» этап для выработки полезной привычки закрытия техдолга, его использование на постоянной основе может привести к тому, что команда будет тратить время спринта на неприоритетные задачи техдолга, только чтобы заполнить фиксированный процент.

А если в команде не заложен бюджет на техдолг?

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

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

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

Рецепт успеха

Подводя итоги, успех выстраивания процесса работы с техдолгом в продуктовой команде зависит от трех составляющих:

• прозрачность техдолга на уровне компании и включение владельцем продукта трудозатрат на закрытие техдолга в бюджет команды,

• оценка техдолга и продуктовых задач в одних и тех же единицах - деньгах,

• регулярное заведение и закрытие техдолга в соответствии со сквозными приоритетами.