Япония... Свет из окон широкими полосами освещает длинное помещение. Цех по сборке телефонных аппаратов. Вдоль стен стоят столы, над каждым склонился работник, каждый что-то делает, но от нашего взора это скрыто ссутуленными спинами. У некоторых на столах стоят дополнительные лампы и увеличительные стёкла на штативе. В конце длинного помещения у стены лицом к нам сидит японец с барабаном и не быстро, но с чёткостью метронома отбивает ритм. Все работники к нему привыкли и не замечают его, но тем не менее каждый удар барабана проносится по нервной системе и вплетается в движения. Каждый делает что-то своё, но общий ритм придаёт всей деятельности гармонию. Работа делается так же ритмично, в ней нет места для пауз и размышлений о бренности бытия. Всё подчинено ритму.

Меня зовут Смирнов Евгений! Трудовую деятельность в сфере IT начал в конце 90х с разработки ПО на заказ. После этого работал в гос конторе, на себя, в банке, в дочках Газпрома и сейчас в одной из крупнейших Российских ИТ компаний. Последние 10 лет выполняю роль архитектора и руководителя.

Последние несколько лет стало популярно держать в штате, в зависимости от масштаба компании, от одного ИТ-архитектора до целого департамента архитектуры. Спрос на архитекторов довольно высок и заработные платы соответствуют. Вообще ситуация напоминает несколько поутихший ажиотаж вокруг позиции менеджера проекта, когда бизнесу казалось, что стоит нанять PM'а и тут же проекты будут ритмично двигаться к успешному завершению без срыва сроков и в рамках бюджета, а ещё заказчики будут плакать от счастья, восхищаясь чудесными инструментами для ведения бизнеса, что в приложениях осталось две кнопки: "принести кофе" и "сделать массаж". На этой волне много молодых людей оплатили обучение MBA, получили сертификаты и мы до сих пор можем их наблюдать в штате компаний. Но, ажиотаж вокруг позиции PM утих. Сейчас, по-моему, PM - это человек задающий ритм регулярными мероприятиями, предусмотренными PMBoK.

Бизнес со временем понял, что PM не решит все его проблемы, к тому же у него, как правило, не лучшим образом обстоят дела с технической частью. Бизнесу был нужен новый герой. Ну и как Вы, очевидно, догадались он нашёл его в лице ИТ-Архитектора.

Архитекторов я выделю 3х видов:

Мой опус касается позиции архитектора решений.

И ещё одно лирическое отступление: В одной познавательной книге "Русская модель управления" рассматривается по сути две модели - конкурентная западная, где во главу угла ставится процесс, спускаемый сверху и чёткое следование которому приводит к требуемому результату. В этой модели руководство берёт на себя часть ответственности, предоставляя подчинённому готовый процесс. И ресурсная, русская модель управления, доставшаяся нам от монголо-татарского нашествия. В ней начальник не указывает подчинённому как достичь результата, но наделяет полномочиями и выделяет ресурсы для этого. И ценен тот работник, который при меньших потребляемых ресурсах сможет дать больший выхлоп. Свободы больше, но и ответственности соответственно тоже больше. У обеих моделей есть плюсы и минусы. Благодаря второй модели, кстати, мы победили в ВОВ.

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

Таким образом, с одной стороны Архитектор должен уточнить, систематизировать и согласовать требования с учётом текущего ИТ-ландшафта. С другой - ИТ-архитектор должен разработать ИТ решение - на верхнем уровне оно представляет из себя документ high level design, иногда с детализацией до ТЗ. С третьей - управлять командой (разработка, тестирование, релиз) для доставки решения конечным пользователям. Вспоминаем про PM'ов из предисловия.

Первую деятельность, зачастую выполняет бизнес-аналитик или сам заказчик и, как правило, она не требует больших ресурсов, поэтому на картинке я её отображать не стал.

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

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

Наблюдения нескольких команд и общение с коллегами только подтверждает эту проблему.

Всё это касается больших компаний с матричной системой подчинения. В небольших командах, где нет токсичных звёзд, как правило, проблем у интровертов нет. После адаптационного периода они вполне могут выполнять роль и технического архитектора и руководителя работ.

Проблему обозначили. Теперь нужно решение. Первое, что кажется естественным - возьмите двух людей: один пусть изготавливает красивые, согласованные между собой, масштабируемые и т.д. технические решения, другой - общается с внешним миром и бьёт в барабаны для команды. В этом случае бизнес должен выстроить взаимодействие между ними, поделить полномочия и ответственность, а бизнес не хочет брать на себя ответственность за неверно построенные взаимоотношения. Следующим шагом кажется логичным поставить над ними общего начальника, который и будет для бизнеса тем волшебным персонажем, который несёт ответственность, за решение задачи. Почему-то ни в одной компании я подобного не встречал. Возможно там есть нюансы, не видимые на первый взгляд. Тем не менее, в следующую итерацию своего трудового пути, постараюсь в структуре команды разделить роль архитектора решений на технического архитектора и PM'а. Почему-то мне кажется, что подразделение, состоящее из технических архитекторов решений и PM'ов будет эффективнее, чем подразделение из того-же количества архитекторов универсалов.

На этом сей опус я буду заканчивать.

Буду рад, если натолкнул кого-то на размышления об организации команды. Буду ждать их в комментариях

Всем хороших новых фич и меньше багов.