Pull to refresh

Comments 25

Привет.
Мне интересно, я тут хожу по собесам на аналитика (вообще любого) в Европе, я бы почитал)

Сегодня как раз собеседовал россиянина из европы и он рассказывал, что в европе требования к аналитикам немного другие, на разные направления поделены, так что в нашем понимании системного аналитика может отличаться от "европейского" кандидата))
Хотя у нас так же немного все объединилось, системный аналитик часто включает в себя и бизнес аналитика и тестировщика, и зачастую еще и архитектора

Могу ошибаться, но ~30 человек для проведения вебинара это очень мало. Если у вас будет реальных 300 человек то 5-10 вполне могут подключиться. При этом есть такой "нюанс" что если проводить днём то люди не могут из-за работы, а вечером не могут поскольку весь день на работе были и теперь время домашних дел.

1,5-2 часа это нереально от слова "совсем", 5-10 минут это реально время на которое можно удержать аудиторию если они не преданные фанаты, не более. Больше у людей просто времени нет, даже если идея курса им интересна.

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

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

Я очень много сам беру курсов и сотрудников посылаю, лучшая схема на мой взгляда у Coursera. Называете свои уроки "неделями", видео в 2 часа разбиваете на логические куски 15 мин максимум. В конце урока-недели - тест. Всё это в своем ритме (self-paced), потому что 1.5-2ч за раз - только в рабочее время за счет работодателя.

Интересная мысль, попробую разбить материал еще на кусочки, спасибо!

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

Много разночтений по этому вопросу. Например, у вас:

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

и

которые хорошо знают SQL

Непонятно зачем системному аналитику навыки анализа данных в Power Query и хорошее знание SQL.

Если я могу загрузить маркетплейс в Excel, что-то там отфильтровать, по API тут же в Excel проверить факт регистрации брендов, тут же по API загрузить цены с Китая и проверить по ним маржу в нише - это тоже анализ данных, но какое отношение он имеет к системному анализу?

SQL зачем вообще, если тут же требуется Excel, который сам умеет брать данные из баз? А в NoSQL данные не встречаются, его почему не спрашиваете? и т.д.

Задаюсь вопросом, актуально ли обучение на системного аналитика?

Очень даже.

Быть может люди не знают о таком направлении и нужно его популизировать или неблагодарное это дело и не стоит заморачиваться?

Как сказал великий, популяризировать нужно только тогда, когда невтерпеж.

Так же в посте упомянул про то, как я провожу собеседование системных аналитиков, какими навыками нужно обладать, чтобы интервьюер обратил внимание на кандидата, даже если у него недостаточно опыта. Пишите в комментариях, интересно ли было бы узнать?

Интересно.

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

Сильно вводная часть, поэтому интерес околонулевой.

Интересно узнать особенности процессов в отраслях. Например, чем отличается сбор требований в телекоме от финтеха или 2С от 2B.

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

Еще пример, как на практике оценивают работу системного аналитика и как это согласуется с реальным качеством работы. Или: когда 100500 диаграмм реально нужны, а когда это не имеет смысла, но сделать надо для галочки.

курс по системному анализу для новичков

Где?

Есть программа курса? Карта навыков? (Само)Квалификация подходящих лидов? Социальные доказательства?

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

Есть лендос с этим офером? На какого рода работу светит попасть после такого экспресс-курса?

 Создал группу в ВК, настроил худо-бедно рекламу

ВК - основной рассадник будущих системных аналитиков? Почему не ОК?

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

Все таки цель - вебинар или обучение? Или системному анализу только в форме вебинара можно обучать?

Одного хотите научить или один миллион? Или экспресс-курс надо продать?

К сожалению ссылку на группу попросили удалить модераторы. Если интересно, то группа в ВК называется kolbunovlab

Непонятно зачем системному аналитику навыки анализа данных

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

Интересно узнать особенности процессов в отраслях. Например, чем отличается сбор требований в телекоме от финтеха или 2С от 2B.

Преимущественно работал в телекоме, но так или иначе и в B2B тоже приходилось участвовать.

Отвечу так, определенная отрасль, требует даже не то чтобы специфики, а более внимательнее обращение внимание на определенные аспекты.

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

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

Такие моменты возникают, чаще конечно либо от заказчиков либо от смежного команды, которая для вас должна что то сделать, что вы смогли реализовать процесс

