Рост архитектора: от техники к бизнес-стратегии

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

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

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

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

>> Назови, пожалуйста, какой ты сертификат последний получил.

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

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

Вот теперь чуть-чуть про Hearts of Skills. Это центр экспертизы, который занимается распространением и накоплением всяких интересных вещей для опытных инженеров и архитекторов. Мы проводим множество бесплатных мероприятий и обучаем вот технических лидеров, архитекторов и синьоров. Медлов уже даже перестали обучать. Вот основное отличие то, что мы не пересказываем тот же самый Тогов или другие правильные и хорошие книжки, источники статьи. А мы рассказываем про то, как все эти красивые принципы и законы реализуются в реальных проектах и в реальной жизни. Половина из этих проектов, обычно реальных, а даже там, не знаю, 2/3 или 3/4, это Legacy, Castle, срочность и прочие, а интересные вещи. И вопрос архитектора - это выжить в этой всей истории, а ещё лучше быть успешным и хорошим архитектором и помогать бизнесом. И это эти ситуации часто отличаются от тех, которые описаны в статьях или книгах. Как быть, когда нет хорошего решения? Как быть, когда вообще нет никакого решения? Что делать? Антон в этом специалист.

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

Вот начинаем мы все, ну, синьора, то, что до синьора мы тут даже не рассматриваем. Синьор хорошо понимает технику, он на ней съел собаку, но он, как правило, не понимает бизнеса, что ему нужно, тем более не понимает в деталях, но зато он мог взять и сделать вещи. Вот. А когда синьор получает технические кругозоры, он становится софтверным архитектором. Что это означает? Вот в моих терминах, в терминах of Scals, это означает, что он может получить техническую постановку, выраженную там в количестве запросов в секунду, в необходимой нагрузке, в необходимых некциональных требованиях, выраженных на языке техники и цифры. и под это выбрать правильные инструменты и правильные решения, возможно, даже правильный процесс разработки и тестирования и delivy, то есть по поставки. А он ещё не понимает бизнес, не глубоко понимает бизнес, и поэтому он делает технические решения по техническим постановкам. Это первый уровень. Иногда это софтверный архитектор внутри монолита, а иногда внутри распределённых систем.

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

А следующее, следующий уровень - это когда тот самый тех, который понимает бизнес, может проектировать и реализовывать небольшие куски, растёт в масштабе своих решений. Он уже обслуживает, например, не только свою команду, но ещё и и ещё одну команду или ещё там две-три-четыре команды. И его решение становится более масштабными. возможно, какие-то части он уже отдаёт, делегирует другим аа инженерам, софтверным архитектором или кому-то ещё, чтобы они могли доделать его решение в рамках конкретно каких-то своих сервисов или компонентов. И когда такой архитектор, ну вот он здесь назван Solution архитектором, когда такой архитектор принимает своё, скажем так, начало, свою оптёку несколько команд, он начинает понимать, что не только бизнес и техника важны. Важны ещё коммуникации внутри организации. Как я донесу до этих команд то, что им нужно сделать? как я их координирую технически и как я их, а-э, ну, отчасти даже где-то замотивирую сделать так, как мне нужно, потому что власти, как у менеджера, у архитектора, как правило, нет. Менеджер может сказать: "Делаем так, такие приоритеты, и это будет его работа". Архитектор обычно так не может говорить. Он приходит к менеджер и говорит: "Давайте сделаем вот так. Это важно". А менеджер думает: "О'кей, мы на это выделяем приоритет или не выделяем". И вот здесь начинаются коммуникации и понимание ещё одной системы, кроме бизнеса и техники - это понимание орструктуры, процессов и коммуникации внутри. И здесь, а, происходит переход уже на уровень где-то даже каких-то политических вещей в компании, где чьи скрытые интересы, кто с кем дружит. И понимая вот эти вот вещи, понимая, как архитектура, техника связана с орбструктурой, со структурой отделов. Ну, собственно, мы получаем терпрайс архитектора. Вот. А дальше есть только ещё один более высокий уровень технический. это уровень CTO, который уже по факту совсем даже не архитектор, а менеджер. Но и организацию, и технику, и архитектуру он должен понимать или хотя бы понимать, как делегировать. Вот и аа вот такой путь архитектора и вот такие важнейшие преобразования, которые архитектору приходится пережить в своём развитии.

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

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

Примерно то же самое, но меняется масштаб, меняется образ действий. Это solution архитектор. Предположим, 3чеп команд, и их нужно как бы выстроить в единую систему и в единую систему выстроить то, что они делают, чтобы это было согласовано, чтобы были правильные взаимодействующие части. Здесь фокус происходит уже не столько на технике, потому что её обычно есть кому делегировать тому самому техряду, например, в каждой команде, а на коммуникациях между бизнесом и разработкой. Техника может у Солюшн архитектора, вообще говоря, отставать и у, скорее всего, Solutiontion архитектор не пишется код руками. Он может делать ещё кодри каких-то особо важных вещей, но тем не менее редко пишут руками. Обычно архитектора поэтому начинают сильно скучать. А вот, но тем не менее писать код для такого уровня человека уже непродуктивно. Он умеет договариваться, он умеет, аэ, как это ослаблять или рационализировать требования разных стейкхолдеров, когда они говорят: "Мы хотим ещё и сразу". Он им говорит, делает этобк и говорит: "Ну всё и сразу как давайте по кусочкам или давайте сначала так, а потом посмотрим". Вот он может работать уже с конфликтами интересов часто. Ну и, разумеется, он может работать с разными командами на уровне их лидов или синьоров или тех. Вот какие-то технические вещи ему уже приходится делегировать.

И Enterprise архитектор - это, как правило, его функция в том, чтобы концентрироваться на стратегии. Эта стратегия может выражаться как просто в техническом развитии, так и вообще в полном преобразовании организации для того, чтобы она стала работать по-новому с учётом технических возможностей. То есть что-то можно автоматизировать, что-то нет. Он работает в первую очередь с людьми и бизнесом и разработчиками, и наборами проектов, которые можно реализовать там шаг за шагом с помощью команды. Как правило, у него под началом или он делегирует часть своих вещей и Solution архитектором и техледам, ну, в зависимости от размера компании. Он очень много коммуницирует и очень мало занимается, собственно говоря, техникой. Хотя выросший из инженера, он очень хорошо понимает, ну, саму технику.

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

А, Антон, пожалуйста.

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

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

Вот частые вопросы про архитекторы, которые, ну, немножко хочется развеять. Архитектору не обязательно писать код, особенно с уровня Solution. архитектуру не обязательно знать всё про всё, всё про технику, особенно если он вот solution или выше. А вот, но, конечно, архитектуру полезно понимать, иногда полезно ещё и приятно пописать код, посмотреть, чем сейчас дышит там, какой новый фреймворк какой версии вышел, что в нём такого особенного. Вот. А так я посмотрю в чатике, есть ли вопросы. Principle architct уровню enterprise или между Enterprise и Solution. Ну, в зависимости от того, что компания вложила, какие функции. Если есть у принципала свои там условно подчинённые архитектора, то, скорее всего, речь где-то об enterprise плюс подчинённый Solution архитектора, грубо говоря. Но точно также я могу представить ситуацию и даже такие ситуации встречал, когда принцип архитектора - это вот уровень solution архитектора, который ещё не решает про организацию и не очень понимает, а просто архитектора или даже техледы - это, вернее, или да, и или тех - это вот то, что у меня описано на под словом тех. То есть нужно смотреть реально на функции, а не на а не название. Вот шельдочка может быть совершенно любой. Это может быть даже сеть, которое нанимается разработкой, потому что это стартап.

