Школа скрам-мастеров

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

С чем связан подобный диалог? Чаще всего с непониманием бизнеса самой сути, а точнее природы технического долга.

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

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

Такая ситуация в команде напоминает мне засор в трубе, через который не может пробиться вода, а в какой-то момент вода уже просто будет стоять…

В недавнем исследовании Sonar-2023 посчитали сколько компании тратят денег на исправление технического долга:

Приведённое число можно с легкостью перевести на российские рубли с учётом стоимости разработчиков и, сразу скажу, число вас неприятно удивит.

Технический долг — это дорого. Создание его должно быть осознанным, как и решение взять кредит в банке. Проценты должны выплачиваться регулярно, чтобы не получить замедления в разработке, из-за «костылей», а также потери разработчиков из-за снижения мотивации. Можно ли писать без технического долга? Можно, но есть нюанс, и это уже не тема этой статьи.

Что же делать? Как же быть?

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

Во-вторых, создали технический долг — «накостыляли» — заведите тикет в бэклоге продукта и обязательно задокументируйте, чтобы и вы (создатель тех. долга) и тот, кто придёт в будущем, понимали что это за архаизм…

В-третьих, установите % capacity команды, который будет отдан на устранение тех. долга — это может быть 10% и более, всё зависит от степени запущенности.

Бывает, что я прихожу в компанию с диагностикой Agile-процессов и на обзоре спринта слышу от Владельца продукта, что следующий спринт — технический, то есть команда будет заниматься своим техническим долгом. Бизнес соглашается, я же стою с озадаченным лицом.
Всё дело в том, что согласившись с техническим спринтом, бизнес согласился, что заплатит (более 1 млн руб.) за то, что команда наведёт уборку…

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

Вместо того, чтобы инвестировать в наведение порядка малый процент своего времени ежедневно: поел — вымыл за собой, вы уходите в длительную уборку… При этом стоит обратить внимание, что беспорядок приводит вас ещё и к определённым ограничениям и неудобствам. Как долго вы сможете жить в таком режиме?

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