Привет, архитекторы, разработчики и неопределившиеся! Меня зовут Сергей Врунов. Я работаю в ВТБ и занимаюсь развитием ИТ-архитектуры. Все мы сталкиваемся с религиозными «архитектурными» дискуссиями и производственными конфликтами на ровном месте. Кажется, у вас есть классное решение или предложение, но почему оно так плохо заходит или вообще не заходит? Что делать? Какой профиль успеха архитектора?

Архитектурная психология! Читайте наш «Кодекс архитектора» и узнавайте, как нанести пользу организации.

Оглавление

1. Какие аспекты будем рассматривать?

2. Профиль успеха архитектора

3. Какие навыки будут полезны в работе?

4. Что мешает договориться?

5. Секреты эффективного взаимодействия

6. Модели обучения

7. Формы обучения

8. Модель продвижения, для иррациональных

9. Какие инструменты можно использовать в продвижении своей идеи

10. Мера успеха

11. Вместо заключения

Часто обсуждая с коллегами специфику работы архитектора, у меня возникал вопрос: какими навыками должен обладать архитектор, чтобы быть успешным в своей работе? На ум приходят:

• Функциональная декомпозиция;

• Владение технологиями;

• Основы интеграции;

• Знание шаблонов;

• Основы проектирования;

• Управление данными;

• И т.д.

Кажется, все верно, но чего-то не хватает. Перефразирую вопрос из известного фильма: «Как вы думаете, что самое сложное в профессии архитектора?» Что скажете?

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

Вспомнив свою студенческую пору (кто не сдавал «курсовик» по «методе» в студенческие годы?), я решил изложить свои мысли в виде методы или конспекта, который подойдет для практического использования.

Какие аспекты будем рассматривать?

• Как добиться успеха как архитектору. Что такое профиль успеха и как использовать его в своем профессиональном росте?

• Какие подводные камни ждут нас в кросс-функциональной работе?

• Как не убиться в такой среде и принести пользу, не потратив зря нашу положительную профессиональную энергию?

• Какие модели поведения можно использовать и как архитектурно маневрировать, чтобы идея была реализована?

• Мы все имеем разный характер, темперамент, манеру общения. Как быть архитектору?

• Как сказываются личностные таланты на квалификации архитектора. Как оценить успешность архитектора?

• И в конце — посмотрим, что делать дальше.

У архитектора должны быть два типа навыков: технические и личностные, но это требует уточнения. Как архитекторы давайте мы рассмотрим «архитектуру успеха» — Профиль успеха архитектора.

Профиль успеха архитектора

Знания – опыт других

Знания — это образование, информация, которую другие люди, обобщили структурировали и передали нам. Универсальный инструмент для принятия решений на все случаи жизни. Например, объектно‑ориентированный анализ, формы нормализации данных, шаблоны надежности и производительности систем и наконец, формальная логика.

Опыт – знания, полученные нами

Опыт — это знания, приобретенные уже нами входе нашей карьеры. Не как проектировать вообще, а какие особенности в проектировании нужно учитывать. Если знания — это то, что имеет выпускник вуза после завершения обучения, то опыт — это то, как полученные знания применять в конкретных условиях. Можно ли мутить создание унифицированной модели данных в организации такой степени зрелости. То есть, то что можно в ВТБ сейчас, было невозможно в ВТБ 10 летней давности или что по силам крупному банку в РФ, и что не по силам среднему или маленькому банку в других странах‑соседях. Прививка от детской болезни «крутизны» в программизме.

Знания и опыт – этого достаточно для прямого общения лишь с компьютером

Эти навыки 100% сработают, если нам нужно иметь дело с компьютером. Взял язык программирования, СУБД, библиотеку визуальных компонентов, «запилил» отличную систему и успех. В работе архитектора, особенно(!) архитектора, такого практически не бывает. Мы всегда работаем с людьми, которые должны реализовать, что задумано архитектором и так, как задумано архитектором. Иначе на пилоте быстро и красиво взлетаем, но вы, как архитектор, предполагали развитие в сторону автоматизации, а разработчик этого не учел и напирал на удобство использования. А значит внутренний дизайн решения не соответствует перспективам развития, которые мы ожидали и дорожная карта развития решения невыполнима. Техника техникой, но архитектор работает с людьми, а не с компьютером. Для этого нужны другие навыки.

