Как я стала системным архитектором без инженерного бэкграунда, и почему это нормально
Системными архитекторами чаще всего становятся бывшие инженеры, проектировщики и системные администраторы. Я же пришла в эту профессию совсем другим путем. Начинала товароведом, была маркетологом и затем через разные позиции в ИТ доросла до системного архитектора. Хочу поделиться опытом и рассказать, почему для системных архитекторов важны не только технические навыки, и показать, что люди из околотехнических специальностей могут также состояться в этой профессии.
Из товароведов в системные архитекторы с пятью остановками
В школе я увлекалась биологией и физикой. После окончания хотела поступать на биофак и мечтала стать биофизиком. Но это были 90-е, мы жили в Орле, и у меня не было возможности уехать учиться в другой город. У нас же были только педагогический и коммерческий институты. В итоге я по совету родителей выбрала коммерческий и отучилась на товароведа-эксперта.
После выпуска я даже девять месяцев проработала по специальности. В итоге поняла, что, во-первых, зарплаты в 500 рублей мне категорически не хватает, а во-вторых, по факту моя деятельность слабо связана с настоящим товароведением. Шел 2000 год: розница была такой, что никому ни моя экспертиза, ни закупка качественных товаров были не нужны.
Я переехала в Москву. Первые два года проработала маркетологом: занималась всем подряд, но должность почему-то называлась именно так. В какой-то момент передо мной возник выбор, куда уходить. У меня было предложение о работе менеджером по продаже строительных материалов с зарплатой в 1500 долларов и возможность перейти в ИТ, где предлагали на 500 долларов меньше. То есть я выбирала между деньгами сейчас и развитием в будущем. И выбрала ИТ, о чем никогда не жалела. Уже в начале нулевых я понимала перспективы этой отрасли в целом и для себя в частности.
Начинала я с контрактного сектора в компании, которая разрабатывала достаточно известную биллинговую систему для операторов связи. И пока я занималась контрактами, поняла, что мне интереснее проектирование оборудования, поставляемого по этим контрактам. Стало любопытно: люди, которые делают эти спецификации —, а как они их делают? Что это за оборудование — серверы, массивы, ленточные библиотеки?
Так любопытство меня привело в технический отдел, и я начала осваивать проектирование платформы. И оно же привело меня в итоге на позицию системного архитектора: по дороге еще был ряд компаний и должностей.
И вот я уже 10 лет системный архитектор, сейчас руковожу небольшой командой. У меня нет технического образования, как и у многих айтишников. Я никогда не была инженером и не занималась внедрениями, что, наверное, нетипично для моей профессии. Бывают моменты, когда меня это смущает, потому что кажется, что все вокруг с Windows- и Linux-бэкграундом и знают то, чего не знаю я. Я же все свои знания получала прикладным путем: стояла какая-то задача, я погружалась в тему, общалась с проектировщиками, инженерами и другими людьми и так осваивала профессию. Еще, конечно, много читала, гуглила, ходила на вендорские курсы и профильные конференции. И теперь думаю, что такой, пусть и не самый распространенный сценарий для системного архитектора, вполне состоятелен, потому что в нашей профессии очень много зависит не только от hard, но и от soft skills.
Разные архитекторы
Здесь нужно сделать дисклеймер. Даже в профессиональной среде есть путаница в понимании того, кто такой «системный архитектор». Потому что есть системные архитекторы, которые занимаются архитектурой приложений, и это больше про разработку, а есть инфраструктурные архитекторы, которые отвечают за платформу, железо, на которых эти приложения будут работать. Я отношусь ко второму типу, и все мои выводы справедливы только в отношении его представителей.
К нам приходит заказчик с задачей и требованиями к вычислительной мощности, ресурсам хранения, производительности и т. д. Еще всегда есть дополнительные разрозненные требования: разработчиков приложений, службы ИБ заказчика, внутреннего регламента ИТ-департамента. И задача архитектора заключается в том, чтобы все эти разрозненные требования собрать и скомпоновать так, чтобы по возможности удовлетворить большинство из них, не потеряв при этом функционал и производительность всего решения. Это в лучшем случае, а в худшем у заказчика есть только проблема или задача, которую нужно решить, а всё остальное архитектору приходится собирать по крупицам. На выходе я формирую техническое решение в виде набора оборудования и системного ПО.
Пара важных инсайтов о лжи и перфекционизме
Инсайт первый. Когдая только пришла в системную архитектуру, самым важным мне казалось найти идеальное техническое решение. Но жизнь быстро мне показала, что все совсем не так и есть вещи важнее оптимального выбора технологий. Например, существующие договоренности с заказчиками и вендорами, уже принятые стандарты компании и множество других ограничений. Так я поняла, что бизнес делают люди, а не технологии.
Вроде звучит просто, но это открытие меня в тот момент потрясло, потому что казалось крайне несправедливым. «Как же так, есть же задача, и она должна быть решена наилучшим способом из возможных», — думала я. Мне было непонятно, зачем инвестировать серьезные деньги в несовершенные решения, пусть уже кто-то сформировал мнение или написал регламенты.
Тогда, на самом старте, это бесило. Сейчас к этому уже выработался некий философский стоический подход. Моя задача как архитектора в этом случае — обозначить ухудшение, которое несет не самый оптимальный выбор или замена. Но иногда бывает и так, что я должна костьми лечь и настоять на лучшем решении, найти какие-то доводы, что «это — не вариант». Иначе мы получим нерабочее решение, и плохо от этого будет и заказчику, и сейлу, и мне. Это непросто: необходимо быть гибким, уметь убеждать и находить подход к собеседнику.
Инсайт второй — все врут. Речь не о злонамеренной лжи, когда тебя осознанно вводят в заблуждение. В работе системного архитектора тебе просто без злого умысла сообщают недостоверную информацию. Если, например, я не погружена в тему, а проектировщик говорит, что надо сделать только вот так, я скажу «спасибо» и пойду спрошу еще одного-двух человек и почитаю, действительно ли это так. Дело не в недоверии или в конкретном человеке. Я просто по опыту поняла, что люди погружены в свои процессы, у всех высокая загрузка, и часто тебе дают ответ по инерции, не особо задумываясь. Или у человека могут быть устаревшие или неполные сведения, он может не понять контекст твоей задачи и просто в чем-то заблуждаться. Если говорить в терминологии Даниэля Канемана, люди часто дают ответ, используя Систему 1 там, где явно нужно подключить Систему 2.
Выход один: я всегда перепроверяю и подвергаю сомнению информацию, которую получаю, даже если она приходит от моей любимой команды. Просто потому, что все мы люди и все мы ошибаемся.
Не инсайт, а общее место. В моем непростом пути в системной архитектуре мне очень помогло то, что я не боюсь задавать вопросы, даже те, что на первый взгляд кажутся дурацкими. Сколько раз я сидела на совещании, и заходила речь о чем-то таком, что половине присутствующих непонятно. Это можно было прочесть по лицам или понять уже после совещания, когда явно мало кто понимал, что в итоге надо сделать, посчитать и т. д. Часто люди предпочитают не подавать вида и сидеть с умными лицами. Я же предпочитаю задавать вопросы, когда мне что-то непонятно. Иногда такие вопросы сначала кажутся дурацкими, но чаще всего, когда на них начинают отвечать, задача раскрывается совсем с другой стороны, и всем становится понятно, что вопросы были по существу.
Технические vs человеческие
Я понимаю, что мощный технический бэкграунд помогает человеку стать хорошим системным архитектором, и все же автоматически его таковым не делает. Ты можешь качественно собрать все технические требования, объединить, обсудить с заказчиком, придумать очень красивое техническое решение —, но это всё потом умрет, потому что ты не сможешь презентовать его сейлу или заказчику. И эта часть проекта «про общение» часто съедает больше сил и ресурсов, чем техническая.
Поэтому я считаю, что личные качества, коммуникативные навыки и прочие soft skills крайне важны для системного архитектора. Путь в эту профессию из проектировщиков и внедренцев признан, но не каждый специалист с суперпрокачанными hard skills может стать хорошим архитектором. Для этого, по моему опыту, кроме уже упоминавшихся гибкости и умения договариваться, человеку нужны следующие качества:
Умение чем-то пренебречь и подняться на уровень выше. Иногда чем больше человек с глубокой технической экспертизой знает деталей, тем сложнее ему принять решение. Хорошо, если человек, зная обо всех нюансах решения, может подняться над ними и сказать: «Ок, вот этим мы можем пренебречь», и обрисовать заказчику связанные с этим риски.
Принятие решений в условиях неопределенности. Это вообще одно из ключевых умений системного архитектора. Потому что не бывает такого, что на старте проекта у тебя есть ответы на все вопросы. И особенно сейчас. Чаще всего заказчик хочет, чтобы сделали «как-то хорошо». А как это — «хорошо»? Вы же эксперты, и это вы мне должны объяснить, что такое «хорошо». Решения приходится принимать в условиях нехватки времени и ресурсов. Например, когда мы ведем пресейл, это 3–5 дней, еще у заказчика есть бюджетные и прочие ограничения — и под таким давлением при недостаточности информации нужно найти оптимальное решение задачи. И взять на себя все связанные с ним риски.
В целом это, конечно, здорово, когда у человека есть знания в технических науках, умение программировать на нескольких языках, он может сам смонтировать и настроить сервер или массив, знает на практике, как работают разные технологии. Это все очень помогает при переходе в архитекторы. Но есть еще личные качества и навыки, которые могут быть у человека из других направлений — например, продаж. Поэтому путь из других околотехнических специальностей также нормален, как и путь из инженеров, только в этом случае человеку будет сложнее: придется потратить много сил и времени на прокачку технических компетенций.
Из пресейла в архитекторы
Сценарий такого перехода будет похож на мою историю. Когда человек работает в пресейле и занимается проектированием, то чаще всего у него есть узкая специализация. Это может быть только виртуализация, или только системы хранения данных и т. д. И первый шаг, который можно сделать на этом этапе в сторону новой профессии, — начать осваивать смежные области.
Следующим уровнем развития будет участие в комплексных пресейлах, в которых есть больше одной составляющей, но которые не требуют участия системного архитектора. Через какое-то время человек уже понимает, что может больше, и готов сам вести проекты. Это эволюционный путь развития — ты идешь через осваивание смежных экспертиз и подготовку всё более сложных комплексных решений.
И дальше уже надо сделать финальный рывок. У нас, например, есть «школа архитекторов». Если в компании нет такой истории с выращиванием архитекторов внутри, можно попроситься к кому-нибудь на проект вторым архитектором, чтобы посмотреть, как эта кухня работает: поездить на встречи, поучаствовать в проектировании и внедрении.
Еще хочется сказать о навыке, который мне очень помог — навык обучения через аналогию. Теперь, по опыту, я понимаю, что эта способность есть не у всех людей. Но для человека, переквалифицирующегося в системные архитекторы, такой навык необходим. Потому что в принципе задачи, которые до этого никто никогда не делал, встречаются на практике достаточно редко. В них могут немного отличаться вводные, иногда условия совпадают один в один, только цифры разные, а иногда надо что-то добавить или заменить. Поэтому, если ты способен действовать по аналогии, — это будет очень сильно помогать.
Нет такого института, куда можно пойти учиться и стать системным архитектором. Это происходит через самообучение, изучение смежных областей и усложнение того, что ты делал. И чтобы стать хорошим специалистом в этой области, нужны эти способности — учиться у других и учиться самостоятельно — плюс некий стартовый набор личных характеристик: системное мышление, коммуникативные навыки, гибкость и др. И это справедливо для человека с любым бэкграундом.
Источник иллюстрации: Shutterstock.com
