В последнее время в сообществах архитекторов и разработчиков часто фигурирует тема технического долга. Техдолг – неотъемлемая часть продуктовой разработки. Ведь для быстрого получения бизнес-результатов, тестирования продуктовых гипотез или закрытия каких-то срочных бизнес-проблем командам часто приходится реализовывать нецелевые MVP решения или откладывать на потом автоматизацию тестирования. Здравый смысл, а кому-то и жизненный опыт финансового долга подсказывают, что лучше не влезать в долги, а если взял, то их своевременно возвращать. Но так ли это в случае с техдолгом?
![](https://habrastorage.org/getpro/habr/upload_files/03e/216/707/03e21670702b7688e8547cc49d9ab35f.jpg)
В своей практике я встречаюсь с противоречивым отношением к техническому долгу в компаниях.
С одной стороны, владельцы продуктов понимают, что техдолгом необходимо управлять, что его прирост негативно сказывается на развитии компании, начиная от усложнения разработки (технические ограничения на доработку решений, увеличение time-to-market) до серьезных финансовых и репутационных рисков падения систем и поддерживаемых ими бизнес-процессов.
С другой стороны, они не готовы выделять реальные ресурсы команды, отдавая приоритет разработке продуктовых фич. Если в вашей команде нет практики заведения техдолга, если процесс работы с техдолгом непрозрачный и зависит от переговорной силы команды, то дайте почитать эту статью вашему продакту.
Как подружить техдолг и продуктовый подход?
Сегодня многие компании активно переходят на продуктовую разработку. Основная причина этого – продуктовый подход базируется на реализации того, что нужно клиенту, что даст наибольшую окупаемость инвестиций. Когда мы говорим о техническом долге, то чаще всего апеллируем к качеству решений, их надежности, современным технологиям и подходам к разработке. Это вступает в противоречие с продуктовым подходом, для которого работа с техдолгом означает сокращение бюджета на новые фичи и, соответственно, ожидаемой выручки.
Самым эффективным вариантом устранения противоречия между задачами развития продукта и обеспечения высокого качества технологического решения я считаю переход к оценке в одних и тех же единицах и сквозную приоритезацию продуктовых фич и техдолга. Для этого я применяю денежную модель сравнения затрат и выгод от реализации любой задачи.
Техдолг на чаше весов
![](https://habrastorage.org/getpro/habr/upload_files/2a6/3a1/bf8/2a63a1bf8bf1fa05365a29438c0a5f12.jpg)
Затратная часть работы с техдолгом очевидна – это время, которое команда потратит на исследование проблемы, поиск решения и его реализацию. Самая сложная задача – монетизировать выгоды от закрытия техдолга.
Накопление технического долга увеличивает сложность системы и порождает две критичные проблемы: падение стабильности систем и рост time-to-market. Выгода от решения техдолга – предотвращенные финансовые потери от этих проблем.
Как монетизировать риск нестабильности системы?
Пререквизитом качественной оценки влияния техдолга на надежность компании является понимание критичных для компании бизнес-процессов, генерирующих денежный поток, и их стоимости. Неработоспособность системы, реализующей какой-либо из шагов критичного бизнес-процесса, приводит к потерянной выручке или понесенным издержкам. Стоимость техдолга в этом случае привязана к реальным финансовым показателям компании и юридическим обязательствам.
Сколько стоит непродуктивный час команды?
Используя продуктовый подход, компании стремятся повысить скорость выпуска изменений на продуктивную среду за счет короткого релизного цикла и постепенных итераций по обратной связи от пользователей. Скорость команды очень важна, сколько задач команда в среднем берет в спринт, сколько времени занимает путь задачи от заведения до деплоя – все это отслеживается по отчетам в Jira.
![](https://habrastorage.org/getpro/habr/upload_files/1b0/161/226/1b01612268bf204a8e308bd094b3351e.png)
Наличие техдолга, как наличие аварии на дороге, заставляет команду стоять в пробке с какими-то продуктовыми фичами или тратить лишнее время на объезд техдолга. В обоих случаях производительность команды снижается. Оценка техдолга, который влияет на скорость разработки, определяется стоимостью времени, которое команда тратит непродуктивно из-за наличия техдолга или из-за отсутствия каких-то инструментов и практик, например, автотестирования.
Фокус на регулярной работе с техдолгом
Формирование единого понимания между командой и владельцем продукта, что есть техдолг, почему он может иметь такой же приоритет как и продуктовые фичи – половина успеха. Важную роль в превращении работы с техдолгом в практику управления им занимает формирование единого понимания, что это не одноразовая акция (завел-закрыл-молодец), а регулярный процесс, который необходимо встроить в ежедневные активности команды.
Команда и владелец продукта должны не только оценивать задачи техдолга и продуктовые фичи в одних и тех же единицах, но и работать с задачами техдолга аналогично продуктовым: заводить их в единый бэклог команды сразу после выявления на любом из этапов продуктовой разработки (анализ, проектирование, разработка, QA, поддержка), оценивать трудозатраты на грумминге бэклога и брать в спринт для реализации в соответствии с приоритетом задачи.
Заведение техдолга для его «выплаты»
![](https://habrastorage.org/getpro/habr/upload_files/be5/db6/527/be5db6527ac44a6c23ed0a66f863a13a.png)
Чаще всего достаточно перехода на денежную оценку техдолга для того, чтобы владелец продукта смог самостоятельно выстроить в бэклоге продуктовой команды сквозные приоритеты между задачами техдолга и продуктовыми фичами. В этом случае проблема «фаворитизма» в отношении продуктовых задач уходит сама собой. РО просто берет в спринт задачи с наиболее высоким приоритетом в бэклоге, не выделяя, что какие-то из них являются техдолгом.
Если на первом этапе РО сложно принять полное «равноправие» продуктовых задач и техдолга, то можно в рамках команды принять решение о выделении фиксированного процента времени в спринт на его закрытие. Однако такой подход полезен как «учебный» этап для выработки полезной привычки закрытия техдолга, его использование на постоянной основе может привести к тому, что команда будет тратить время спринта на неприоритетные задачи техдолга, только чтобы заполнить фиксированный процент.
А если в команде не заложен бюджет на техдолг?
Большим препятствие для выстраивания работы с техдолгом может стать жесткая привязка на уровне компании бюджета команды к разработке заявленных продуктовых фич. В этом случае у владельца продукта связаны руки: он может изредка пытаться выделять время команды на закрытие наиболее критичных задач техдолга, но не более того, эффективное управление со сквозными приоритетами выстроить будет невозможно.
![](https://habrastorage.org/getpro/habr/upload_files/1ff/203/717/1ff203717ff2d7f16b4ba677efd3b42c.jpg)
Для владельца продукта важно донести до руководителей компании факт наличия техдолга в продукте и закладывать в трудозатраты на регулярную работу с ним при формировании бюджета.
Добиться получения бюджета можно только прозрачностью техдолга: понятная денежная оценка риска или упущенной выгоды, сопоставимая с ожидаемой выручкой продуктовых фич, регулярное подсвечивание динамики стоимости техдолга и тех рисков, которые принимает на себя компания.
Рецепт успеха
Подводя итоги, успех выстраивания процесса работы с техдолгом в продуктовой команде зависит от трех составляющих:
прозрачность техдолга на уровне компании и включение владельцем продукта трудозатрат на закрытие техдолга в бюджет команды,
оценка техдолга и продуктовых задач в одних и тех же единицах - деньгах,
регулярное заведение и закрытие техдолга в соответствии со сквозными приоритетами.