Мы как личность

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

Мы – среди людей

Архитектор, как любой человек, животное социальное, работает в команде. Именно этим разделом «Профиля успеха» мы и займемся.

Начну с риторического вопроса: чья же это проблема, что разработчик неправильно понял наш блестящий замысел? Придумать пол‑, если не четверть дела, объяснить, убедиться, что поняли правильно — вот основанная задача. В нашей команде, чтобы придумать шаблон проектирования для платформы, уходит одна встреча и 2–3 часа внимательного обдумывания, но на обсуждение с командами, на уточнение и на то, чтобы убедиться, что мы друг друга поняли, могут уйти недели и месяцы.

Идея вброшенная, а значит брошенная либо умрет, не дойдя до «прома», или придет туда совсем не в том виде, на который мы рассчитывали. Чтобы этого не случилось, нужно уметь работать с людьми и среди людей.

Какие навыки будут полезны в работе?

Один в поле не воин, а нас рать

Сейчас в области ИТ одиночка не может выпустить и поддерживать продукт. Нужна бригада специалистов. Суть командной работы — в том, чтобы каждое действие приносило команде что-то ценное, именно команде, а не ее отдельным членам. Для успеха нужно, чтобы все, без исключения члены команды отработали хорошо, для неудачи же достаточно, чтобы накосячил только один. Что нужно сделать чтобы команда была эффективной?

• Необходимо взаимное усиление, если допустить ослабление (рост энтропии), то команде нужно потратить больше ресурсов для достижения результата;

• Нужна мотивация к работе — без желания хорошо сделать невозможно;

• Важен учет интересов — результат должен удовлетворять всех. Один получит орден, остальные проблемы. Следующий раз не будет мотивации и вероятность неудачи увеличивается;

• Необходимо способствовать развитию команды — либо повысить эффективность, либо помочь вырасти текущему сотруднику. Если есть потенциал нужно его обязательно использовать;

• Крайне важна общая позиция вне команды — не выносить сор из избы публично. Все дискуссии внутри, если решение принято, то нельзя вне подвергать его сомнению. Если мы из одной команды не нужно затевать публичную дискуссию на внешней площадке. Сначала внутри, потом общая позиция или инициированная командой дискуссия, сравнением вариантов +/−, если не договорились.

Знания имеют срок годности

Готовность к изменениям — у любых знаний или навыков есть срок годности. Можно определить фундаментальные знания и коротко живущие. Например, навык функциональной декомпозиции практически не имеет срока годности. Это навык был нужен и 100, и 200 лет назад — это фундаментальный навык. Коротко живущие знания — это обычно технологии. Давайте вспомним арсенал разработчика 10 лет назад и сравним его с текущим. Все очень поменялось. Поэтому важной личностной компетенцией является готовность меняться, не бояться изменений и быть к ним привычным. Действительно, если не можешь изменить мир — меняй себя.

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

• Адаптация — надо понимать изменение непрерывны, с этим ничего не сделать. Надо сделать так, чтобы изменения не были колоссальным стрессом. Экзамены в СССР и сейчас: тогда было достаточно мало ответственных экзаменов — выпускные в школе не очень сложны, но вступительные весьма стрессовые, конкуренция и последствия провала. Первый курс тоже был стрессом, многие отсеялись, но потом экзамены стали рутиной. Нужен аналогичный навык, меняется технологический стек, или средства разработки — не проблема, освоим и перейдем, если это будет целесообразно;

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

• И в конце концов сделать изменения нормальным, привычным для нас процессом. Только вне зоны комфорта есть развитие.

Копим фундаментальное ядро и постоянно обновляем переменную оболочку. Как пробковое дерево кору.

Клиентоориентированность

