Для тех, кто хочет изучить все тонкости нотации BPMN, есть отличный You Tube канал на русском языке.
Материалы будут полезны для всех БА уровня Junior и Middle.
Детальное объяснение процессов, разбор кейсов и ответы на практически все возникающие вопросы по BPMN.

Смотреть: BPMN YouTube Channel

🔥🔥🔥 Сегодня поговорим о такой важной теме, как CHANGE REQUESTS. Как их оформлять и зачем.

Все когда-либо сталкивались с ситуацией, "Всё пропало..., клиент уезжает..., гипс снимают...".
Любое изменение системы, это и есть запрос на изменения, либо Change Request CR), возможно еще услышать Problem or Change Request (PCR).

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

Первые два похожи и иногда объединяются в "requirement", но чаще всего существуют отдельно, так как это разные вещи.
Варианты определяются от источника запроса, новую функциональность может требовать бизнес или пользователь сервиса, в свою очередь рефакторинг и переписывание ядра, это требование технического руководителя либо архитектора.

Третий вид "defect" - в большинстве случаев находит тестер, иногда пользователь системы.

Необходимо помнить самое важное, что система в итоге изменяется и все изменения необходимо чётко фиксировать и контролировать.

📃 Как документально фиксировать Change Requests?

В содержании CR можно выделить обязательные блоки:
📍 Автор (submitter)
📍 Имя / Название (subject)
📍 В какой версии
📍 Подробное описание
Можно добавлять блоки в зависимости от процесса и команды разработки:
📍 Ожидаемое поведение
📍 Конфигурация системы
📍 Лог-файлы

👉🏻 Типовой жизненный цикл CR:
New -> Assigned -> Opened -> Resolved -> Closed

✔️ Итого: CR - Формальное обращение, необходимое для получения официального разрешения на изменения в предметной области проекта, проектных решениях, методах, плановых сроках и затратах или других показателях проекта.

❗️ ВАЖНО: СR должен быть задокументирован, зарегистрирован и оценен, выполняется, только после одобрения со стороны бизнеса.

📖Рекомендация книги:📖

Леффингуэлл Дин, Уидриг Дон
"Принципы работы с требованиями к программному обеспечению. Унифицированный подход"

👉🏻 Must have для чтения для начинающих аналитиков, а также аналитиков уровня middle.
В книге автор последовательно, без лишней воды рассказывает о работе с требованиями, о сложностях, которые могут возникнуть и о возможностях решения этих сложностей.

В книге около 440 страниц.
Книга есть в свободном доступе в интернете.

2 бесплатных курса от Coursera на английском языке, которые будут полезны бизнес аналитику.
1. "Introduction to Systems Engineering"
Описание тренинга

2. "Requirements Writing"
Описание тренинга

​​Как улучшить понимание английского на слух ?

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

👉🏻 ЕСЛИ НЕПОНЯТНА РЕЧЬ ОДНОГО ЧЕЛОВЕКА

Сделайте запись одной из встреч (у многих это и так регулярная практика). После этого включите речь заказчика и слушая предложение за предложением, транскрибируйте🖌 (записывайте) все, что говорит человек. Если есть белые пятна, оставляйте их, потом можно переслушать или попросить помощи другого человека с хорошим английским понять, что же говорил клиент. Здесь важно именно записывать!🗒
После того, как максимально поняли, постарайтесь как можно похоже повторить его фразу. Слушаете и повторяете, фразу за фразой, таким образом давая мозгу адаптироваться к манере произношения, скорости речи.

Такое упражнение лучше делать НЕ более 40 минут (лучше 20-30), и, желательно, ежедневно. Слушайте по предложению, останавливайте запись и старайтесь записать. Через неделю такой практики ухо привыкнет к необычной речи и понимать человека на слух станет намного проще. 👂🏻

👉🏻ЕСЛИ НЕПОНЯТЕН АКЦЕНТ ИЛИ ПРОИЗНОШЕНИЕ КОНКРЕТНОЙ СТРАНЫ/РЕГИОНА

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

👉🏻 ЕСЛИ ХОЧЕТСЯ ПРОСТО УЛУЧШИТЬ ВОСПРИЯТИЕ АНГЛИЙСКОГО НА СЛУХ

Включаете кино (лучше сериал с короткими сериями) и смотрите серию два раза (для тех, кто на уровне Intermediate и выше) или три раза (для тех, кто на уровне PI, Elementary). Первый раз на русском, второй на английском с субтитрами, выписывая незнакомые слова и третий раз чисто на английском без субтитров, стараясь максимально разобрать слова.
И опять же повторяйте за героями фразу за фразой, максимально их копируя.

📍Ежедневная практика 20-30 минут и вы уже через неделю почувствуете результат.

