«Брат, я не знаю»: о курьезах, мифах и катастрофах в профессии Solution Architect

Работа архитектора в IT-компании — это не только объемный сухой регламент с кучей обязанностей. Solution Architect в Ciklum Константин Ходыкин рассказал о смешных и раздражающих ситуациях на работе, а также «проколах» специалистов, которые обернулись многомиллионными потерями для компаний и настоящими катастрофами, в продолжении интервью Highload.

Человек на интервью сказал мне: «Брат, я не знаю»

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

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

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

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

Есть несколько мифов, связанных с профессией Solution Architect

Любимые фразы архитектора — «это зависит от…», «и да, и нет». Один из мифов об этой профессии гласит, что архитектор — это продвинутый инженер. Он должен знать много технических фреймворков, понимать технологии — я согласен, но кроме этого очень важно еще и понимание бизнеса. Без этого работать архитектором очень сложно.

Еще миф: архитектор — это менеджер. Это не совсем так: у него нет прямых подчиненных, он просто предоставляет технический бэклог. Есть также мнение по поводу того, что представители бизнеса, с которыми работают архитекторы, не понимают, что они делают. Якобы, если бы понимали, как сделать продукт, они бы не приходили к сервисным компаниям. Да, они не понимают, как строить технологический продукт. Но, с другой стороны, это единственные люди, которые понимают свой бизнес. Поэтому думать, что заказчик совсем не соображает, что делает, тоже неправильно. 

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

У меня были на работе такие задачи и раньше — я частично исполнял функцию Application Architect (архитектора программного обеспечения — прим.). Но здесь — другой уровень. Нет человека, который скажет тебе, что делать. Это было неожиданным открытием. 

Ошибка архитектора может стоить миллиард долларов

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

В индустрии есть примеры многомиллионных убытков из-за ошибок архитекторов. Скажем, кейс Knight Capital с потерей $440 миллионов, катастрофа с ракетой Ariane 5, стоившая $370 миллионов, или менее драматичная, но поучительная история с багом Ad-hoc Wi-Fi подключения. Вполне вероятно, именно эта ошибка и стала причиной популярности Bluetooth. 

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

Архитекторы высокого уровня способны занимать позиции СТО, CIO

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

У нас есть джуниор, мидл, синьор, лид Solution Architect. Если архитектор только пришел в компанию, ему нужен старший напарник, который поможет во всем разобраться и не совершить ошибок. Затем архитектор растет и становится более независимым, может сам участвовать в проекте. Senior Solution Architect может вести пресейлы, несколько проектов, участвовать в разработке процессов компании. Считается, что архитекторы высокого уровня способны занимать позиции СТО, CIO в компании.

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