Слышали ли вы подобный диалог между разработчиками и бизнесом, в т.ч. Владельцем продукта?
С чем связан подобный диалог? Чаще всего с непониманием бизнеса самой сути, а точнее природы технического долга.
Просто о техническом долге, для тех кто не из ИТ я писала в своей статье
По моим наблюдениям, технический долг появляется по причине того, что бизнес просит сделать быстрее-быстрее, а когда к нему приходят и говорят, что пора платить по счетам, то не понимает, что за счёт и откуда он взялся. По сути мы получаем историю, когда вы взяли деньги в кредит под определённый процент и затем решили, что проценты выплачивать вы не будете. Как итог, у вас не только задолженность по процентам, но и штрафные санкции, которых может стать так много, что вами начнут заниматься определённые структуры.
Если перевести это на язык разработки, то в связи с тем, что вы решили не платить проценты, не уделять время техническому долгу, ваша система начинает замедляться и стоимость каждой новой функциональности будет всё выше и выше, так как выходить будет медленнее.
Такая ситуация в команде напоминает мне засор в трубе, через который не может пробиться вода, а в какой-то момент вода уже просто будет стоять...
В недавнем исследовании Sonar-2023 посчитали сколько компании тратят денег на исправление технического долга:
Проблемы в коде накапливаются со временем и могут привести к образованию технического долга. Технический долг приводит к снижению качества продукта, увеличению рисков безопасности, снижению скорости, эффективности и морального состояния разработчиков.
На основе анализа более 200 проектов, выполненных в течение 12 месяцев, мы смогли оценить стоимость накопленного технического долга.
Стоимость технического долга за 5 лет для типичного проекта в 1 млн.строк кода (LoC) оценивается в 27 500 часов работы разработчика или 1,5 млн. долл.
Приведённое число можно с легкостью перевести на российские рубли с учётом стоимости разработчиков и, сразу скажу, число вас неприятно удивит.
По данным исследования (Stripe-2018), разработчики тратят 33% своего времени на устранение технического долга, что равносильно снижению производительности и значительным затратам компании в год.
Компании решают проблему технического долга по-разному. Один из подходов - ничего не делать или отложить исправления на более поздний срок. Такой подход, если его продолжать, в конечном итоге может потребовать значительного рефакторинга или полного переписывания программного обеспечения.
Посколько команды разработчиков постоянно меняются, решение исторических проблем, созданных кем-то другим, также может привести к большим трудностям, сложностям и разочарованию.
Технический долг – это дорого. Создание его должно быть осознанным, как и решение взять кредит в банке. Проценты должны выплачиваться регулярно, чтобы не получить замедления в разработке, из-за "костылей", а также потери разработчиков из-за снижения мотивации. Можно ли писать без технического долга? Можно, но есть нюанс, и это уже не тема этой статьи.
Алгоритм работы с техническим долгом
Что же делать? Как же быть?
Во-первых, перед тем, как создать технический долг, открыто об этом скажите, чтобы было принято совместное решение о “костыле”. Вы берёте в долг и должны знать цену - об этом точно должен знать Владелец продукта.
Во-вторых, создали технический долг - “накостыляли” - заведите тикет в бэклоге продукта и обязательно задокументируйте, чтобы и вы (создатель тех.долга) и тот, кто придёт в будущем, понимали что это за архаизм…
В-третьих, установите % capacity команды, который будет отдан на устранение тех.долга - это может быть 10% и более, всё зависит от степени запущенности.
Начните бить тревогу
Бывает, что я прихожу в компанию с диагностикой Agile-процессов и на обзоре спринта слышу от Владельца продукта, что следующий спринт - технический, то есть команда будет заниматься своим техническим долгом. Бизнес соглашается, я же стою с озадаченным лицом.
Всё дело в том, что согласившись с техническим спринтом, бизнес согласился, что заплатит (более 1 млн. руб.) за то, что команда наведёт уборку...
Это напоминает опять такую историю: вы долгое время не прибирались дома и когда у вас закончились посуда и одежда, вы решили, что пора провести генеральную уборку.
Вместо того, чтобы инвестировать в наведение порядка малый процент своего времени ежедневно: поел - вымыл за собой, вы уходите в длительную уборку... При этом стоит обратить внимание, что беспорядок приводит вас ещё и к определённым ограничениям и неудобствам. Как долго вы сможете жить в таком режиме?
Надеюсь, эта статья поможет Владельцам продуктов начать смотреть на технический долг как на то, к чему надо относиться с вниманием - не плодить сущности без надобности, а уж если наплодили, то прибираться вовремя за собой.
Больше о том, как управлять бэклогом продукта вы можете узнать на нашем тренинге "Управление бэклога продукта и построение User Story Map"