Что с этим делать? прокачивать навык коммуникации и убеждение))

Еще пример, как на практике оценивают работу системного аналитика и как это согласуется с реальным качеством работы. Или: когда 100500 диаграмм реально нужны, а когда это не имеет смысла, но сделать надо для галочки.

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

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

курс по системному анализу для новичков

"Где?"

Попросили удалить ссылку. Если интересно, то группа в ВК называется kolbunovlab

Есть лендос с этим офером? На какого рода работу светит попасть после такого экспресс-курса?

Пока только группа в ВК. Я хочу дать самые базовые знания для человека, а там уж куда его судьба заведет. Однозначно если прошел курс, то стоит на вакансии сис аналитика откликаться.

Все таки цель - вебинар или обучение? Или системному анализу только в форме вебинара можно обучать?

Вебинар, это как бесплатный стрим, где делюсь, кто такие аналитики и заинтересовываю (надеюсь) людей, чтобы они заинтересовались профессией и записались на курс.

Одного хотите научить или один миллион? Или экспресс-курс надо продать?

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

 

Понравился момент в комментарии про различия сбора требований в разных сферах , часто про это думаю ( бизнес - аналитик)

Мне эта тема очень близка. Я сам работал разработчиком, потом аналитиком, сейчас архитектором, техлидом (по факту одновременно и разработчиком, и аналитиком). На мой взгляд аналитические навыки важны для любого ИТшника. Лично у меня такой топ навыков:

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

2) Понимание процесса разработки в целом. Какая бы специализация у человека ни была, очень хорошо если он понимает через какие этапы проходит задача:

а) бизнес-анализ - когда задача максимально размыта, непонятно что делать и нужно преимущество собирать информацию, заниматься НИР

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

в) разработка

г) тестирование

д) демонстрация заказчику, сдача в эксплуатацию

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

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

3) Затем идёт основной навык специалиста.

Для разработчиков - это безусловно умение описывать и реализовывать алгоритмы. Конечно далеко не на всех проектах требуются сложные алгоритмы. Но, блин, даже в самых простых задачах условно "по перекладыванию JSONов" я часто вижу какой-нибудь поиск по массиву с квадратичной сложностью, какой-то безумный код, в котором просто невозможно ничего понять. Хотя бы базовое знание структур данных, алгоритмов нужно. Но заметьте, что я поставил это на третье место!

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

Для тестировщиков и РП мне лень писать. Иначе этот комментарий рискует превратиться в монографию. Хотя, блин, я не могу удержаться, знания переполняют меня, я на столько преисполнился понимаем этого мира, что просто не могу не поделиться своей мудростью (и наверное во многом болью) с человечеством (по крайней мере с той его частью, которая читает хабр).

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

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

Да, на самом деле, все эти навыки важны для всех ИТшников, просто каждый специализируется в первую очередь на своём.

4) Общие технические знания. Мне лень подробно на этом останавливаться. Но для всех не лишне иметь какое-то представление о базах данных и нормализации данных, о форматах данных (чтобы отличать XML от JSON), о протоколах передачи данных, многослойной архитектуре, API и т.д.

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

6) Знание конкретных языков и фреймвоков. С одной стороны, конечно если ты раньше использовал C# и Entiy Framework, а на проекте требуется Java и Hibernate с его безумными только запутывающими исключениями, то не получится сразу начать быстро работать, много времени будет уходить на копание во всём этом бессмысленном бреде. Но с другой стороны, я вообще не понимаю зачем на собеседованиях делать основной и единственный акцент на знании какой-то специфической хрени. Типа для JavaScript разработчика написать лапшу из промисов, setTimeout(), queueMicrotask() и спрашивать что будет. Да, инсульт ж...пы будет у любого нормального разработчика, если он увидит такое в коде!

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

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

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

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

Привет! Было бы интересно узнать про скоуп вопросов по хардам и софтам, именно с разделением по грейду. И как их грамотно выявлять у кандидата в процессе интервью, а не спрашивать тех. вопросы тупо «в лоб».

Привет!
У меня так складывался опыт, чтоб прям конкретно искали человека с определенным набором скилов как хардовых так и софтовых, нет. Так или иначе у кандидата будут пробелы, скорее из за специфики продукта, и при собеседовании в целом оценивается кандидат. Не только по скилам, но и как он анализирует и рассуждает. Ну а зачастую, системных аналитиков в целом не так уж много на рынке, и выбираешь из тех кандидатов, которые более менее подходят и дальше уже их курируешь или направляешь.

