Comments 29
А потом появляется очередная статья. "Я крутой архитектор и не умею писать код (я не про уровень студента, а про уровень хорошего сеньора. l5 Гугла примерно). Почему меня никто не берет на работу?" Собственно вот поэтому и не берут.
Ну не, эта статья про другое. Если увидите такое, зовите, будем вместе отрабатывать
Работал в Сбере несколько лет назад, в нашей команде архитектором был человек, без опыта работы разработчиком. Было очень тяжело.
Человека? Или Сбер?
В стандарте как раз описывается, что опыт кода должен быть.
Сейчас с коллегами тоже ведем дискуссию по этому стандарту, должен или не должен, и появляется тезис, что код для архитектора может быть инструментом для выполнения своих задач.
Вот пример от моего коллеги https://youtu.be/B7IqUR9yb0w?si=CX1UY8wHwmzy5q6I использования такого инструмента архитектором.
Тоже крутая штука!
Вот пример от моего коллеги
Кстати, @rpiontik регулярно говорит и пишет, что архитектор программировать должен, а то потеряет контакт с реальностью. И под программированием он имел ввиду не только нотации DocHub, на сколько я его понял.
Да, так и есть, держать руку на пульсе безусловно надо, главное не лезть в Продакшн продукта!
На ArchDays разговаривал со своим одногруппником, он тоже говорит что периодически пишет код (потому что умеет), но решает с помощью кода свои управленческие или архитектурные задачи.
А подход Романа в части architecture as a code мне тоже нравится, но это уже больше инструмент архитектора и решение вопросов архитектуры, а не непосредственно Продукта.
Поэтому пишите код в свое удовольствие!
Увы, именно так обычно все и получается.
Откуда вообще эта мысль что человек который не пишет код может понять как проект внутри должен быть устроен? Он же понятие имеет как реально себя ведет та или иная система, какие у них реальные ограничения и чем разработка хочет/не хочет пользоваться. Желания разработки весьма вероятно мотивированы чем-то.
Нарисовать пять квадратиков соединить их стрелочками и уйти в закат можно. Но смысл? Потом опять придут разработчики и сделают нормально. Или быстро, если так надо.
А как насчёт Solution Architect, являющийся частью Sales команды в качестве технического специалиста и помогающий будущему клиенту понять как покупаемое клиентом ПО может использоваться клиентом. Эту роль вряд ли можно назвать руководителем среднего звена.
Эту роль можно смело назвать менеджером по продажам. Представьте архитектора зданий который ходит по квартирам и рассказывает какие поклеить обои. Не хотел резко, но как аналогия норм
Представьте архитектора, который встречается с заказчиком небоскрёба до того как его построят для того, чтобы согласовать ожидания, требования и будущий облик. Или вы думаете, заказчику не нужна вся эта ерунда и нечего обсуждать с архитектором, достаточно только с девочкой из маркетинга попить кофе?
Ладно, хожу с козырей, раз дела уже дошли до небоскреба. Представьте, как он (архитектор) прибежал на встречу по теме нового небоскреба с другой встречи по строительству избушки.
Вот мой посыл: работодатель платит большие деньги архитектору, например, 1000 руб./час * 8 = 8000 руб./сутки.
Строительство избушки принесет работодателю выгоду 1500 руб., а встреча займет 2-4 часа.
Поэтому в целом да, архитектор на предпродажке может быть, и должен быть, но если один клиент купил, а другой не купил, а работодатель платит деньги архитектору, а мог бы оптимизировать эти затраты и платить специалисту грамотному, но попроще, то человек, который помогает определиться клиенту с продажей - вряд ли архитектор, он менеджер по продажам, потому что его KPI зависит от продажи.
Так себе у вас козыри. Исправление ошибок, допущенных на раннем этапе проекта на последующих обходится на порядки дороже. Вы сэкономили на оплате недели работы архитектора на пресейле, ура! В итоге он не понял что хотел заказчик и построил небоскрёб, а заказчику нужен был бассейн на 58м этаже. А ещё вентиляцию на крышу из подвала - там будет ресторан.Теперь будем в готовое здание впердоливать бассейн и дополнительную вентиляцию. За чей счёт? Экономия!
И согласование это процесс двусторонний. Архитектор мог бы сразу отговорить от бассейна на 58м этаже по тому, что это слишком сложно и дорого. А предложил бы бассейн в фундаменте. Но не отговорил и не предложил. Сэкономили!
Это вопросы к менеджеру, который продал небоскреб, и к Заказчику, который согласился на это. У Заказчика вообще есть 58 этаж? Менеджер сам может в этом убедиться? Пусть делает свою работу и составляет график проекта, а не отрывает грамотных людей от работы.
По поводу вентиляции не скажу, не спец, у меня только ИТ
Архитектор ПО это наверное software architect, который занимается архитектурой собственно приложения - на уровне пакетов, модулей, компонентов, классов.
Следующий уровень systems architect. Он делает так, чтобы разные приложения и информационные системы в организации работали вместе.
Solution architect это мостик между бизнесом и решениями его бизнесовых проблем. Он строит свои решения уже на уровне capabilities организации (которые включают в себя не только айтишные функции). Стоит ли ему писать код? Ну ни кто не запрещает, но это действительно не его основная задача.
Могу немного рассказать про роль в рамках американских компаний. Последние 5 лет имел роль L6 архитектора в компании из fortune 20. Для контекста, мой орг насчитывал 70 человек в 3 странах. Мы поддерживали 3 платформы с миллионными QPS и реализовывали десятки E2E решений в год для определенного круга бизнес задач. Я напрямую репортил L8 синьор директору, периодами VP.
Для платформ я был system architect. Основные обязанности были: 1) Предоставление виденья развития на следующие 1-5 лет. 2) Выявление и документирование и внедрение инженерных стратегий на основе архитектурных записей. 3) Помогать продуктовым и инженерным менеджерам с квартальным планированием. 4) Ревью дизайн документов. Можно заметить, что я не занимался дизайном решений сам. У платформ есть тех лидеры и несколько стафф инженеров, для которых проектная работа важнее в плане роста. Но я контролировал, какие решения выбирает команда и как они согласуются со стратегиями и виденьем.
Для E2E решений я был solution architect. Обычно в проекте участвовало 50-60 человек из 10-15 команд. Но были у меня и проекты на 400 человек. Основные обязанности: 1) Сбор требований для проекта 2) Разработка модели 3) Согласование с безопасниками и юристами 4) Согласование со всеми командами и лидерами. Для больших проектов согласование может быть в формате офф-сайт на 100+ человек на 2-3 дня, как правило, в долине, но однажды был в Нью-Йорке. 5) Помощь в планировании 6) Помощь с внезапными вопросами в процессе реализации. 7) Ретроспектива и обновление стратегий/видения. Опять же отличается от описанного в статье. Дизайн, реализация, тестирование и поддержка ложатся на плечи лид инженеров из соответствующих команд. Контроль выполнения, решение комуникационных проблем и "мотивирование" успеть в срок лежит на TPM. У TPM, как правило, 1-3 важных проекта на квартал, у них есть на это время. У моей команды обычно было 10-15 важных проекта на квартал. Я либо сам участвовал, либо спонсировал своих падаванов.
Еще в обязанности входит менторинг, обучение команды и прочие technical excellence. Обычно мне на квартал давали 2-3 человека, и еще двое помогали мне на постоянной основе. Я хостил минимум один коричневый мешок в квартал. Плюс иногда отвечал за technical excellence проекты, например, смещение акцента с юнит тестов на интеграционные и внешние функциональные. Такой проект обычно включает несколько презентаций и близкую работу с тех лидами в течении квартала.
Можно заметить, что горизонт планирования у меня был квартал. Это означает, что надо мной было еще 2 уровня архитекторов. Надо мной был архитектор ответственный за 10к орг. Ее горизонт планирования в районе года. Обычно я с ней созванивался пару раз в неделю. Над ней был еще круг из 3х архитекторов, чьи позиции эквивалентны VP+, они ответственны за стратегические решения, которые повлияют на компанию в следующие 3+ года, может десятилетия.
По поводу должен ли архитектор писать код. На первом интервью с рекрутерои на L6+ вам скажут, что ожидают от линейных инженеров на этой позиции 70% проектной работы и 30% написания кода. Как архитектор, я иногда пилил маленькие проверки идей в последний месяц квартала, если удача была на моей стороне. Но никто не просил меня писать код. Я пытался хотя бы делать код ревью ключевых фич в моих проектах чтобы поддерживать связь с реальностью.
Работаю солюшен аритектором уже лет 15. Продуктивный код не пишу ... тут понятно, так как чтобы это делать, надо делать регулярно.
Но в рамках PoC собрать чего-то новое - почему бы и нет. Тут как раз лучше руками почувствовать как это новое выглядит
Есть важный аспект, который пропущен. Это закрытие gap'ов в команде. Часто делаешь что-то что просто некому во время внедрения, пока не найдет/обучишь альтернативу
Меня закидают тапками, но я работал архитектором решения и код не писал. Во всяком случае по своему решению. Это разная работа. У архитектора хватает чем заняться, а код есть кому писать.
Точно! Ему нужно проектировать вентиляцию на 85 этаже!
Мое мнение - что стандарт очень нужный, просто на рынке полно вакансий для универсальных солдат. Тапки кидать не буду.
Помню, как мне предложили эту должность со словами "Придётся 40 часов в неделю сидеть на созвонах". Действительно, хватает чем заняться.
ну да. Только не "сидеть на созвонах", а активно согласовывать противоречивые требования и решения. И от качества этой работы зависит что вы в итоге построите - франкенштейна или гармоничное решение, где все части будут согласованы и к месту. Если у вас все крутят гайки и никто не видит общей картины - то будет франкенштейн. "К пуговицам претензии есть?" (с)
Я наверняка не буду оригинален в том, что большинство сберовских созвонов вообще не нужны и могут быть заменены парой-тройкой писем или задачей в Jira, и большая часть их времени бесполезна чуть более, чем полностью.
Я не сидел на сберовских созвонах, ничего о них сказать не могу. Но чтобы построить большую и красивую систему, надо очень много нюансов обсудить, согласовать и сбалансировать. Каждое поле, каждая галочка имеет свой смысл и влияет на поведение системы, каждая должна быть на своём месте и работать ровно так, как надо. А как надо? Это кто-то должен продумать и всех заинтересованных убедить, что именно так будет лучше всего. И сточки зрения потребителей и сточки зрения технической. И всё должно следовать какой-то единой концепции. Это большая работа, в основном на совещаниях, да. Но это очень интересная и важная работа. Мне было очень интересно этим заниматься.
Solutions architect, который не пишет код