Печально, конечно(( Overqualificated - такой "диагноз" стал популярен для профессионалов. В западной парадигме люди с этим "диагнозом" открывают свой консалтинговый бизнес. В наших реалиях - рулят инфоцыгане ( читай - за хорошие деньги я готов отрабатывать любую психиатрию клиента)... Удачи и Успеха, Александр!
Бизнес не хочет иметь над собой чужую власть и ограничения. Его дело прибегать с квадратными глазами "мне тут буклетик сунули т что от ерп все будет зашибись". А ваше - рисовать картинки решения, как ничего не меняя и с 0 затрат придти к процветанию. Все они понимают, но отдавать власть кому-то постороннему, да еще душниле который копает в суть вещей и показателей - это невозможно
Вся проблема в том, что покупатель (работодателей) не может объяснить что ему нужно (нужно всё и сразу), а продавец (слискатель) удовлетворить неопределенные потребности. Так и живём)
Вузовская база. При разработке любой ИС изначально рассматривают и разрабатывают 5 слоёв архитектуры. Бизнес, ит, данных, приложения, аппаратный уровень.
Возможно, что "отдельные люди" существуют только в воспаленном воображении начальства. Не видел ни разу, чтобы одмины по доброй воле пытались помочь 1с - смотрит на исключение винды и не моргнув глазом: это 1с, все вопросы тудой. Чистого dba тоде привлечь особо нечем - у любого от строения базы 1с конвульсии начинаются, чем ое помочь может - а погружаться в дивный мир 1с это для него терять квалификацию по сути
Александр, спасибо за видео. Хотел бы увидеть продолжение вашего исследования по поиску работы. Появился вопрос. Как вы считаете, архитектор по какому либо контуру должен владеть одним программным продуктом или он должен знать линейку продуктов по своей области? Например, УТ, КА, УПП, ЕРП или БП, ЕРП, КА, УПП или ЗУП, БП, ЕРП?
В середине видео Вы упомянули, что изменилось Ваше отношение к ТОГАФ, можете кратко рассказать в чем, какие аспекты подхода стоит пересмотреть? Можно без супер-детализации, просто хочется понимать о чем речь
Одна из причин, которая может подтолкнуть к желанию перейти из программистов в руководители, это страх снижения ментальных способностей с возрастом. Обязанности руководителя менее подвержены изменениям - да, появляются некие новые механизмы управления проектами, аджайл, скрам и т.п., но это происходит значительно реже, чем, допустим, выход очередной версии 1С. Таким образом, руководитель может отточить свое мастерство и, эксплуатируя накопленный опыт, продолжать и в солидном возрасте повторять "заученные трюки", несмотря на то, что способности изучать что-то новое уже сильно уменьшились. Для программиста же способность быстро изучать новое - это необходимая часть профессии. Да, мастер может выучить новый язык или фреймворк быстро. Но сможет ли он это сделать после 50? А после 60? А рискнет ли HR взять такого специалиста, понимая, что с возрастом мозг не становится быстрее? И не лучше ли взять менее опытного, но молодого, который за ночь выучит язык и завтра начнёт "перформить"? Не настаиваю на правильности этой версии, но лично меня подобные размышления привели к решению потихоньку разворачиваться в сторону руководящих позиций.
Здравствуйте, Александр. Ответьте, часто ли вы встречали в жизни людей с набором скиллов, описанных в видео. Если встречали, то как часто эти люди применяли все эти скиллы на практике?
Ну, справедливости ради "потупил в ютубчике" - это тоже может быть полезным действием, для восстановления психической и умственной энергии. Мы в этот момент не заставляем мозг думать, и даем ему худо-бедно переключиться, выработать быстрый дофамин. Да, погулять было бы эффективнее, но все таки, если такой возможности в данный момент нет - то why not?
1С лезит из кожи, чтобы быть как другие языки программирования, отсюда стремление к тем же градациям, типа сеньор и архитектор, хотя ни того ни другого в 1с нет.
На мой взгляд, любая программная автоматизация и 1С здесь не исключение - это процесс ответов на четыре вопроса: 1. Зачем? Отвечает на этот вопрос бизнес. Заказчик. Если он не понимает зачем ему изменения системы, почему без них нельзя обойтись и как это должно повлиять на его бизнес - изменения не нужны. 2. Что надо сделать? Есть начальное состояние системы, оно не удовлетворяет текущему состоянию бизнеса - ЧТО надо сделать в этой системе (или системах), чтобы прийти в конечное состояние - соответствие с бизнесом. И это глубже чем просто давайте вот тут в Заказ клиента добавим проверку что менеджер заполнил договор и адрес доставки. Это именно системное понимание изменений. Здесь я полностью согласен с Александром, что лучше обойтись типовым функционалом, по возможности. 3. Как это сделать? Если изменений конфигурации не избежать, то они должны быть сделаны оптимальным способом, схема "тяп-ляп и в продакшен" не подходит, как бы бизнес не давил на сроки. 4. Когда? Изменения должны быть вовремя, не раньше (потому что тогда они не будут востребованы и станут лишь обузой) и не позже (потому что тогда в них уже и смысла особо нет, бизнес УЖЕ обогнал автоматизацию). На вопрос ЗАЧЕМ- отвечает Бизнес-архитектор (хотя зачастую это не архитекторы а бизнес-топы, поэтому ответ на этот вопрос зачастую являет собой невнятную кашу, отсюда же потом и результаты автоматизации, но мы же тут пока просто размышляем...). ЧТО - функциональный архитектор. Это человек который отвечает не за Функцию, а за Функциональность. Чтобы сделанные изменения работали так как ожидалось, решали ту задачу для которой сделаны и при этом не ломали общую функциональность. КАК - технический архитектор. Регистры, документы, интеграции, инженерные решения и вот это вот все. Чтобы, внезапно(!), сделанные изменения работали так как ожидалось, решали ту задачу для которой сделаны и при этом не ломали общую функциональность. КОГДА - это менеджер проектов, который собирает воедино бизнес и ИТ с целью достижения конкретного конечного результата. Функциональный архитектор и Технический архитектор - это должен быть либо один человек (если ума палата), либо два проработавших в тестой спайке спеца понимающих друг друга с полуслова - иначе результата толком не будет.
@@moscowisolation9901 можно еще по кругу обмазаться специалистам , как архитектор qa, devops, архитектор железа и подобное, только в 90% будет пара заказчик(бизнес или аналитик) и исполнитель(обычный скромный программист). Если программист не может сказать ЧТО, КАК и КОГДА, он не программист 1С. Собственно в этом основное заявленное преемущество 1С, быстрая разработка. Может конечно в идеальном мире все эти "архитекторы" пригодились бы как нибудь, но зачем бизнесу держать 4 сотрудника, вместо одного, который прекрасно справляется.
Ну микросервисы вы слишком упростили) есть ряд случаев, когда они оправданы. Взять тот же пример Авито, там очень большая кодовая база, сотни, если не тысячи разрабов, и тут хочешь не хочешь, но на работу с одним монолитом всех пускать нельзя, они будут наступать друг другу на пятки(приходится разбивать их на команды, направления, и тут включается закон Конвея), нагрузки это приложение будет выдерживать скверно, масштабировать его отдельные кусочки невозможно, поднять еще одну копию монолита - это означает купить еще один инстанс очень дорогого железа. А микросервисы (не смотря на их сложность) - позволяют купить много дешевого железа и раскатать там сервисы в нужном количестве. Да, часть инфраструктуры теперь начинает работать на то, чтобы эти микросервисы обеспечивать. Но в некоторых случаях микросервисы - это жизненно необходимая для компании история.
У меня только один вопрос - как внедрить erp (оперативный и рег. контуры) на производственном предприятии (100 пользователей) в "одну каску" (крайне лимитированным бюджетом) за полгода?😢
Рынок этот, в целом, хочет нанять 1 человека так, чтобы этот человек все эти вопросы закрыл. А как он называется…?ну как ты хочешь себя называть, так и называйся.
Александ, спасибо за этот подкаст! Беда творится в головах как собственников бизнеса, так и hr-ов - знаю по собственному опыту. "Прогрессивное западное бизнес-образование" дало свои плоды. Например, в PMBOK 7 руководитель проекта вообще не имеет никаких полномочий, но при этом отвечает!!! за успех проекта, добавим к этому метедологически заложенные конфликты ролей и функционала - получаем картину маслом(( Этакий брат Семируко- нога из Вашего подкаста. Сил Вам и Успеха!
Порой складывается впечатление, что у потенциального работодателя отключается мозг, когда доходит дело до найма кого-то на работу. Это касается и оформления/описания вакансии и непосредственно, самого собеседования.
Люди принимающие решение о найме персонала такого уровня в ойтишечке не шарят как правило. Найм происходит по критениям понравился (вписался в картину мира нанимателя, а тут уже полно профессиональных суетологов - которые умеют смотреть со значением и повторять "когдасделаете") или рекомендации от доверенных людей
Дробление функций и ввод очеродного градации типа sinor json dev - это на руку инфоцыганам разного толка в 1с - одну и ту же воду можно лить с 10-ти кранов вместо одного - больше денег
Держитесь, Александр, вам будет не просто - 99% вакансий шлак или вы для нее будете оверквалифед - если оставить в вакансии именно то чем занимаются люди этого уровня, без попыток запихать в вакуху "не хотите поработать у нас отделом". Четких должностных и функциональных обязанностей вам не назовет никто практически. "Мы за хххх рублей хотим делегировать вам нашу головную боль с 1с" - это все
Зачастую в вакансиях hh архитектор - универсальный васян который должен заставить работать эту коробку с ерп, которую нам втулили ушлые фране под девизом "сама все делает". А там, вот это поворот, нужен целый взвод народу
С подключением, Александр!) Сколько вам предстоит открытий чудных совершить на рынке труда.. А что если скажу, что работаю в ОЧЕНЬ крупном холдинге, каждую из его компаний знает любой человек в стране и наверное большинство еще и пользуется постоянно. Так вот, у нас есть архитектурный отдел 1С, в котором сидят ТОЛЬКО сисадмины и DBA (Эксперты 1С). И да, они занимаются только инфраструктурой и сложными вопросами оптимизации. А кто же тогда принимает конечное решение за согласование бизнес и программного слоя решения (базы 1С), при разработке новой подсистемы например? Ну как повезет, в каждом отделе по разному. Коллективно обычно)) Когда пришел был в шоке, сейчас тоже. Понял, что для меня ближе всего реализовать себя как архитектор решения, эта позиция максимально понятна всем участникам и ее легко объяснить, а значит избежать конфликтных ситуаций. Я главный по базе и все, последнее слово за мной, т.к. отвечаю за нее я, не важно как звучит, важно что не трачу время на объяснение своей роли. А насчет деления на ФА и ТА во многих франчах так принято, думаю из-за текучки, не хочется одному человеку доверять такую власть, он уйдет и все рухнет, а так рухнет только половина, которую можно временно подменить другими. А вообще, это вопрос культуры, в 1С это не развито в такой степени. Ваш опыт и размах несравнимо выше, так что тут все еще более абстрактно. Лучше наверное объяснять какие проблемы вы можете решить, чем подстраивать свой опыт под вакансию. ИМХО конечно)
Вторая крайность (синдром элиты) - это достаточно полезная крайность. Там всё очень не однозначно. Прикрепляю ресурс: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-0H9TfRJz_fY.html&si=-NWym6za_1RlF-9m Рад буду услышать ваше мнение. Возможно я не прав. Там суть в действиях. Жаль я не знал про дырки в штанах раньше, пхахах Минус того, что начал программировать в 15 лет. Также считаю, что очень важна осознанность, потому что синдром самозванца на мой взгляд - это обычное явление, когда человек видит возможный рост, но он не признан социумом. Его переход даёт очень много, а если ты свободен от общественного угнетения, что пропагандирует фильм бойцовский клуб (купил машину не потому, что машина твоей мечты, а чтобы тебя не считали лохом), то это тебя не раздражает особо, но время от времени светится. Меня больше убили переработки и неверные действия.
Прошло 5 лет, переслушиваю и ничего не меняется. Больше всего убивает, что нет желания и воли со стороны этих руководителей. Все хотят сидеть в экселях...
В моем понимании agile очень хорошо может быть на этапе реализации того, что было запланировано и сложено в бэклог, вообще не противореча нормальному циклу архитектуры, о котором вы говорите. Пример: отработали с заказчиком все его хотелки, с аналитиками придумали юзкейсы, технический специалист написал некоторый высокоуровневый солюшен, удовлетворяющий бизнес-потребности, тимлид нарезал на него задачи, сложил в бэклог. И тут на сцену выходит Agile, где команда из бэклога берет приоритизированные таски и спокойно по ним работает. То есть одно другому не противоречит.
Мне вообще очень не нравится когда программист какого-то синтаксиса языка. Это практика курсов которые за 3-6 месяцев штампуют толпы людей которые учат именно синтаксис.
Сможет, в рамках такого же по уровню абстрагирования фреймворка. Проблема типового 1с-ника - он не понимает по сути что он делает. Он просто дергает фреймворк за доступные интерфейсы примитивными алгоритмическими скриптами. Как объект работает с которым он взаимодействует - хз. Плюс чаще всего - отсутствия знаний в ойтишечке за пределами 1с. И говорить с ним не о чем - он не понимает что ему говорят - он просто никогда не писал ни на чем дальше хелло волд
Полностью подтверждаю. Когда начали проходить программирование, то сначала изучали алгоритмы (даже рисовали блок-схемы), типы данных, логику (условия, циклы) и только потом сами языки.
Вы говорите все правильно, я досматриваю сейчас плейлист по корп. архитектуре, делаю некоторые зарисовки себе, чтобы это устаканилось в голове, и часто возникает мысль "Так вот как оно должно было работать". За это очень сильно Вас благодарю.
"В коде не должно быть классов, которых нет в диаграмме" - Если по каким-то причинам мне понадобилось в своем рест-апи принять такое решение: Под каждый новый метод в этом сервисе создается новый класс, наследуемый от общего интерфейса. Учитывая, что эти классы не предполагают дальнейшего переиспользования кода, насколько большую ошибку я (на самом деле не я) совершил? И нужно ли при этом каждый класс вносить в диаграмму? Сразу скажу, что сейчас вообще никакой диаграммы классов нет, собственно как и человека, который был бы за это ответственным.
О, а я думал, я такой ущерб, что не тяну бу, ну, кадры и прочая, зато с легкостью все остальное... Думал, что все остальное - не имеет ценности без глубокого не то что понимания, нет. Именно фундаментального знания тонкостей проводок, хотя общий принцип и даже помощь в решении закрытия периода или корректировки фин результата могу оказать, но постоянно встречаются вопросы типа - 25, 26, 44 счета, где приходиться поскрепеть мозгами.
Очень полезное видео. Спасибо. Работаю аналитиком с 2017 года. Обязательно после работы ходила расслабляться на природу, практиковала созерцание, медитации. Последние 2 года был очень сложный проект. Пренебрегла практиками и свалилась в кризис. 3 месяца выходила из кризиса, 2 месяца восстанавливалась. Не шутки! Никогда бы не подумала, что аналитика повернется ко мне такой стороной.
Добрый день. Умственная, физическая и психическая энергия( все три вида вместе - жизненная энергия ) могут закончится у любого человека. Разница между нами( человеческими существами ) в том какой у нас запас их, как быстро мы его тратим и с какой скоростью восстанавливаем .
Благодарю за видео. Возникает очень интересный момент. Заказчики/пользователи и прочие могут делегировать ит-директору обязанности и ответвтенности, а право требования оставить за собой. Выразить это можно одной фразой: "Ты сделай, а мы посмотрим и выкатим требования". Может быть есть алгоритм становления этого процесса?