Антон, пожалуйста.

>> Я не хотел тебя перебивать, а, но в моей практике у меня был и лычка была, и Principal Architector, и Head of Architecture. И я занимался одним и тем же. Просто синонимы одного и того же оказались в разных компаниях. Тут прав, что как как назовутся, так и поплывёт. важнее, гораздо важнее, чем ты занимаешься на самом деле.

>> Спасибо, Антон. А, о'кей. Двигаемся дальше. А, значит, ну, виды архитекторов, опять-таки, как называется, так и называется, а что делает эта отдельная история. Я попытался разделить всех архитекторов, ну, всех, которые я там смог вспомнить ээ быстро. Вот по контексту техническому и контексту бизнесовому. А технический контекст обозначает, что он хорошо помнит, что что там находится в TCP пакетике, например, или как там правильно делать аки в кавку или как правильно сделать в редис какой-то, в общем, правильный вопрос, чтобы там этоль был правильный и всё остальное. Вот это мелкие детали. Крупный контекст это у нас Ага. У нас база данных постгре, у нас дата вхау на ещё чём-то. У нас тут, в принципе, Java со спрингом. А тут у нас мstaк из из нашего Legacy, ещё из девяностых, а тут ещё что-нибудь. Вот это крупный контекст техники. Мелкие детали бизнеса - это о'кей, в этой формочке такая валидация. В этой транзакции должно быть совершено то, то и то. Это всё должно быть закомичено в табличке. Вот это вот мелкие детали бизнеса. Крупный контекст бизнеса. В нашем бизнесе есть какие-то функции, направления. У нашего бизнеса такая-то стратегия, и её мы реализуем примерно такими шагами. Это крупный контекст бизнеса. Ну вот, если очень сильно упрощать. Вот. И вот по вот этой вот по этим координатам я разместил разные виды архитекторов.

Мой софтверный архитектор хорошо понимает мелкие детали, а техники и мелкие детали тех фич, которых, которые он проектирует и реализует. Большого контекста бизнеса он не видит, большого контекста техники он тоже чаще всего не видит, но погружён там в глубины, а не высоты. Java архитектор, конечно, бывает очень по-разному этим словом назнательно вообще, особенно впрас каких-то проектах. Ну, как правило, за счёт слова Java он хорошо понимает в своей в своём технологическом домене. Вот. И, следовательно, он, наверное, меньше понимает бизнес-домене, потому что у него, ну, восне понимает крупные мозки, бизнес домена, потому что он сконцентрирован. Скорее всего, он их жалефрастракши примерно то же самое, только вместо техники по имени Жава, техника по имени инфраструктура. Он хорошо в ней понимает, как тамроваться, как там, но там особенности бизнес там каких-то драйверов, от него далеки, BI, там Clouds, Integration. Integration часто понимает бизнес в более широком контексте. Может даже вот где-то вот так, потому что он разные куски, но и в технике он, ну, так нормально понимает. Вот Solution вот, наверное, даже сюда переставлю. Больше понимает в бизнесе. в смысле его там общая картина, но в технике, в деталях он уже от них может отрываться. Formation архитектор - это чисто про потоки информации, про технику можно даже особо не понимать. Системный может быть всё, что угодно. Видел системных архитекторов уровня вообще всего бизнеса Sinonim от Head of Architecture. Видел системных архитекторов, которые до деталей, до байтиков там всё всё понимали. Вот тепрай архитектор два раза. Он крупный контекст техники и крупный контекст бизнеса со стратегиями и развитием. Вот. А, в принципе, системный аналитик, он хорошо понимает бизнес и, скорее всего, в крупном контексте. И находится где-то, наверное, вот здесь, там, где примерно information архитектор. И он и чтобы стать ему архитектором, ему нужно чуть-чуть прокачаться вот в технику. То есть чуть-чуть вот спуститься немножко до деталей, разумеется, не до самого дна, там до кода, но до более мелких деталей особенностей.

Вот ещё вещь, которая касается работы архитектора, то, что на ранних этапах жизненного цикла проекта архитектор вовлечён сильно. Даже код ещё там писать совсем не начали, потому что непонятно какой код писать и куда его писать. Сектор уже во всё работает. А кто же тут значим для этого проекта? А что у них спросить? А что ему нужно? Снять требования проектирует, рекомендует каким-то скилам команды, а проектирует. И вот когда он занимается примерно проектированием, возможно, набирается команда на этот проект, там на найм внутрь или там это аутсорс аутсорс команда. Вот. И она занимается имплементацией. На этапе имплементации архитекторы нужно поддерживать, а не проектировать. и, возможно, проектировать какие-то новые дополнительные вещи, которые не были додуманы ещё на этапе вот первоначально, этапе там инфраструктуры, а, внедрения, обслуживания, поддержки. Архитектору вообще делать почти нечего. Ну, то есть можно спустить где-то до до нуля, даже вот раньше, чем Customer success, а ещё вот раньше на уровне внедрения. Вот если архитектор допустил какие-то серьёзные ошибки вот здесь на сборе требований или проектирований, то проект может до внедрение это, собственно, и не дожить. Вот это а вот тот человек, который приходит на проект, стартует его, отдаёт его разработчикам, он вот его функция достаточно близка к функции архитектор. Может быть, есть какие-то вопросики. А нет, это просто инвентарий. А так поехали. Карьера. А, возможно, Антон здесь меня дополнит. А, смены подходов при переходе от роли к роли. Я их немножко упомянул перед этим. Сейчас я расскажу более подробно. Вот. Ну, Синьор учится технике глубже и шире и становится архитектором. Вот паттерны всевозможные и Clean CД, и Clean Architк, и вот как компоновать компоненты в распределённой системе, правильно? Вот это сюда. Если к этому добавить понимание бизнеса, а то это получается роль техледа. Собственно говоря, я привык архитектора рассматривать скорее как толнача между бизнесом и техникой. Для меня настоящий архитектор начинается вот всё равно здесь. Здесь происходит серьёзнейшая трансформация, на которую не всехри вообще хотят идти, потому что это много коммуникации, потому что это много понимания вдомлости, в которой, ну, вообще говоря, ты не очень знаком, потому что всю жизнь-то делал свою там жалу, питон, что угодно, а а бизнес там не сильно задумывался. Вот. И вот это очень такая сильная и большая трансформация, которая ущет, а, технаря думать не красотой кода, правильностью решений или даже там скоростью решения, а думать требованиями функциональными и нефункциональными. Иногда ни скорость, ни красота кода, ничего не имеет значения. Имеет значение нечто другое. Вот когда а тех, понимая бизнес и понимая технику, учится, начинает понимать, как работает организация с процессами со всем он превращается влюрхитектор. Когда это понимание организации увеличивается то а получается прайс архитектор. Архитектор управляет, собственно говоря, архитектурой часто через выстраивание организаций и процессов, а не через systemмдизайн. А вот значит у нас получается бизнес, коммуникации и выстраивание организации чаще всего.

Антон, может быть, меня чуть дополнишь или поправишь?

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

Вы находитесь. А так ничего не могу скорректировать прямо.

Угу. Классно.

Горжусь собой.