Воркшоп по выявлению требований: коротко о главном

📍ЧТО ТАКОЕ ВОРКШОП - управляемая сессия по проработке требований будущего решения совместно со всеми стейкхолдерами (представители бизнеса,технические специалисты, UX-специалисты, конечные пользователи). Основная отличительная черта - одновременное участие всех заинтересованных лиц в процессах обсуждения и принятие решений.

📍КОГДА ПРОВОДИТЬ:
Запуск нового продукта/проекта, когда нам нужно за короткий промежуток времени очень быстро проработать бизнес и пользовательские требования;
Проработка нового функционала для существующего продукта, когда есть некая бизнес-инициатива и задача бизнес-аналитика понять пользу от ее внедрения в продукт.

📍ЧТО НАМ ДАЕТ ВОРКШОП:
Единое понимание сути проблемы и её решения у всех участников проекта;
Самый быстрый способ для бизнес-аналитика продвинуться от высокоуровневой хотелки до продуктового бэклога;
Принятие решений по продукту происходит совместно со всеми участниками проекта, а не ложиться на плечи аналитика;
Типовой набор активностей (техник), которые можно адаптировать под разные проекты;

📍КОГО ПРИГЛАСИТЬ:
Спонсор/представитель спонсора;
Владелец продукта (Product owner);
Профильные эксперты (SME’s);
UI/UX-специалист;
Архитектор/тех лид;
Конечные пользователи.

👉🏻 Лайфхак: в идеале на воркшопе должны присутствовать от 7 до 10 человек. Меньше - есть риск упустить важное в требованиях. Больше - сложнее принимать решения.

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


👉🏻 Типичная агенда и применяемые техники для воркшопа длительностью 1 день (в процессе проведения может изменяться и дополняться):

1️⃣ Kick-off meeting - даем краткие вводные всем присутствующим по поводу, того что, как и для чего будет происходить во время воркшопа. Длительность - до 20 мин.
2️⃣ Определите скоуп проблем. Здесь поможет техника Anchors&Engines. Длительность - от 30 мин.
3️⃣ Поговорите о видении будущего решения и метриках достижения успеха. Техника - Elevator Pitch. Длительность - от 30 до 60 мин.
4️⃣ Определите будущих пользователей, техники - Personas/Empathy Map. Длительность - до 45 мин.
5️⃣ Изучите существующий процесс (если таковой имеется). Используйте техники CJM, Pain points mapping. Длительность - до 45 мин.
6️⃣ Спроектируйте будущий процесс при помощи техник CJM, How might we. Длительность - до 45 мин.

➡️ Перерыв на обед - 1 час.

7️⃣ Продумайте и создайте прототипы будущего пользовательского интерфейса, техника Collaborative sketching. Длительность - от 45 до 60 мин.
8️⃣ Провалидируйте с пользователя и продумайте архитектуру решения (Focus groups, ABT, Architecture design). Длительность - 45 мин.
9️⃣ Разбейте решение на юзер-стори, приоритезируйте и спланируйте поставки. Техника - Story Mapping. Длительность - 60 мин.
🔟 Презентуйте результаты воркшопа всем заинтересованным лицам, выслушайте и внесите все необходимые корректировки. Длительность - 45 мин.
1️⃣1️⃣ Соберите обратную связь от участников - это поможет вам скорректировать текущую агенду для дальнейшей работы. Длительность - 15 мин.

Подробнее с каждой из техник мы будем знакомить вас в наших следующих статьях.

🔥Легендарный Гарвардский курс CS50
Отличный курс для бизнес-аналитиков, у которых нет знаний программирования, но есть желание разобраться, что и как работает «под капотом».
👉🏻 Очень простая и интересная подача.
👉🏻 Что такое программирование. С чего начинать. Алгоритмирование, простейшие языки, шифрование. С, С++, немного Python. Введение в нейросети и API. Очень много практических занятий.
👉🏻 Курс есть на английском и русском языках в бесплатном доступе.
Можно просто изучить, а можно получить сертификат после изучения курса (Цена-90$).

Курс на русском языке

Отличные новости! Подоспели замечательные вакансии от замечательной компании🔥.

