Описания задач им делал в UML, с текстовыми комментариями, после смотрели вместе и голосом обсуждали, тогда еще по Скайпу с показом экрана.

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

на сайте супер мега теста для аналитиков есть исключение
https://thumb.tildacdn.com/tild3662-3133-4635-b231-333461396436/-/resize/650x/-/format/webp/_34.png

https://stepik.org/course/1128?auth=login вот про что говорил

В бытность продажником использовал шаблоны под тз составленные совместно с исполнителями, тоже вещь полезная

Ты не на словах попробуй донести, а текстом и рисунками. (Перед этим ещё Цель доработки обязательно выясни и напиши) Это и будут твои первые требования на доработку. Дай их почитать разработчику, он тебе по ним кучу вопросов напишет и своих идей как улучшить твою идею, отработай их и покажи ещё раз. Это будет твоё первое портфолио с ним смело иди на собеседования. Ищи работу, как правильно тут написали за небольшие деньги. Тут практика важна. Не трать деньги на обучение. Наша профессия слишком размыта. Главное в ней уметь общаться с заказчиком и разработчиком и класть договоренности на бумагу в виде требований, чтобы они были понятны тебе самому, заказчику и разработчику. Остальное детали, они не так уж и важны, многие из них уникальны на каждом проекте, поэтому систематики по ним, а значит и курсов хороших нет. Собеседуйся, на собесах тебе порекомендует, что подучить, почитать или посмотреть нужно.

примеры что бизнес хотел и разработчики не поняли зачем

Интеграционный сервис, при обнаружении более одной записи с одинаковыми параметрами, создаёт третью, вместо одного дубля, получается три. Говоришь сервис нужно переделать. И начинается "soap, rest, api, такая архитектура, невозможно, дорого, жили же раньше" итп

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

+мне кажется что архитектуру можно было по проще для начала закласть
к примеру тем же row_number() брать первую запись

Хах чем-то напоминает ответы моего начальника на вопрос может стоит нанять нормального системного аналитика

А это чем-то напоминает ответ моего начальника, когда он говорит мне, сколько можно копаться и анализировать, пойди и заставь их 😪

Простите, а это надуманный пример, да?
Не совсем понимаю, причем тут rest или soap при создании дублей. Сервис нужно переделать или доработать? Как вы поставили задачу разработчикам, в какой форме? "Создает дубли, надо переделать?" Вы понимаете, почему создаются дубли на физическом уровне? И последнее: разве вы имеете право заставлять разработчиков?

Пример реальный. Сервис создаёт дубли, потому что когда он писался 5 лет назад, никто не проверил его алгоритмы  на граничных условиях, работу приняли, команда разбежалась. А в изменившихся условиях, он начал создавать проблемы, но нынешняя команда, не хочет отвечать за грехи предыдущей и в чем-то разбираться. Понятие "заставлять", сейчас очень расплывчатое в рамках плоской структуры и agile-подходов. Вроде могу, а вроде они мне и не подчиняются.  Как это организованно на физическом уровне, я плохо представляю. Поэтом - хочу всех обратить внимание, на мой первоначальный вопрос - где можно поучиться на СА, помимо самообразования(!).

Я все таки не понимаю, почему не собраться в троем - вы, начальник и итшник и не проговорить шаблон(чеклист) постановки задач? вы получите инструмент для работы, ИТшник меньше головной боли, начальник увидит, на чьей стороне проблема

Нет проблемы. Я просто хочу повысить свою компетентность

Так тут не проблема в работе СА в части предметной области. Тут проблема коммуникаций. Разработчики просто не хотят заниматься легаси. Вы можете изучить тему описания API, UML, SQL, BPMN и другие нужные для работы СА вещи. Но проблема с коммуникациями останется.
То есть, если нужно решить описанную задачу, то нужно решать в первую очередь эту проблему.

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

А, ок. Получается, что пример приведен неудачный.

#вакансия #москва #офис #BI #DWN #fulltime #аналитик

Вакансия: Аналитик BI
Компания: Код Подбора
Локация #россия #москва
З/п: 180-220k
Контакты: @natiateliya


Обязанности:
-Сбор требований с функциональных подразделений Заказчика;
-Работа с нормативными документами Заказчика;
-Анализ полноты реализации функциональных требований в прикладном программном обеспечении и постановка задачи на его доработку;
-Создание проектной документации на разрабатываемое прикладное ПО в соответствии с ГОСТ;
-Участие во внедрении разработанного ПО в эксплуатацию.


Требования:
-Опыт участия в проектах по разработке программного обеспечения для внешних Заказчиков;
-Опыт сбора и формализации требований Заказчика;
-Опыт подготовки проектной документации уровня спецификации требований;
-Знание методологий и нотаций моделирования предметной области (UML, ER, Archimate);
-Знание технологий BI \ DWH. Предпочтительно опыт работы с Tableau;
-Опыт работы с офисными приложениями (Excel, в том числе работа с Pivot, Word, в том числе использование стилей, Visio, PowerPoint).


Условия:
-Трудоустройство по ТК РФ;
-В компании есть выстроенная система обучения;

Подробнее: @natiateliya
#работа

Системный же, чего bi то называете

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

https://q.hh.ru/poll/7JWn7Zuqr7QB0g56gCxOCv

Анонимно, без регистрации и смс