Аа, хорошо. А куда расти, если вы, ну, архитектор на разных уровнях? Причём вот по функциям, а не по названиям, да? А сеньор, а значит, важно понимать те принципы и вещи, которые стоят за кодом. Знание немногих принципов освобождается от знания многих факторов. Аа изучать только ключевые вещи, которые меняются в индустрии. Сейчас это, разумеется, я и громкий. Вот растит сеть контактов для того, чтобы можно было расти дальше, проходить всевозможные курсы, например, вот очень хороший курс для синьоров, и читать всевозможные книги, которые погружают синьора глубже в мир техники, структуры данных какие-нибудь там продвинутые, например, conflict frees, где там ML или друг другие вещи, там теорема CP и так далее. Это погружение синьора дальше в тех, условно говоря, от фреймворков и реализации фич каким-то принципом, на основе которых самому можно делать любые фреймворки, говоря про фичей, про фичи.

Вот софтверный архитектор вот в этой терминологии, это если вот могу проектировать систем дизайну так нормально, но вы мне, пожалуйста, объясните, чего хочет от меня этот дядька в пишаке, который пришёл и и недоволен. Вот это уровень софтверного архитектора. Ему нужно понимать этого дядьку в пиджаке. И мало ли в чём сейчас ходит предприниматели SEO и прочее. Вот это а расширять свои границы очень сильно и учиться понимать бизнес и понимать, что тот самый дядька важнее, чем красота кода и архитектуры. Развивать знания в домене. понимать, где AI или вообще автоматизация в принципе улучшает что-то, а где она вредит. немножечко расти в сторону, ну, вернее, не немножечко, а сильно расти в сторону тише такого человека, понимая в разных областях, особенно на общебилити сильно вот сильно потребуется вот, а учиться делать архитектурные всякие документы по а-а не знаю, по их шаблону, которые достаточно много, от понимания бизнеса до технического решения, и опреснять их как команде с одной стороны, так и бизнесу. С другой стороны, проходи тот же самый курс техлип, который направлен и вот на этот вот этап развития, и передать всевозможные книги про уже связь аа бизнеса и архитектуры или про структурирование э тех архитектурных знаний, которые у архитектора на уровне софтвера уже есть. А примерные вот книги здесь указаны. Их довольно сложно, вообще говоря, перечислить. А вот Software Architecture Practice мне нравится за счёт того, что там систематизировано мышление архитектора, хотя ещё и не очень хорошо сделано, на мой взгляд, там описано взаимодействие с бизнесом. Ну и систематизировано, вообще говоря, не до конца, но начало очень хорошее этому и положено.

Вот если тех, то есть тот, кто уже умеет переводить с одного на другой, делать более масштабные решения, наверное, это вот для него единственный такой путь развития. Для этого придётся гораздо больше коммуницировать. Ну, без я сейчас никому и всем нужно понять, как эта работа может улучшить решение. И здесь уже речь про не столько проектирование, потому что оно вроде как освоено на нормальном уровне, а про документирование, про архитектурные процессы, про коммуникации, работа со стекхолдерами, потому что это нужно всё больше и больше применять. Вот работа с командами и как их вот групповая динамика, условно на уровне команд. А часто уже таким ребятам приходится интриировать достаточно серьёзные технические роли, поэтому про интервью тоже вот неплохо почитать. Ну и для солюшена аа расти в сторону Enterprise через тот самый тогов сей через вот вот эти вот книжки, ну через наши курсы, разумее смотря куда хочется расти из изолюшена и растить снова самое главное драйвер, собственно говоря, развития растецтво команд, а на которых ты влияешь масштаб решения. Как только, чем больше масштаб, тем сам масштаб будет провоцировать развитие в необходимую сторону про коммуникации, продажи своих решений, представления всего всевозможным странам разрешения конфликтов, а и как менять устройство организации, чтобы она продуцировала хорошую архитектуру. Вот enterprise архитектор, а программменеджмент, структура организаций, основы бизнеса на уровне, ну, конечно, не NBA, но вот на неплохом уровне. А, и вот эти вот книги. Мы не делаем курсов Линпрайс архитекторов, например, потому что их слишком мало требуется вообще уже, грубо говоря, вершин. Вот, может быть, есть какие-то вопросы. Доступ к презентации обязательно будет, так же, как и доступ к записи.

Так, а спасибо, Олег, за ответ. Аа, переходим к зарплате. Э, вот к реальности архитектора. А горечь реальности архитектора в том, что не все решения, не все задачи имеют красивые решения. То есть, скорее всего, задачи вообще не имеют красивых решений. Есть такие задачи, которые не имеют решений вообще и как-то её не решают, всё равно станет хуже. Так тоже бывает, что все те красивые техники, патерны, подходы к коммуникациям и так далее, они не всегда работают, потому что организация и взаимосвязи, и компетенции накладывают свои ограничения. Думаю, все из вас все видели Legacy системы, которые исторически сложилось мне бюджета менять. А что приводит ко многим всяким интересным вещам? Некоторым приходилось работать с некомпетентными командами. Например, я когда-то делал архитектуру очень давно для команды Нов. И я мне приходилось делать вообще максимально простые решения. И потому что у меня главное требование было, чтобы Джне могли это заимплементировать. Вот получилось там куча дублирований и всё остальное, но оно работало, и они это сделали. Вот. Больше я в такие игры не играю. А, ну и прочие вещи, которые, да, иногда приходится работать, в том числе и с некомпетентными архитекторами, особенно, например, с теми ребятами, которые там второй, третий, первый инженер в компании, который уже 10 лет, которые обрамлены ореолом уважения и трепета, которые влияют на решение всех дефанудера, но которые дальше уровня сеньора просто не пошли, потому что, ну, что их и так уважают, у них и так всё хорошо. И когда такой человек говорит что-то, что противоречит там бизнесу, ну не всем это может быть понятно. И это тоже создаёт проблемы. С такими людьми надо тоже договариваться.

В этой реальности есть ещё одна сторона, эта зарплата. А она, ну, я не буду на ней подробно останавливаться, она бывает очень разная, в зависимости от компании, от региона, там удалёнка, не удалёнка. Архитекторы на удалёнке тоже бывают. И в зависимости от огромного количества других вещей, в конце концов, того, как договоритесь, какие референсы вы предоставите и так далее. Вот. И, а, кроме того, эта зарплата, вообще говоря, сама цифра мало что говорит, потому что если вот вы живёте в Лондоне, это одно, если вы живёте в Балатуме, это совершенно другое, потому что разные налоги и разная стоимость жизни. Поэтому это можно поискать. Некоторые ссылки здесь предоставлены, но для своего региона, для своих стран стоит самостоятельно это всё делать. А вот а это в месяц. А ну, например, недавно одному из моих ментей сделали, накидали оферов, там, где средняя цифра в год с бонусами, там 200.000 долларов. Вот и он в арша. Это и уровень там солюшн архитектор. Вот такой хороший Solution архитектор. Это тоже реальность, поэтому цифры, ну вот могут быть совсем разные. А так может быть, есть какие-то вопросы? А, Константин, пожалуйста. Так, я не слышу. А, не слышно. Тук-тук. Так, о'кей. Тогда я пока отречу на то, что там вот пишут тон.

О, а вот сейчас слышно. Да, пожалуйста.

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

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

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

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

Угу.

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

Вот просит ли у архитекторов портфолио? Антон, наверное, тебе вопрос лучше.

А я никогда не спрашивал, хотя провёл, наверное, там полсотни интервью точно. И у меня никто никуда не спрашивал, когда меня кто-то интервьюировал. Вот мой ответ: нет.

