x

Добро пожаловать в IT Leader Assistant.
Please Войти!

Создать аккаунт

Что делать если IT команда опять хочет переписать проект? Как работать с рефакторингом.

Максим Шаламов
05-05-2021 13:02
Что делать если IT команда опять хочет переписать проект? Как работать с рефакторингом.

Введение

Сегодня я хотел бы поговорить о частой проблеме, особенно со старыми проектам: желанием команды разработки переписать или значительно переработать проект и большим нежеланием продуктовой команды это допускать. Я постараюсь посмотреть на вопрос со стороны и разработки и бизнеса, а также дам советы из своей практики. В статье я исхожу из ситуации, когда рефакторинг или переписывание проекта действительно назрело и есть четкий план как его производить.

Отношение IT команды к проекту

Хочу сразу развеять еще один распространенный миф. Среди бизнес команд многих проектов бытует мнение, что IT команде совсем не интересен продукт - это не так. Все любят делать проект для людей, чтобы им пользовались и чтобы он приносил пользу. Ничего так не демотивирует команду, как задачи сделанные “в стол”. Ситуации, когда кажется, что команда разработки совсем не интересуется продуктом, скорее всего говорят о проблемах на проекте, и с этим нужно срочно разбираться. Несмотря на то, что команде разработки важен продукт, нужно понимать, что IT команда отвечает за работоспособность проекта и занимается кодовой базой проекта каждый рабочий день, большую часть своего рабочего времени. Поэтому качество и удовлетворенность от работы с кодовой базой проекта со временем перевесят все крутые фичи, которые можно выпустить. Мотивация от работы с запущенным кодом быстро падает и начинается текучка. Об этом нужно помнить всем участникам команды, так как страдает от этого не только техническая часть проекта, но и продуктовая.

Метрики, как обязательная составляющая рефакторинга

Первое о чем я бы хотел поговорить и о чем обычно забывают - это метрики. Нельзя подходить к вопросу о глобальном рефакторинге или отказе от него без метрик. Метрики могут быть как влияющими на бизнес на прямую, например баги, t2m и скорость работы проекта. Так и косвенно влияющие на бизнес составляющую.: скорость погружения сотрудников в проект, количество человек владеющих кодовой базой, уровень дублирования кода (а порой и сервисов), количество возвратов pr (пулл реквестов) и тд. На самом деле все эти метрики влияют на качество продукта. Те что кажутся косвенными, обычно приводят к большой текучке и вымыванию сильных разработчиков из команды, что замедляет выпуск фич и напрямую влияет на отказоустойчивость и общее качество продукта.

Как говорить о рефакторинге со стороны IT команды

Инициаторами рефакторинга должна быть IT команда, поэтому ее задача инициировать сбор метрик, если они по какой-то причине не ведутся. Дальше нужно смотреть динамику этих метрик (например рост числа багов, рост времени починки багов и тд). После этого IT команда должна встретится с бизнес командой и обсудить с ними метрики, узнать (если еще не узнали) рост каких метрик для них критичен и насколько (обычно говорят о t2m и багах). После чего нужно представить свой план рефакторинга в котором обязательно должны быть:
  • сроки. Без сроков на рефакторинг нет смысла даже начинать разговор;
  • ресурсы. То есть что и кто вам нужен для рефакторинга;
  • потребность в остановке выпуска бизнес фич. В идеале фичи хоть какие-то выпускать нужно или договориться с бизнес командой будет очень сложно. Важно заранее продумать этот вопрос;
  • на какие метрики и как повлияют работы по рефакторингу;
  • какие запланированные шаги.
Если все разложить в таком ключе, то договориться будет возможно. Скорее всего это потребует времени и терпения, но разговор с конкретными цифрами, сроками и ресурсами проще для понимания и несет минимум субъективности.

Как реагировать на предложение о рефакторинге бизнес команде

Для представителей бизнес команд хотел бы дать совет, который позволит не только сохранить сильную и мотивированную команду, но и позволит не завести проект в тупик в техническом плане. Не упирайтесь при словах рефакторинг и переписывание, это абсолютно нормальный процесс, особенно если вы работаете по гибким методологиям (в таких процессах предугадать потребности, а значит и архитектуру на годы вперед невозможно). Требуйте понятные метрики, на которые показывают проблемы проекта, формулируйте свои приоритеты и потребности в плане метрик (t2m и тд), обсуждайте как вы этого достигнете и какими ресурсами. После рефакторинга обязательно проверяйте достижение показателей. Помните, что вы одна команда и плохо работающий проект не позволит вам развивать продукт не в меньшей степени, чем вашей IT команде.

Заключение

В заключение и для бизнеса и для IT команды хочу еще раз напомнить: помните, что вы одна команда и у вас должна быть общая цель. Не забывайте о метриках, не занимайте бескомпромиссную позицию, имейте терпение и у вас все получится.
Если у вас есть какие-то вопросы или пожелания вы можете воспользоваться формой для связи с нами:

Комментарии

Чтобы оставить комментарий, пожалуйста, авторизуйтесь

Подписывайтесь на обновления

Последние статьи из нашего блога