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