А спасибо. Иногда можно дать, чтобы там похвастаться, если уверен, какие-то референсы на предыдущих там проектов, какие-то люди, которые там что-то могут про тебя хорошее сказать, но это скорее показатель моей уверенности и, может, даже наглости. А, ну вот как можно дать портфолио архитектора, да? Ну вот я делал этот самый вот мира, да, мира, во-первых, я делаю там канц там, в общем, не такой уж большой кусок, но оченьочень важно. Это правда. Ну вот как я его дам в портфоворить любых слов, проверить. Это будет нереально сложно, если только этот человек не достучится до там менеджеров, которые были у меня в мира, которыми я общался. Мой непосредственный менеджер ушёл через месяц после меня. CO, который меня нанимал, там теперь другой сети. Ну вот, то есть технически как это проверить? Ну почти никак. почти невозможно. Слишком дорого. А так так. О'кей. Хорошо.

А двигаемся дальше по презентации. Тренда в архитектуре. Здесь в презентации уделено очень большое место AI. Вот. А на самом деле я не хочу настолько много внимания уделять ИА, потому что я обещал уложиться в час и не укладывалось. Ещё и потому, что Айк, с моей точки зрения, очень сильно переоценён. Он сейчас на хайпе, и поэтому, а, его стоит адаптировать под себя, под свои нужды, в том числе архитекторские и девелоперские, но они быстрее вообще, чем каждый человек, это может делать. Сейчас индустрия эта идёт, она делала оче очень большой скачок, и человечество в целом пока ещё не может это полностью. как-то вот адаптировать. Ещё нет понятия там, как best practтисы про AI, они только рождаются. Тренды про AI оченьочень противоречивые. Кто-то говорит там всех разрывочиков, архитекторов скоро заменят и всё. Кто-то говорит, инженеров без AI заменят инженеры с AI, что более реалистично. Кто-то кто-то опубликовывал исследование из таких уважаемых организаций, что AI в среднем замедляет разработку на процентов 25, потому что пока ты ему объяснил, ты уже сам быстрее сделаешь на уровне синьора, грубо говоря. Вот. А есть достаточно узкий класс задач, на которых я и очень хорошо себя ведёт время всевозможные POC, MVP, но там, где нужно грамотно править контекстом. практис ещё не так уж много. То есть там, где у нас legy, там, где у нас вот это вот, ну, большие сложные системы, а это большинство систем, в которых есть деньги, там и Аю, в принципе, сложно, причём в любом. Некоторым проще, некоторым сложнее. А вот то же самое в работе архитектора. В принципе, по понятной постановке набросать там, сделать предположение об архитектуре или каких-то подходах А может надо сначала постановку взять и вытащить из техров, а это живые коммуникации и всё. Вот, Антон, может быть, ты как-то меня дополнишь или поправишь?

А нет, давай продолжать. Интересно рассказываешь просто.

Хорошо. Да. Значит, я не так давно, ну, консультировал организацию, которая была цель ускорить разработку в азы с помощью использования AI. Эта цель была поставлена, ну, ещё как только там AIpe начался. И похоже, что она у них не будет выполнена, хотя очень многие части вокруг разработки, процессы разработки, в том числе и процессы тестирования и процессы документирования были, а-а, вот улучшены с помощью AI, то есть там, где текст для человека, там тесткейсы, тестпланы, там я себя показывает лучше, чем там, где текст, который требует, ну, вот точного понимания и там безошибочность до запятой. То есть код и код - это на самом деле, пока я вот вижу по опыту этой компании, некоторых других, то, что код - это на самом деле наиболее сложно подверженная автоматизации вещь. Хотя вот появ появилась кажется у антропика таскмастера, да, который нужно задачу сначала разбить, а потом по кусочкам реализовывать, но опять-таки я сильно сомневаюсь в том, что это пригодно где-то шире, чем MVP. Вот какие-то простейшие штуки. Вот. А следить за этим нужно, использовать cloud D лучше, который вот пока считается там наиболее удобным или там хотя бы курсор или тот же самый ээ чат GPT кодекс, который комитики может сам делать даже. Стоит понимать, что это такое, стоит понимать все эти слова, там MCP, как рак, что там интелгентные системы и прочее, хотя бы в общих чертах примерно, но там как-то всерьёз к этому, ну, считать, что оно там что-то где-то заменит, ну, сильно вряд. Вот. Тем более, что AI обучен-то на среднем коде, который доступен Open Source проектах. А, и часто, ну, даже если код после работает, его нужно причёсывать, рефакторить и делать его, ну, как бы не средним, а хорошим. Вот поэтому я, ну, вот вы можете просмотреть, я и есть много проектов, которые AI пытаются помочь в архитектуре и так далее. И это, ну, относительно реалистично при условии, что у нас есть полученные требования. Вот. Ну а требования извлечь будет сложно, а потому что это про людей.

Вот есть ещё один код. Код тренд, который на фоне AI совершенно не слышим, но тем не менее он большой. Это кодкод разработка. А-а тоже не буду тут вот так вот сильно вдаваться, тебе тут очень много написано. Это когда можно перетаскивать квадратики, чтобы получилось что-то работающее для того, чтобы писать код. Это действительно удобная вещь для простых бизнесов и простых автоматизаций. Я, да, вот в Беларуси даже один банк обучил своих менеджеров, которые занимаются обычной там банковской работой, тем, что они могут процессы в в системе там этого кодло low cд как-то вот сами настраивать. Вот. И это даже у них работает. Банк вполне себе нормально живёт, не хуже, чем раньше. Вот. Но это скорее возможно для таких вещей, где не нужна там слишком большая нагрузка или там слишком много данных или какие-то там, в общем, совершенно стандартные интеграции всего совсем. Ну вот из маркетинга часто нужно бёрнуть что-то одно, потом другое, потом третье, отправить что-то куда-то. Вот для этих решений, ну, код очень выгоден. То есть там того, чтобы я вот до я там писал там сотни строк кода для того, чтобы делать эти простые интеграции, а сейчас вот есть тамн тот же самый, на котором это накидывается квадратиками. Да, от начала надо человека обучить на, но то, что у меня как там у синьоры разработчика отнимало там день, теперь отнимаю этого гораздо более там, ну, дешёвого человека, полно, ну, выгодно. Вот, чтобы это реально было применимо в архитектуре, вряд ли, но какая-то автоматизация внутренних процессов компании, ну, почему бы и нет. Вот тренды в архитектуре, разумеется, касаются, как это правильно всё использовать, как внедрять, как эти раги в чатботики и так далее.