Потребителю сервисов команды нужен прежде всего именно этот сервис. Как любой — сервис команды имеет определенный контракт с потребителем, то есть функциональные и нефункциональные требования, на которые вы договорились с потребителем. Нужно сделать, все, чтобы выполнить взятые на себя обязательства и заслужить доверие потребителя. Например, вы договорились с потребителем, что ваш API по получению выписки по счету будет иметь время отклика 0,5 сек и возвращать текущий остаток, но у вас получилось реализовать время отклика 2 сек и остаток с запаздыванием на 10 сек. Так не годится. Если пообещал, то сделай, или не обещай, пока не будешь уверен, что сделаешь. Даже если мы ловко объясним потребителю, почему не удалось и он воспримет такое объяснение, со временем или сразу, нам перестанут доверять и не будут использовать наш сервис, а наша востребованность в организации станет нулевой.

Для того, чтобы ваш сервис потребляли, он должен не только соответствовать договоренностям, но и общение с вами должно быть комфортным для потребителей. Предположим ваш API прекрасен, работает великолепно, но вы так высокомерно, через губу общаетесь с потребителями, распираемый собственной "крутостью" или начинаете умничать, учить как делать, «а это опять ты» или «ну что тебе надо» и т.д., то вашим потребителям каждый контакт с вами будет некомфортен. Нет положительного клиентского, точнее партнерского опыта, тогда потребитель начнет задумываться: стоит ли терпеть такое общение и начнет искать возможности минимизировать взаимодействие с вами и вашей командой, а ваш сервис лишится заказчиков, драйверов изменений, прекратит свое развитие, заказов на изменение ведь нет, и в конце концов начнет деградировать и рано или поздно умрет.

Потребителя нужно беречь — он смысл существования вашей команды.

Ответственность за результат — добились, что к нам обращаются, а что с результатом

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

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

Итого имеем: в команде каждый делает, то, что от него зависит, команда не боится изменений, от клиентов нет отбоя, все чувствуют ответственность за результат — теперь дело за ключевыми компетенциями, чтобы достичь результата.

Влияние и убеждение — авторитет

В каждодневной практике возникают дискуссии с лицами, принимающими решения. Обычно в инженерной практике предложения базируются не только на общеизвестных знаниях, а на нашем опыте. Так называемая "серая" зона. Наш партнер по дискуссии, особенно, если он не подкован в архитектуре, может просто не понимать этого опыта. Действительно, есть аргументы за ваше предложение, есть против, что больше сыграет в будущем партнеру по переговорам, без вашего опыта, выбрать трудно. И в таких случаях важную помощь в принятии правильного архитектурного решения может сыграть авторитет, уверенность, навыки общения с конкретным человеком.

Мне известен случай — архитектор горячо и аргументировано отстаивал свое предложение, на коллегиальном органе его «против» даже было зафиксировано в протоколе. Когда тО, о чем предупреждал архитектор, случилось в самом худшем виде, руководитель упрекнул того архитектура: «что ж ты?» Архитектор напомнил о своих предупреждениях, руководитель после небольшой паузы сказал: «Ты был неубедителен». Чья здесь вина? Сейчас, по прошествии некоторого времени, я уверен, что главной причиной этой неудачи, несмотря на технические аргументы, была недостаточность навыка влияния и убеждения. Надо искать причину в себе. Если найдешь ее в себе, следующий раз решение задачи будет зависеть от тебя, а не от специфики твоего текущего руководителя (дай ему бог удачи).

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

Формулировка подхода

И последняя в нашей классификации компетенция — продажа, в хорошем смысле, идеи. Допустим, вы придумали отличную штуку. Идея прекрасна, но эта идея, чтобы быть реализованной она должна зажечь, тех, кто будет ее реализовывать.

Бывает так, что мы уверены, приятны и все такое, но если мы не можем сформулировать идею, то результата добиться будет трудно. Нужно понимать, что формулировка идеи должны быть адаптирована к аудитории: на архитектурный коллегиальный орган акценты на одно, бизнес коллегиальный орган другое, в команде реализации третье — исходя из интересов слушателей. Идею нужно четко, кратко (слушатели загружены), комфортно донести до аудитории. При формулировке для определенной группы людей нужно отбросить все лишнее, для данной аудитории, и сконцентрироваться на основной идее, внимательно следить за «боковиками». Нужно так вести обсуждение, чтобы не потерять слушателей. Если действительно «боковик», аккуратно уйти от него в обсуждении, но может и не «боковик», а что-то ценное для идеи.  Изложение должно быть прежде всего понятно и комфортно аудитории, а не нравиться вам. Это уже архитектурная пропаганда, но об этом в будущих публикациях следите — за нами.

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

