Pull to refresh
45
0
Денис Бесков @beskov

Руководитель онлайн-школы Systems.Education, CPRE

Send message

традиционная инженерия идет по граблям инженерии программной, не пытаясь изучить, почему провалились Case-средства и model driven architecture в ИТ

как дипломированный инженер САПР, начавший карьеру в ИТ именно с разработки ETL-процедур, скажу, что в статье описан бред сивой кобылы, которая не понимает разницу между инженерной моделью объекта проектирования, моделью операционного учёта бизнеса и аналитической моделью бизнес-показателей

Непонятно, где тут вообще портфельное управление

Так Марина Head of Systems Analysis или руководитель направления системной аналитики?

Было бы круто указать в заголовке, что речь именно про продуктовых аналитиков, не про аналитиков бизнес-процессов, не про аналитиков требований, не про интеграционных аналитиков

так а причём тут датасеты?

вы типа исследователь, но не разобрались нифига, что есть как минимум 2 категории БА:

1. те, кто занимаются преимущественно качественными исследованиями, см. в википедии статью Business Analysis

2. те, кто занимается преимущественно количественными исследованиями, см. в википедии статью Business Analytics

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

Это отдельная большая часть работы, которую сложно продать заказчику, поэтому можно использовать более легковесные техники, чем формальное моделирование процессов, например, Event Storming

я продуктовый исследователь

очередная поделка от выпускников «gender studies»

бизнес-аналитикам процессов не очень нужен Питон, скорее BPMS + RPA + Archimate

какая трешанина

начали с того, что БА занимается процессами и требованиями, а потом в уровнях компетенций сразу вылез какой-то kaggle

практикум продолжает пукать в воду

субъективное тоже можно замерить. и меня удивляет, как технари обычно намекают, что субъективное — что-то плохое:) оценка качества сервиса всегда субъективна, и это хорошо. экспертиза конкретных экспертов тоже субъективна, как тут. благодаря их совместной работе получаются интересные и ценные картины мира, более сильные, чем просто статистика.

например, если просто верить статистике рынка вакансий, никому на фиг не нужно концептуальное проектирование систем (3 уровень в профстандарте) и экономически и технически обоснованный выбор вариантов решений. надо просто делать то, что первым приходит в голову кому-то.

а мы как эксперты знаем, что нужны и концептуальное проектирование и рациональный выбор вариантов решений

лучшее не становится автоматически популярным, тк для него нужны отдельные когнитивные и организационные ресурсы

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

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

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

Так возник глубокий интерес к разработке качественных ТЗ и требованиям, с точки зрения группировки пакета работ его традиционно называли «системный аналитик».

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

Но нужно принимать много разных проектных решений по внешнему и внутреннему поведению системы:

а) проектировать взаимодействие человек-машина на уровне сценариев: разработчики обычно это делают плохо, тк их этому не учили

б) проектировать взаимодействие машина-машина: тут у разработчиков сильно лучше, но оказалось экономически выгоднее заказывать эту работу по технической контрактации выделенному специалисту

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

Далее выяснилось, что архитекторы настаивают, что командам нужны не только структуры данных, но и доменные модели. Бизнес-аналитики доменные модели делают не очень, СА в этом сильнее натренированы.

Сейчас ещё пытаются отдать СА не только проектирование взаимодействия, функционального состава, интеграций, но ещё и структур БД и архитектуры. Последнее имхо спорно без кругозора, но этот кругозор скоро научатся давать благодаря движению system design и прочим, а у программиста всё равно этот кругозор не сильно шире, тк он обычно проектирует в 2-х режимах-крайностях: 1) сделаем вот так, потому что так работало всегда в предыдущих проектах (это если времени мало); 2) сделаем на новой технологии, потому что она новая и интересная (если времени много). Ни то ни другое, очевидно, не является рациональным архитектурным подходом.

Это профессия, причём:

а) древняя, для примера посмотрите тезисы конференции 1976-года (48 лет назад): https://dl.acm.org/doi/proceedings/10.1145/800282

б) популярная, 500 тыс занятых в США по данным их Бюро трудовой статистики: https://www.bls.gov/ooh/computer-and-information-technology/computer-systems-analysts.htm

в) растущая: прогноз роста спроса по ссылке выше 10% на 10 лет.

я основной автор первой версии стандарта и целиком за сдвиг в проектирование

вплоть до того, что я профессию предагал переименовать)

но министерство такого хода конём не поймёт

профстандарт должен фиксировать лучшие практики, а не популярные

иначе можно дойти до варианта, что СА — это такая птица-ит-секретарь

Программа института не основана на деятельности министерства, тк минтруда запросило у минкомсвязи, какие профстандарты заказывать. Минкомсвязи назвало в том числе системного аналитика.

А дальше минтруда заказало через открытый конкурс разработку стандарта у любых желающих. И при первичной разработке стандарта конкурс выиграла организация из индустрии — IBS, которая тесно работает с отраслевой ассоциацией АПКИТ.

А в составе рабочей группы стандарта были сплошь действующие практики.

Вузы делают учебные программы на базе ФГОС, а не профстандартов. При этом вузы должны как-то учитывать профстандарты, но характер этой обязанности не определён, так что прямой связи нет никакой.

теперь должны ориентироваться программы обучения

а что изменилось ТЕПЕРЬ? профстандарт существует 10 лет, в прошлом году просто обновлён

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


так посмотрите, текст стандарта доступен как в справочно-правовых системах по ссылками в статье выше, так и на отдельном специальном сайте профстандартов минтруда

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

А зачем их так много? Нужны выборочные рекомендации, какой для чего

Information

Rating
3,517-th
Location
Москва, Москва и Московская обл., Россия
Registered
Activity

Specialization

Chief Executive Officer (CEO)
Middle
People management
Business development
Monitoring and market analysis
Product management
Strategic planning
Company management
Organization of business processes
Optimization of business processes
Automation of processes
Customer support