Вот. Э, очень хороший, большой тренд, который, наверное, мне кажется достаточно многообещающим, это мультионетные системы, когда а каж когда есть несколько, ну, как бы агентов, у каждой из которых управляется своим промфтом и который выполняет свою часть задачи. Типа этот понимает установку, расписывает детализирует, разбивает и так далее. другой по каждой части пишет код, э, третий по постановке пишет сначала тесты, а потом четвёртый запускает эти тесты на этот код и возвращает обратно с указанием ошибки и так далее. Вот какие-то такие системы теоретически пытаются создать, а и у Google, там в Google Mass там нетная система и другие. Насколько они тоже работают? Ну, тоже непонятно. что управление этими контекстами - это очень, ну, нетривиальная вещь, потому что у нас контекст вот в голове, и он очень часто неосознаваем даже. То есть мы просто делаем так, потому что так мы чувствуем. А как это передать то, что мы чувствуем? Как, во-первых, понять, что это нужно передать, потому передать, вот это вот, э, ээ, большой вопрос. Возможно, когда-нибудь к этому придём, но я не думаю, что в ближайшие 5 лет, а может быть, даже в ближайшие 10 лет. Вот. Кроме того, есть ещё одно препятствие на э пути AI. Это то, что люди инертные, организации инертные на порядок больше, чем люди. И внедрение подобных вещей, а, ну, требуют достаточно больших вложений временных. то есть денежных или и денежных, и ещё временных. И при этом большая тенденция есть в том, что большие организации быстрее и более организованно внедряют к себе AI. А, вот, наверное, про тренды это всё. Я сейчас посмотрю, что у нас в чатике. Я вижу, что Антон ответил. Что-то там про ква третьего спрашивают, да? А вот, наверное, от Есайна вопрос: могу ли я, будучи сеньором, попробовать встроиться в другую компанию на должность софтверного архитектора, при этом не имея опыта работы архитектором? Во-первых, а, нужно найти сначала компанию, которая будет нужна именно сильный технический человек, который будет делать по техническим постановкам. Обычно хотят людей, которые делают по бизнес-постановкам технические вещи. Это во-первых. То есть это уже ограниченный круг. Во-вторых, ну теоретически это можно попробовать сделать, показывая я на интервью, что я тут, понимаешь, полкарьеры уже делаютную архитектуру, но я ещё назывался просто сньором, потому что не было у нас таких грейдах. Вот. Но опять-таки, а-а, часто приходится расти одновременно и софтверную архитектуру, постигая глубинной технологии на проекте и плюс в бизнес, постигая там какие-то базовые вещи, касающиеся как минимум моей сечи. И это развитие, которое у меня обозначено и линейно, оно идёт от сеньора. Ну так не совсем линейно, иногда параллельно. И вот здесь в тех, да, а вот здесь там в глубокую технику. Я, наверное, сейчас запутываю. Ну, миру сложнее, чем я его нарисовал. А вот я бы рекомендовал дорасти в своей организации до уровня то, что у меня обозначено тех, начать выполнять задачи по коммуникации с бизнесом и проектированию, даже самые маленькие, и потом уже это продавать, это ценнее, потому что это там, где бизнес, где бизнес, там больше денег. А вот, о'кей. Э-э, дальше я перейду к презентации курса Солюшная архитектура в диреде.

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

А второй раздел у меня посвящён коммуникациям Solution архитектора. Как понять, в какой я организации, какая у неё структура и кто вообще тут кому папа? И может быть вот тот самый старый и самый старый инженер в организации, самый главный технический человек, несмотря на наличие сетьо. Так тоже, вообще говоря, бывает. Как завоевать доверие? Я прихожу, я архитектор, и здравствуйте. Что мне делать? делайте то, что я говорю, потому что я архитектор. Так не работает. Работает по-другому. Надо это доверие завоёвывать. А продажи решений, как документировать так, чтобы даже вопросов не возникало. Ну, если, конечно, человек прочитал, блит сравнения и так далее. Это уже ближе к реальной жизни, что происходит в докоммуникациях архитектора. А документирование, это вообще говоря документация тоже вид коммуникации, потому что один её пишет, а другой читает. И присылы, как для тех, кто работает в сервисных компаниях, как готовить арките proposal, как какие вообще особенности у присейлов есть.

Ещё один раздел, который посвящён, собственно, по которому курс назван - это Безумный мир. То, что происходит на самом деле, это вот те самые случаи, когда решения нет, когда мы выбираем между плохим и ещё более плохим решением. А какие кейсы при этом бывают? Каких кейсов стоит опасаться? Ну вот самое самый простой пример - это проклятая роль, когда структура организации такова, что столько много ожиданий вся организация сформировала кроля единственного архитектора, что даже никакой самый гениальный талантливый человек не сможет это вытащить, потому что все от него хотят всего сразу. Вот завышенное ожидание. некомпетентные архитекторы, вот те самые супервлиятельные разработчики, как с этим вообще жить и выживать, как что такое культура компании, как её понимать и как под неё подстраиваться, а, ну и прочие разные интересные кейсы, которые вот из жизни. И что в них делать и что в них можно сделать или нельзя сделать. А много байечек от Антона и от меня, то есть небольшие компании, большие компании, что в них происходит и там сервисные проекты, продукты, стартапы, какие в них есть ловушки для архитектора и как их обходить. Да, оно всё в теории, по идее, сходится к красивым решениям стогофа, но в жизни происходит всё совершенно по-другому. Вот. Ну и ещё а один раздельчик посвящён, ну, собственно, тому, как сейчас видится будущее. Это про AI, а это про Low Code no CД и про Enterprise архитектуру. И, конечно, как нам строить карьеру архитектора вообще этом безумном мире.

Преподаёт курс Антон. Чуть-чуть его поддерживаю я в некоторых случаях там байечки порассказывать ещё из моего опыта, не только из опыта Антона. А вот обучение проходит в Google Meet. Там вот созвончики тельями, как чатик, календарь, всё вот это вот все эти формальности, записи всем курсам доступны. 12 недель по два раза в неделю плюс домашнее задание. Вот запись на курс происходит через интервью со мной, потому что мне нужно понять, что человек, во-первых, готов к принятию этой информации, у него хватает для этого бэкграунда. И, во-вторых, то, что он ожидает от курса то, что он действительно там может получить, а не чего-то другое. Потому что архитектора могут хотеть развиваться в разные стороны и, возможно, не в ту сторону. которая даёт курс. Вот. То есть на консультации мы формируем цель и её критерии, собственно говоря, что будет получено и что нет. Если я вижу, что цель не совпадает с курсом, то я лучше прямо так и скажу, э потому что иначе будут недовольны клиенты. А скидочка 5% тех, кто зарегистрируется до 24 сентября на интервью, на консультацию ко мне. Вот, собственно говоря, это презентация курса. А Олег сбросил аа календарь на выбор слота для консультирования. Ага, там ещё Сергей скинул какую-то ссылочку, не буду по ней переходить, а вдруг она какая-нибудь нехорошая. Вот. А-а, о'кей. Вопросы, пожалуйста, пишите в чате или задавайте. Антон, я передаю тебе слово. Ты же, наверное, можешь расшарить, да? Тон. Всё нормально?

Да. Надеюсь, что Да.

Это ты расшая. Всё прекрасно. Это не я расшарил. Или ты? А, ну, вроде мой экран, мне кажется, начало лагать, когда я

начал шарить. Ну, давайте попробуем. А, да, вопросы, пожалуйста, пишите. А, >> да, лагает 100%. >> Я могу расшарить свой? Буду за тобой. Давай. Хорошо. >> Буду за тобой следовать. Так вот. Ну, поехали. Антон отвечает на вопросы при регистрациях. А, ну, слушай, я, наверное, буду пользоваться презентацией, которую ты, э, провёл, да, и на на некоторые э на некоторые вопросы отвечать, как как будто бы мы дали ответ в ходе презентации на него, да. А, но обязанности области ответственности транзитный период. Буквально 2 дня назад мы проводили встречу, на которой я рассказывал интересный путь архитектора и как измерять, собственно, критерии успешности, да. Поэтому на ютюбчике, наверное, уже есть. Вот там сильно больше информации найдёте, чем а я могу рассказать сейчас. Сколько языков надо знать и какие? Отвечу в своём стиле. А первый язык, который нужно знать - это язык, ээ, на котором вы будете коммуницировать со своей командой, со стекхолдерами. Русский, английский, не знаю, у кого как. И, конечно же, английский, потому что придётся архитектору много информации добывать. Как правило, самое самое актуальное, интересное в первую очередь появляется в английском языке. Потом уже где-то всплывает в русскоязычных сегментах. А, Паша, да. чуть перебит к первому вопросу. Олег, сбрось, пожалуйста, ссылочку на запись понедельничного ивента. >> А, да, Паш, если у тебя есть своё мнение, конечно же, его высказывай. Мне очень ценно слышать мнения, которые отличаются от моего, и понимать, почему они вообще есть и что за ними стоит. Поэтому очень рад. Мне уже мы с тобой друг друга хвалим. Продолжай, пожалуйста.