Что мешает договориться?

Что мешает людям договориться?Два фактора, может быть есть и другие, но эти самые душные. Первый — информационные разрывы. Действительно очень трудно договориться, объяснить свою идею, адаптировать ее с помощью общения с другими людьми, если у нас на лицо разное понимание, разная информация в головах.

Самое частое — мы говорим о разном. Например, в моей практике была дискуссия об аутентификации. Одна команда имела в виду аутентификацию пользователя, другая аутентификацию информационной системы. Разумеется, каждая команда, будучи в контексте свое задачи, не говорили «аутентификация пользователя», а просто «аутентификация», это же ясно, и вторая тоже опускала очевидное уточнение. Пока не поняли, что говорят о разном — договориться было трудно. Это первое, в чем нужно убедиться, что говорим об одном и том же (первый закон логики, как вы помните — тождественность понятий, определиться с понятиями). Нужно всегда помнить цепочку: мысль в вашей голове, выражается словами, передается другому собеседнику, он понимает эти слова по-своему и в его голове возникает его мысль. То, что вы ловко объяснили свою идею, не гарантирует, что в голове собеседника возникнет такая же мысль. Необходимо убедиться в этом. Есть масса способов, как это сделать:

• идея сопровождается какой-то метафорой, например, различия в розничных продуктах и продуктах для VIP или корп: фаст-фут (типовые блюда) или рестораны (блюда на заказ);

• шаблоны проектирования из 3-х составляющих: проблема—контекст —решение;

• уточняющие вопросы;

• и самое эффективное для архитектора — визуализация идеи. Не экономьте на визуализации, больше времени потратите на описание схемы словами, чем на подготовку картинки. Очень важный навык.

Это, что касается предмета обсуждения. Но нужно понимать обстоятельства партнеров по общению. У них релиз и нет времени вообще, они договорились с заказчиком о чем-то и это у них в голове, важен контекст, в котором ребята сейчас находятся. Например, команда только формируется, а вы общаетесь как будто команда полностью укомплектована. Обратно тоже верно, нужно сделать так, чтобы ребята тоже понимали в каких вы условиях и чего хотите.

Еще один риск кросс-функционального взаимодействия. Комплекс «мы/они» — возникновение между людьми разделяющих линий. Это очень серьезная проблема. При общении мы выражаем свою точку зрения, свою позицию исходя из своих интересов или интересов своей команды. Например, архитекторы и бизнес, команда прикладной системы и используемого ей общего сервиса платформы. Как только возникает конфликт интересов (разделительная линия) легко может случиться так, что участники общения разобьются на группы по интересам. Это, в свою очередь, может привести к тому, что команда займется не решением общей задачи, а защитой своих интересов в таком сепаратном пространстве. В принципе мы стараемся "нарезать" команды с минимальным конфликтом интересов, но полностью избежать этого очень трудно.

Я хочу рассмотреть конфликты на уровне людей, в команде, стриме или трайбе и т.д. Они не так явны, не так быстро проявляются, но, если упустить — будет беда. Разбитый бокал можно склеить, но звенеть он уже не будет.

Позиции и интересы выражаются словами и именно слова, неправильные слова, могут привести к появлению сначала чуть заметных разделительных линий в отношениях людей, со временем линии будут увеличиваться, а потом превратятся в стены непонимания и работа встанет. Например, такая фраза «мы архитекторы видим решение так», кажется, что все нормально, но сразу проводится невидимая линия — мы архитекторы, а вы не архитекторы, вы из другой группы.

Важно хорошо чувствовать появление разделительных линий и не запускать микроконфликт. Он хоть и микро, но все-такт конфликт, у которого может исчезнуть приставка "микро". Важно вовремя это заметить. Рассмотрим сценарии неправильного использования слов:

• Информационный разрыв. Вы думали мысль, выразили ее, собеседник услышал, и начал думать свое. В этом случае собеседник может услышать или понять что-то отличное от того, на что вы не рассчитывали. Тут необходимо проверить нет ли варианта, когда ваша фраза может быть некомфортна (быть истолкована как упрек, обвинение, наезд и т.д.) и запустить микроКонфликт. Рассмотрим три примера скрытых микроконфликтов. Как могут неправильно быть поняты наши слова и последствия этого:

  • Упрек. Например, у вас финал дискуссии с партнером, ваша точка зрения становится приемлемой для собеседника. Вы начинаете встречу с фразы, «как я говорил ранее…». Такая фраза может быть истолкована как «я же тебе говорил». Как старый анекдот: нет бы написать — «Пива нет», а то написали: «Пива не-е-е-ет». Если ваш партнер поймет это именно как упрек, не важно, что конкретно вы имели ввиду, это приведет к тому, что он сразу перестанет обсуждать проблему и сосредоточится на защите от «услышанного» то наезда, причем неосознанно, на уровне подсознания. Всегда проверяйте свою речь, по правилу «Пива не-е-е-ет». Да это вероятный, но микроконфликт. Множество таких микроконфликтов с одним собеседником, могут выработать у него сначала дискомфорт, в общении с вами, а потом и неприязнь и вы утратите возможность эффективно сотрудничать с этим человеком. То, что вы имели ввиду, менее важно, чем то, как вас могут понять;

  • Поручения. Например, вы можете написать или сказать коллеге: «Александр, пришлите, пожалуйста, информацию по такому-тому вопросу». Кажется, что ничего страшного, но это может быть понято как поручение. А загруженный работой человек инстинктивно защищается от поручений. Если перефразировать фразу «Саша, помоги, пожалуйста, найти информацию...» Неофициально (официально опять пахнет поручением или угрозой), и просьба о помощи, а не поручение, что более располагает к коммуникации;

  • Угроза. Еще вариант: вы просили человека, правильно, с точки зрения предыдущего пункта, что-то сделать для вас, он обещал. Как напомнить ему о вашей просьбе? Неправильная формулировка: «Михаил, ты обещал согласовать материал». Неявная угроза, ты не выполнил обещания. Более комфортная формулировка: «Миша (не Михаил), удалось посмотреть материал?» Даете понять, что понимаете интересы, что ваша просьба причиняет дискомфорт, человек занят и мы показываем, что мы это понимаем;

  • Всегда формулируйте фразу безусловно комфортно для собеседника, а не для вас. Заменяйте поручения на просьбы помочь, напоминания об обязательстве, на обращения "удалось ли сделать" и т.д.

• Неправильные слова.  Часто слова начинают незаметно формировать комплекс «Мы/Они». Например,

  • Неравенство. Тон, интонации. «Коллеги, нужно сначала проговорить с моим заместителем, потом со мной». Вас можно понять, что ваше время очень ценно, гораздо ценнее времени людей, которые к вам пришли. Тут же неравенство, кто ты и, кто они? Понимается именно так, хотя вы имели в виду, что ваш коллега (который случайно еще и ваш зам), более глубоко погружен в тему и он поможет быстрее и качественнее. Фраза: «Парни (а не официальное "коллеги"), с Мишей говорили? Он глубже в теме, проговорите, пожалуйста, с ним, если с ним все решите, мы сами внутри синхронизируемся». Как одна мысль, сформулированная различными способами, может по-разному восприниматься;

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

Очень важно: универсальный алгоритм «Пива не-е-е-ет », для проверки фразы на комфортность собеседника.

Секреты эффективного взаимодействия

Какие личностные таланты нам нужны посмотрели, какие ключевые проблемы тоже понятно. Теперь посмотрим ключевой момент в эффективных отношениях.

В кросс-функциональной команде мы зависим друг от друга — с этим ничего не сделать, это данность. Помним, чтобы взлетело — должны отработать все, чтобы упало, достаточно одного. Из этой данности есть две возможности. Каждое действие членов команды может привести к взаимному усилению или ослаблению. Усиление — это когда твое действие помогло команде-партнеру сделать ее работу, а не осложнить исполнение. Ты свою часть сделал, партнер нет и весь результат насмарку. Если между СУБО и КП согласия нет — оба не добьются результата.

