Япония.
Свет из окон широкими полосами освещает длинную комнату.
Цех сборки телефонов.
Вдоль стен стоят столы, над каждым склоняется рабочий, все что-то делают, но от нашего взгляда это скрыто их сгорбленными спинами.
У некоторых есть дополнительные лампы на столах и лупы на штативе.
В конце длинной комнаты японец сидит у стены лицом к нам с барабаном и отбивает ритм не быстро, но с четкостью метронома.
Все рабочие к этому привыкли и не замечают этого, но тем не менее каждый удар барабана проносится по нервной системе и переплетается с движениями.
Каждый делает что-то свое, но общий ритм придает гармонию всем занятиям.
Работа выполнена в такой же ритмичной манере, здесь нет места паузам и размышлениям о бренности существования.
Все подчинено ритму.
Меня зовут Евгений Смирнов! Свою карьеру в сфере ИТ он начал в конце 90-х с разработки программного обеспечения на заказ.
После этого он работал в госучреждении, на себя, в банке, в «дочках» «Газпрома», а теперь и в одной из крупнейших российских IT-компаний.
Последние 10 лет исполняю роль архитектора и менеджера.
За последние несколько лет стало популярным нанимать, в зависимости от размера компании, от одного ИТ-архитектора до целого архитектурного отдела.
Спрос на архитекторов довольно высок, а зарплаты стабильны.
В целом ситуация напоминает несколько утихший ажиотаж вокруг должности проектного менеджера, когда бизнес думал, что если нанять PM, то проекты сразу будут ритмично двигаться к успешному завершению без срыва сроков и в рамках бюджета, а клиенты будут плакать от восторга.
счастье, любуясь чудесными инструментами для ведения бизнеса, что в приложениях осталось две кнопки: «принести кофе» и «сделать массаж».
На этой волне многие молодые люди оплатили обучение MBA, получили сертификаты, и мы до сих пор видим их в штатах компаний.
Однако шумиха вокруг должности премьер-министра утихла.
Сейчас, по моему мнению, премьер-министр – это человек, который задает темп регулярными мероприятиями, предусмотренными ПМБОК.
Со временем бизнес понял, что ПМ не решит всех его проблем, к тому же с технической стороны он, как правило, работает не лучшим образом.
Бизнесу нужен был новый герой.
Ну, как вы, очевидно, догадались, он нашел его в лице ИТ-Архитектора.
Я выделяю 3 типа архитекторов: 
Мой опус касается позиции архитектора решений.
И еще одно лирическое отступление: В одной учебной книге «Российская модель управления» рассматриваются по сути две модели – конкурентная западная, где основное внимание уделяется процессу, нисходящему сверху, и строгое следование которому приводит к требуемый результат. В этой модели руководство берет на себя часть ответственности, предоставляя подчиненным готовый процесс.
И ресурсная, российская модель управления, которую мы унаследовали от монголо-татарского нашествия.
В нем начальник не говорит подчиненному, как добиться результата, а дает полномочия и выделяет для этого ресурсы.
А самым ценным работником является тот, кто при меньшем потреблении ресурсов может произвести большую продукцию.
Свободы больше, но соответственно и ответственности больше.
Обе модели имеют плюсы и минусы.
Благодаря второй модели, кстати, мы выиграли ВОВ.
В наших реалиях, возможно, это мой субъективный опыт, бизнес не готов брать на себя ответственность за развитие процесса.
Легче найти человека, который сам добьется результата.
Эта роль предназначена для архитектора решений, которому в лучшем случае на вход подаются бизнес-требования (в худшем — несформированные пожелания), а на выходе ожидается работающий программный продукт, включающий в себя несколько ИТ-систем и новые процессы их использования.
системы.
В качестве ресурсов для архитектора под конкретную фичу собирается команда, с помощью которой он будет реализовывать ИТ-продукт. Таким образом, с одной стороны, Архитектор должен уточнить, систематизировать и согласовать требования с учетом текущего ИТ-ландшафта.
С другой стороны, ИТ-архитектор должен разработать ИТ-решение — на верхнем уровне это проектный документ высокого уровня, иногда с детализацией вплоть до технических спецификаций.
Третий — управлять командой (разработка, тестирование, выпуск) для доставки решения конечным пользователям.
Вспомним про ПМ из предисловия.
Первое действие часто выполняет бизнес-аналитик или сам заказчик и, как правило, не требует больших ресурсов, поэтому на картинке я его не отображал.
А вот второе и третье, на мой взгляд, требуют совершенно разных навыков и качеств характера.
В первом случае нужны профессиональные навыки + умение долго концентрироваться, потому что.
сложные технические решения требуют одновременного анализа множества влияющих факторов и нюансов.
Во втором – мягкие навыки, коммуникабельность, стрессоустойчивость, харизма.
Свойства, перечисленные для первой и второй деятельности, присущи разным психотипам: интровертам и экстравертам.
В результате персонажам на позиции архитектора приходится прилагать усилия над собой либо для управления командой, ожиданиями клиентов, либо для оправдания технических ограничений.
Экстравертам необходимо приложить усилия, чтобы надолго погрузиться и сформулировать техническое решение на существующем ИТ-ландшафте с учетом всех требований и существующих ограничений различного характера.
Несколько больше повезло амбивертам, умеющим комбинировать эти психотипы в зависимости от ситуации.
Но, во-первых, их мало, а во-вторых, архитекторов-амбивертов еще меньше.
Результат – постоянное моральное напряжение, смена работодателя, выгорание.
Наблюдения нескольких команд и разговоры с коллегами только подтверждают эту проблему.
Все это касается крупных компаний с матричной системой отчетности.
В небольших коллективах, где нет токсичных звезд, у интровертов, как правило, проблем не возникает. После периода адаптации они вполне могут выполнять роль и технического архитектора, и руководителя работ. Проблема выявлена.
Теперь нам нужно решение.
Первое, что кажется естественным, — взять двух человек: пусть один делает красивые, слаженные, масштабируемые и т. д. технические решения, другой общается с внешним миром и бьет в барабаны за команду.
В этом случае бизнес должен выстраивать между ними взаимодействие, разделять полномочия и ответственность, а бизнес не хочет брать на себя ответственность за неправильно построенные отношения.
Следующим шагом кажется логичным поставить над ними общего начальника, который будет магическим персонажем для бизнеса, ответственным за решение проблемы.
По какой-то причине я никогда не видел ничего подобного ни в одной компании.
Возможно, там есть нюансы, не видимые на первый взгляд. Однако на следующем этапе своей карьеры я постараюсь разделить в структуре команды роль архитектора решений на технического архитектора и PM. Мне почему-то кажется, что подразделение, состоящее из архитекторов технических решений и проектировщиков, будет более эффективным, чем подразделение, состоящее из такого же количества архитекторов-универсалов.
На этом я закончу этот опус.
Буду рад, если вдохновлю кого-нибудь на мысль об организации команды.
Я буду ждать их в комментариях Всем хороших новых функций и поменьше багов.
Теги: #Управление разработкой #Управление проектами #архитектура #Анализ и проектирование систем #управление проектами и командой #управление командой #управление проектами #архитектор решений #архитекторы
-
Новый Youtube Для Android
19 Oct, 24 -
Три Способа Меньше Беспокоиться
19 Oct, 24 -
Стандартные Телефоны Damps
19 Oct, 24 -
Фиксированный Или Текучий?
19 Oct, 24
