Когда мне пишут по поводу обучения, я всегда задаю вопросы, чтобы «прощупать почву» и в итоге более точечно помочь.

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

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

Вопросы следующие:

1️⃣ Чем сейчас занимаешься? Чем занимался раньше?

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

2️⃣ Какая итоговая цель?

Как ни странно, но не у всех итоговой целью является устройство на работу. Поэтому это важный вопрос. Это помогает понять нужно ли человеку обучение в принципе.

3️⃣ Что знаешь сейчас о бизнес-аналитике или о системной аналитике?

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

4️⃣ Какие дедлайны?

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

Юзер стори (user story)❗️

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

Представим, что мы описываем требования для СЭД (система электронного документооборота)

1. Масштаб user story

Масштаб user story должен соответствовать приблизительно уровню CRUDL операций (создать, прочитать, редактировать, удалить, лист)

Например: скачивание документа является частью просмотра документа, мы можем проверить эту функцию в критериях приемки. Если мы их разделим на отдельные us (просмотр + скачивание) то мы не выдержим требования по INVEST критериям (1 user story на спринт, а не на день, слишком мелко).

2. Трассировка требований по user story

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

Допустим у нас есть функция уведомления об изменении статуса документа (при создании, подписании и т.д.)

Например: если мы отдельно не вытаскиваем us по уведомлениям, то мы должны учесть это в критериях приёмки других user story (подписание документа). Если вытаскиваем отдельно, то не надо это прописывать в критериях приёмки например создания т.к это будет дублированием.

В конце проработки всех user story надо сопоставить их между собой и убедиться, что мы учли всю функциональность в критериях приёмки

3. User story - пользовательское требование

Т.к user story - это пользовательское требование, то нужно критерии приёмки писать с точки зрения пользователя, а не системы.

Т.е как я проверю как пользователь, что фича работает корректно

Примеры:

❌Система проверяет данные в документе по БД и предоставляет информацию о незаполненных обязательных полях
✅Пользователю на экране отображается ошибка при незаполненных обязательных полях в документе

4. Никакой конкретики в критериях приемки

Примеры:

❌Пользователь жмёт кнопку "отправить", после чего документ отображается в списке документов
✅Пользователь отправляет документ, после чего документ отображается в списке документов

В первом случае нарушается один из INVEST критериев. Критерий Negotiable. История перестаёт быть обсуждаемой и содержит конкретные детали реализации

5. Бизнес и пользовательская ценности user story

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

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

Если формулировка звучит как "Я, как пользователь, хочу создать документ для того, чтобы он появился в системе", то это не несет в себе никакой ценности для пользователя и тем более для бизнеса. Это звучит примерно на уровне "Я ем, чтобы есть"

❌Я, как пользователь, хочу создать документ для того, чтобы он появился в системе
✅Я, как пользователь, хочу создать документ в системе для того, чтобы уменьшить время его обработки, в части согласования, по сравнению с ручной обработкой

⭐️Сегодня знаменательный день⭐️

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

Теперь вы не просто делаете аналитические артефакты!

⚡️В ходе обучения вы полноценно будете вовлечены в общение с бизнесом, с командой и в прочие аналитические процессы, что позволит вам⚡️

1️⃣ Расширить кругозор в части необходимости использования тех или иных аналитических артефактов в зависимости от особенностей проекта;
2️⃣ Проработать навык общения с заказчиком, а также презентации своих артефактов для людей, которые не погружены в аналитическую часть;
3️⃣ Повысить уровень своей компетенции в части концептуального понимания особенностей проектирования системы;
4️⃣ Более глубоко и приближенно к реальности погрузиться в особенности аналитической работы на проекте.