Помню свой первый серьёзный разговор с финансовым директором. Я пришёл с презентацией про рефакторинг, слоистую архитектуру и покрытие тестами, говорил двадцать минут, а в конце услышал: «И сколько это нам принесёт в рублях?» Я завис. Мне казалось, что если код стал чище и жить стало легче — это и есть результат. Для бизнеса это был результат, который нельзя положить в отчёт, а значит, его как будто не существовало. Именно тогда я понял: проблема не в том, что бизнес не понимает инженеров. Проблема в том, что мы разговариваем на языке, который в их системе координат ничего не значит.
Технический долг — это ровно тот же долг, что и финансовый, и это не метафора, а рабочая аналогия. У него есть тело (сумма, которую нужно отдать), есть проценты (то, что мы платим каждый спринт в виде замедления) и есть кредиторы (конкретные люди, которые ждут свою фичу, а получают её позже). Как только я начал описывать долг в этих терминах, разговор поменялся. Бизнесу не нужно покупать чистый код. Бизнесу нужно покупать скорость, предсказуемость и меньший риск — а чистый код всего лишь инструмент, который это обеспечивает.
Мой рабочий способ перевода — четыре числа, которые я собираю сам, без героических усилий. Первое: сколько времени команда тратит на задачи, которые не двигают продукт вперёд, — горящие баги, ручные выкладки, обходы известных ограничений. Второе: сколько стоит один инцидент, включая часы дежурных, потерянные сделки и репутационные последствия. Третье: сколько дней занимает онбординг нового разработчика до первой осмысленной задачи. Четвёртое: как доля техподдержки и «мелочей» растёт от квартала к кварталу. Каждое из этих чисел бизнес понимает без перевода, потому что сам ими пользуется.
Показательный пример из моей практики. Мы полгода откладывали переписывание одного старого модуля, потому что «всё же работает». Потом я сел и посчитал: каждая новая интеграция в этом модуле занимала в среднем на девять дней больше, чем в соседнем. За квартал таких интеграций было восемь. Умножил девять дней на восемь, взял стоимость команды за день и получил сумму, которая оказалась больше, чем вся смета на переписывание вместе с рисками. Я принёс не аргумент «код плохой», а картинку: вот сколько мы уже заплатили процентов и вот сколько стоит закрыть тело долга. Решение приняли на той же встрече.
Теперь я делаю это регулярно и скучно, и в этом весь секрет. Раз в квартал я собираю короткую сводку из пяти-шести строк: доля времени на неплановую работу, стоимость инцидентов, среднее время до релиза, biggest blockers с оценкой в днях. Никаких диаграмм связей и метрик сложности. Это живёт в том же документе, где планируются деньги, и обсуждается в тех же терминах. За пару лет такой практики я ни разу не слышал вопроса «а зачем нам это», потому что вопрос звучал иначе: «это дороже, чем мы думали, — что режем?»
Что бы я посоветовал тем, кто только начинает. Не врите и не завышайте числа в свою пользу: один раз пойманное преувеличение убивает доверие ко всей таблице на годы. Начинайте с одного показателя, который болит у всех, — обычно это время до релиза. Не используйте слова вроде «рефакторинг», «легаси» и «архитектурная энтропия» в отчёте для руководства: замените их на «время», «риск» и «деньги». И обязательно предлагайте не проблему, а вариант: вот цена вопроса, вот что мы получим, вот что не получим, если отложим. Бизнес прекрасно умеет выбирать, когда выбор сформулирован честно.
И ещё одно, что я понял не сразу. Технический долг — не всегда зло. Иногда взять его осознанно, чтобы проверить гипотезу быстрее, — это лучшее бизнес-решение из возможных. Разница между здоровой командой и выгорающей не в том, берёт ли она долг, а в том, знает ли она, сколько взяла и когда планирует вернуть. Как только долг перестаёт быть стыдной тайной и превращается в строку бюджета, всё становится проще: и разговоры, и планирование, и отношения между разработкой и бизнесом.
Расскажите, а как у вас в команде — вы уже переводили технический долг в деньги, и какая метрика оказалась самой убедительной для вашего руководства?
Технический долг — это ровно тот же долг, что и финансовый, и это не метафора, а рабочая аналогия. У него есть тело (сумма, которую нужно отдать), есть проценты (то, что мы платим каждый спринт в виде замедления) и есть кредиторы (конкретные люди, которые ждут свою фичу, а получают её позже). Как только я начал описывать долг в этих терминах, разговор поменялся. Бизнесу не нужно покупать чистый код. Бизнесу нужно покупать скорость, предсказуемость и меньший риск — а чистый код всего лишь инструмент, который это обеспечивает.
Мой рабочий способ перевода — четыре числа, которые я собираю сам, без героических усилий. Первое: сколько времени команда тратит на задачи, которые не двигают продукт вперёд, — горящие баги, ручные выкладки, обходы известных ограничений. Второе: сколько стоит один инцидент, включая часы дежурных, потерянные сделки и репутационные последствия. Третье: сколько дней занимает онбординг нового разработчика до первой осмысленной задачи. Четвёртое: как доля техподдержки и «мелочей» растёт от квартала к кварталу. Каждое из этих чисел бизнес понимает без перевода, потому что сам ими пользуется.
Показательный пример из моей практики. Мы полгода откладывали переписывание одного старого модуля, потому что «всё же работает». Потом я сел и посчитал: каждая новая интеграция в этом модуле занимала в среднем на девять дней больше, чем в соседнем. За квартал таких интеграций было восемь. Умножил девять дней на восемь, взял стоимость команды за день и получил сумму, которая оказалась больше, чем вся смета на переписывание вместе с рисками. Я принёс не аргумент «код плохой», а картинку: вот сколько мы уже заплатили процентов и вот сколько стоит закрыть тело долга. Решение приняли на той же встрече.
Теперь я делаю это регулярно и скучно, и в этом весь секрет. Раз в квартал я собираю короткую сводку из пяти-шести строк: доля времени на неплановую работу, стоимость инцидентов, среднее время до релиза, biggest blockers с оценкой в днях. Никаких диаграмм связей и метрик сложности. Это живёт в том же документе, где планируются деньги, и обсуждается в тех же терминах. За пару лет такой практики я ни разу не слышал вопроса «а зачем нам это», потому что вопрос звучал иначе: «это дороже, чем мы думали, — что режем?»
Что бы я посоветовал тем, кто только начинает. Не врите и не завышайте числа в свою пользу: один раз пойманное преувеличение убивает доверие ко всей таблице на годы. Начинайте с одного показателя, который болит у всех, — обычно это время до релиза. Не используйте слова вроде «рефакторинг», «легаси» и «архитектурная энтропия» в отчёте для руководства: замените их на «время», «риск» и «деньги». И обязательно предлагайте не проблему, а вариант: вот цена вопроса, вот что мы получим, вот что не получим, если отложим. Бизнес прекрасно умеет выбирать, когда выбор сформулирован честно.
И ещё одно, что я понял не сразу. Технический долг — не всегда зло. Иногда взять его осознанно, чтобы проверить гипотезу быстрее, — это лучшее бизнес-решение из возможных. Разница между здоровой командой и выгорающей не в том, берёт ли она долг, а в том, знает ли она, сколько взяла и когда планирует вернуть. Как только долг перестаёт быть стыдной тайной и превращается в строку бюджета, всё становится проще: и разговоры, и планирование, и отношения между разработкой и бизнесом.
Расскажите, а как у вас в команде — вы уже переводили технический долг в деньги, и какая метрика оказалась самой убедительной для вашего руководства?