Переход от разработчика к архитектору
О себе: занимаюсь разработкой уже более 15 лет. Поймал себя на мысли, что когда что-то могу описать и показать другому, то заодно получается и хорошо структурировать мысль и систематизировать знания. Поэтому начал делать для себя заметки, которыми делюсь.
Уже много написано и прочитано о том, как перейти от роли разработчика к роли менеджера. Не так давно я прочитал книгу Фундаментальный подход к программной архитектуре: паттерны, свойства, проверенные методы (не реклама!) , в которой наткнулся на главу, где подробно разбиралась роль архитектора и проводилось сравнение его задач с задачами разработчика. Задумался:
А как разработчик становится архитектором и какие изменения этот переход за собой влечет 🤔
Попробую описать…
За что отвечает разработчик
- Дизайн классов
- Исходный код
- Программа и ее интерфейс
За что отвечает архитектор
- Свойства архитектуры
- Стиль построения архитектуры
- Структура компонентов
Ожидания от архитектора
- Принятие архитектурных решений
- Анализ текущей архитектуры
- Контроль за исполнением архитектурных решений
- Изучение и применение современных тенденций
- Обширные знания и опыт
- Владение навыками коммуникаций
- Понимание бизнеса и политики компании
Что кроется в этих зонах ответственности, делая переход таким сложным?
Изменение масштаба
- Во-первых, архитектору необходимо брать в расчет потребности бизнеса. Появляется еще одна область, которая балансирует и часто перевешивает техническую
- Во-вторых, должен измениться взгляд: с глубокого на широкий. Разработчик знает свою часть кода, свой сервис. Архитектор работает со всей системой в целом, часто не зная деталей реализации отдельных пакетов и классов
- Архитектор начинает мыслить более абстрактными понятиями и верхнеуровневыми процессами, тогда как разработчик мыслит конкретными алгоритмами и функциями системы
- Архитектор берет во внимание больше заинтересованных лиц/ролей и взаимодействует со всеми этапами производства
- Задачи архитектора настолько объемные и иногда так конфликтуют с задачами разработчика, что часто невозможно заниматься ими по остаточному принципу и совмещать с ролью разработчика
Динамика результатов
- В конце рабочего дня архитектора не всегда можно будет пощупать результат его работы, так как весь день может пройти на встречах или за составлением схем. Результатами могут быть договоренности, выявленные требования, принятые решения и они не всегда видны явно, как строчки кода
- Отложенный эффект — последствия решений архитектора проявляются через несколько месяцев, тогда как результат работы разработчика может быть заметен уже через несколько часов после коммита
Ответственность
- Ошибки архитектора стоят дороже, что повышает уровень сложности и ответственности
- По аналогии с переходом в менеджеры, у новичка-архитектора может появиться соблазн самому создать диаграммы классов или выбрать паттерны проектирования, потому что он это умеет! Придется отпустить и начать решать другие задачи
- Нужно будет научиться выстраивать отношения с бизнесом и отталкиваться от интересов заказчика, иногда принимая решения не в пользу «любимой разработки»
- Ну и коммуникации — их станет больше, они будут сложнее и нужно будет учиться эффективно их проводить
Получается, что разработчику нужно будет серьезно перестроить свое мышление, привычки и существенно выйти из зоны комфорта. Отпустить то, что он так хорошо умел делать еще вчера и сменить вектор своего развития.
Что же нужно сделать/изменить/приобрести, чтобы из AS IS (разработчик) перейти в TO BE (архитектор) ?
Новые навыки
- Помимо задач проектирования и дизайна своего сервиса или части подсистемы начать брать задачи, которые касаются нескольких сервисов. Изучать другие решения. Сравнивать!
- Брать задачи по анализу и развитию текущей архитектуры на проекте
- Стараться не только реализовывать архитектурные требования, но и пытаться их описывать, анализируя потребности бизнеса
- Изучать архитектуру и структуру ПО — книги, статьи, доклады, конференции, менторы
- Погружаться в system design и архитектурные ката — пробовать, пробовать и пробовать! И главное — получать обратную связь, после чего снова пробовать
- Изучать нотации, используемые в компании: UML, С4, ArhiMate, … Главное, уметь изложить мысль так, чтобы ее кто то смог изучить и понять
- Набираться опыта! Это важно, потому что теория для архитектора, это только пол дела, нужен богатый багаж ошибок и насмотренности!
- Качать проектное управление, так как теперь архитектор может генерировать задачи на других. Да, далеко от менеджмента уйти не получится, нужно будет освоить основы…
- Учиться налаживать коммуникации, разрешать конфликты и строить эффективные команды. Наращивать этот опыт на практике, за помощью можно обратиться к HR или менеджерам проектов в вашей компании
Кругозор
- Расширять кругозор технологий: изучать больше аналогов среди уже используемых инструментов: БД, языки программирования, протоколы взаимодействия, методологии разработки. Учиться их сравнивать и выделять характеристики, ключевые для решаемой задачи
- Начинающему архитектору нужно отпустить глубокую экспертизу и стать экспертом широкого профиля, чтобы иметь почву для осмысленного и эффективного выбора. Да, другие сотрудники могут обогнать вас в глубине экспертизы по отдельны языкам и фреймворкам и вы не всегда будете понимать, о чем они говорят
- Больше изучать на перспективу — что может пригодиться уже сейчас или в будущем
- Пытаться разбираться не только в кодировании, но и в аналитике, тестировании и поддержке продукта — в смежных областях
- Изучать, какие виды архитекторов бывают (software, solution, enterprise, infrastructure, data, …)
Мышление
- Отказаться от категоричности, начать смотреть в сторону компромиссов и взвешенных решений. Для старта поможет составление сравнительных таблиц
- Качать критическое и системное мышление, поощрять культуру challenge и обмен мнениями. Дополнительный взгляд со стороны может помочь увидеть недочеты в предлагаемых решениях
- Качать soft-skills для общения с заказчиком, переговоров и успешной аргументации
- Снова качать soft-skills!
- Учиться презентовать идеи и внедрять большие изменения
Последние 7 лет радует то, что наблюдается тенденция, когда перед сеньором или техлидом уже не стоит бинарный выбор: менеджер или архитектор. Многие компании добавляют треки развития для эксперта, когда сотрудник в рамках своего функционального направления может расти и дальше, принося пользу команде, качая глубокую экспертизу и получая бОльшую ЗП! У сотрудника появляется возможность выбрать наиболее подходящий вектор своего развития
Разработку ПО и управление командами разбираю в своем Telegram канале. Буду рад вашим вопросам!