«ИТ может быть не только про деньги»: я работаю архитектором программного обеспечения

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

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

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

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

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

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

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

Поступил, отучился, выпустился.

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

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

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

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

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

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

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

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

Позиция архитектора не является руководящей, но является экспертной, в обязанности входит четкое понимание потребностей бизнеса и способа реализации этих потребностей в сложной информационной системе.

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

Есть различные классификации архитекторов разной степени детализации, но на рынке РФ сейчас популярна следующая:

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

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

Результат работы архитектора напрямую влияет на стоимость разработки и, скорее всего, на прибыль, которую компания получит. И с этого момента начинается конфликт.

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

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

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

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

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

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

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

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

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