Cozy_Svetlana
New member
Привет, форумчане! Хочу поделиться своим опытом, как я научился считать техдолг и, что важнее, доносить его стоимость до CEO. Долгое время в нашей команде техдолг был чем-то вроде фонового шума: все знают, что он есть, но никто не воспринимает его как финансовую проблему. Пока однажды CEO не спросил: «Почему мы так медленно выпускаем фичи?» Вот тогда я понял, что пора переводить технические страдания на язык бизнеса.
В тот момент мы работали над продуктом, которому было лет пять. Каждый спринт уходил на тушение пожаров: то интеграция отвалится, то тесты падают, то на онбординг нового разработчика уходит месяц. Я решил посчитать. Взял две недели и скрупулёзно записывал, сколько времени команда тратит на обходные пути, переписывание старого кода и разбор багов, которые появились из-за кривых архитектурных решений. Получилось, что примерно 40% спринта уходит не на развитие продукта, а на борьбу с последствиями техдолга.
Дальше я перевёл это в деньги. Умножил часы на среднюю стоимость часа разработчика, прибавил потери от задержек релизов и упущенную выручку. Цифра получилась неприлично большой — как если бы мы каждый месяц выбрасывали на ветер зарплату двух инженеров. Я оформил это в простую таблицу: вот сколько мы теряем сейчас, вот сколько потратим на рефакторинг, а вот сколько сэкономим за год. CEO не нужно было объяснять про «чистый код» — он увидел прямую упущенную прибыль.
Главный урок: CEO не обязан разбираться в SOLID и паттернах. Ему важно знать, как техдолг влияет на скорость, риски и деньги. Поэтому мой совет — говорите не о качестве кода, а о стоимости бездействия. Например: «Каждый месяц мы теряем X часов на ручные фиксы, из-за этого релиз новой функции задерживается на Y недель, и мы недополучаем Z рублей». Это работает безотказно, потому что бизнес мыслит цифрами.
Ещё один приём, который мне помог: не предлагать «всё переписать». CEO пугается больших бюджетов и долгих сроков. Лучше разбить техдолг на небольшие куски и показать быстрые победы. Мы начали с одного модуля, который чаще всего ломался. За месяц привели его в порядок, и количество инцидентов упало на 70%. После этого CEO сам спросил: «А что ещё можно починить?» Так техдолг перестал быть запретной темой и вошёл в регулярный планинг.
Теперь я веду учёт техдолга как финансового показателя. Раз в квартал мы оцениваем, сколько он нам стоит, и закладываем в бэклог задачи на его снижение. Это не значит, что мы тратим на это всё время, но у нас есть прозрачный баланс между фичами и здоровьем кода. Коллеги, а как вы считаете техдолг в своей команде? Есть ли у вас рабочие способы убедить руководство? Поделитесь историями — уверен, многим будет полезно!
В тот момент мы работали над продуктом, которому было лет пять. Каждый спринт уходил на тушение пожаров: то интеграция отвалится, то тесты падают, то на онбординг нового разработчика уходит месяц. Я решил посчитать. Взял две недели и скрупулёзно записывал, сколько времени команда тратит на обходные пути, переписывание старого кода и разбор багов, которые появились из-за кривых архитектурных решений. Получилось, что примерно 40% спринта уходит не на развитие продукта, а на борьбу с последствиями техдолга.
Дальше я перевёл это в деньги. Умножил часы на среднюю стоимость часа разработчика, прибавил потери от задержек релизов и упущенную выручку. Цифра получилась неприлично большой — как если бы мы каждый месяц выбрасывали на ветер зарплату двух инженеров. Я оформил это в простую таблицу: вот сколько мы теряем сейчас, вот сколько потратим на рефакторинг, а вот сколько сэкономим за год. CEO не нужно было объяснять про «чистый код» — он увидел прямую упущенную прибыль.
Главный урок: CEO не обязан разбираться в SOLID и паттернах. Ему важно знать, как техдолг влияет на скорость, риски и деньги. Поэтому мой совет — говорите не о качестве кода, а о стоимости бездействия. Например: «Каждый месяц мы теряем X часов на ручные фиксы, из-за этого релиз новой функции задерживается на Y недель, и мы недополучаем Z рублей». Это работает безотказно, потому что бизнес мыслит цифрами.
Ещё один приём, который мне помог: не предлагать «всё переписать». CEO пугается больших бюджетов и долгих сроков. Лучше разбить техдолг на небольшие куски и показать быстрые победы. Мы начали с одного модуля, который чаще всего ломался. За месяц привели его в порядок, и количество инцидентов упало на 70%. После этого CEO сам спросил: «А что ещё можно починить?» Так техдолг перестал быть запретной темой и вошёл в регулярный планинг.
Теперь я веду учёт техдолга как финансового показателя. Раз в квартал мы оцениваем, сколько он нам стоит, и закладываем в бэклог задачи на его снижение. Это не значит, что мы тратим на это всё время, но у нас есть прозрачный баланс между фичами и здоровьем кода. Коллеги, а как вы считаете техдолг в своей команде? Есть ли у вас рабочие способы убедить руководство? Поделитесь историями — уверен, многим будет полезно!