Ожидания и Реальность от Роли Архитектора
В статье вы найдете примеры, инсайты из вакансий, статистические данные и «темные стороны», о которых обычно не говорят.
Я хотел бы поделиться размышлениями о роли архитектора — о том, как мы ее представляем и с чем сталкиваемся на практике. Мы часто создаем вокруг этой роли определенный шарм и завышенные ожидания, которые не всегда соответствуют реальности. Это приводит к разочарованию у тех, кто приходит в профессию. Давайте поговорим об этом честно.
Этот материал основан на моем выступлении на ежегодной конференции по архитектуре IT- решений ArchDays.
Как обычно разработчик представляет работу архитектора
На старте своей карьеры, да и наблюдая за коллегами, я не раз встречал следующие типичные представления об архитекторе:
- «Высокоуровневое проектирование» и «принятие стратегических решений»: Эти термины сами по себе звучат весомо. Архитектор воспринимается как тот, кто работает с масштабными системами и бюджетами, решает сложные задачи. Это кажется вершиной карьеры разработчика.
- Уход от рутины: Предполагается, что архитектор занимается только интересными, сложными проблемами, освобождаясь от рутины.
- Работа на другом уровне: Архитектор участвует в обсуждениях с бизнесом о стратегических решениях и направлениях развития, что выглядит как новый, значимый этап.
- Свобода выбора: Кажется, что архитектор наконец получает возможность свободно выбирать технологии, процессы, методологии проектирования и наконец сделает настоящее микросервисное архитектурное решение.
Откуда берутся эти ожидания?
1. Миф о «высшей роли»
Есть некоторое устойчивое представление, что переход на позицию архитектора автоматически означает избавление от рутинных задач и переход исключительно к стратегической работе. Многие уверены, что архитектор лишь определяет направления, «спускает» решения разработчикам и не погружается в операционные вопросы.
2. Книги, курсы и выступления известных архитекторов рисуют образ высококвалифицированного специалиста, принадлежащего к особой группе.
Может казаться, что архитектор решает только сложные интеллектуальные задачи и его работа принципиально отличается от работы разработчиков.
3. В профессиональной среде архитекторы редко говорят о существующих сложностях.
Чаще принято открыто обсуждать решения и подходы, но не собственные проблемы и неудачи. В результате кажется, что все коллеги якобы успешно справляются с любыми вызовами.
4. Вакансии и собеседования лишь укрепляют этот образ роли, полной свободы и влияния.
И конечно, никто не говорит про бесконечные совещания, постоянные уступки и объем технического долга, с которым придется работать новому архитектору.
А вот с чем сталкивается архитектор в реальности (и что подтверждают данные)
А теперь давайте обратимся к реальным обязанностям архитектора. За основу я взял анализ 167 вакансий в RU-сегменте:

Среди обязанностей архитектора есть как ожидаемые, так и неочевидные направления. К последним можно отнести участие в пресейлах и различные менеджерские функции. Однако основу работы по-прежнему составляют три ключевых направления:
- Проектирование и разработка архитектурных решений: Это действительно основа работы: создание и утверждение архитектуры, разработка детализированных решений, составление функциональных требований, декомпозиция систем. Казалось бы, все логично — именно этим архитектор и должен заниматься. Но есть нюанс: во многих вакансиях отдельно прописывают необходимость оптимизации существующих решений, хотя на практике времени и ресурсов на это почти никогда не хватает.
- Работа с требованиями: Здесь от архитектора ждут активного участия: анализа и согласования бизнес-требований, плотного взаимодействия с бизнес-аналитиками, оценки влияния принимаемых решений.
- Поддержка и взаимодействие с командой разработки: От архитектора все чаще ожидают постановки задач разработчикам, объяснения решений, плотного взаимодействия с командами, включая участие в решении инцидентов. Именно поэтому soft skills превратились из желательного дополнения в обязательное требование. Причем этот тренд хорошо прослеживается в вакансиях — если раньше акцент делали на технических навыках, то сейчас требования к коммуникативным способностям выходят на первый план.
Чем еще занимается архитектор: обязанности, которые редко упоминаются в вакансиях
Такие важные аспекты работы как:
- вендор-менеджмент,
- интеграционные процессы,
- архитектурный надзор,
- распространение знаний,
- поддержка,
- участие в пресейлах
редко указываются в требованиях, хотя на практике отнимают значительную часть времени. Особенно заметна доля времени на поддержку (по опыту некоторых коллег – до 60% времени) и вендор-менеджмент, который всегда связан с бюджетным давлением и является серьезным стресс-фактором.
Честная статистика от самих архитекторов
Чтобы получить более полную картину, я решил пойти дальше и провел опрос среди участников Russian Association of Software Architects. Один из вопросов звучал так: «Вы, как архитектор, занимаетесь постановкой задач разработчикам и формированием бэклога?».

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

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