Можно проиллюстрировать эту идею как вектора: все усилия (вектора) должны быть направлены в сторону достижения результатами с минимальными затратами для команды. Главное средство и инструмент — сотрудничество. Что нужно для сотрудничества: общие интересы, устранение болевых точек общения (их нужно выровнять — мы/они долой), нужно прозрачное информационное поле (информационные разрывы — берегись), доверие друг к другу — все это и поможет нам выстроить общение так, чтобы достичь общего результата.

Теперь я бы хотел предложить вам наш способ добиться такого сотрудничества — модели поведения архитектора. Мне представляется, что имеется базовая модель поведения, которая применима во всех случаях и есть ее две специализации, учитывающие разные типы людей: рациональная и иррациональная. Они применимы в комбинации. Прошу сразу иметь ввиду, что модели работают именно в комбинации, а не противопоставлении. Иначе мы можем увлечься иррациональной частью и свалиться в манипуляции.

Суть модели мы сформулировали следующим образом — базовая это общие принципы работы архитектора, и ее расширения; рациональная, основанная на одной половине нашего мозга — логике, и дополняющая ее эмоциональная модель.

Первая модель — базовая, применима в большинстве случаев. Она основана на рациональном способе поиска оптимального решения, при данных условиях. Возможно, в других условиях оптимальным будет другое решение. Для простоты допустим, что архитектор в этой модели безупречен в технической части. Он предлагает, соответствующие требованиям, решения. У нас созрела идея. Если мы не донесем ее до людей, она так и останется идеей. Берем инициативу на себя. Готовим материал, излагающий эту идею (помним о профиле успеха, навыках формулирования подхода, влиянии и убеждениях). Не ждем, когда спросят. Не выходя из зоны комфорта ничего не достигнешь.

При социализации идеи могут возникать разногласия — ведем дискуссию, используя навыки клиентоориентированности, ответственности за результат. Все разногласия фиксируются и обрабатываются. В итоге, архитектор должен оценить насколько своевременна его идея в данный момент. Можно предложить следующие критерии:

• Сколько людей разделяют идею?

• Есть ли кто-то, кто ее готов реализовать — владелец продукта?

• Соответствует ли текущий уровень зрелости организации и исполнителя сложности задачи?

Если все критерии выполняются — все хорошо, идея получила путевку в жизнь. Используем профиль успеха для реализации, помним о правилах кросс-функционального взаимодействия. А если нет? Можно обидеться и уйти непонятым, но это неверное решение. Оно редко приводит к результату. Очевидно здесь конфликт интересов противников и сторонников идеи. Тут целесообразно оценить, что еще нужно сделать, чтобы все же дать идее ход. Одним словом – стоит ли овчинка выделки. Если стоит, аккуратно продолжить работу, но помнить, что нужно вовремя остановиться и не стать рабом идеи. А вот что делать, если критерии не достигнуты?

Очевидно — нужно подождать, когда идея созреет и можно снова вернуться к ней. Для этого "архитектурный маневр", по дозреванию идеи для конкретной организации. Например, некоторые вещи затевались еще в ВТБ24, и только сейчас мы приходим к их реализации (НСИ, партнерства и т.д.).

Главная цель архитектурного маневра — отследить, когда что-то изменится в критериях актуальности, чтобы вернуться к идее на другом уровне. Как?

• Не кипятим океан, экономим силы (есть же еще задачи), не запускаем конфликты;

• Шлифуем идею, визуализация, краткость и понятность;

• Анализируем критерии реализуемости;

• Ждем момента завершения архитектурного маневра и возвращаемся к идее, но без упреков — "я же говорил!". В этом случае коллеги встанут в позицию защиты и идея уйдет на еще один круг маневра.

Здесь мы должны использовать все наши технические и личностные таланты для получения максимального результата команды.

Модели обучения

Принципы базовой модели определены, теперь рассмотрим ее расширения в обеих половинках нашего мозга. Каждая модель направлена на достижение результата, но разными средствами. Напомню, что нужно их комбинировать, а не упираться в одну их них. Также можно использовать их в обратную сторону — оцените, какую модель применяют к вам, чтобы скорректировать свое поведение для достижения общего результата.

