Сауны Омска - https://101sauna.ru/Omsk

Ошибки в ИТ стоят дорого: как архитектор спасает проекты и команду от провала

0

Ошибки в ИТ стоят дорого: как архитектор спасает проекты и команду от провала

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

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

Ошибки в ИТ стоят дорого: как архитектор спасает проекты и команду от провала

Виктор Мозжерин

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

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

— Знаете, я мог оказаться совсем в другой профессиональной сфере, потому что лет в 10 я мечтал стать врачом! Но уже в старших классах меня заинтересовали, заворожили компьютеры, тем более тогда они не у каждого были. Кроме игр, там оказалось много всего интересного. Я был в восхищении, когда узнал, что есть и другая операционная система — не Windows, а Linux. Мне в руки попал профильный журнал, и там была первая форма распространения программного обеспечения, первый дистрибутив. И классе в 10-м я решил сам поставить себе Linux. Всё, что было на компьютере, потерял, начал изучать и пробовать разные дистрибутивы пробовать и плюс-минус разобрался, настроил модем, начал изучать работу в этой операционной системе и сделал первые шаги в программировании.

— Понравилось?

— Да, меня это дело заворожило, и в 2005 году я поступил в СибАДИ на факультет информационных технологий по специальности "Информационная безопасность". Помню, первая лекция была посвящена низкоуровневому языку программирования ассемблеру (назначение этого низкоуровневого языка программирования — дать возможность работать с машинными командами процессора). Преподаватель называл такие термины, например, стек, регистр — всё было непонятным. Но потом всё пошло, сложилось, меня это заинтересовало ещё больше, и на 4-м курсе мы начали изучать базы данных. Это меня увлекло. Я начал экспериментировать вне учёбы, а мой одноклассник уже работал программистом на предприятии "Сиблифт". Он сказал, что им нужен администратор баз данных. Устроился: регистрировал базы данных, управлял ими. Там был неплохой встроенный язык программирования, и можно было писать разную бизнес-логику, и я вот разрабатывал бизнес-логику внутри базы данных. Начал больше перетекать в разработчика, чем заниматься администрированием.

— Ушли с предприятия?

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

— Не жаль было покидать место техлида и свою команду разработчиков?

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

Ошибки в ИТ стоят дорого: как архитектор спасает проекты и команду от провала

— Виктор, что такое архитектура в ИТ?

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

— Чем архитектор в ИТ отличается от привычного всем программиста?

— Это разный уровень стратегии и тактики. Программист, разработчик выполняет конкретную задачу, например, оптимизирует код. Задача архитектора — смотреть выше и часто даже не на код, а на систему целиком. И даже не на технические вопросы, а больше на работу с заказчиком. Архитектору важно понять его, узнать, что он хочет, и потом вниз команде спустить архитектурные требования. Ещё они отличаются ответственностью. Разработчик в коде, он отвечает за определённую область. А архитектор, опять же, отвечает за систему в целом, и с него спрос выше. Архитектор до старта работы над проектом, продуктом должен видеть общую картинку, которая должна в итоге получиться. Каждый должен делать своё дело, поддерживать систему на своём уровне и вести к успеху.

— Виктор, какие задачи в команде решает архитектор-разработчик в ИТ-проекте и почему его роль важна для успеха всей команды?

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

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

— Мы стараемся их минимизировать, но в целом в индустрии возникают базовые ошибки. Например, связанные с компонентами, когда они зависят друг от друга. Любое изменение в одном повлечёт за собой каскад изменений в следующих. И этот каскад в итоге может быть бесконечным, с невозможными или очень сложными изменениями. А доработки во всей системе — это значительное увеличение бюджета, и, к тому же, они могут привести к новым ошибкам, проблемам, например, с производительностью. Хорошая система должна быть спроектирована так, чтобы можно было взять кусочек и изменить его, подменить, дополнить без ущерба другим компонентам. Ещё система должна легко поддаваться расширению. Также есть ошибки внутри кода: использование неправильных шаблонов или в целом код неудобно читать. Бывает и такое, что команда долго идёт к реализации продукта, но в итоге оказывается, двигалась не в том направлении. Вот последнее — часто может быть архитектурной ошибкой, но и недоработкой аналитика: сделали, может быть, и хорошо, но не то, что надо.