🌞 ANDERSEN (http://andersenlab.com/) – это команда, создающая качественное программное обеспечение для клиентов практически на всех континентах. Среди наших клиентов присутствуют такие гиганты как Amazon, Marvel, Samsung.

ANDERSEN приглашает:
📍Опытных ВА, middle/senior, english 🗣 B2 и выше;
📍Опытных СA , middle/senior, english 🗣 B2
📍Опытных СА, middle/senior,можно без английского, но с опытом в финтех (проекты Альфабанк, ВТБ, Тинькофф и др)

💬Контактное лицо:
Анна Польщикова- лид рекрутер по ВА
E-mail
a.polshchikova@andersenlab.com
Telegram
@AnnaAndersen

Рабочий день закончился и можно смело праздновать наш день! День Бизнес Аналитика!

​​Definition of Ready и Definition of Done. В чем разница?

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

📌 DEFINITION OF READY (DoR)
это чек лист того, что необходимо сделать с элементом бэклога продукта (как правило с пользовательской историей), прежде чем команда сможет приступить к его реализации в следующем спринте.

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

Что может выходить в Definition of Ready?
Например:
📎пользовательская история описана
📎критерии приемки определены
📎пользовательская история соответствует INVEST
📎пользовательская история оценена командой
📎команда понимает ценность истории

Важно отменить, что не существует универсального списка, и на своем проекте в вашей команде вы можете выбрать подходящие именно вам критерии.
При этом важно:
Команда должна согласиться со всеми критериями, входящими в DoR
DoR должен быть одинаков и применяться для всех историй в проекте

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

Что может входить в DoD:
📎все критерии приемки выполняются
📎юнит тесты пройдены
📎критические баги отсутствуют
📎код ревью пройдено и др.

При этом DoD может использоваться на разных уровнях: для истории, для спринта, для релиза и тд.

Так в чем же разница? Если упростить все вышесказанное, то
👉🏻 DoR это критерии, которым должен соответствовать элемент бэклога ПЕРЕД тем, как пойдет в разработку, а
👉🏻 DoD - критерии его готовности для выхода в продакшн ПОСЛЕ разработки.

🗣 Если вы хотите прокачать свой английский и узнать последние новости в сфере технологий (и не только), узнать новые слова, применимые в работе, то существует замечательный портал
https://breakingnewsenglish.com/technology.html

📌 Каждая новость имеет адаптацию под определенный уровень знаний английского. Можно читать и слушать новости, начиная с Beginner и заканчивая Advanced.

📌 Много свежих интересный новостей, которые постоянно обновляются

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

Бизнес аналитики и заказчик
#BAmemeRU

​​FOLLOW UPS. ЧТО ЭТО, ПОЧЕМУ ВАЖНО, КАК ПИСАТЬ

Вуди Аллен говорил, что 80% успеха — просто прийти. При всем уважении к Вуди, этого уже недостаточно: в бизнесе все решает фоллоу ап, как сигнал, что вы держите ситуацию под контролем.

🖍 Фоллоу ап — калька с английского follow up, бизнес-термин, пока не имеющий фиксированного русского аналога. В общем и целом означает поддержание контактов с заинтересованным лицом. Например, это может быть электронное письмо после знакомства и личной встречи или повторное письмо клиенту, который не откликнулся на первоначальное предложение. Цель такого звонка или письма — напомнить о себе, прояснить ситуацию, узнать решение и получить обратную связь.
🖍 Для бизнес-аналитика follow up также является важным инструментом общения с заинтересованными лицами, приведем несколько причин, по которым стоит написать follow up letter после общения с ними.

1️⃣ Стейкхолдеру будет сложнее о вас забыть
Даже в самых лучших компаниях случаются не лучшие дни, и сотрудник, с которым вы работаете по извлечению требований, может быть слишком загружен работой. Или он может по каким-то причинам отнестись невнимательно к своим обязанностям. Обнаружив сообщение от вас, он вспомнит о вашем существовании.

2️⃣ Это возможность задать уточняющие вопросы или поделиться дополнительной информацией
Часто через после общения со стейкхолдером вы понимаете, что из-за волнения или недостатка времени забыли прояснить какие-то важные детали относительно проекта. Для того, чтобы узнать эту информацию или сообщить новую, смело используйте follow up письмо.

3️⃣ Это возможность получить обратную связь
На основании общения с разными заинтересованными лицами по проекту у вас может сложится свое абсолютно уникальное видение процесса, для того, чтобы сверить имеющуюся информацию, идеально подойдет follow up письмо, которое вы можете направить лицу, принимающему решение по проекту, сверив свои предположения и получив его комментарии.

4️⃣ Это возможность зафиксировать договоренности, к которым вы пришли с с заинтересованными лицами
Часто процесс извлечения требований бывает длительным и может включать в себя разные активности, для того, чтобы письменно задокументировать некоторые промежуточные договоренности, выраженные ранее в устной форме, можно использовать follow up письма.

❓Как именно писать follow up письмо❓
Важно понимать, что идеального шаблона нет и быть не может, потому что все зависит от конкретной ситуации. Однако есть несколько рекомендаций, которые точно сделают текст лучше.


👉🏻 Сделайте так, чтобы всю связанную с вами информацию было легко найти или вспомнить
Для этого в теме письма можно указать название проекта, компании, в основной части удобно будет указать дату предыдущей встречи/ звонка, вложенные файлы удобно дополнить названием проекта (аббревиацией), все это позволит заинтересованному лицу быстрее вспомнить вас или вопрос, по которому вы общались.

👉🏻 Кратко опишите суть ситуации и четко определите цель вашего письма
Это позволит собеседнику быстро вникнуть в суть вопроса и оперативно отреагировать на ваш вопрос, либо предоставить необходимую информацию, согласовать или опровергнуть указанную в письме информацию. Именно поэтому важно, чтобы follow up письмо было не слишком большим по объему, включало четко выделенные информационные блоки.

14 июля состоится онлайн-конфа Business Analysis Night от APOLLO Product School!

Спикеры и темы конференции:
1. Кирилл Белявский, Lead Business Analyst / Business Analysis Office Service Manager в компании SoftServe. 8 + лет в бизнес анализе.

Тема: «Business Objective Model».


2. Геннадий Кобзарь, Senior Business Analyst в EPAM Systems. Более 5 лет опыта в сфере бизнес-анализа. Постоянный участник БА комьюнити в Украине.

Тема: «Юмор как аналитический инструмент».


3. Мария Ивашко, Senior Business Analyst в iTechArt. Ранее работала в EPAM, Andersen. Более 6 лет опыта.

Тема: «Как провести первую встречу со спонсором проекта».


4. Мария Попова, Lead Business Analyst в EPAM, более 10 лет в бизнес анализе. SAFe Product Owner / Product Manager (4.5).

Тема: «Планирование дня для БА».

Когда? 14 июля
Где купить билет? https://www.apollo-design.center/events-all/event/business-analysis-night
Цена? 299 грн

🔥Книга must have для всех, кто работает в сфере ИТ. Научит основам юзабилити и возможно даст пару-тройку отличных идей.

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

💻 Книга есть в свободном доступе в интернете.

​​Техника ELEVATOR PITCH: примеры и типичные ошибки

👉🏻 Elevator pitch (в переводе с английского «презентация в лифте»)— это небольшой рассказ о сути реализуемого продукта либо услуги, который длится в течение 60–120 секунд. Технику часто используют для самопрезентации при устройстве на работу либо на этапе привлечения инвесторов при запуске стартапа. Основная идея - быстро и четко донести суть т.к в большинстве случаев лица, принимающие решения (инвесторы, наниматели, спонсоры) ограничены во времени.

👉🏻 Когда используем технику - на этапе выявления требований (воркшопы, интервью, работа с фокус-группами).

📃 Плюсы техники:

📌 Помогает понять заинтересованным лицам, куда мы движемся;
📌 Позволяет договориться об образе решения за достаточно короткий промежуток времени;
📌 Помогает удерживать фокус внимания на ценности продукта и его основных функциях;
📌 Не занимает много времени, в среднем от 30 до 60 минут.

👉🏻 Результат техники - можно отправлять прямиком в “Документ об образе и границах“ ( Vision and Scope Document) в раздел “Положение о концепции” (Vision Statement)

👉🏻 Как работает техника?

1️⃣ Объясняем заинтересованным лицам, что такое Elevator Pitch (в чем заключается суть техники);
2️⃣ Рассказываем, что помещать в каждый раздел;
3️⃣ Предоставляем время для обдумывания;
4️⃣ Помещаем результаты на доску (офлайн/онлайн);
5️⃣ Обсуждаем каждый пункт.

FOR - целевая аудитория - для кого мы создаем продукт;
WHO WANT - основные потребности пользователей;
“Product name” - название продукта;
IS A - категория продукта;
THAT - ключевые преимущества, основные причины для покупки и/или использования;
UNLIKE - какие на данный момент имеются конкурентные решения;
THE PRODUCT - основные отличия и преимущества продукта;

🖍 Например,

FOR - для людей в возрасте от 22 до 60 лет;
WHO WANT - которые хотят следить за своим питанием, нуждаются в помощи при выборе продуктов питания;
“Product name” - Здоровое питание;
IS A - трекер питания;
THAT - который, сканирует продукты в режиме реального времени, предоставляет информацию о КБЖУ;
UNLIKE - в отличие от всех существующих на рынке решений;
THE PRODUCT - бесплатный и удобный в использовании.

👉🏻 Типичные ошибки:

➖ Не обсуждайте детали будущего продукта, элементы интерфейса;
➖ Помните о ценности, которую должен приносить продукт;
➖ Не тратьте на обсуждение каждого из пунктов более 5-7 минут - есть вероятность, что вы углубились в детали, обсуждение которых можно перенести на попозже.
➖ Изучите домен будущего продукта - так вы будете говорить со всеми заинтересованными лицами на одном языке и лучше понимать их боли/потенциальные возможности.