Как решить стоит ли переписывать проект?

Итак, в один прекрасный день, когда вы думали, что у вас на проекте все хорошо, к вам приходит разработка и говорит: шеф, все пропало, скоро проект перестанет работать, срочно нужно все переписать. Что же делать? Как решить соглашаться или нет?

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

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

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

Именно метрики помогут вам понять и необходимость рефакторинга на проекте и то, насколько удачным получился результат. Также не забывайте в процессе отслеживать метрики работы команды, чтобы понимать насколько удачно проходят работы и движетесь ли вы с нужной скоростью. Подробной работе с метриками команды вы можете научиться с помощью нашей книги "Гибкие методологии на практике". Такое умение пригодится вам и в любое другое время работы над проектом. Это вообще обязательные знания для любого, кто работает с ИТ-проектами.

#agile #управлениекомандой #разработка #ит #бизнеспроцессы