Так, переход на Solution Architect или платформу инженерию. Я таких транзитов не наблюдал, если честно, но могу сказать так, что в платформах архитектура есть, а, да, она там важна. И, э, довольно часто вижу, как меня подменяются понятия ценности именно в платформе. И стекхолдером почему-то считают Девопса, а не того, кто будет использовать эту платформу. А, и скорее всего, если вот будущий архитектор будет понимать, для чего на самом деле делается продукт, кто у него бизнес, да, какие там ценности и, что важно, этот транзит будет успешный. Я бы так ответил на этот вопрос. А потом очень интересная карточка, прямо такая невероятная. Куда расти архитектору или становиться и получать все его проблемы не хочется. Я, наверное, всё с копом прочитаю, как бороться с синдромом самозванца. А на собеседоваях спрашивают какую-то фигню. Какая верхняя вилка ЗП архитектора? Мы немножко про зарплаты поговорили. Везде разные, я бы так сказал, да. Где-то, а, грос такой, как GNET, вы видите, да, всё очень индивидуально и по-разному. И даже в российских продуктах а бывают хорошие, очень хорошие предложения, на самом деле. А чем специфика архитек? Просто тем ли архитектуры, да? Типа того. Их два зарплата. Ну не знаю, был бы счастлив, наверное. Какой возрастной ценс архитектора? Ну я пока с иджизмом не столкнулся, а слава богу. И хочется верить, что что он отсутствует. Ну я, наверное, искренне тут заблуждаюсь, если честно. Нагоняю позитива просто. >> О, сорри, глупость скажу. По моей статистике лысом дают преимущество. >> А, опасная дорожка, слушай, вот прямо поэтому вернусь к вопросам. А, слушайте, карточка эта написана человеком, как будто бы, мм, который как будто бы я её сам писал, да? Мм, я бы сам с удовольствием послушал бы ответы на эти вопросы, потому что мучаюсь, страдаю точно так же. Вот поэтому, Паш, если ты тут можешь помочь с высоты там опыта, помоги, пожалуйста.

>> Я попробую. Дело в том, что архитектор, а, обладает достаточно большим влиянием, уважением в организации, что очень хорошо сказывают наши внутренние животинки. Вот. Но при этом не обладает всем геморроем, которым обладают менеджеры сети. И это, наверное, ну, для меня тоже это, ну, такая самая тёплая и приятная позиция, где я могу и умным быть, и влиять, и при этом не заботиться о том, что кто-то заболел в день релиза или там накануне релиза и не выполнил свои задачи и что и что-то по этому поводу бежать и делать. А вот и отсюда выходит, что архитектору э дальше расти просто некуда. Это самый крутой технарь, потому что вся чего уже обычно менеджер. А вот можно консультировать, что сложно, потому что это нужно ещё сначала продать всё правильно. Вот. А можно завести хобби или пэк-проект. Можно как я обучать других, но у меня это связано гораздо раньше, чем я стал архитектором. Поэтому здесь, возможно, стоит посмотреть на какие-то другие способы самореализации. Э, если задумываться про бизнес, то это то же самое, как сетьо, только с ещё большей ответственностью. Поэтому, ну, такой себе путь. Вот как бороться с синдромом самозванца. Сказать себе, что синдром самозванца - это признак нормального и хорошего этого профессионала. Сейчас в IT нет, ну, только у психопатов нет синдрома самозна. Очень, очень грубо скажу. Практически все не оканчивали профильные вузы, а те, кто оканчивали, и те, кто там архитектуре, точно не учились. Вот Антон получил сертификат от всей и, наверное, у него синдром самозванца теперь поменьше. Вот ему сказали умыли. >> Нет, ничего, ничего подобного. А вот количество вот этих вот сертификатов, оно, ну, лично мне наоборот докидывают этого самого синдрома, типа знания получил, э, хочется получить импакт. Вот я про это, кстати, наверное, вот после этой мысли-то и расскажу. А, а границы продукта не позволяют себе вот всё это проверить всё, да, и понять, что работает, что не работает. И ты начинаешь думать: "А зачем вообще эти знания? Помню ли я их именно так, как их рассказывали?" Короче, для меня это хуже история получается в плане синдрома именно. А так, да, если у тебя нет синдрома, что-то с тобой не так. Я думаю, вот правильный ответ. >> А если что, у меня тоже есть синдром сзан. как и у преподавателя тоже. Но с этим надо как-то жить. Короче, вот верхняя вилка. Я я попытался, ну, в общем, реально способа узнать верхнюю вилку совсем нет, только ходить на собеседование. А иногда реалистично в Европе получать американскую зарплату. В Европах это не вот не в бывшем СНГ. В бывшем СНГ нужно для этого очень постараться. Как при переходе от Сньоров Тимлида, так и переходе при от архитектора к лиду архитекторов илиходов архитек возрастание зарплаты не происходит или практически не происходит. Такова жизнь. Вот какой возрастной ценс. А сейчас отрасль, ну, как бы уже стареет. Если в каких-то нулевых это была отрасль молодых горящих и там всякие дядки с боро с бородами ещё были, как странно, вот то отрасль, ну сами сотрудники, в общем, стареют, те, кто остаётся в отрасли, становится старше. И, собственно говоря, для архитектора возраст - это даже скорее плюс, потому что он как посмотрит на какого-нибудь молодого, так молодой сразу всё поймёт. А молодого так не получится посмотреть. Ну, если очень грубо говорить, это так жизненный опыт. Это уже вот эта вот потёртость, стрелянные воробьи все. И обычно больше эмоциональной устойчивость, отсутствие паники в ситуации, когда другие, которые ещё в таких ситуациях не бывали, начинают бегать кругами, махать руками. Вот так что скорее для архитектора возраст по идее даже плюс, если правильно его преподносить. Вот это очень много про различный бренд архитектора внутри организации. Антон, ты хотел добавить ещё что-то?

>> А, да, про рост, про возможно рост архитектора. Это мысль не моя, но я её эксплуатирую. Это мысль Грегори Хопа, да, это там принципл архитектор Авса всего был, по крайней мере, пару лет назад. Сейчас не знаю. Ну, короче, дядька пишет книги очень умный. Грегори Хоп, ещё раз повторю. найдите, почитайте, прямо кайфанёте. А, и он говорит, что, э, да, есть вот знания, они должны оказывать импакт, но импакт ограничен, да, единственный способ архитектору оказать больший импакт, да, своими знаниями - это ими делиться. А вот что я, собственно, благодаря харцу скилам и делаю, на самом деле, и получаю от этого искренне удовольствие. Это маленькая такая маленькое дополнение было. А, >> двигаемся дальше. Да, следующий вопрос. Стои на пороге переходов Solution. Не могу избавиться от рутильных задач. Я начинаю уже спешить. Быстрый ответ будет делегировать. Делегировать то, что не касается архитектуры кому-то, да, концентрироваться на архитектурных задачах. А, пом-пом-пом. Тон, если у тебя по времени нормально, то ты не спеши. Кому интересно, тот дослушает, запись останется. В общем, так что лфри. >> А, хорошо. Тогда длинный ответ будет, в принципе, такой же, только с красивыми прилагательными, наверное, да? А следующий вопрос, где тот переходный момент, когда человек считается архитектором? А, вернёмся к презентации. С чего Паша начал? архитектор, тот человек, который начинает разбираться, а, в сути вещей, ээ, в связях вещей, имеет системный подход, а ещё лучше там критическое мышление, а, как было сказано, дальше не спешит, не суетится, спокойно решает поставленные задачи. Вот. Э, ну, естественно, задачи, связанные с архитектурой, да, вот где- это с архитектурной функция быть спокойным и писать код, наверное, это не совсем про архитектора. Вот переход инженера в архитектуру - это, в принципе, про что у нас сегодня, а, был весь наштап. История. А если интересно кому-то узнать, как Паша попал в архитектора, он с удовольствием расскажет мою историю. Я тоже с удовольствием расскажу, если останется время. А след дальше идём. Можно ли ставить солuttionн архитект без серьёзного опыта в разработке? Мм, как поставить границу ментор? А не няника. Про ментора однозначно вопрос к Паше, потому что у меня такие ситуации тоже случаются и я там не всегда идеально из них выхожу. А можно ли стать архитектором без опыта разработки? Да, моё моё убеждение - это прямо, да, на примере тех же самых системных аналитиков. Я в них верю, я в них верю больше, чем в инженеров. Вот. А про менторство Шпоки, пожалуйста.

