Архитектурный или проектный рефакторинг это всегда болезненная проблема на проекте. Польза от рефакторинга, для нас технических специалистов очевидна, но продать и обосновать эту идею клиенту зачастую бывает тяжело. Главная причина в том, что мы технические специалисты не знаем как говорить с бизнесом.
Главная проблема в коммуникация между техническими специалистами и людьми, которые делают деньги. Они говорят на разных языках, хотя и пытаются решить одни и те же проблемы.
Данная статья является переводом оригинала с английского: Architecture Refactoring and Design Refactoring How to Sell it Client. Если у вас есть коллеги, не владеющие русским языком, они могут прочитать оригинал на моем болге.
Польза от рефакторинга очевидна для всех технических специалистов, но зачастую мы не можем донести эту идею до бизнеса. Почему так случается? Мы пропускаем несколько незначительных для нас, но очень важных шагов для бизнеса.
Разделим весь процесс на 6 простых, но обязательных шагов:
Этот шаг довольно привычен для нас технических специалистов. Рассмотрим его на реальных примерах.
Билд падает практически после каждого комита.
Есть несколько причин почему это может происходить:
Еще один пример. Деплоймент приложения занимает длительное время, а также наблюдаются проблемы с производительностью.
Основными причинами могут быть:
Следующий шаг немного сложнее, но все еще привычный и несложный для разработчиков senior+. Мы все хорошие технические специалисты и всегда знаем, что должно быть улучшено. И в этот момент мы совершаем ошибку и бежим к клиенту со словами давай сделаем это.
Но мы разумные архитекторы и будем следовать нашему плану из 6 шагов шаг за шагом.
На основе предыдущего примера с монолитным приложением, решения очевидны. Разбить большое сложное приложение на более маленькие независимые модули. Это первые шаги к сервес-ориентированной или микросервисной архитектуре.
Разделим этот шаг на две фазы: техническое и бизнес обоснование.
Техническое обоснование выглядит логично для нас. Разбить монолит на более мелкие сервиса, в следствии чего мы получим:
Обоснование с точки зрения бизнеса – очень важный шаг, про который часто забывают технические специалисты. Вы должны помнить, что важно для бизнеса. Правильно – это деньги.
Если кратко: если рефакторинг не приносит пользу бизнесу – его нет смысла делать.
На основе нашего примера, вы можете предложить клиенту следующие преимущества:
План должен быть четким и детальным. Каждая итерация должна быть четко описана и должны быть задокументированы все архитектурные и дизайнерские изменения.
Создавай свой план вы должны ответить на следующие вопросы:
Очень важный шаг. Не пожалейте времени на это, если действительно хотите продать рефакторинг бизнесу.
Каждый менеджер и бизнесмен хочет знать ответы на два вопроса:
Постарайтесь разбить рефакторинг на маленькие итерации. Каждая итерация должна приносить техническую и бизнес ценность. Довольно тяжело продать рефакторинг на годы и стоимостью в миллионы долларов без каких-либо промежуточных результатов.
Каждая итерация должна содержать информацию о продолжительности и количестве специалистов необходимых для этого. Эта информация поможет ответить менеджеру на два основных вопроса заданных чуть выше.
Собирайте метрики проекта до и после рефакторинга на каждой итерации. Это поможет вам показать какую техническую и бизнес ценность принесла эта итерация.
Прежде чем пойти со своим решением к бизнесу, проверь его со своим непосредственным менеджером. Взгляд со стороны всегда хорошо, особенно если это взгляд со стороны бизнеса. Возможно, у вашего менеджера больше контекста и он поможет вам поменять план в соответствии с ожиданиями бизнеса.
Вы должны знать как ответить на классический вопрос.
Обычно когда вы презентуете архитектурный рефакторинг, бизнес может спросить. Почему нам нужен рефакторинг? В прошлом году мы потратили достаточно средств на архитектуру, а теперь у нас снова проблемы.
На классический вопрос есть классический ответ. Этот архитектурное решение было хорошо год назад, но бизнес растет и меняется и архитектура должна меняться вместе с ним.
Совет №2. Не заставляете паниковать своего клиента. Предоставляйте информации как срочную, но не как катастрофа. Скажите, что у вас есть полгода на рефакторинг, но начинать его надо прям сегодня.
Напоследок. Презентуя свое решение старайтесь образовывать людей, а не обвинять. Помните, что, обвиняя людей вы столкнетесь с сопротивлением с их стороны. Вы должны искать пути решения проблем, а не виновных.
Больше статей по архитектуре и architecture soft skills вы найдете на оригинальном ресурсе.
Всем хорошего рефакторинга!
Главная проблема в коммуникация между техническими специалистами и людьми, которые делают деньги. Они говорят на разных языках, хотя и пытаются решить одни и те же проблемы.
Данная статья является переводом оригинала с английского: Architecture Refactoring and Design Refactoring How to Sell it Client. Если у вас есть коллеги, не владеющие русским языком, они могут прочитать оригинал на моем болге.
Польза от рефакторинга очевидна для всех технических специалистов, но зачастую мы не можем донести эту идею до бизнеса. Почему так случается? Мы пропускаем несколько незначительных для нас, но очень важных шагов для бизнеса.
Разделим весь процесс на 6 простых, но обязательных шагов:
- Определить причину проблемы
- Решить какие изменения должны быть сделаны
- Обоснование решения
- Составить план рефакторинга
- Создать roadmap
- Презентовать свое решение
Найдите причину проблемы
Этот шаг довольно привычен для нас технических специалистов. Рассмотрим его на реальных примерах.
Билд падает практически после каждого комита.
Есть несколько причин почему это может происходить:
- Компоненты приложения очень тесно связаны между собой и зависят друг от друга
- Компоненты приложения не имеют должной изоляции между собой
- Отсутствие unit тестов
- Отсутствие SDLC процессов и CI/CD
Еще один пример. Деплоймент приложения занимает длительное время, а также наблюдаются проблемы с производительностью.
Основными причинами могут быть:
- Монолитное приложение растет быстро и стало слишком большим для одного приложения
- Приложение большое и потребляет много оперативной памяти и процессорных мощностей
- Приложение сложное и написано не эффективно
Решаем какие изменения должны быть сделаны
Следующий шаг немного сложнее, но все еще привычный и несложный для разработчиков senior+. Мы все хорошие технические специалисты и всегда знаем, что должно быть улучшено. И в этот момент мы совершаем ошибку и бежим к клиенту со словами давай сделаем это.
Но мы разумные архитекторы и будем следовать нашему плану из 6 шагов шаг за шагом.
На основе предыдущего примера с монолитным приложением, решения очевидны. Разбить большое сложное приложение на более маленькие независимые модули. Это первые шаги к сервес-ориентированной или микросервисной архитектуре.
Обоснование решения
Разделим этот шаг на две фазы: техническое и бизнес обоснование.
Техническое обоснование выглядит логично для нас. Разбить монолит на более мелкие сервиса, в следствии чего мы получим:
- Более разрозненные компоненты
- Проблемы с билдом будут не такие частые
- Маленькие сервиса потребляют меньше оперативной памяти и процессорных мощностей, как следствие – лучшая производительность
- Отдельные сервиса можно задеплоить быстрее и не зависимо друг от друга
Обоснование с точки зрения бизнеса – очень важный шаг, про который часто забывают технические специалисты. Вы должны помнить, что важно для бизнеса. Правильно – это деньги.
Если кратко: если рефакторинг не приносит пользу бизнесу – его нет смысла делать.
На основе нашего примера, вы можете предложить клиенту следующие преимущества:
- Новый функционал будет разрабатываться быстрее
- Качество приложения будет лучше, как следствие меньше затрат на bug fix и довольный пользователь приложения, что так же положительно сказывается на бизнесе
- Уменьшение затрат на разработку и деплоймент
- Проще найти мотивированный и опытных специалистов готовых работать с проектом.
План рефакторинга
План должен быть четким и детальным. Каждая итерация должна быть четко описана и должны быть задокументированы все архитектурные и дизайнерские изменения.
Создавай свой план вы должны ответить на следующие вопросы:
- Какая цель этой итерации?
- Какая техническая и бизнес ценность этой итерации?
- Как сократить продолжительность итерации?
Roadmap
Очень важный шаг. Не пожалейте времени на это, если действительно хотите продать рефакторинг бизнесу.
Каждый менеджер и бизнесмен хочет знать ответы на два вопроса:
- Сколько это будет стоить?
- Как много времени это займет?
Постарайтесь разбить рефакторинг на маленькие итерации. Каждая итерация должна приносить техническую и бизнес ценность. Довольно тяжело продать рефакторинг на годы и стоимостью в миллионы долларов без каких-либо промежуточных результатов.
Каждая итерация должна содержать информацию о продолжительности и количестве специалистов необходимых для этого. Эта информация поможет ответить менеджеру на два основных вопроса заданных чуть выше.
Собирайте метрики проекта до и после рефакторинга на каждой итерации. Это поможет вам показать какую техническую и бизнес ценность принесла эта итерация.
Презентую свое решение
Прежде чем пойти со своим решением к бизнесу, проверь его со своим непосредственным менеджером. Взгляд со стороны всегда хорошо, особенно если это взгляд со стороны бизнеса. Возможно, у вашего менеджера больше контекста и он поможет вам поменять план в соответствии с ожиданиями бизнеса.
Вы должны знать как ответить на классический вопрос.
Обычно когда вы презентуете архитектурный рефакторинг, бизнес может спросить. Почему нам нужен рефакторинг? В прошлом году мы потратили достаточно средств на архитектуру, а теперь у нас снова проблемы.
На классический вопрос есть классический ответ. Этот архитектурное решение было хорошо год назад, но бизнес растет и меняется и архитектура должна меняться вместе с ним.
Совет №2. Не заставляете паниковать своего клиента. Предоставляйте информации как срочную, но не как катастрофа. Скажите, что у вас есть полгода на рефакторинг, но начинать его надо прям сегодня.
Напоследок. Презентуя свое решение старайтесь образовывать людей, а не обвинять. Помните, что, обвиняя людей вы столкнетесь с сопротивлением с их стороны. Вы должны искать пути решения проблем, а не виновных.
В заключение
- Рефакторинг дорогое удовольствие и его тяжело продать бизнесу
- Архитектурный рефакторинг это не только техническая проблема, его еще нужно продать бизнесу
- Помните о том какую пользу рефакторинг принесет бизнесу
- Всегда легче продавать маленький рефакторинг, но часто, чем большой, но один раз
Больше статей по архитектуре и architecture soft skills вы найдете на оригинальном ресурсе.
Всем хорошего рефакторинга!