Почему так сильно расходятся ожидания и реальность?
- Ограниченность опыта разработчика. Когда разработчик становится архитектором, он сталкивается с неожиданной для себя реальностью. Из позиции исполнителя мы видим лишь готовые архитектурные решения, но что скрывается за кулисами? Бессонные ночи согласований, изучение документации, бесконечные уточнения требований. Эта часть архитектурного процесса обычно скрыта от глаз разработчиков.
- Романтизация руководящих позиций. Архитектора часто воспринимают как руководителя, хотя на практике это скорее «играющий тренер». Да, архитектурные решения должны учитываться при разработке, но сама роль предполагает не столько управление, сколько экспертизу и координацию.
- Невидимые задачи архитектора. Почему архитекторы постоянно завалены работой? Ответ прост — львиная доля времени уходит на неочевидные со стороны задачи: постоянные встречи, разъяснения решений разным сторонам, различные координационные и менеджерские функции.
- Неожиданное количество коммуникаций. Разработчик в основном фокусируется на коде после получения ТЗ. Как архитектор вы обнаружите, что ваш календарь забит встречами на месяцы вперед. Значительная часть времени уходит на обсуждения и согласования. Возникает вопрос: «Когда же проектировать?».
- Неизбежность компромиссов. Разработчик работает с готовыми решениями, когда основные компромиссы уже достигнуты, архитектор же постоянно балансирует между техническим качеством, бюджетом, сроками, имеющимися компетенциями. Поэтому вместо поиска «самого лучшего» решения приходится искать «достаточно хорошее» в рамках заданных ограничений. Это требует фундаментальной перестройки мышления.
- Бизнес-ориентированность архитектурных решений. Решения руководствуются не только техническими аспектами — они могут казаться технически неоптимальными, но при этом быть критичными для партнерства или будущего развития. В результате архитекторам приходится часто заниматься тем, что коллеги называют «архитектурной политикой».
- Много времени на согласование. Принятие решений редко бывает единоличным. Часто требуется согласование с множеством стейкхолдеров, и любое возражение может заблокировать решение. Это заставляет задуматься: «Принимаю ли я решения на самом деле или это коллективный процесс?». Хотя практически все книги об архитектуре говорят, что решение принимает архитектор.
- Ограничения в выборе технологий. Утверждение о выборе «любых технологий» часто оказывается условным. Исследования показывают, что лишь 20% архитекторов действительно выбирают инструменты свободно (Gartner), а 64% строго следуют корпоративным стандартам (Tech Republic). Из личного опыта могу сказать, что в работе мы используем не более 10% из всего арсенала доступных архитектурных практик (а возможно, и меньше).
- Много операционной работы. Поддержка старых систем, исправление ошибок, устранение технического долга: на собеседованиях состояние существующих систем редко обсуждается подробно. Однако на практике такие задачи будут отнимать много времени.
- Дефицит времени на инновации и стратегию. Операционные задачи и рутинная работа оставляют мало пространства для стратегического планирования и инноваций, что часто расходится с изначальными ожиданиями.
Архитектор, а еще инженер, психолог и дипломат
Книги и курсы в основном учат проектированию. Однако реальность показывает, что проектирование – лишь часть работы. Значительную часть времени занимает то, о чем редко говорят на собеседованиях и в кулуарах: согласования с бизнесом, работа с унаследованными системами, поиск компромиссов.
И что же со всем этим делать? Я дам несколько несколько полезных рекомендаций, которые помогут справляться с реальными вызовами профессии:
- Адаптироваться к реальности и учиться работать в рамках существующих ограничений. Признать, что ограничения существуют и они будут всегда — технические, организационные и финансовые. Поэтому главная задача архитектора — найти не идеальное, а оптимальное решение в реальных условиях.
- Признать, что быть архитектором — это постоянное обучение. Выделять время на систематическое обновление знаний, но фокусироваться на том, что действительно применимо в вашем контексте.
- Оставаться на связи с разработчиками и делиться реальным опытом. Говорить не только об успехах, но и о неудачах. Обсуждать сложные кейсы, технический долг, неудачные компромиссы. Это делает профессию прозрачнее и помогает коллегам избегать повторения ошибок.
И в то же время работа архитектора невероятно увлекательна и интересна в том числе за счет своей неоднозначности и широкого спектра знаний и навыков, требуемых для качественного выполнения поставленных задач.

Метрики — это ключевой инструмент при разработке продукта. Но иногда они не помогают, а, наоборот, усложняют работу, привнося хаос вместо четкости и прозрачности. В статье мы разберем, какие метрики полезны в Agile-тестировании и как их правильно использовать, чтобы повысить качество продукта, отслеживать прогресс и улучшать результаты команды.

Какие ошибки в Agile Testing мешают командам стать по-настоящему гибкими и быстрыми? В статье обсудим, как избежать этих ловушек и что делать, если ваша команда уже столкнулась с ними.

Руководство по работе с функциональными и техническими исследовательскими задачами.