>> Да, значит, нужно очень хорошо понимать сферу воздействия ментора. А есть у нас менсий, который вот он делает задачи и и менторится. У меня есть его задачи. Вот это вот это вот эта рука. И менси как-то на эти задачи взаим вот воздействует. И я вот стою сверху. И я воздействую не на мен, не на задачи, а на тот способ, которым он задачи делает. Вот способ - это мой объект воздействия как ментор. Если я сохраняю вот эту память, что я воздействую на способ, то тогда, когда менти говорит: "О, проверь мою задачу. Он у меня здесь не получается. У меня есть, ну, основа, на которую я могу ответить. Я твою задачу проверять не буду. Она твоя. Но я могу тебе напомнить наши основные правила по решению этой задачи. Инструкция, которую там ты сам мне тут сформулировал, выполнил ли ты все её шаги. Да ответственность, он тебя хочет спихнуть, а ты ему обратно, потому что на способ, а не на задачу и не на мити. >> Ну я твой ответ понял, услышал. Спасибо. >> А вот э давай дальше. В последнее время слышно теории про то, что всех на скоро уволят и востребованы будут люди, которые умеют правильно использовать АИ. Да, я перефразировал. Ну да, наверное, когда-то такой риск будет более актуален, чем сегодня, но расскажу, как есть. Собственно, мы пробовали челленджить чат GPT, да, на примере там несложных архитектурных решений. Это было смешно, прям ни одно решение ни разу не прошло и там до середины ревью не доходило. Ну просто просто ах и ох, чисто чисто посмеяться. И расскажу про курсы про наши, да. Студенты, студентам даются домашние задания, и некоторые хитрые студенты пытаются их решать с помощью чата GPT и прочих инструментов подручных. Значит, ну сразу видно становится. И мы точно также на разборе домашки смотрим, улыбаемся. Я прошу больше так не делать. Вот иначе какой смысл в практическом применении теоретических знаний, если человек слушает, а реализует потом не человек, просто теряете его возможности, на самом деле. >> Вот даже могу, наверное, дополнить про Low CноД решение. Возможно, когда продукт находится на какой-то суперранней стадии своего развития и там нужны супер простые вещи какие-то поднакидать, да? Ну вот гигиену продукта закрыть, как это сейчас модно говорить, наверное, а и low cд no cд может сильно бустануть на старте, но когда продуктовые фичи а понятные продуктовые фичирны, мы выходим там в голубые океаны, да, начинаем фантазировать, придумывать там единорогов каких-то сверху накручивать. Не только человек справится с такими задачами и в плане архитектуры, и и в плане кодинга. Вот. Ну, мой опыт такой, если у кого-то получалось там суперразмазанную по проекту фичу затащить с помощью нечеловека, ну, я бы посмотрел и перенял этот положительный опыт. А, но я таким, к сожалению, не обладаю пока. Вот. А-а, и давай следующую карточку. Просто интересно послушать. Нам приятно, приятно вам порассказывать. А как лучшим? Так, я, честно говоря, ответ на этот вопрос не знаю. А вот, может быть, и знать не хочу. А, но если, Паша, есть и есть чем поделиться, ну давай.

>> А, я хочу сказать, что становиться лучше нельзя. Нужно всегда быть самым глупым или хотя бы вторым по уму в комнате, чтобы было у кого учиться. Тогда будет развитие. Индустрия и всё остальное развивается очень быстро. И тут бы, собственно, не как лучшим, а как там хоть как-то удержаться и вообще на всём этом, что происходит. Вот поэтому стать лучшим. Как только вы станется лучшем, вы сразу же, ну, собственно, начнёте умирать как профессионал. Да, скорее из области психологии. А вот правильный способ развития - это вот у меня всегда есть там моя стратегия и пункты, которые я в себе прокачиваю, а значит, я не лучший. >> Согласен. А, хороший ответ. >> И мне на 5 минут нужно отойти. Я выключу камеру, отойду и потом вернусь. Паш, помоги, пожалуйста, удачи тогда. Продолжу пока. Да. А рост в тим вида out of scope для нашей презентации, потому что у меня про архитекторов. Но суть в том, что нужно пойти договориться с менеджером. Давай я буду тим рядом, давай мне хотя бы какие-нибудь задачки, которые вот отсюда в тим ряда. Это именно не в тех, а в тимреда. Вот иногда в компании могут оказаться, что все места заняты, и тогда в этой компании такого роста не получится. Так тоже бывает. Переход из мобильного разработчика вне мобильный архитектор и опыт. Есть достаточно большое количество ребят, которые хотят перейти из мобильщиков или из фронтендеров, которые там уже собаку всех собак съели на бэкэнд, потому что там можно расти в архитектуру, а в мобильном или во фронт, как правило, нельзя. То есть почти никогда нельзя. Вот здесь без нужно либо сразу подниматься на уровень бизнеса, уровень вот системной аналитики и уровень понимания бизнеса, либо провести хотя бы и оттуда уже растик как бы сверху от бизнеса вниз, а это будет проще, потому что он как бы всё равно инженерный. Вот. Либо годика, там год, два-три поработать бэкэнде, особенно если там технологии сложные, понять их и уже оттуда повторять. вот ту ступене ту лестницу роста вот синьора и выше вот а необходимо ли солюшну уметь писать код возможно ли быть успешным архитектором без напада как мы уже выяснили у системных аналитиков это вполне получается и как анкем говорил что это даже унихцене больше чем тех архитекторов которые из разработчиков чем современный инструмент архитектора как и всегда это коммуникации это язык и и мозги. Это всё можно украшать с помощью яи, но редко. А вот рисовать диаграммы и схемы можно вообще в любом инструменте, на доске в мира или в красивой, специальной и дорогой штуке, которая для этого предназначена и разработана. Смысла в этом одинаково, одинаковое количество. Основной инструмент архитектора - это коммуникации всё-таки. Остальное всё это, ну вот крайне редко где-то, крайне там что-то, э, можно, в общем, при чем занимаются люшены в разных компаниях, переводят с бизнеса на технику и обратно, а, дружат тех и других между собой. Ну, вот я вот сегодня рассказывал, да, жусли на ролик те, которые слится синдромом синдрома самос. А, наверное, да. Только вот эта вот вторая степень синдрома, вторая производная, меня как немного смущает, наверное, это артистска, а не сакан, печатка. Ээ вот, э, ну, в целом, ну, если нет синдромов самозван и человек считает, что я тут уже самый лучший всё знаю, то, наверное, у него проблемы. Вот, Антон, пожалуйста.

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

