Александр, спасибо за видео. Хотел бы увидеть продолжение вашего исследования по поиску работы. Появился вопрос. Как вы считаете, архитектор по какому либо контуру должен владеть одним программным продуктом или он должен знать линейку продуктов по своей области? Например, УТ, КА, УПП, ЕРП или БП, ЕРП, КА, УПП или ЗУП, БП, ЕРП?

В середине видео Вы упомянули, что изменилось Ваше отношение к ТОГАФ, можете кратко рассказать в чем, какие аспекты подхода стоит пересмотреть? Можно без супер-детализации, просто хочется понимать о чем речь

Спасибо!

Классно выдал базу )

Правильная позиция, есть над чем подумать и что отвечать HR)

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

Спасибо большое, продолжайте, пожалуйста.

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

Ну, справедливости ради "потупил в ютубчике" - это тоже может быть полезным действием, для восстановления психической и умственной энергии. Мы в этот момент не заставляем мозг думать, и даем ему худо-бедно переключиться, выработать быстрый дофамин. Да, погулять было бы эффективнее, но все таки, если такой возможности в данный момент нет - то why not?

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

На мой взгляд, любая программная автоматизация и 1С здесь не исключение - это процесс ответов на четыре вопроса: 1. Зачем? Отвечает на этот вопрос бизнес. Заказчик. Если он не понимает зачем ему изменения системы, почему без них нельзя обойтись и как это должно повлиять на его бизнес - изменения не нужны. 2. Что надо сделать? Есть начальное состояние системы, оно не удовлетворяет текущему состоянию бизнеса - ЧТО надо сделать в этой системе (или системах), чтобы прийти в конечное состояние - соответствие с бизнесом. И это глубже чем просто давайте вот тут в Заказ клиента добавим проверку что менеджер заполнил договор и адрес доставки. Это именно системное понимание изменений. Здесь я полностью согласен с Александром, что лучше обойтись типовым функционалом, по возможности. 3. Как это сделать? Если изменений конфигурации не избежать, то они должны быть сделаны оптимальным способом, схема "тяп-ляп и в продакшен" не подходит, как бы бизнес не давил на сроки. 4. Когда? Изменения должны быть вовремя, не раньше (потому что тогда они не будут востребованы и станут лишь обузой) и не позже (потому что тогда в них уже и смысла особо нет, бизнес УЖЕ обогнал автоматизацию). На вопрос ЗАЧЕМ- отвечает Бизнес-архитектор (хотя зачастую это не архитекторы а бизнес-топы, поэтому ответ на этот вопрос зачастую являет собой невнятную кашу, отсюда же потом и результаты автоматизации, но мы же тут пока просто размышляем...). ЧТО - функциональный архитектор. Это человек который отвечает не за Функцию, а за Функциональность. Чтобы сделанные изменения работали так как ожидалось, решали ту задачу для которой сделаны и при этом не ломали общую функциональность. КАК - технический архитектор. Регистры, документы, интеграции, инженерные решения и вот это вот все. Чтобы, внезапно(!), сделанные изменения работали так как ожидалось, решали ту задачу для которой сделаны и при этом не ломали общую функциональность. КОГДА - это менеджер проектов, который собирает воедино бизнес и ИТ с целью достижения конкретного конечного результата. Функциональный архитектор и Технический архитектор - это должен быть либо один человек (если ума палата), либо два проработавших в тестой спайке спеца понимающих друг друга с полуслова - иначе результата толком не будет.

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

У меня только один вопрос - как внедрить erp (оперативный и рег. контуры) на производственном предприятии (100 пользователей) в "одну каску" (крайне лимитированным бюджетом) за полгода?😢

Рынок этот, в целом, хочет нанять 1 человека так, чтобы этот человек все эти вопросы закрыл. А как он называется…?ну как ты хочешь себя называть, так и называйся.

Александ, спасибо за этот подкаст! Беда творится в головах как собственников бизнеса, так и hr-ов - знаю по собственному опыту. "Прогрессивное западное бизнес-образование" дало свои плоды. Например, в PMBOK 7 руководитель проекта вообще не имеет никаких полномочий, но при этом отвечает!!! за успех проекта, добавим к этому метедологически заложенные конфликты ролей и функционала - получаем картину маслом(( Этакий брат Семируко- нога из Вашего подкаста. Сил Вам и Успеха!

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

Дробление функций и ввод очеродного градации типа sinor json dev - это на руку инфоцыганам разного толка в 1с - одну и ту же воду можно лить с 10-ти кранов вместо одного - больше денег

Держитесь, Александр, вам будет не просто - 99% вакансий шлак или вы для нее будете оверквалифед - если оставить в вакансии именно то чем занимаются люди этого уровня, без попыток запихать в вакуху "не хотите поработать у нас отделом". Четких должностных и функциональных обязанностей вам не назовет никто практически. "Мы за хххх рублей хотим делегировать вам нашу головную боль с 1с" - это все

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

Это базовая проблема 1с - изобретение своей терминологии, зачастую еще вносящую хаос в общепринятые ойтишные вещи

С подключением, Александр!) Сколько вам предстоит открытий чудных совершить на рынке труда.. А что если скажу, что работаю в ОЧЕНЬ крупном холдинге, каждую из его компаний знает любой человек в стране и наверное большинство еще и пользуется постоянно. Так вот, у нас есть архитектурный отдел 1С, в котором сидят ТОЛЬКО сисадмины и DBA (Эксперты 1С). И да, они занимаются только инфраструктурой и сложными вопросами оптимизации. А кто же тогда принимает конечное решение за согласование бизнес и программного слоя решения (базы 1С), при разработке новой подсистемы например? Ну как повезет, в каждом отделе по разному. Коллективно обычно)) Когда пришел был в шоке, сейчас тоже. Понял, что для меня ближе всего реализовать себя как архитектор решения, эта позиция максимально понятна всем участникам и ее легко объяснить, а значит избежать конфликтных ситуаций. Я главный по базе и все, последнее слово за мной, т.к. отвечаю за нее я, не важно как звучит, важно что не трачу время на объяснение своей роли. А насчет деления на ФА и ТА во многих франчах так принято, думаю из-за текучки, не хочется одному человеку доверять такую власть, он уйдет и все рухнет, а так рухнет только половина, которую можно временно подменить другими. А вообще, это вопрос культуры, в 1С это не развито в такой степени. Ваш опыт и размах несравнимо выше, так что тут все еще более абстрактно. Лучше наверное объяснять какие проблемы вы можете решить, чем подстраивать свой опыт под вакансию. ИМХО конечно)