При составлении статьи про собеседование, подумаю над твоим предложением, разбить на блоки по грейду.

Почему выбрана именно платформа ВК для размещения курсов? А если попробовать что-то другое, с учётом массового использования? Например, создать канал в телеграмм. И 2 часа для курсов это да, многовато. Хотя бы минут 30 максимум.

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

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

По заливанию трафика лучше обратиться к доступным ресурсам в интернете, я больше потребитель контента )). Что хотелось бы видеть:

  • разбор резюме;

  • тестовое собеседование, что ожидаете от кандидата;

  • решение тестовой задачи: от постановки до реализации;

  • используемые инструменты в работе;

  • архив своих вэбинаров )

Ну я напишу как есть, вы ж обратную связь ищете, а не мишени для "минусомета" :)

Вот я прочитал предисловие, идти к такому преподавателю на курс ... ну такое. Тут бы порекомендовать скорее :)

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

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

И это точно вас не красит - кому нужно учиться идти по пути проблем.

Если же вы хотели написать что-то другое - ну блин ...

«Системный аналитик – если кратко, это сотрудник, который выясняет, что хочет заказчик, анализирует задачу, и говорит разработчику, что нужно разработать»

Да вы бы детальнее расписали :) А то по такому определению можно всех описать. Разработчки - тот кто пишет код. Тестировщик - тот, кто тестирует код.

А что, бизнес аналитик не выясняет потребности заказчика? Так, птица говорун на большой ставке, себя показать, на других посмотреть? Или он не пишет "сторьки"? Или он не анализирует?

Ну честно, это либо рассчитано на полных ждунов, но в роли системного аналитика получить полного ждуна - это конечно эпический кейс. Круче наверное только архитектор - полный джун.

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

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

А в системном анализе. Ну вам требвоания дали. Они однозначны, либо добивайте заказчика до однозначности. Дальше то что. Если вы "сидите" на платформе, то у вас решений обычно одно или два. Все. Если нет - ну максимум: мы делает по написанному, либо параметризируем. Ну что вы еще поменять то можете?

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

Очередное "кровь из глаз" предложение. Как вы доку то пишите? Начинаете с того, что требуется "немного". Потом, в одном предложении идете на описание недостатков, а к конце абзаца "все плохо".

Если кратко курс создал в виде презентации, разбил на блоки, с домашним заданием, которое закрепляет пройденный материал. Очень емко и кратко, но этот тот минимум, с которым можно уже проходить собеседования на младшего аналитика. Всего 6 уроков, по 1,5 – 2 часа

Джуны плодят джунов методом "обучения". Новые метод в биологии, ничего не скажешь. Было делением, почкованием, однополые, разнополые (я уже не сильно помню), но вот такого варианта не было точно.

Мир стоял перед пропастью и шагнул вперед, не иначе

Задаюсь вопросом, актуально ли обучение на системного аналитика? Быть может люди не знают о таком направлении и нужно его популизировать или неблагодарное это дело и не стоит заморачиваться?

Не стоит

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

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

Ответ был в следующем предложении, но с точки зрения построения предложения, да, звучит немного коряво =)

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

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

Ну как можно учить "системного" аналитика? Я даже не знаю, руки опускаются

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

  • снять требования

  • поучаствовать в согласовании их с другими стейкхолдерами

  • помочь в оптимизации и генерации идей

  • передать команде и далее отслеживать

  • ...

Важно - это БИЗНЕС аналитик. Есть более продвинутые, и совсем (которые могут уже работать на уровне бизнес-стратегии компании). Суть в том, что они

  • владеют доменом (либо так быстро участся, что всем кажется, что владеют)

  • отвечают за конвертацию "функционального хочу" заказчика в нечто более формально

Можно ли из учить - да! Они ж как-то появляются

--------------

Теперь, что такое "системный" аналитик. Во-первых, очевидно, он не бизнес аналитик, иначе зачем его было бы изобретать. Обычно, это человек, который "сидит" на системе, или платформе. И его ГЛАВНАЯ фишка - знание этой системы и платформы. И он может, увидев требования, разложить по системе/платформе как это сделать. Понятно, он тоже "птица говорун", но в меньшей степени. И это ключевое отличие.

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

