Если верить статистике, то вероятно они откроются раньше

чОрт)))

если ты доживешь до этого момента))))

я всё присматриваюсь к Harvard Business School. Получать у нас MBA два года (он сам по отзывам отстал на 10) то может оказаться что на момент завершения твои знания несколько устареют, скажем так.

Так я про то же)

r/#maybemaybemaybe

Все сильно зависит от продукта и навыков специалиста, в моем случае был аналитик + разработчик

Зависит от многого. Но суть в том, что проекты очень разные и часто аналитик на первых парах не нужен. Иногда нужен. Надо знать когда он там нужен.

Или нет

Ты как Вейдер из робоцыпа: "Реактор надо ставить везде, где есть возможность!"
https://vk.com/video185711297_163728875

Люди, а кто то может посоветовать книжку по архитектуре/рефакторингу но такую чтобы для системного аналитика?)

Какая задача и какие технологии?

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

"Чистая архитектура" с 104 страницы Роберт Мартин.

Часть конспекта по книге. Надо бы его дописать...

Вообще аналитик может вмешиваться и давать советы в разработку
Либо если он хорошо знаком с базой данных, её устройством, правилами нормализации и так далее (виды БД, запросы SQL, развёртывание, администрирование, НФТ).
Либо если он умеет в программирование, проектировал API, знает паттерны проектирования, понимает НФТ при работе разных алгоритмов (алгоритмы, API, преобразование данных, парсинг, синтаксис конкретного языка (типы данных, ограничения), понимание принципов использования библиотек и фреймворков, принципы проектирования, вроде SOLID).
Либо если он разбирается в архитектуре на уровне компонентов, их взаимодействия, правил доступа, последовательности обращений, плюсов и минусов тех или иных архитектурных структур, технологий передачи данных (монолит, м-сервисы, сервис-ориентированная архитектура, очереди, кафка, JSON, SOAP, прочее прочее).

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

Лучше и проще всего начать с уровня баз данных. Изучить SQK, разобраться какие другие бд бывают - вроде файловых, эластиков всяких, нереляционных. Полистать доку по основным представителям, а ещё лучше выписать каждый + по 2-3 статьи по каждому почитать на хабре. Почитать про альтернативные варианты хранения данных - ключ-значение, кеш и прочее.

А дальше идти либо в архитектуру, беря код как чёрный/серый ящик, либо в код, до уровня понимания что там происходит в целом.

Можно посмотреть последний analyst days, там много интересного было рассказано. Или archdays.

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

Вот интересные статьи, которые на первый взгляд дают понимание рефакторинга доступного для аналитика
https://habr.com/ru/post/576326/
https://habr.com/ru/company/infopulse/blog/316236/
https://habr.com/ru/company/yoomoney/blog/321824/
https://habr.com/ru/post/258629/

Можно поискать конфы на ютубе.
Может кто-то ещё статьи подкинет.

К слову скажу, что аналитик очень и очень поздно начинает понимать в рефакторинг кода, т.к. чтобы этим заниматься, надо очень хорошо понимать, как работают паттерны в рамках того или иного языка.
Так что код лучше оставлять за программистами, а для себя иметь ТОЧКИ КОНТРОЛЯ.

Это:
1. API в сервис
2. Запросы в БД, структура БД
3. Запросы в другие сервисы
4. НФТ (скорость выполнения запросов, частота ошибок, прочее). Можно обложиться метриками в Кибане/Графане и втыкать на них.
5. Происходящее на UI

Короче код, это как анекдоте:

"Мужик приезжает на автосервис и говорит:  
— Можно что—то сделать с моим автомобилем?  
Автослесарь отвечает:  
— Если снять передний и задний бампер, между ними можно поставить новую машину"

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

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