AndrewKozlov
New member
Год назад я закрыл квартал и с ужасом понял, что мы не выпустили ни одной крупной фичи. Три месяца команда чинила то, что сломалось само, переписывала места, которые «и так работают, но страшно трогать», и разбиралась с падениями на проде. Формально все были заняты, отчёты пестрели закрытыми задачами, а продукт стоял на месте. Именно тогда я впервые осознал, что техдолг — это не абстрактная метрика для инженеров, а самая настоящая строка в P&L, только её никто не видит, потому что она размазана по чужим задачам.
Первое, что я сделал — перестал спорить о вкусах и начал измерять. Две недели мы просто фиксировали, куда уходит время: сколько часов съедают инциденты и хотфиксы, сколько — доработки из-за хрупкого кода, сколько — ручные операции, которые давно пора автоматизировать. Параллельно я снял базовые метрики: время от идеи до прода, частоту откатов, долю задач, которые возвращаются с ревью или с багов, время онбординга нового разработчика. Отдельно посчитал, сколько раз в неделю мысленно говорим «здесь лучше не трогать» — это звучит наивно, но именно эти зоны потом дали самые дорогие аварии.
Дальше началась самая интересная часть — перевод технического в денежное. Часы на борьбу с последствиями умножаем на стоимость часа команды, прибавляем потери от простоя и упущенную выручку от фич, которые не вышли вовремя, добавляем ушедших клиентов и выгоревших людей, которых пришлось заменять и снова учить. Когда я собрал это в одну таблицу, цифра оказалась в разы больше, чем я готов был произнести вслух. И вот тут случился перелом: бизнес не готов обсуждать абстрактную чистоту кода, но он прекрасно понимает, почему квартальная задержка релиза стоит конкретных денег и репутации.
Главный урок по продаже техдолга: говорите на языке денег, рисков и сроков, а не на языке рефакторинга. Слова «нам нужно переписать модуль» вызывают у руководителя зевоту, а фраза «этот модуль каждые три недели роняет оплату на два часа и срывает обещанный клиентам SLA» — живой интерес. Я перестал просить «время на техдолг» и начал приносить маленький бизнес-кейс: вот проблема, вот как мы её измерили, вот что будет, если ничего не делать, вот что будет, если вложить две недели, и вот как мы это проверим. Просить стало в разы легче — потому что просил не я, а цифры.
Что реально сработало: пилот на узком участке вместо большого штурма, быстрые победы в первые две недели, чтобы руководство увидело эффект до того, как устанет ждать, и зафиксированная доля ёмкости команды, которую никто не имеет права забрать под срочные фичи. У нас это сначала двадцать процентов каждого спринта, потом договорились до трети на самых горячих направлениях. Ещё очень помог публичный дашборд: графики инцидентов, времени до восстановления и доли времени на поддержку. Когда картинка перед глазами у всех, спорить о том, есть ли проблема, уже не нужно.
Что не сработало и чему я научился на своих ошибках: большие переписывания «в тишине», без промежуточных результатов, без понятной точки выхода и без метрик до и после. Один такой проект мы тянули почти полгода, внутри всё стало красиво, а бизнес так и не понял, за что заплатил. Теперь я всегда разбиваю работу на куски, каждый кусок приносит измеримую пользу, и после каждого этапа мы сверяем цифры с теми, что были в начале. И ещё: техдолг нельзя вылечить раз и навсегда — его можно только держать под контролем, как давление у гипертоника.
Если вы сейчас в похожей ситуации, вот что я бы посоветовал. Начните с честного замера, даже грубого: неделя наблюдений лучше года дискуссий. Найдите союзника среди менеджеров, который устал объяснять клиентам задержки. Приходите не с жалобой, а с расчётом и вариантами — сколько стоит ничего не делать и сколько стоит вмешаться. Договаривайтесь о постоянной доле времени, а не о разовом героическом рывке. Показывайте результат маленькими порциями и обязательно фиксируйте состояние до и после. И не пытайтесь сделать всё сразу: техдолг побеждается не героизмом, а дисциплиной и терпением.
А теперь вопрос к вам, коллеги: какой самый неожиданный способ измерить или «продать» техдолг сработал лично у вас — может, вы нашли метрику, которая убедила руководство с первого раза, или придумали хитрый аргумент, после которого бюджет наконец выделили? Поделитесь, очень интересно собрать коллекцию рабочих приёмов.
Первое, что я сделал — перестал спорить о вкусах и начал измерять. Две недели мы просто фиксировали, куда уходит время: сколько часов съедают инциденты и хотфиксы, сколько — доработки из-за хрупкого кода, сколько — ручные операции, которые давно пора автоматизировать. Параллельно я снял базовые метрики: время от идеи до прода, частоту откатов, долю задач, которые возвращаются с ревью или с багов, время онбординга нового разработчика. Отдельно посчитал, сколько раз в неделю мысленно говорим «здесь лучше не трогать» — это звучит наивно, но именно эти зоны потом дали самые дорогие аварии.
Дальше началась самая интересная часть — перевод технического в денежное. Часы на борьбу с последствиями умножаем на стоимость часа команды, прибавляем потери от простоя и упущенную выручку от фич, которые не вышли вовремя, добавляем ушедших клиентов и выгоревших людей, которых пришлось заменять и снова учить. Когда я собрал это в одну таблицу, цифра оказалась в разы больше, чем я готов был произнести вслух. И вот тут случился перелом: бизнес не готов обсуждать абстрактную чистоту кода, но он прекрасно понимает, почему квартальная задержка релиза стоит конкретных денег и репутации.
Главный урок по продаже техдолга: говорите на языке денег, рисков и сроков, а не на языке рефакторинга. Слова «нам нужно переписать модуль» вызывают у руководителя зевоту, а фраза «этот модуль каждые три недели роняет оплату на два часа и срывает обещанный клиентам SLA» — живой интерес. Я перестал просить «время на техдолг» и начал приносить маленький бизнес-кейс: вот проблема, вот как мы её измерили, вот что будет, если ничего не делать, вот что будет, если вложить две недели, и вот как мы это проверим. Просить стало в разы легче — потому что просил не я, а цифры.
Что реально сработало: пилот на узком участке вместо большого штурма, быстрые победы в первые две недели, чтобы руководство увидело эффект до того, как устанет ждать, и зафиксированная доля ёмкости команды, которую никто не имеет права забрать под срочные фичи. У нас это сначала двадцать процентов каждого спринта, потом договорились до трети на самых горячих направлениях. Ещё очень помог публичный дашборд: графики инцидентов, времени до восстановления и доли времени на поддержку. Когда картинка перед глазами у всех, спорить о том, есть ли проблема, уже не нужно.
Что не сработало и чему я научился на своих ошибках: большие переписывания «в тишине», без промежуточных результатов, без понятной точки выхода и без метрик до и после. Один такой проект мы тянули почти полгода, внутри всё стало красиво, а бизнес так и не понял, за что заплатил. Теперь я всегда разбиваю работу на куски, каждый кусок приносит измеримую пользу, и после каждого этапа мы сверяем цифры с теми, что были в начале. И ещё: техдолг нельзя вылечить раз и навсегда — его можно только держать под контролем, как давление у гипертоника.
Если вы сейчас в похожей ситуации, вот что я бы посоветовал. Начните с честного замера, даже грубого: неделя наблюдений лучше года дискуссий. Найдите союзника среди менеджеров, который устал объяснять клиентам задержки. Приходите не с жалобой, а с расчётом и вариантами — сколько стоит ничего не делать и сколько стоит вмешаться. Договаривайтесь о постоянной доле времени, а не о разовом героическом рывке. Показывайте результат маленькими порциями и обязательно фиксируйте состояние до и после. И не пытайтесь сделать всё сразу: техдолг побеждается не героизмом, а дисциплиной и терпением.
А теперь вопрос к вам, коллеги: какой самый неожиданный способ измерить или «продать» техдолг сработал лично у вас — может, вы нашли метрику, которая убедила руководство с первого раза, или придумали хитрый аргумент, после которого бюджет наконец выделили? Поделитесь, очень интересно собрать коллекцию рабочих приёмов.