Первое расширение — рациональное. Нужно совместно с коллегами понять проблему, совместно найти решение, выровнять это решение в головах, включая свою. Здесь вспоминается модель обучения Сократа, когда мы получаем понимание совместным поиском ответов на вопросы. Сократ задавал вопросы и совместно с учеником по мере поиска ответа получал необходимые знания. Мы это попробовали воплотить в нашем архитектурном чек-листе. Он тоже ставит вопросы в виде правил, а вы с помощью приложений к разделам ищите правильные ответы. Если эта тема интересна, то может подготовить статью и на эту тему.

Что важно при обучении, каковы принципы этого обучения:

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

Бесконфликтность — мы смотрели выше, конфликт очень сложная штука, нужно быть с ним очень аккуратным;

Взаимовыгода — помните о цели обучения: поделиться своими знаниями и компетенциями с коллегами, они должны их получить взамен потраченного времени. Цель наставника научить, а не круто и ярко выступить, дать возможность ученикам искупаться в лучах его блистательного интеллекта. Передать знания, а не заработать лайк или подписку на канал; Если ученик после курса поймет, что ничего полезного не получил — он только расстроится и больше к вам учиться не придет.

Двусторонность — тоже рассмотрели выше, напомню профиль успеха ВТБ: понимать интересы партнера. Согласитесь, то чему мы хотим научить и, что нужно ученику — может отличаться. Что нужно ученику глубоко погрузиться или решить задачу( сделать курсовик) и забыть;

Итеративность — безусловно. Человек может не понять сразу. Слона нужно есть по частям. Даем идею постепенно, а то большим куском можно и "подавиться";

Терпение — какая итеративность без терпения;

Ненавязчивость — идея или знания должны заходить добровольно. Насильно навязать идею очень трудно. Если заставить без понимания, снаружи все хорошо, но внутри у человека будет отторжение, а значит он реализует не так, как задумывалось. Если человек еще не понял вашу мысль, не навязывайте, а спокойно объясните;

Практичность — идея должна иметь цель на решение практических задач. Зачем космолет, если он не взлетит;

Долгосрочность — мы видели выше, что знания имеют срок годности. Идея должна иметь свой горизонт эффективности и не перестать быть актуальной сразу после реализации;

Доступность — не понял идею, правильно не сделаешь;

Достаточность — не нужно лишней информации, вероятно, она кажется вам важной, но нужно следить, чтобы она не замылила основою идею.

Эти принципы представляются необходимыми для обучения, и вы можете их пополнить своими, чем нанесете пользу всем.

Формы обучения

Это принципы, но где и как их применить? Какие формы обучения могут быть. Все вы их прекрасно знаете — все возможные мероприятия прямого общения с коллегами. Здесь нам опять в помощь компетенции профиля успеха. Таких площадок много — нужно на них выходить, если не много - организуйте.

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

Поэтому прямые коммуникации нужно дополнять офлайн-коммуникациями. Как понять, что процесс обучения завершен? Обычно в образовательных учреждениях — это просто экзамен, у нас такой возможности почти нет. Предлагаю другой по форме, но тот же по сути выход. Когда ваш партнер начинает применять вашу идею на практике — вы достигли результата. Придумайте метафору своей идее, ключевую смысловую фразу, как только ее повторят без вас в нужном месте — идея зашла.

Модель продвижения, для иррациональных

Мы рассмотрели применение рациональной части наших талантов. Теперь рассмотрим, как их можно дополнить или усилить иррациональной половиной нашего мозга. Люди очень разные, есть холерики, сангвиники, фанаты какой-то идеи или технологии. Можно попытаться переучить таких людей моделью обучения, но вдруг не получается, как же быть? Интеллектуальное насилие, вряд ли принесет плоды, а партнер очень умен и компетентен, нужно просто привести его к вашей же идее, только другим, эмоциональным путем.

Сначала посмотрим, как определить иррациональность. Некоторые признаки:

Гностицизм —  вы не понимаете высокий смысл этой идеи, она вам не постижима, только я знаю, как ее применить, и она применима везде. Например, микросервисы — серебряная пуля и мне ИТ-бог лично объяснил, что надо делать;

