KateThomas
New member
Лет семь назад я пытался продать своему директору идею выделить отдельный спринт на рефакторинг. Принёс красивую презентацию с диаграммой зависимостей, показал циклические связи между модулями и честно сказал, что кодовая база гниёт. Директор покивал, попросил не тратить его время на технические детали и спросил, сколько денег мы теряем. Я не смог ответить. Спринт мне не дали. С тех пор я перестал ходить к бизнесу с чисто инженерными аргументами.
Тогда я начал считать. Первое, что стало понятно: технический долг — это не абстракция, а вполне конкретные денежные потоки, просто они размазаны по статьям бюджета и потому невидимы. Переработки на релизах, часы поддержки в выходные, замедление онбординга новых разработчиков, потерянные сделки из-за того, что фича выходит на месяц позже обещанного. Когда я сложил это в одну таблицу за год, сумма оказалась больше, чем стоила вся перепилка злополучного модуля.
Методика, к которой я пришёл, состоит из трёх шагов. Сначала инвентаризация: я прошу команду составить список болевых точек и для каждой назвать признаки — частоту инцидентов, время ручных операций, число людей, которые боятся трогать этот код. Потом оценка: каждую точку перевожу в часы и деньги по трём линиям — прямые потери на поддержку, потеря скорости поставки и риск. Риск считаю через вероятность и стоимость худшего сценария, например падения платежей на сутки. И только потом приоритизация.
Для приоритизации я использую простую матрицу: по одной оси стоимость устранения, по другой годовой размер потерь. Всё, что попадает в зону высокой потери при низкой стоимости, уходит в ближайшие два-три спринта, обычно это нелепые мелочи вроде отсутствия нормального логирования или вечно падающего пайплайна. Долг с высокой стоимостью исправления я разбиваю на части и защищаю как отдельный проект с ежемесячными контрольными точками, потому что большой запрос на переписывание почти всегда проигрывает конкуренцию за бюджет.
Разговор с CFO у меня теперь строится строго вокруг трёх чисел. Сколько мы тратим сейчас, сколько потратим, если ничего не менять, и сколько нужно вложить, чтобы эти траты снизить. Никаких слов вроде архитектура, легаси и связанность — их оставляю для встреч внутри команды. Вместо этого говорю о стоимости задержки, о риске остановки выручки и о том, что часть бюджета на поддержку можно перебросить на разработку новых продуктов. Финансисты прекрасно понимают язык сценариев, им не нужны детали реализации, им нужны допущения и диапазоны.
Главная ошибка, которую я совершал раньше и которую вижу у коллег, — пытаться продать технический долг как вопрос профессиональной совести. Бизнесу всё равно, насколько красиво написан код. Ему важно, чтобы продукт не падал, фичи выходили в срок и расходы были предсказуемыми. Поэтому я всегда привязываю работы по долгу к конкретным бизнес-целям: ускорить выход на новый рынок, снизить нагрузку на поддержку перед сезоном, подготовиться к аудиту или к росту нагрузки в пять раз.
Что бы я посоветовал читателям. Не ждите, пока долг превратится в пожар, заведите привычку раз в квартал обновлять реестр технических рисков с денежной оценкой. Держите наготове один короткий и один длинный сценарий улучшений, чтобы воспользоваться удобным моментом в бюджете. И обязательно фиксируйте результат после каждого вложения, иначе в следующий раз вам просто не поверят. А как у вас в компании говорят о техническом долге — есть уже привычка считать его в деньгах или пока всё держится на энтузиазме отдельных инженеров?
Тогда я начал считать. Первое, что стало понятно: технический долг — это не абстракция, а вполне конкретные денежные потоки, просто они размазаны по статьям бюджета и потому невидимы. Переработки на релизах, часы поддержки в выходные, замедление онбординга новых разработчиков, потерянные сделки из-за того, что фича выходит на месяц позже обещанного. Когда я сложил это в одну таблицу за год, сумма оказалась больше, чем стоила вся перепилка злополучного модуля.
Методика, к которой я пришёл, состоит из трёх шагов. Сначала инвентаризация: я прошу команду составить список болевых точек и для каждой назвать признаки — частоту инцидентов, время ручных операций, число людей, которые боятся трогать этот код. Потом оценка: каждую точку перевожу в часы и деньги по трём линиям — прямые потери на поддержку, потеря скорости поставки и риск. Риск считаю через вероятность и стоимость худшего сценария, например падения платежей на сутки. И только потом приоритизация.
Для приоритизации я использую простую матрицу: по одной оси стоимость устранения, по другой годовой размер потерь. Всё, что попадает в зону высокой потери при низкой стоимости, уходит в ближайшие два-три спринта, обычно это нелепые мелочи вроде отсутствия нормального логирования или вечно падающего пайплайна. Долг с высокой стоимостью исправления я разбиваю на части и защищаю как отдельный проект с ежемесячными контрольными точками, потому что большой запрос на переписывание почти всегда проигрывает конкуренцию за бюджет.
Разговор с CFO у меня теперь строится строго вокруг трёх чисел. Сколько мы тратим сейчас, сколько потратим, если ничего не менять, и сколько нужно вложить, чтобы эти траты снизить. Никаких слов вроде архитектура, легаси и связанность — их оставляю для встреч внутри команды. Вместо этого говорю о стоимости задержки, о риске остановки выручки и о том, что часть бюджета на поддержку можно перебросить на разработку новых продуктов. Финансисты прекрасно понимают язык сценариев, им не нужны детали реализации, им нужны допущения и диапазоны.
Главная ошибка, которую я совершал раньше и которую вижу у коллег, — пытаться продать технический долг как вопрос профессиональной совести. Бизнесу всё равно, насколько красиво написан код. Ему важно, чтобы продукт не падал, фичи выходили в срок и расходы были предсказуемыми. Поэтому я всегда привязываю работы по долгу к конкретным бизнес-целям: ускорить выход на новый рынок, снизить нагрузку на поддержку перед сезоном, подготовиться к аудиту или к росту нагрузки в пять раз.
Что бы я посоветовал читателям. Не ждите, пока долг превратится в пожар, заведите привычку раз в квартал обновлять реестр технических рисков с денежной оценкой. Держите наготове один короткий и один длинный сценарий улучшений, чтобы воспользоваться удобным моментом в бюджете. И обязательно фиксируйте результат после каждого вложения, иначе в следующий раз вам просто не поверят. А как у вас в компании говорят о техническом долге — есть уже привычка считать его в деньгах или пока всё держится на энтузиазме отдельных инженеров?