❤️ Меняя мир - начинай с себя!

Привет, друзья!

На Хабре вышла моя статья о том, как мы провели внутреннюю оптимизацию согласований и прокачали рабочие процессы.
По ссылочке много текста, но поверьте, там специально разобрано все по шагам — чтобы вы могли взять уже готовое решение ☺️ Вдохновляйтесь! 💫

Если после прочтения появятся идеи или вопросы — пишите мне, обсудим в комментариях! 💡

📌 Статья: Читать на Хабре

🔍 Обмен опытом — must-have для бизнес-аналитиков. И вот почему!

Привет, друзья!

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

Речь не о частой смене работы, а о разборе реальных кейсов. Автоматизировали работу с клиентами, или запускали совершенно новую функцию в операционной службе, или выстраивали стратегию для запуска продукта - это все требует разного набора и техник, и артефактов! Но что делать, если текущие задачи не дают такого разнообразия? Ответ прост — перенимайте опыт коллег!

Как?
1️⃣ Через конференции (и я жду осени, чтобы анонсировать наш Business Analysis Day в Газпромбанке 😉)
2️⃣ Через профильные каналы — в них всегда есть:
🎯Готовые решения — зачем изобретать велосипед?
🎯Разбор ошибок — учитесь на чужих промахах
🎯Неочевидные подходы — возможно, вашу задачу уже решили
🎯Экономия времени — заберете проверенные схемы и методы.

Кстати, недавно команда devrel Газпромбанка запустила новый канал @gpb_tech — там:
🔹 Реальные ИТ-кейсы Газпромбанка
🔹 Разборы и ссылки на выступления экспертов
🔹 Анонсы мероприятий для обмена опытом
🔹 И немножко закулисья жизни ИТ Газпромбанка😉

💡 Подписывайтесь → [@gpb_tech] — и перенимайте опыт!

Отчет об исследовании: как его читать и готовить (чтобы не путать с отчетом об обследовании)

Друзья, привет!

Сегодня разбираем отчет об исследовании — важный артефакт, с которым бизнес-аналитик сталкивается в двух случаях:
✅ Когда нужно его подготовить (например, для анализа рынка или продукта);
✅ Когда нужно проанализировать готовый отчет и сделать выводы для проекта (GAP-анализ, требования, рекомендации).

📌 Чем отчет об исследовании отличается от отчета об обследовании?
(Чтобы не путать — про второй сделаю отдельный пост 👌🏻)
- Исследование = анализ данных, поиск закономерностей, прогнозы (как научная работа).
- Обследование = фиксация текущего состояния процессов/систем (как аудит).

🔎 Из чего состоит отчет об исследовании?
Это почти научный труд, поэтому структура знакомая:
1. Введение — зачем проводили исследование, какие вопросы решали.
2. Методология — как собирали данные (опросы, метрики, бенчмарки?).
3. Практическая часть — что изучили, какие данные получили.
4. Выводы и рекомендации — главные инсайты и что делать дальше.

💡 Часто в начале добавляют краткий обзор для руководства: ключевые выводы на 1 страницу. И при этом формат представления данных может быть любым.

📝 Каким должен быть текст отчета?

▪️ Объективность — только факты, без воды.
▪️ Структура — логика, которая ведет читателя от проблемы к решению.
▪️ Ясность — термины объясняем, сложные данные визуализируем.
▪️ Академические нормы — цитаты, ссылки, единообразие.

И если вы подумали, что не сталкивались с такими отчетами, приведу пару примеров:
1️⃣ GARTNER — их отчеты по ИТ-трендам (например, про AI) помогают компаниям строить стратегии.
2️⃣ Markswebb — исследования финтеха, которые влияют на проектирование банковских сервисов.

🔗 В первом комментарии — пример интересного исследования: как часто в России используют ИИ. Спойлер: мы в топе!


@open_BA #полезное_proBA

Отчет об обследовании 📋

Друзья, привет! 👋 Как обещала — сделала для вас пост про отчёт об обследовании.
На радость и на вдохновение! ✨ #полезное_proBA @open_BA

_______________________________

📌 Отчет об обследовании - один из итоговых артефактов работы бизнес-аналитика на «предпроекте».

Что имею в виду?
🤔 ➡️ Прежде чем автоматизировать/изменять/внедрять нужно понять - а что именно следует поменять? То есть понять состояние AS IS.

И вот такой аудит текущего состояния процесса (когда еще не выбраны подходы к автоматизации) бизнес-аналитик оформляет в отчёт об обследовании.

Разберем состав отчета! 🧐

🔹 Основная часть отчета - это описание процесса AS IS. Чаще всего оформляется в формате таблицы с колонками: 