>> Хорошо. Значит, я схитрю этот вопрос. Я всё равно оставлю Антону, потому что на него ответит намного лучше, чем я. А вот и вопрос от системного аналитика. Возможно ли прийти и стать архитектором без знания код коммерческого? Да, возможно. Антон его только что про это произносил. Как стать архитектором? Собственно, сегодня была вот часть презентации именно про это. с какого уровня растём и что, что именно делать. А кроме того, приходите на интервью консультацию, и я вам смогу рассказать точечно. Хочу разобраться, куда двигаться в горизонте лет. У, мне бы разобраться. Интересно послушать, о чём говорят люди с большим опытом в моей сфере. А автору вопроса предлагаю прийти на консультацию перед курсом. Ну, без обязательства про курс, просто поговорить. Я собираю разные интересные кейсы и сценарии развития и могу и поделиться, и мне будет интересно узнать, что у вас. Интеграция инструментов в архитектуру компании. Пока лишь мечты и фантазии, если говорить всерьёз. Антон вот не так давно говорил, что вот час GP делает, ну, всякую ерунду. Возможно, если размить на 1.000 шагов каждому шагу, да, дать свой правильный контекст, так проще архитектуру сделать с нуля. Вот, Антон, я оставил тебе вот этот вопрос по стандарту архитектурной документации. Мне кажется, ты на него ответишь лучше, чем я.

>> А, ну да, давайте я попробую ответить. А стандартов существует невероятно огромное количество, да? Какие-то хорошо применяются в маленьких проектах, какие-то хорошо и прямо необходимы в больших проектах. А, начиная от бывают разные нотации, формальные, полуформаные, неформальные, э, разного уровня, разного масштаба, кому, как, что заходит. Есть некоторый набор золотых принципов, следуя которым можно держать объём документации в неком балансе, чтобы её было и, >> Антон, пропал твой звук. Антон, Антон, Антон. >> А >> звук пропал на на условие, чтобы её нужно было и пропала. Так, я говорил, чтобы её можно было и удобно поддерживать в актуальном состоянии, удобно использовать и никого это не напрягало. и чтобы её был объём, а, небольшой, на самом деле, достаточный объём для использования, потому что архитектор, а зачем делать архитектуру, и документацию, да, как артефакты своей деятельности, чтобы бизнес достигал своих целей через инженерные, э, решения. Вот инженерам нужно эти решения, собственно, и донести на понятном им языке, что очень важно. Как правило, это там какие-то адры, конечно, м либо там solution architecture document. Могут быть нотации всем известные и понятные. В модели CC4 можно рисовать UML диаграммки, особенно sequence диаграммы до сих пор супервостребованны оказываются. Есть стандарт ARC 42. А, короче, э очень много разных вариантов, на самом деле. инструменты для а написания, а, начиная от Draw. IO и заканчивая там, а, плазами для рprй архитектуры, такими как Sparks инструменты, архимейты и так далее. Вот. И я бы хотел вернуться к вопросу, я его неправильно прочитал. Если не хочешь релокацию, как найти удалённую работу? Да. А я перевернул эту историю как раз-таки с удалёнки на Rocate. У меня сложилась история, я отказался от неё. А как раз-таки я последних, наверное, 3-4 года практикую удалённую работу. И это это реально, а это возможно. Есть некоторые проблемы с коммуникациями в том плане, что, э, сетевые лаги, вот это вот всё, иногда они очень удобные, иногда там часовые пояса путаться начинаются, а, но работа делается, и если у вас цель найти удалённую работу, такие предложения на рынке есть. Вот не отчаивайтесь, всё получится. Да.

>> Ну дальше, дальше какой вопрос дальше? >> Вот про роль и ответственность солюшена и мельчайшие нюансы и границы коммуникации с дивоопсами, инженера инженеринг-менеджерами и стекло. А, а давайте в то же в то же видео редирекм, да, где я обговорил про раси матрицу и инструкцию, как как коммуницировать, проводить границы. >> А ещё лучше давайте редирекнем ко мне на консультацию, чтобы потому что на курсе про это будет целых 3 месяца. >> М. Да, да, да, да, да. А дальше высоко нагруженные приложения. Ну, вопрос суперабстрактный. Вот как и сам термин высокой нагрузки, да, он для всех будет абсолютно свой и разный. Я так, Антон, у тебя снова звук это пропал. >> Скорее всего, ответы на все вы найдёте на курсе про тех, мне кажется. >> А я по нагрузке отдельный курс делаю. Он уже выставлен, собственно, для продвижения на сайте, поэтому можете туда залезть и посмотреть. Там как раз пощупается, что такое нагрузка, запустить её руками с мониторингом и посмотреть вообще какая она. Вот. Но это, на самом деле, out of scope, потому что нагрузка, хотя это модные вещи, типа там такие процессора крутятся, крутятся, на самом деле это хорошо, если полпроцента или 1%, ну, всех проектов, потому что нагрузка - это, ну, это несложно, а вот сложная бизнес-логика и коммуникации, это обычно сложно. >> А, слушай, нагрузка, нагрузка не сложна, когда есть деньги на инфраструктуру, да? А когда у тебя там крылышки подрезаны, то а приходится выкручиваться и из большой нагрузки делать нормальную тогда. Вот. А давайте дальше. Какие есть возможности развития дальше в технической части? Не у всех компаний есть выделенный роли архитекторов. Вопрос как-таки для меня странновато звучит. А, а ты хочешь развиваться для того, чтобы как бы уйти в роль архитектора или ты просто хочешь развиваться, добрать на себя больше ответственности и и как бы вот органически туда куда-то двигаться? И как это нет возможности развития? А если кто-то думает, что там работодатель будет доставлять эти возможности, то, наверное, на сегодня это такое серьёзное фундаментальное заблуждение. Вот, по крайней мере, да. Да. Значит, здесь на самом деле достаточно просто. А нужно растить сколк своей ответственности, как при любом росте. Если хочется расти в архитектора, значит брать, а архитекторские задачи на проектирование, на коммуникации и становиться солюшеном де-факто. А а что там написано, неважно. И тогда, когда вы появите следующую компанию, у вас уже будет реальный опыт. Вы скажете: "Да, я назывался синьором, потому что была там полностью поская структура". На самом деле я занимался вот этим, вот этим и вот этим. И те, кто понимают, те поймут, что это про архитектуру. Или дать де-факто архитектор им сказать: "Ребята, я архитектор, дайте мне шильдочку архитектора, я хочу". И компания может вполне пойти навстречу. Но есть ещё один способ сменить компанию с риском и с риском не найти компанию, которой есть возможность для развития у архитектора. Вот. Но, вообще говоря, лучше быть сеньором в команде у очень сильных ребят, чем архитектором в команде слабых.

>> А, ну и слушай, ну фактически-то, а если если архитектора нету, ну кто-то ж архитектурную функцию-то выполняет, да? Аа вот это может быть тех, ээ, может быть, ты разработчик, в общем-то. А и если ты делаешь эту работу, а, ну, блин, подрасти, да, наберись необходимых знаний, чтобы себя уверенно чувствовать, иметь те самые варианты, из которых можно знать плохие варианты, чтобы можно было выбрать наименее худшие. Вот. >> А, о'кей. На этом вопросы закончились при регистрации. Спасибо большое Антону за ответы. Напоминаю, что до 24 сентября действует скидочка для тех, кто записался на консультацию до этого этой даты. Подробное описание курса вот по ссылке с красивой картинкой. А вот на этом мы заканчиваем. Спасибо всем, кто дослушал нас до конца. Надеюсь, вам было полезно. Запись будет завтра примерного в обед опубликована. Вот, Антону, спасибо тебе большое. >> Да, всем спасибо за участие.