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