Коммуникации в организации, да и в жизни являются краеугольным камнем успеха. Люди, которые умеют слышать собеседников, чётко доносить свои мысли и объясняться просто и понятно всегда добиваются большего успеха, чем те, кто этого не делает. На эту тему написано много бизнес книг и приведено множество способов как развить в себе эти качества.
Я считаю, что архитектор, а особенно корпоративный архитектор должен владеть коммуникациями в совершенстве. Моё глубокое убеждение — архитектор — это не самый умный человек в комнате, а коммуникатор, который способен понимать как людей из бизнеса, так и технических специалистов и выстраивать мосты между ними.
Gregor Hohpe в своей книге 37 Things One Architect Knows about IT Transformation предлагает рассматривать архитектуру как лифт между этажами бизнес людей и технарей, а архитектор в этой системе швейцар.
Я искренне не понимаю архитекторов и прочих специалистов в IT-сфере, которые фонтанируют умными фразами, технологиями и аббревиатурами в общении с бизнесом. А иногда и излишне умничают в присутствии других IT-коллег.
Архитектор должен уметь объяснять сложные вещи простыми словами, а для этого искать общие темы с бизнесом и рассказывать об архитектуре на понятных и житейских примерах.
Я, например, рассказываю об устройстве базы данных на примере ящика для хранения крепёжного инструмента, если общаюсь с мужчинами или на примере косметички, если с женщинами. Почти все, с кем я общаюсь, пользовались или одним или другим предметом и довольно быстро понимают проблемы поиска, хранения, индексации и суть осознанной денормализации данных.
Это в свою очередь существенно упрощает мне жизнь в дальнейших объяснениях проблем и задач, снимает лишние барьеры в общении и позволяет быстро налаживать доверительные отношения. Когда человек понимает то, что ему говорят, он не ощущает себя дураком и у него начинает формироваться доверие к собеседнику. Потому мой девиз – чем проще, тем лучше.
Умение объяснять сложные вещи на простых примерах я приобрёл ещё на заре своей карьеры в телеком, когда работал тренинг-менеджером и обучал сотрудников технической поддержки колл-центра.
Люди, которые приходили в колл-центр, не имели специального IT-образования. Это было в 2008–2009 годах и тогда такое образование вообще было трудно получить. Да и далеко не у всех было даже техническое образование.
Интернет тогда был дорогим и достаточно редким явлением, как следствие многие будущие сотрудники имели крайне ограниченный к нему доступ, а то и не имели его вовсе. Да и контента, который не был бы направлен на гиков в этой области или хотя бы написан на русском языке было не много.
А мне этих людей нужно было не только научить каким-то теоретическим основам, а ещё и вывести их на онлайн-линию, на которой они должны были не просто демонстрировать свои заученные знания, а помогать клиентам, которые обладали ещё меньшим техническим бэкграундом, решать возникающие у них технические проблемы.
Мои первые рассказы про пакетную передачу данных, инкапсуляцию, маршрутизацию, ATM и прочее вызывали только пустоту в глазах и мысль «Я не смогу» — в головах. Люди нам были нужны, и я хотел, чтобы на линию они таки вышли, а потому стал искать другие способы преподносить материал.
Через некоторое время моих экспериментов я обнаружил, что моим студентам были намного ближе и понятны принципы передачи данных на примере обычной почты. Имея перед глазами объекты реального мира – письмо, конверт с нанесённым на него адресом, а также цепочку рук, через которые проходило это письмо, людям быстро становились понятны концепты инкапсуляции и маршрутизации. А те, кто хоть раз отправлял посылки, обычно быстро понимали проблемы безопасности и разницы работы протоколов UDP и TCP.
Моя жена, например, спустя вот уже 13 лет помнит, что инкапсуляция – это коробочка, в коробочку, в коробочку, хоть и не помнит уже зачем это надо делать.
Люди всегда боятся всего нового и непонятного, а особенно когда можно проявить свою неосведомлённость публично. И меньше всего в такой ситуации они хотят увидеть перед собой заумного нерда-архитектора, который рассказывает им о проблемах кластеризации, контейнерах и сохранении целостности архитектуры при переходе на микросервисы и прочее-прочее.
Проблема объяснения становится особенно острой, когда вам нужно вести переговоры с топ-менеджментом, которому нужно сохранять лицо не только и не столько перед вами, а перед лицом всей компании, за которую он отвечает. Эти люди как правило разбираются в финансах, стратегии, управлении персоналом и других вещах, в которых как правило не разбираются IT-архитекторы. На них лежит огромная ответственность, у них очень мало времени, и мало желания разбираться ещё и в тонкостях IT-технологий. Более того - они и не должны, ведь для этого у них есть вы IT-архитектор. Потому умение быстро переходить на язык понятный топ-менеджменту не только ваша обязанность, а часто ещё шанс остаться в компании надолго.
Я не раз видел примеры, когда люди лишались работы, примерно вот с такой формулировкой – “мутный он какой-то, говорит какие-то заумные вещи, но я его не понимаю и не понимаю то ли он меня пытается наколоть, то ли и в самом деле выносит проблемы. В общем пользы всё равно не приносит, вот мы с ним и простились”.
Даже если речь не идёт о топ-менеджменте и выживании в компании, а о работе с линейными руководителями или средним менеджментом, умение находить “общие понятия” крайне полезно.
Что лично мне удивительно, несмотря на очевидную пользу быть понятным, некоторые архитекторы на полном серьёзе считают, что, если бизнес их не понимает, это проблема бизнеса и квалификации людей. И что бизнес-людям стоит поднять свою квалификацию, чтобы они могли понять его блистательные идеи и оценить остроту ума.
Я не разделяю таких взглядов и уже не раз становился свидетелем, когда такие архитекторы с треском проваливали задачи получения бюджета, защиты архитектурных решений, приобретения нового оборудования или запуск новых технологий. А всё, потому что сыпали кучей терминов и на запросы объяснить подробнее (читайте объяснить понятнее) – ещё больше ударялись в детали технологии и тем самым заваливали дело окончательно.
Из-за такого недопонимания я становился свидетелем роста затрат на реализацию решений, отказов от сотрудничества, эскалаций высшему руководству и вызовов на ковёр с разной тяжестью последствий, отказов в выделении средств и так далее.
Приведу два примера вышеупомянутых ошибок:
1. Создание твёрдого убеждения у топ-менеджера, что внедрение операционного CRM позволит реализовать функционал аналитической базы данных.
Для тех, кому это ничего не говорит, представьте себе, что вы искали коня, чтобы на нём пахать землю, возить телегу с овощами и, возможно, возить тяжеловооруженного всадника. А вам продали арабского скакуна только потому, что в начале своего предложения вы сказали – “Я ищу лошадь…”
2. Неспособность объяснить разницу между системой формирования заказа и системой исполнения заказа привела к тому, что заказчик купил только первую часть и был уверен, что вторая часть—это всего лишь настройка первой. При начале проектирования и заказчика, и поставщика ждал неприятный сюрприз.
На бытовом языке представьте себе ситуацию, что вы заказали услуги дизайнера интерьера и купили все необходимые материалы для ремонта квартиры.
А когда дело дошло до выполнения работ, вам сообщили, что придут устанавливать межкомнатные двери и вешать светильники, как финальная стадия оформления дизайна, а вот выполнение всех прочих работ в контракт не входит.
Потому мой вам совет, если хотите быть успешным архитектором или даже решите стать лучшим в профессии, вам обязательно потребуется освоить навык объяснения сложных IT-вещей простыми и понятными словами для бизнеса.
Или как говорят наши западные коллеги развейте в себе навык – «To find common ground».
Чтобы вам было проще с чего-то начать, вот несколько примеров для старта:
1. Нужно объяснить, как работает Телеком-сеть – расскажите на примере почты;
2. Как устроена БД, индексация и нормирование – коробка для хранения крепёжного инструмента / косметичка;
3. Интеграция IT-систем – барная стойка, холодильники, общий чан с пивом;
4. Очереди сообщений и проблемы масштабирования – кофейня Старбакс;
5. Проблемы и сложности миграции – перевод текста с английского (около 1,2 миллиона слов) на русский (400 тысяч слов). Если этот пример вас не устраивает или оппонент спорит о количестве слов:
a. Превращение Кириллицы в латиницу – транслитерация (особенно мягкого и твёрдого знака);
b. Переведите output и outcome и объясните разницу;
c. Изготовление сложного изделия, например двигателя автомобиля на оборудовании метрической системы измерений по чертежам сделанным в дюймовой;
6. Работы с большими данными – на примере библиотеки;
7. Проблемы отката транзакций – касса в магазине и всем известная Галя с ключом доступа к корректировке.