Ошибки в ИТ стоят дорого: как архитектор спасает проекты и команду от провала

— На ваш взгляд, что общего между архитектором в ИТ и архитектором, который проектирует здания?

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

— Как архитектура влияет на развитие и поддержку проекта в долгосрочной перспективе?

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

— Как можно стать архитектором в ИТ?

— Можно, как я, перейти из техлида, из разработчика, но это мой сценарий. Не слышал, чтобы на профильных факультетах обучали именно архитектуре. Есть курсы, конечно. Но, на мой взгляд, компетенции архитектора надо просто взращивать в себе, развивать их, и без определённых подходов и взглядов на профессию тут не обойтись. Можно же зациклиться на своём кусочке задач и обязанностей, а можно стараться смотреть на систему в целом, выше. Смотреть на отрасль в целом, изучать новые технологии, подходы, да тот же ИИ. Глупо сейчас его игнорировать. И здесь не обязательно использовать языковые модели и углубляться только в них. Это может быть и машинное обучение. Считаю, тот, кто не занимается этим вопросом, просто отстаёт. Чтобы быть архитектором, нужно не просто делать техническую часть, а с интересом смотреть и изучать чуть больше. Уверен, могут быть десятки разных путей, чтобы прийти в архитекторы. Однако определённо нужна база, нужен определённый опыт в ИТ.

— Так и что же нужно знать архитектору на старте?

— Нужно знать языки программирования, потому что язык — это синтаксис, а среда даёт уже готовые библиотеки. Нужно знать фреймворки, шаблоны, паттерны, известные команды. Точно пригодится подход, который называется предметно-ориентированное проектирование DDD (Domain-Driven Design — подход к разработке ПО, который фокусируется на глубоком понимании предметной области и создании моделей, отражающих реальные бизнес-процессы и понятия — прим. ред.) Как видите, кругом языки. Плюс нужно понимать какой подход используется, понимать, где использовать микросервисы, где монолит, где модульный монолит и так далее. И здесь тоже есть определённые шаблоны облачной архитектуры. Нужно знать подходы событийной архитектуры и так далее. И без насмотренности тоже никуда. Архитектору нужна практика: одно дело знать теорию, и другое — набить себе шишек и извлечь из этого урок.

Ошибки в ИТ стоят дорого: как архитектор спасает проекты и команду от провала

— Виктор, я поняла, что вы очень любите свою работу и находитесь именно на своём месте — глаза горят. Но какие ещё у вас есть увлечения, помимо ИТ?

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

— Что обычно играете на гитаре, и вообще какая музыка вам по душе?

— Я большой поклонник Егора Летова, знаток его творчества. С ним лично, конечно, не знаком, но не раз общался со многими музыкантами группы "Гражданская Оборона", Сергеем Летовым. С Чёрным Лукичом, Вадимом Кузьминым, который написал песню "Мы идём в тишине", ставшую популярной благодаря исполнению Летовым, мне посчастливилось познакомиться и пообщаться. Увлёкся его творчеством я класса с 6-7-го и до сих пор это один из моих главных музыкальных. Если в целом про музыку говорить, то, не считая нашего русского рока, например, Виктора Цоя и так далее, нравится Nirvana и рок 60-х типа групп The Doors и Rolling Stones.

Чтобы больше знать, чем живёт мир информационных технологий в Омске и за его пределами, читайте нашу рубрику "Войти в ИТ".

Фото: Илья Петров

Главное изображение создано с помощью Midjourney 

Источник

Оставьте отзыв

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.