------------

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

Теперь в итоге. Как и чему вы хотите учить системного аналитика? Как обычного аналитика? Так это и будет обычный аналитик :) Как системного? А о какой платформе идет речь?

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

А на практике, что чаще всего бывает, что в команде есть только ПО, менеджер, сис аналитик и разработчик. Бывает даже что и аналитика нет и все работу делает разработчик ("да..., это жестко")

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

И последнее, ваше не пренебрежительное к должности сис аналитика

Теперь, что такое "системный" аналитик. ... Обычно, это человек, который "сидит" на системе, или платформе.

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

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

Ну так вы попробуйте поработать в "полноценной" команде :) Просто ... ну блин, если у вас нет такого опыта, откуда тогда у вас может быть четкое понимание о ролях и из разделении? Это не наезд, но просто логика.

Совмещение ролей - да, конечно бывает везде. Даже в больших организациях. Но есть такой момент:

Пока вы не поработаете на "выделенной" позиции, у вас не выйдет полнойценно почуствовать суть роли.

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

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

Ладно, вам виднее :)

Мне кажется, что автор не очень представляет себе область в которой собирается "наставничать".

Системный анализ -- научная дисциплина и это не то чем занимается "системный аналитик" автора, с другой стороны, определение автора не совпадает с профессиональным стандартом. ("Системный аналитик").

Я уже не говорю про то, чем "системные аналитики" занимаются на практике.

Мне, опять же, кажется, что лучше определиться с терминами заранее.

Работаю аналитиком 17 лет, тоже в телекоме. Собеседовал и студентов (часть из них уже ведущие аналитики) и сетевиков которые в хотят аналитики ( тоже опыт скорее положительный).

Накидаю тезисов

1) Сообщество аналитиков большое. Топовые тг каналы - это 5000 человек, поиск работы 22к подписчиков. Есть профстандарты даже. AnalystDays, Flow и другие конференции

2) Материалов по обучению много, нет, прям ОЧЕНЬ много. Есть хорошие, есть не очень.Курсов по обучению тоже порядочно, порядочно тг каналов, в том числе по прохождению собеседований для аналитиков

3) Хайпом "войти в айти" накрыло и эту профессию. И по умолчанию , любые новые курсы это "инфоцыганщина", sad but true. В сообществах людей пытающихся монетизировать обучение как минимум челленджат, а как правило буллят. Но если материал достойный, вебинар бесплатный, то почему нет.

4) В описанной истории я вижу логические несоответствия.

4.1)Какую проблему всё таки автор адресует? Как он формулирует задачу? Почему нужно что то новое обучабщее, в чём научная новизна?

4.1.1) На собеседованиях люди не соответствуют ожиданиям?

А может дело в том, что выгребается самое дно с минимальной зп и очевидно , что и скиллы соответствующие? Тут либо поднять планку, либо это не проблема. Если нужен бесплатный совет - Очень хорошие аналитики получаются из студентов топовых вузов (если сможете их удержать). За них идёт борьба с Яндексом, Сбером и т.п. Как вариант посмотреть на лучших из худших. Тут в защиту автора могу добавить, что проблемы скиллов есть и у опытных тоже.

4.1.2) Помочь людям понять, что нужно системным аналитикам. Кажется это просто в молоко, скинь "аналитик на галере" или ещё аналогичные каналы

4.1.3) Монетизировать свои скиллы вне работы (в целевом виде, начиная с вебинара, группы, секты и т.п.) Достойная цель, удачи, первый блин комом - возможно, потому что решение было не той проблемы. А можно просто залить на ютуб и сделать статью.

4.2) Какую бы проблему автор не адресовал, кажется вышел "фейл". А если бы была задача начинать онбординг с подобного вебинара, то вышел бы "вин".

С одной стороны "едрить сударь Вы простофиля" .

С другой стороны это очень отрезвляет, видимо где то что то не так, логическая цепочка не складывается.

На Может не та ЦА, может и не надо перенадувать интернет обучающими материалами, но логическую цепочку от потребности до задачи решения надо выстроить и зачелленжить её на все нестыковки. Пока она не сходится.

5) Под лежачий камень вода не течёт. Таков путь. Удачи.

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

Sign up to leave a comment.

Articles