• 🎯 Шаг процесса: его наименование и порядок.
• 👥 Участник (достаточно роли/должности).
• 📥 Входы: что поступает на вход этапа.
• 📤 Выходы: что получается на выходе.
• ⚙️ Действие: что выполняет участник.
• ❗ Какие проблемы имеются (что нужно исправить). Вот в этом пункте будет полезно указать также мнение опрашиваемого сотрудника.
• 💻 Можно добавить столбец с задействованными ИТ-системами. Если процесс выполняется в Excel — так и пишем 👌🏻

💡 Обратите внимание, что в отчет можно добавлять схемы. Классный пример схематичного состояния AS IS в упрощенной sequence diagram для процесса онбординга нового сотрудника привела в картинке к посту 🙏🏻

🔹 Вторая большая часть отчета - это описание состояния TO BE.

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

✅ Вместе с тем, описание необходимых модулей и функциональностей должно присутствовать обязательно. Ровно в той части, которую называют «требования бизнеса» и «требования заинтересованных сторон» (например, «добавить автоматическое назначение курсов новому сотруднику»).

🎯 Также стоит сразу указывать приоритет автоматизации: с каких модулей начинать автоматизацию.

📎 И добавляем обязательные элементы отчета:

• ✍️ Автор отчета, дата составления
• 🎯 Объект обследования
• 🎯 Цели и задачи

Вот и все! 🎉 Наш отчет об обследовании готов!

Теперь у вас есть четкий план действий и структура, которая поможет провести анализ системно и качественно! 💪🏻

#бизнес_анализ #ASIS #TOBE #автоматизация

🚀 ДАЙДЖЕСТ OPEN BA: 5 КРУПНЫХ ТЕМ ДЛЯ ПРОКАЧКИ В БИЗНЕС-АНАЛИЗЕ

Друзья, привет!

Собрала для вас ТОП наших постов: от базового минимума до роскошного максимума 😄👌🏻

Наслаждайтесь выходными и полезными материалами

1. ФРЕЙМВОРК BACCM — ФУНДАМЕНТ АНАЛИТИКА

Must-read для любого BA.
Почему это важно: Дает единый язык и системный подход к проектам любой сложности.

2. USE CASES: ОТ СТРУКТУРЫ ДО СЛАЙСОВ: РАЗ, ДВА

Глубокий разбор use case с двумя важнейшими аспектами:
- Структура use case и почему мы договорились опционально выделять потоки исключений (спойлер: чтобы не усложнять)
- Техника деления на слайсы — как use case разбивать на части, что критично в SAFe и гибких методологиях

3. ПРИОРИТИЗАЦИЯ: РАЗ, ДВА, ТРИ

Четыре мощных инструмента для определения что делать в первую очередь:
- MoSCoW
- Матрица Эйзенхауэра
- Модель Кано
- RICE
На практике: Используйте в зависимости от контекста. Для одного массового продукта мы используем RICE

4. ТЕХНИКА «5 ПОЧЕМУ» — РАЗБИРАЕМ БАЗУ

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

5. РАБОТА С СТЕЙКХОЛДЕРАМИ: РЕАЛЬНЫЙ КЕЙС

Опыт улучшения взаимодействия с заинтересованными сторонами

🚀 Кто с нами завтра на Analyst Days 21?

Друзья, привет!

14-15 ноября в Москве проходит профильная конференция для системных и бизнес-аналитиков.

Из года в год замечаем, как растет и количество участников, и уровень докладов. Делимся с вами своими рекомендациями ⬇️ - отметили доклады, на которые идем сами и вам от всего сердечка советуем 🤗

Отметьтесь, кто будет, или напишите в комментариях 👌🏻

До встречи на стенде Газпромбанка😉

От практики: как мы приоритизировали фичи методом RICE в реальном проекте

Друзья, привет! 👋

У нас было несколько постов о приоритизации задач (РАЗ, ДВА, ТРИ), но все они были про теорию. Сегодня - практический разбор одного мощного инструмента из нашего арсенала: метода RICE 📊

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

Напомним формулу:
RICE Score = (Reach × Impact × Confidence) / Effort

А теперь разберем каждую компоненту на основе нашего опыта:

👥 R (Reach) - Охват

Для нас охват - это количество клиентов-юридических лиц, которых затронет фича. Но на практике сразу же столкнулись с нюансом! 🤔

