Alex.Kiselev
New member
Когда я впервые столкнулся с проблемой технического долга, мне казалось, что я единственный, кто видит в этом катастрофу. Мой коллега сказал: «Давай потом, когда будут деньги». Потом не наступало никогда. С тех пор я понял, что проблема не в том, что бизнес не хочет выделять время на рефакторинг. Проблема в том, что мы, инженеры, плохо умеем говорить о долге на языке, который бизнес понимает.
Нажать чтобы Перейти на сайт
Я работал в команде, где мы месяцами пинали друг друга за «медленный код», пока не поняли: никто не считал реальную цену. Мы потратили три недели на то, чтобы измерить, сколько часов в месяц разработчики тратят на обходные решения и отладку чужих костылей. Результат был шокирующим: около двадцати процентов рабочего времени уходило на борьбу с последствиями долга. Это были не абстрактные «медленные запросы» — это были реальные деньги.
Второй шаг — перевести технический язык в язык бизнеса. Вместо «у нас кросс-слоевые зависимости и низкая связность» я начал говорить: «Если мы не разделим модули сейчас, то через полгода каждый новый фичу будет требовать два разработчика вместо одного». Вместо «тестовый покрытие проседает» — «мы не можем безопасно деплоить в пятницу, потому что каждый релиз — это лотерея». Бизнес слышит про риски, сроки и деньги. Технический долг нужно продавать как инвестицию, а не как уборку.
Третий шаг, который я усвоил на собственном горьком опыте — начинать с малого. Когда я впервые попросил у менеджера «мне нужно два спринта на рефакторинг», я получил отказ. Но когда я предложил выделить десять процентов каждого спринта на уменьшение долга и показал, что это не блокирует новые фичи, а ускоряет их доставку, сопротивление рухнуло. Маленькие, регулярные инвестиции в качество работают лучше, чем эпические двухнедельные марафоны.
Узнать подробнее →
Наконец, важно показать результат. Мы начали вести простой трекер: сколько багов было до рефакторинга и сколько после. Через два месяца количество критических дефектов упало на треть, а время деплоя сократилось с часа до пятнадцати минут. Эти цифры говорят сами за себя. Бизнес не против рефакторинга — бизнес против непрозрачности и непредсказуемости. Покажите, что вы управляете этим процессом, и деньги найдутся.
А как вы подходите к вопросу убеждения бизнеса выделить время на технический долг? Удалось ли вам найти формулировки, которые заставили менеджеров выделить ресурсы на рефакторинг? Делитесь опытом в комментариях.
По теме советую почитать: Монетизация open source: личный опыт
Нажать чтобы Перейти на сайтЯ работал в команде, где мы месяцами пинали друг друга за «медленный код», пока не поняли: никто не считал реальную цену. Мы потратили три недели на то, чтобы измерить, сколько часов в месяц разработчики тратят на обходные решения и отладку чужих костылей. Результат был шокирующим: около двадцати процентов рабочего времени уходило на борьбу с последствиями долга. Это были не абстрактные «медленные запросы» — это были реальные деньги.
Второй шаг — перевести технический язык в язык бизнеса. Вместо «у нас кросс-слоевые зависимости и низкая связность» я начал говорить: «Если мы не разделим модули сейчас, то через полгода каждый новый фичу будет требовать два разработчика вместо одного». Вместо «тестовый покрытие проседает» — «мы не можем безопасно деплоить в пятницу, потому что каждый релиз — это лотерея». Бизнес слышит про риски, сроки и деньги. Технический долг нужно продавать как инвестицию, а не как уборку.
Третий шаг, который я усвоил на собственном горьком опыте — начинать с малого. Когда я впервые попросил у менеджера «мне нужно два спринта на рефакторинг», я получил отказ. Но когда я предложил выделить десять процентов каждого спринта на уменьшение долга и показал, что это не блокирует новые фичи, а ускоряет их доставку, сопротивление рухнуло. Маленькие, регулярные инвестиции в качество работают лучше, чем эпические двухнедельные марафоны.
Узнать подробнее →Наконец, важно показать результат. Мы начали вести простой трекер: сколько багов было до рефакторинга и сколько после. Через два месяца количество критических дефектов упало на треть, а время деплоя сократилось с часа до пятнадцати минут. Эти цифры говорят сами за себя. Бизнес не против рефакторинга — бизнес против непрозрачности и непредсказуемости. Покажите, что вы управляете этим процессом, и деньги найдутся.
А как вы подходите к вопросу убеждения бизнеса выделить время на технический долг? Удалось ли вам найти формулировки, которые заставили менеджеров выделить ресурсы на рефакторинг? Делитесь опытом в комментариях.
По теме советую почитать: Монетизация open source: личный опыт