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