Эмоциональность —  человек очень подвержен модным течениям и тенденциям на рынке. Вчера был увлечен SOA, сегодня уже весь в микросервисах, завтра композитная архитектура, DataMesh и т.д;

Нечеткость — человек очень расплывчато формулирует свою позицию. Его позиция больше основывается на ощущениях, чем на строгом анализе и понимании. Например, что такое архитектура абсолютно понятно, есть четкое определение, но человек может использовать свою собственную трактовку, отражающую его восприятие;

Некритичность — человеке верит в идею и не подвергает ее критике, а по Попперу это основы научного подхода. Утверждения сопровождаются аргументами, утверждения без обоснования трудно критиковать, можно только верить;

Софистика — нарушение законов логики, обычно обсуждение ведется без четкого определения понятий, больший акцент на ощущения и как следствие информационный разрыв.

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

Какие инструменты можно использовать в продвижении своей идеи

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

Таргетинг — нужно учитывать, как, какому человеку продавать идею. Кому-то сухая подача, кому-то нужно добавить артистизма;

Простота и яркость — также, как и в модели обучения, но больше яркости и необычности в подаче материала;

Унисон с верующим — если столкнулись с фанатом чего бы, то ни было, технологии, принципа нужно быть с ним в одной религии, например, фанаты больших американских машин. Есть аналогии в ИТ: Oracle, С и т.д;

Магия — в докладе по идее должно быть, что-то непонятное иррациональному слушателю, что поможет ему поверить в идею другим способом.

Везде продвигать свою идею — продактплейсмент. Если попали в ИТ-секту, фанаты мэфреймов, СУБД ORACLE, а вам нужно заменить эту технологию — нужно быть как разведчик в тылу противника. Двигайте идею окнами Овертона. Важно, используя данную модель, не перейти черту порядочности и помнить, что нам нужно, чтобы партнер понял идею, а не запутался. Рано или поздно он заметит, что его ввели в заблуждение и дальнейшая работа будет затруднена. Надо быть крайне внимательным.

Мера успеха

Мы рассмотрели дополнительные компетенции — личностные таланты, какие необходимы и как применять их, теперь посмотрим, как оценить нашу успешность.

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

Самая важная вещь в доверии — это его добровольность. Нельзя насильно внушить к себе доверие, его можно только заслужить. Чтобы заслужить доверие нужно время, потерять же его можно в один момент. К потере доверия может привести любой из талантов профиля успеха, может вы не можете объяснить понятно или с вами неприятно общаться — любой из пробелов снижает доверие. Оценку доверия можно сделать на основании частоты обращения к вам. Если по вашей теме к вам не обращаются, то нужно внимательно посмотреть почему? Результаты нашей работы не нужны, с нами некомфортно общаться или нам просто не доверяют.

Важно заметить связь между доверием отдельному человеку, архитектору, и доверие ко всей архитектурной функции. Например, мы начинаем работать в организации. Уровень доверия к нам, в этом случае, будет равен текущему уровню доверия ко всей архитектурной функции банка. Дальше уровень доверия к человеку зависит во многом от самого человека, от его навыков и талантов. Причем это уровень доверия будет влиять на уровень доверия к функции и об этом нужно помнить. Чтобы наш уровень соответствовал уровню функции как минимум, а лучше повышал уровень доверия к функции через уровень доверия к сотруднику.

Если уровень доверия архитектора невысокий, то это начинает снижать общий уровень доверия к архФункции и это наша недоработка — это не только наше личное дело. Это может отрицательно сказаться на наших коллегах по опасному бизнесу. Отсюда следует, что квалификация архитектора соответствует уровню доверия к нему, или другими словами авторитету.

Итак, подведем итоги рассмотрения нашего опыта.

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

Вместо заключения

Предложенный кодекс архитектура нужно рассматривать как одностороннюю конвенцию. Мы предлагаем своим партнерам жить по нашим правилам, но не хотим навязывать их насильно.

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

Дополнительно нужно учитывать связи между архитекторами. Один использует функционал другого и тут тоже нужны горизонтальные доверительные отношения. Например, хочу «попользовать» ТС, ЕПА или УИП ( таинственные компоненты в ИТ‑ландшафте ВТБ), нужно доверие к данному решению. И вертикальное доверие от руководства подразделения.