Alex.Miller
New member
Привет, форумчане. Хочу рассказать историю, которая стоила нашей компании нескольких миллионов рублей упущенной выручки и научила меня считать технический долг не в сторипоинтах, а в деньгах. Долгие годы я, как технический директор, воспринимал его как абстрактную инженерную категорию: код некрасивый, тестов мало, зато фичи летят в прод и все довольны. Пока CEO на планёрке не спросил меня прямым текстом: сколько нам стоит то, что релизы буксуют. И я не смог ответить. Это был неприятный, но очень полезный момент.
Начиналось всё банально. Мы собрали MVP на монолите, два бэкендера, один фронтендер, релизы руками по пятницам, «временных» решений накидали столько, что половина уже не помнила, зачем они нужны. Каждый спринт мы обещали вычистить хвосты, и каждый спринт находилась фича поважнее. Классика жанра. Я тогда искренне считал, что мы экономим время, а на самом деле мы брали кредит под очень невыгодный процент и платили по нему из прибыли, просто не видели строчки в отчёте.
Первым тревожным звонком стало то, что доля времени на багфиксы и поддержку выросла с пятнадцати процентов до почти половины инженерной ёмкости. Мы наняли ещё троих разработчиков, а скорость выпуска не изменилась: новые люди тонули в онбординге по три месяца и боялись трогать старый код. Потом случилась авария в самый разгар сезонной распродажи, мы потеряли два дня продаж и пару крупных клиентов. Тогда я сел и начал переводить технический долг в понятный бизнесу язык. И знаете, цифры оказались настолько неприятными, что спорить с ними перестали даже самые ярые сторонники скорости любой ценой.
Вот метрики, которые я считаю обязательными для любого CTO, если рядом сидит CEO. Первая группа — классические показатели потока: время от коммита до прода, частота релизов, доля неудачных релизов и время восстановления после инцидента. Они отлично показывают, насколько команда способна быстро и безопасно доставлять изменения. Вторая группа — то, что я называю налогом на долг: доля инженерного времени, уходящая на поддержку и латание дыр, а не на развитие продукта, и стоимость изменения. Если простая правка интерфейса занимает неделю вместо дня, вы уже платите проценты. Третья группа — человеческие метрики: время онбординга нового разработчика, текучесть кадров в команде и количество задач, которые никто не рискует взять.
Самое важное — научиться умножать всё это на деньги и время. Час инженера стоит вполне конкретную сумму, значит сорок процентов ёмкости на поддержку — это конкретный ежемесячный расход, который не создаёт ничего нового. Задержка релиза на месяц — это упущенная выручка, а не абстрактная строчка в бэклоге. Инцидент — это потерянные продажи, сгоревшая репутация и премии поддержки за ночные смены. Сложный код — это лишние деньги на найм, потому что хорошие специалисты не хотят поддерживать легаси и уходят туда, где можно строить. Как только я начал приходить на совет директоров с такой таблицей, разговор про рефакторинг перестал быть разговором про эстетику и стал разговором про эффективность вложений.
Что мы сделали практически. Завели реестр технического долга: каждая проблема — это тикет с оценкой, влиянием на бизнес и владельцем, а не безымянное «когда-нибудь починим». Договорились резервировать около двадцати процентов ёмкости каждого спринта на долг, и это перестало быть наказанием, потому что результат стало видно в метриках. Метрики потока и налога на долг вывели на один дашборд рядом с выручкой и конверсией, чтобы инженерные цифры жили в одной комнате с бизнесовыми. И раз в квартал я делаю короткий отчёт для CEO и совета: столько-то часов ушло в поддержку, столько-то выручки потеряли на задержках, вот что мы починили и вот что нам это дало. Никакой магии, просто дисциплина и честные числа.
Через полгода такой работы время до прода сократилось примерно втрое, доля времени на поддержку вернулась к третьей части, а отток клиентов заметно замедлился. Но главный эффект был не в этом, а в том, что у нас появился общий язык. Инженеры перестали оправдываться, а бизнес перестал воспринимать долг как выдумку ленивых программистов. Что советую вам: начните хотя бы с одной метрики, например с доли времени на поддержку, измерьте её честно, а потом переведите в деньги. Не пытайтесь вычистить всё сразу, не превращайте погашение долга в самоцель и обязательно фиксируйте состояние до и после, иначе вам никто не поверит на слово.
Свою главную ошибку я тоже признаю: я годами не говорил с бизнесом цифрами, потому что считал, что меня и так должны понимать как профессионала. Не должны. Понимают только язык денег, времени и рисков, и это нормально, а не цинизм. А теперь вопрос к вам, форумчане: какая метрика первой заставила ваших руководителей относиться к техническому долгу серьёзно, и что помогло вам превратить инженерные проблемы в понятный бизнесу аргумент? Поделитесь опытом, вместе мы точно придумаем формулу убедительнее.
Начиналось всё банально. Мы собрали MVP на монолите, два бэкендера, один фронтендер, релизы руками по пятницам, «временных» решений накидали столько, что половина уже не помнила, зачем они нужны. Каждый спринт мы обещали вычистить хвосты, и каждый спринт находилась фича поважнее. Классика жанра. Я тогда искренне считал, что мы экономим время, а на самом деле мы брали кредит под очень невыгодный процент и платили по нему из прибыли, просто не видели строчки в отчёте.
Первым тревожным звонком стало то, что доля времени на багфиксы и поддержку выросла с пятнадцати процентов до почти половины инженерной ёмкости. Мы наняли ещё троих разработчиков, а скорость выпуска не изменилась: новые люди тонули в онбординге по три месяца и боялись трогать старый код. Потом случилась авария в самый разгар сезонной распродажи, мы потеряли два дня продаж и пару крупных клиентов. Тогда я сел и начал переводить технический долг в понятный бизнесу язык. И знаете, цифры оказались настолько неприятными, что спорить с ними перестали даже самые ярые сторонники скорости любой ценой.
Вот метрики, которые я считаю обязательными для любого CTO, если рядом сидит CEO. Первая группа — классические показатели потока: время от коммита до прода, частота релизов, доля неудачных релизов и время восстановления после инцидента. Они отлично показывают, насколько команда способна быстро и безопасно доставлять изменения. Вторая группа — то, что я называю налогом на долг: доля инженерного времени, уходящая на поддержку и латание дыр, а не на развитие продукта, и стоимость изменения. Если простая правка интерфейса занимает неделю вместо дня, вы уже платите проценты. Третья группа — человеческие метрики: время онбординга нового разработчика, текучесть кадров в команде и количество задач, которые никто не рискует взять.
Самое важное — научиться умножать всё это на деньги и время. Час инженера стоит вполне конкретную сумму, значит сорок процентов ёмкости на поддержку — это конкретный ежемесячный расход, который не создаёт ничего нового. Задержка релиза на месяц — это упущенная выручка, а не абстрактная строчка в бэклоге. Инцидент — это потерянные продажи, сгоревшая репутация и премии поддержки за ночные смены. Сложный код — это лишние деньги на найм, потому что хорошие специалисты не хотят поддерживать легаси и уходят туда, где можно строить. Как только я начал приходить на совет директоров с такой таблицей, разговор про рефакторинг перестал быть разговором про эстетику и стал разговором про эффективность вложений.
Что мы сделали практически. Завели реестр технического долга: каждая проблема — это тикет с оценкой, влиянием на бизнес и владельцем, а не безымянное «когда-нибудь починим». Договорились резервировать около двадцати процентов ёмкости каждого спринта на долг, и это перестало быть наказанием, потому что результат стало видно в метриках. Метрики потока и налога на долг вывели на один дашборд рядом с выручкой и конверсией, чтобы инженерные цифры жили в одной комнате с бизнесовыми. И раз в квартал я делаю короткий отчёт для CEO и совета: столько-то часов ушло в поддержку, столько-то выручки потеряли на задержках, вот что мы починили и вот что нам это дало. Никакой магии, просто дисциплина и честные числа.
Через полгода такой работы время до прода сократилось примерно втрое, доля времени на поддержку вернулась к третьей части, а отток клиентов заметно замедлился. Но главный эффект был не в этом, а в том, что у нас появился общий язык. Инженеры перестали оправдываться, а бизнес перестал воспринимать долг как выдумку ленивых программистов. Что советую вам: начните хотя бы с одной метрики, например с доли времени на поддержку, измерьте её честно, а потом переведите в деньги. Не пытайтесь вычистить всё сразу, не превращайте погашение долга в самоцель и обязательно фиксируйте состояние до и после, иначе вам никто не поверит на слово.
Свою главную ошибку я тоже признаю: я годами не говорил с бизнесом цифрами, потому что считал, что меня и так должны понимать как профессионала. Не должны. Понимают только язык денег, времени и рисков, и это нормально, а не цинизм. А теперь вопрос к вам, форумчане: какая метрика первой заставила ваших руководителей относиться к техническому долгу серьёзно, и что помогло вам превратить инженерные проблемы в понятный бизнесу аргумент? Поделитесь опытом, вместе мы точно придумаем формулу убедительнее.