На прошлой недели мониторил НН, по архитекторам. Посмеялся и закрыл)

Вторая крайность (синдром элиты) - это достаточно полезная крайность. Там всё очень не однозначно. Прикрепляю ресурс: kzbin.info/www/bejne/ZnmchZmIf9-SnLs&si=-NWym6za_1RlF-9m Рад буду услышать ваше мнение. Возможно я не прав. Там суть в действиях. Жаль я не знал про дырки в штанах раньше, пхахах Минус того, что начал программировать в 15 лет. Также считаю, что очень важна осознанность, потому что синдром самозванца на мой взгляд - это обычное явление, когда человек видит возможный рост, но он не признан социумом. Его переход даёт очень много, а если ты свободен от общественного угнетения, что пропагандирует фильм бойцовский клуб (купил машину не потому, что машина твоей мечты, а чтобы тебя не считали лохом), то это тебя не раздражает особо, но время от времени светится. Меня больше убили переработки и неверные действия.

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

Еще ксиати, есть такие причины вырасти из програмииста: Еще 5 лет и профессия программист вымрет, весь код будут писать нейросети

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

Так называемый программист 1с с большооооой долей вероятности не сможет разрабатывать на другом языке без долгой фундаментальной переподготовки...

Спасибо!

Полностью подтверждаю. Когда начали проходить программирование, то сначала изучали алгоритмы (даже рисовали блок-схемы), типы данных, логику (условия, циклы) и только потом сами языки.

Ура! Звук отличный, громкий!

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

Ну на счет 2 вакансии (где про UseCase и BPMN) слегка перегнули, UseCase можно очень хорошо описывать, иллюстрируя их за счет BPMN.

Автор просто подумал, чем он хуже Нолана.

Александ, спасибо за опыт, которым делитесь и практику визуализации хайку)

Я безмерно Вам благодарен. Это лучшее, что есть по архитектуре!!!! Спасибо Вам огромнейшее!!!!

Вообще не понятно. Хорошо что вы знаете

"В коде не должно быть классов, которых нет в диаграмме" - Если по каким-то причинам мне понадобилось в своем рест-апи принять такое решение: Под каждый новый метод в этом сервисе создается новый класс, наследуемый от общего интерфейса. Учитывая, что эти классы не предполагают дальнейшего переиспользования кода, насколько большую ошибку я (на самом деле не я) совершил? И нужно ли при этом каждый класс вносить в диаграмму? Сразу скажу, что сейчас вообще никакой диаграммы классов нет, собственно как и человека, который был бы за это ответственным.

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

Очень полезное видео. Спасибо. Работаю аналитиком с 2017 года. Обязательно после работы ходила расслабляться на природу, практиковала созерцание, медитации. Последние 2 года был очень сложный проект. Пренебрегла практиками и свалилась в кризис. 3 месяца выходила из кризиса, 2 месяца восстанавливалась. Не шутки! Никогда бы не подумала, что аналитика повернется ко мне такой стороной.

Благодарю за видео. Возникает очень интересный момент. Заказчики/пользователи и прочие могут делегировать ит-директору обязанности и ответвтенности, а право требования оставить за собой. Выразить это можно одной фразой: "Ты сделай, а мы посмотрим и выкатим требования". Может быть есть алгоритм становления этого процесса?

Постоянно развиваться, это минус?

Ждем обещанного видео про мастера-программиста

Добрый день! Подскажите, пожалуйста, можно ли вырасти в архитектора решений из системного аналитика, не имея опыт в непосредственной разработке (написании кода)?

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

О да! Теперь звук на уровне! Благодарю!

Здравствуйте, Александр. Не могли бы Вы собрать у себя на канале плейлисты по тематикам? Если Вам не сложно, конечно же.

Спасибо за видео. Крайне познавательно. На основе примера из вашего видео. Поступает металл. Приходуют его в систему через несколько дней, но "задним" числом. Соответственно, некоторые процессы, связанные с планированием, рушатся. Возникает ситуация - "сломалась 1с, звоните программисту" (утрирую) 🙂 Подскажите, пожалуйста, в чьей зоне ответственности находится формализация (описание) бизнес процессов? Если в зоне ответственности ИТ, то как Ит может воздействовать на своевременность, полноту и достоверность данных?

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

Александр, доброго времени суток. Давно назрел к вам вопрос. Какие знания, навыки, умения нужны чтобы стать бизнес-архитектором, а в перспективе корпоративным архитектором. Буду признателен, если поделитесь не только перечислением, но и напишите какие-то источники/книги. Заранее благодарю, Николай.

Звук очень тихий. Хорошо бы поднять громкость раза в два - три.