- PVSM.RU - https://www.pvsm.ru -
Архитектурный или проектный рефакторинг это всегда болезненная проблема на проекте. Польза от рефакторинга, для нас технических специалистов очевидна, но продать и обосновать эту идею клиенту зачастую бывает тяжело. Главная причина в том, что мы технические специалисты не знаем как говорить с бизнесом.
Главная проблема в коммуникация между техническими специалистами и людьми, которые делают деньги. Они говорят на разных языках, хотя и пытаются решить одни и те же проблемы.
Данная статья является переводом оригинала с английского: Architecture Refactoring and Design Refactoring How to Sell it Client [1]. Если у вас есть коллеги, не владеющие русским языком, они могут прочитать оригинал на моем болге.
Польза от рефакторинга очевидна для всех технических специалистов, но зачастую мы не можем донести эту идею до бизнеса. Почему так случается? Мы пропускаем несколько незначительных для нас, но очень важных шагов для бизнеса.
Разделим весь процесс на 6 простых, но обязательных шагов:
Этот шаг довольно привычен для нас технических специалистов. Рассмотрим его на реальных примерах.
Билд падает практически после каждого комита.
Есть несколько причин почему это может происходить:
Еще один пример. Деплоймент приложения занимает длительное время, а также наблюдаются проблемы с производительностью.
Основными причинами могут быть:
Следующий шаг немного сложнее, но все еще привычный и несложный для разработчиков senior+. Мы все хорошие технические специалисты и всегда знаем, что должно быть улучшено. И в этот момент мы совершаем ошибку и бежим к клиенту со словами давай сделаем это.
Но мы разумные архитекторы и будем следовать нашему плану из 6 шагов шаг за шагом.
На основе предыдущего примера с монолитным приложением, решения очевидны. Разбить большое сложное приложение на более маленькие независимые модули. Это первые шаги к сервес-ориентированной или микросервисной архитектуре.
Разделим этот шаг на две фазы: техническое и бизнес обоснование.
Техническое обоснование выглядит логично для нас. Разбить монолит на более мелкие сервиса, в следствии чего мы получим:
Обоснование с точки зрения бизнеса – очень важный шаг, про который часто забывают технические специалисты. Вы должны помнить, что важно для бизнеса. Правильно – это деньги.
Если кратко: если рефакторинг не приносит пользу бизнесу – его нет смысла делать.
На основе нашего примера, вы можете предложить клиенту следующие преимущества:
План должен быть четким и детальным. Каждая итерация должна быть четко описана и должны быть задокументированы все архитектурные и дизайнерские изменения.
Создавай свой план вы должны ответить на следующие вопросы:
Очень важный шаг. Не пожалейте времени на это, если действительно хотите продать рефакторинг бизнесу.
Каждый менеджер и бизнесмен хочет знать ответы на два вопроса:
Постарайтесь разбить рефакторинг на маленькие итерации. Каждая итерация должна приносить техническую и бизнес ценность. Довольно тяжело продать рефакторинг на годы и стоимостью в миллионы долларов без каких-либо промежуточных результатов.
Каждая итерация должна содержать информацию о продолжительности и количестве специалистов необходимых для этого. Эта информация поможет ответить менеджеру на два основных вопроса заданных чуть выше.
Собирайте метрики проекта до и после рефакторинга на каждой итерации. Это поможет вам показать какую техническую и бизнес ценность принесла эта итерация.
Прежде чем пойти со своим решением к бизнесу, проверь его со своим непосредственным менеджером. Взгляд со стороны всегда хорошо, особенно если это взгляд со стороны бизнеса. Возможно, у вашего менеджера больше контекста и он поможет вам поменять план в соответствии с ожиданиями бизнеса.
Вы должны знать как ответить на классический вопрос.
Обычно когда вы презентуете архитектурный рефакторинг, бизнес может спросить. Почему нам нужен рефакторинг? В прошлом году мы потратили достаточно средств на архитектуру, а теперь у нас снова проблемы.
На классический вопрос есть классический ответ. Этот архитектурное решение было хорошо год назад, но бизнес растет и меняется и архитектура должна меняться вместе с ним.
Совет №2. Не заставляете паниковать своего клиента. Предоставляйте информации как срочную, но не как катастрофа. Скажите, что у вас есть полгода на рефакторинг, но начинать его надо прям сегодня.
Напоследок. Презентуя свое решение старайтесь образовывать людей, а не обвинять. Помните, что, обвиняя людей вы столкнетесь с сопротивлением с их стороны. Вы должны искать пути решения проблем, а не виновных.
Больше статей по архитектуре и architecture soft skills [2] вы найдете на оригинальном ресурсе.
Всем хорошего рефакторинга!
Автор: lehaalexx
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/349694
Ссылки в тексте:
[1] Architecture Refactoring and Design Refactoring How to Sell it Client: http://alexandvira.com/architecture/architecture-refactoring-and-design-refactoring-how-to-sell-it-client/
[2] architecture soft skills: http://alexandvira.com/category/architecture/
[3] Источник: https://habr.com/ru/post/492454/?utm_source=habrahabr&utm_medium=rss&utm_campaign=492454
Нажмите здесь для печати.