Наш инсайт: бывают продукты для юрлиц, но конечным пользователем является физлицо. Классический пример - зарплатные проекты. Ключевой вопрос: кого считать в «охвате»? Клиента, который платит, или конечного пользователя?
Наше решение: мы договорились на старте, что для нашего проекта в R мы считаем именно юрлицо - принимателя решения. Главное - заранее четко определить для себя эту границу, чтобы не запутаться в метриках ✅

💥 I (Impact) - Влияние

Оказалось, что субъективная оценка «высокое/среднее/низкое влияние» слишком размыта. Мы перевели в цифры даже это 📈

Наш инсайт: Мы использовали нелинейную шкалу от 0.25 до 5, где:
0.25 - «косметическое» улучшение 🎀,
а 5 - это критически важный функционал.

Наше решение: Мы детально расписали, что значит КАЖДЫЙ уровень влияния для нашего продукта. Это свело на нет споры «а мне кажется, что это 3, а не 2» 🤝

🎯 C (Confidence) - Уверенность

А вот это - самый «опасный» параметр, который команда невольно пыталась завысить! ⚠️

Наш инсайт: здесь мы тоже использовали шкалу от 25% до 100%, но жестко привязали ее к доказательной базе 🔗

· 100%: есть подтвержденная массовая потребность (данные опросов, отчеты, цифры по обращениям в поддержку) 📋
· 80%: есть результаты A/B теста или качественного исследования 🔬
· 50%: есть аналогичное решение у конкурентов или предположение, основанное на косвенных данных 🏢
· 25%: все строится на догадках, интуиции продакта без каких-либо исследований❓

Наше решение: подтверждать каждое значение уверенности. Это дисциплинирует и не дает строить воздушные замки. 🏗

⏱️ E (Effort) - Усилия

«Здесь-то уж точно все просто!» - подумали мы. Но и тут нашлись подводные камни🗿

Наш инсайт: перед расчетом сначала нужно определиться – а что именно мы считаем? Общую трудоемкость задачи (от проектирования до релиза), или только те, что в ближайшем спринте, или только разработку? ⏳
Наше решение: мы считаем общие усилия по всей задаче от передачи в реализацию до прома. Только так можно получить объективный RICE Score и сравнивать между собой абсолютно все задачи в бэклоге - и большие, и маленькие ⚖️

Итог:

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

P.S. А какими методами приоритизации пользуетесь вы? Сталкивались с похожими сложностями? Ждем ваши кейсы в комментариях! 👇

🚀 Business Analysis Day: Итоги и Инсайты

Привет, друзья!

В начале декабря состоялось одно из главных событий года для бизнес-аналитиков — Business Analysis Day от Газпромбанка. И это был не просто митап, а настоящая стратегическая сессия, где обсудили вектор развития профессии. Делимся ссылкой, где можно в деталях прочитать все ключевые моменты: vc.ru

Но знаете какой главный инсайт мы вынесли?
Сообщество единомышленников — это сила. А обмен опытом между бизнес-аналитиками из разных индустрий — бесценен 🫶🏻 Спасибо, друзья, что делитесь, что участвуете в сообществах и определяете будущее профессии!

🎄 А теперь — самое главное!

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

Желаем
💎 Еще больше сильных профессиональных инсайтов.
💎 Карьерных прорывов.
💎 Баланса между амбициозными проектами и личным временем.
💎 И, конечно, еще больше качественных мероприятий! Чтобы мы чаще встречались, делились опытом и вместе определяли будущее нашей профессии.

Спасибо, друзья, что вы с нами!
Встретимся в новом году 😉

@open_ba

#BusinessAnalysis #БизнесАнализ #BACommunity

Друзья, привет!

На канале LSBA начинаем делиться большим циклом лекций, записанных в партнерстве с Финтех хабом Банка России, и приглашаем вас освежить свою теоретическую базу 🤩

В рамках Темы 1 «Производственный процесс» вас ждёт:

🔹 Видео 1. Бизнес-анализ и BACCM

Часто так происходит, что роль бизнес-аналитика в разных компаниях понимают очень по-разному. В этом видео разберём, в чём заключаются задачи БА, обсудим отличия БА от других аналитиков и где именно он создаёт ценность для бизнеса.

🔹 Видео 2. Жизненный цикл программного обеспечения 

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

🔹 Видео 3. Матрицы ответственности

Если у вас в проектах периодически возникает вопрос «а кто вообще за это отвечает?» - вы не одиноки 🙂 В этом видео обсудим, как использовать матрицы RACI и DACI, чем они отличаются, какие ошибки в них допускают чаще всего и как применять эти матрицы так, чтобы они помогали команде и не оставались формальностью.

А Тема 2 «Техники анализа текущего состояния» уже доступна в MAX 🌀. Присоединяйтесь, если вы ещё не с нами ☺️