BA GIRL | Бизнес-аналитик в IT

​​Кейс. Что не так в пользовательском сценарии?

Коллеги, с Новым годом!

Начинаем мы его с практического кейса из реальной жизни.

Сейчас покажу вам кусочек артефакта, но прежде дам немного вводных.

1️⃣ Артефакт предназначен для того, чтобы команда могла дать оценку на разработку функционала (примерную), т.е. детали реализации, не влияющие значительно на сложность фичи, неизвестны и на текущем этапе не важны.

2️⃣ Показанный кусочек — пользовательский сценарий, предполагает описание основных позитивных сценариев в рамках данной фичи без множества деталей (отдельно есть раздел ФТ в документе: важные и известные требования вынесутся туда).

3️⃣ Фича: виджет, в котором я могу создавать и формировать (наполнять) разные группы из своих коллег, чтобы видеть определенные события. Существует свернутый вид виджет, в котором видим только тех, у кого определенные события есть, и развернутый вид, в котором видим всех людей, добавленных в группы. (Для нашего кейса функциональная составляющая не критична, но важна). Если для ответа вам нужны, на ваш взгляд, еще детали, напишите вопросы в комментариях.

Перед вами описанный сценарий одним из аналитиков. Давайте порассуждаем о качестве 💬👇

Наводящие вопросы:

1️⃣ О чем подумали при прочтении? Видите ли вы сценарий? Ощущения.

2️⃣ Какие видите недочеты и как бы их исправили?

3️⃣ Какие сценарии бы выделили и стали описывать? Ключевые тезисы в сценариях?

Потом я расскажу свои комментарии и покажу предлагаемый пример оформления от меня.

—
Поддержать канал

​​Миграция данных. Процесс подготовки к миграции данных со стороны анализа. Часть 2.

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

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

Как же, на мой взгляд, должен выглядеть процесс подготовки со стороны анализа?

1️⃣ Определение объема и целей миграции:

Первый шаг в подготовке — это четкое понимание целей миграции. Зачем вообще переносить данные? Какие именно данные будут мигрироваться? Какой объем данных требуется перенести? Эти вопросы определяют весь дальнейший процесс и помогают избежать непредвиденных проблем.

2️⃣ Анализ текущей системы и данных:

Вам нужно понимать, как устроена текущая система и каковы характеристики данных, которые будут переноситься. Какие данные являются критически важными? Есть ли дублирующиеся или неактуальные данные, которые можно исключить? Какие форматы данных используются, и нужно ли их преобразовывать?

3️⃣ Определение требований к новой системе:

Далее необходимо согласовать, как будут использоваться данные в новой системе. Какие требования предъявляются к данным? Нужно ли учитывать вопросы совместимости форматов или возможные ограничения новой платформы? В чем заключается разница между имеющимися данными в старой системе и ожидаемыми в новой?

4️⃣ Планирование этапов миграции
Миграция данных редко осуществляется за один этап. Разделите процесс на несколько шагов: подготовка, тестирование, основная миграция, постмиграционные проверки. Важно, чтобы каждый этап был тщательно проработан и протестирован.

5️⃣ Планирование тестирования и валидации:

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

6️⃣ Управление рисками:

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

Почему это важно?

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

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

P.s. спасибо всем, кто поделился своими процессами под предыдущим постом! 🙏

--
поддержать канал

​​Миграция данных. Что такое и чем отличается от похожих процессов? Часть 1.

Mиграция данных — это перенос существующих исторических данных в новое хранилище, систему или формат файла.

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

Существует несколько очень похожих процессов, но все-таки концептуально отличающихся друг от друга: миграция, интеграция и репликация.

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

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

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

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

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

Расскажите, сталкивались ли вы с миграцией данных? Как выглядел процесс подготовки к миграции со стороны анализа? Что делали и какие артефакты готовили? 💬👇

А потом я расскажу, как, на мой взгляд, выглядит процесс анализа для поддержки миграции данных.
—
поддержать канал

​​Интеграционные сценарии. Что такое и при чем тут аналитик?
(30 секунд)

Итак, как вы уже поняли из предыдущих постов, у меня накопилось много интересного про интеграции. Не отписывайтесь, скоро вернёмся к разговорам о «сложных» стекхолдерах)

Итак, одна из очень важных частей описания интеграций — это описание сценариев.

Что вообще такое интеграционный сценарий? Это последовательный набор шагов, которые должна выполнить каждая из сторон интеграции (чаще всего — конечные стороны: система-источник и система-получатель) для решения определённой задачи.

Описание сценариев состоит концептуально из 2-х вещей:

1️⃣ Определить, какие сценарии должны поддерживаться в рамках интеграции;

2️⃣ Описать шаги каждого сценария.

При чем тут аналитик, спросите вы?

Все просто.

Интеграционные сценарии не отвечают на вопрос: как? Сценарии интеграции отвечают на вопросы: кто? и что?

Именно аналитику, владеющему пониманием целей интеграции и процессов внутри систем, проще всего корректно определить и описать сценарии.

Что важно?

Важно не путать сценарии интеграции с sequence diagram, как методом описания межсервисного взаимодействия.

Во-первых, sequence diagram — это просто способ описания, а не сам сценарий, а во-вторых в случаях описания интеграционных сценариев sequence точно не хватит.

Итак, давайте поделимся: кто сталкивался с описанием интеграционных сценариев? Расскажите о подходе, который используете для определения, какие вообще интеграционные сценарии должны поддерживаться? 💬👇

А потом я расскажу о своём)

--
Поддержать канал

​​Привет!

Пока я тут собираю очередной интересный пост (анонс: про сценарии интеграции и подход, который я люблю использовать для их описания), на бусти вышел животрепещущий гайд: «Как попросить повышения ЗП, чтобы вам её точно повысили»🤞

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

P.S. по секрету, конец лета/ начало осени — лучшее время, чтобы успеть попросить повышения ЗП. Осенью обычно идут в активный найм, чтобы израсходовать бюджеты, выданные на год, и с повышениями может быть чуть сложнее.

Дерзайте и делитесь своими историями повышения ЗП 💬👇!

​​Может ли архитектор «наложить вето» на бизнес-фичу? Часть 2.
(54 секунды)

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

Мне кажется, что важно удостовериться, что мы сами не подменяем понятие бизнес-фичи и точно говорим именно о ней.

Приведу пример:

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

Является ли это бизнес-фичей или бизнес-требованиями? Нет, не является. Это решение.

И выходит, что мы говорим не о бизнес-фиче, а о необходимости использовать решение.

Как бы звучало бизнес-требование? Необходимо разработать модель полномочий и их назначения такую, чтобы..

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

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

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

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

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

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

--
Поддержать канал

​​Может ли архитектор «наложить вето» на бизнес-фичу?
(30 секунд)

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

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

Ну ладно, пост был не об этом.
Сейчас у нас идёт оценка бэклога на следующую фазу.

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

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

Здесь надо сделать паузу и рассказать вам несколько вводных о самом бэклоге:

1️⃣ Бэклог (краткие названия фичей) были переданы команде владельцем продукта со стороны заказчика и ни раз провалидированы со всеми ЗЛ со стороны бизнеса.

2️⃣ Бизнес-анализ сформировал описания этих фичей для оценки, включая:
- проблему, которую решаем фичей или бизнес-ценность фичи;
- бизнес-требования;
- концептуальные (верхнеуровневые требования) к реализации фичи.

И ещё раз согласовал все это с бизнесом ДО того, как все постановки были выданы команде в оценку.

Итак, зная все это, что думаете о словах нового архитектора? Что ответили бы ему?

И главное: может ли архитектор «наложить вето» на бизнес-фичу? 💬👇

--
Поддержать канал

​​Система-витрина. Особенности работы бизнес-аналитика на проектах разработки систем этого класса. Часть 2.
(49 секунд)

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

И в общем-то, это довольно правильно, и абсолютно точно тянет за собой сильного системного аналитика на проект, но начинается все не с этого.

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

Вопрос 1️⃣
Каковы бизнес-цели и бизнес-ценность системы-витрины для заинтересованных лиц?

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

Вопрос 2️⃣
Какие данные будут использоваться в витрине и какие преобразования данных потребуются, чтобы выполнить требования к системе-витрине?

Очень важно на начальных этапах максимально явно провалидировать, что все необходимые данные в мастер-системах имеются и все необходимые преобразования действительно возможны. Этот вопрос идёт в связке и в параллель со следующим вопросом.

Вопрос 3️⃣
Какие системы будут мастер-системами для витрины и какие процессы с данными заложены в этих системах?

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

Хотела бы ещё отдельно проговорить маленькое замечание: если в вашей карьере случится такой проект, будьте очень внимательны в отношении «мастер-систем». Сейчас в компаниях настолько широкий спектр систем, что найти действительно «мастер» бывает не просто. Более того, иногда «мастер-системой» для витрины может быть и не первоисточник данных. Обратите на это особое внимание.

Продолжите мой топ вопросов? Какие вопросы, на ваш взгляд, необходимо проработать, попадая на проект создания «системы-витрины»? 💬👇

——
Поддержать канал

​​Система-витрина. Особенности работы бизнес-аналитика на проектах разработки систем этого класса. Часть 1.
(20 секунд)

Итак, сегодня поговорим про довольно интересный «класс» проектов, на которых разрабатываются системы-витрины.

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

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

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

Если вы знакомы с понятием витрина данных в архитектуре и знаете особенности этой формы хранилища данных, то наверняка поняли и особенности системы-витрины для бизнес-аналитика, т.к. термин на уровень «систем» вышел именно из архитектуры.

Давайте попробуем сначала вместе порассуждать. Сталкивались ли вы с такими системами на проектах? Как считаете, в чем особенность работы бизнес-аналитика на таких проектах? 💬👇

—
Поддержать канал

​​«Нам не нужен Team Lead». Что делать, если заказчик считает, что управлять командой не надо?
(120 секунд)

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

Спустя несколько недель моей работы, когда были написаны и внедрены регламенты, организована работа команды и все встало на стабильные рельсы, заказчик на общей встрече задал вопрос: «А почему Анастасия не пишет постановки в разработку, как остальные аналитики? Чем она занимается? Мы не собираемся платить за тим.лидство, нам оно не надо. Регламенты она уже написала, все понятно, теперь пусть работает, как остальные.»

Сначала стало грустно на мгновение, потом забавно, как незаметна работа Тим.Лидов, когда ты перестаешь выдавать артефакты, при том, что к КАЖДОМУ артефакту напрямую приложена твоя рука (но об этом же никто не знает:))

В общем-то в моем случае, все закончилось прекрасным менеджментом на стороне моей компании и моими хорошими отношениями с ними, когда менеджмент в ультимативной форме сказал, что считает, что таким количеством аналитиков необходимо управлять. И либо у нас есть тим.лид анализа, либо пусть управление ложится на плечи вашего PO. А PO у Заказчика — отдельная история.

Но я задумалась, как бы я аргументировала необходимость тимлидства команды анализа и value для заказчика от отдельной выделенной роли?

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

2️⃣ Для экспертов со стороны заказчика есть единая точка входа по всем вопросам: я. Не надо думать и искать, кому задать вопросы.

3️⃣ Для команды история такая же (сначала ко мне — потом на заказчика), в связи с чем сократилось кол-во вопросов, которые в целом выносятся на экспертов и заказчика.

4️⃣ Перестала теряться информация, т.к. появилась структура и внутренняя организация хранения всей информации, стали фиксироваться результаты встреч. Все знают, где и что искать. (> сократилось кол-во “переспрашиваний”, возвращений в уже обсужденные вопросы и т.д.).

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

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

Важно сделать замечание, что большинство аналитиков в команде — Junior/Middle, работа которых без саппорта — это просто постоянный цикл и регулярно возникающие новые, непроработанные вопросы, что абсолютно естественно, учитывая их уровень. И будь уровень моих аналитиков другим, то и кол-во времени на «лидство» и уровень вовлеченности в задачи каждого тоже был бы другим, а значит могло бы появиться время на «свои постановки в разработку».

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

Кто для вас Team Lead команды анализа? Нужен ли он? Хотелось бы вам иметь на проекте человека, к которому всегда можно прийти за советом, который всегда поддержит и скорректирует до того, как вы вынесете результаты на оценку клиента? Или если он у вас уже есть, нравится ли вам его работа? 💬👇

—
Поддержать канал

BA GIRL | Бизнес-аналитик в IT pinned Deleted message

BA GIRL | Бизнес-аналитик в IT pinned a photo

Ценность функционала. Почему о ней важно говорить и писать в постановках на разработку?
(16 секунд)

Однажды я пришла на проект, на котором уже работала команда.

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

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

Постановки отвечали на вопрос «что?», но не отвечали на один важный вопрос. Более того, на него команде разработки не могли ответить и аналитики, например, на груминг-сессиях.

Догадываетесь на какой?

«Зачем?»

Как думаете, должны ли постановки в разработку отвечать на этот вопрос? Почему всей команде важно или не важно понимать, зачем им тот или иной атрибут/функционал?💬👇

——
Поддержать канал

​​Фокусировка при описании фичи и её важность. Почему "растекаться мыслью" плохо?
(40 секунд)

Недавно меня попросили поревьюить одну постановку в разработку. Отношения ко мне и к моему проекту постановка не имеет, поэтому, как человек, который не в контексте, я непредвзято смотрела на артефакт.

В этой постановке было очень много текста и лишних слов. И это первое, что бросилось мне в глаза.

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

И это большая ошибка. В той постановке, которую мне отдали на ревью был полный набор последствий такого «писательства»:

1️⃣ Несостыковки по тексту из-за большого объёма.

2️⃣ Много информации, не относящейся непосредственно к функционалу в текущей постановке. Информация о смежных фичах, которая НИКАК не влияет на текущую, но даёт «объёма» и «массы» постановке.

3️⃣ Синонимичный ряд постоянно заставляет читателя вспоминать синонимы из прошлых абзацев и думать, а точно ли это одно и то же, что было уже раньше или нет (помните, что в идеале в начале каждого проекта должен появится словарь терминов? Вот он должен появиться не просто так. Лучше пусть ваша постановка выглядит «беднее», но будет однозначно интерпретирована).

4️⃣ Присутствие фраз: «не только, но и», «однако», «в случае описанном выше и в случае, описанном, в пункте 5» и т.д. сильно усложняет восприятие и больше путает, чем вносит ясности или удобства.

📍Хорошая постановка НЕ равно большая!

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

И помните: чем чётче описание, тем меньше текста, а значит больше вероятность, что постановку прочитают внимательно до конца.

Поделитесь своими мыслями. Что думаете на счёт реализации писательского таланта в постановках на разработку или при описании требований? Сталкивались с таким?💬👇

——
Поддержать канал

​​Я не могу сказать «нет» владельцу продукта. Он же владелец продукта, он главнее. (с) Часть 2.
(28 секунд)

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

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

Не можете сказать «нет» владельцу продукта? Значит не можете грамотно сказать «нет» ни одному стекхолдеру. Последствия? Плачевные. Стекхолдеры будут вас любит, а команда ненавидеть. Скоуп будет стремительно расти, а доходы от проекта стремительно подать. В общем-то, в какой-то момент с вами просто попрощаются.

Учитесь аргументированно и грамотно говорить «нет» и отстаивать свою позицию.

По-моему скромному мнению, такая иерархия между PO и BA на российском рынке возникла по нескольким причинам.

1️⃣ Перевод Product Owner на русский как Владелец продукта и интерпретация русскоговорящими людьми слова «владелец», как собственник, руководитель, а не как «человек, несущий ответственность».

2️⃣ На рынке «постсоветского» аутсорса (и не только, к сожалению), PO, как правило, это человек со стороны заказчика, а Заказчик — главнее.

📍 Умоляю, забудьте такие установки! Нет никого главнее, есть общая цель — сделать хороший продукт коллаборативным путем. Будем искать, кто главнее и мериться силой — закончим бурным расставанием и недовольством всех участников проекта.

3️⃣ Слабые BA, которые не хотят брать на себя ответственность и перекладывают его на «того, кто главнее», «того, кто скажет, как» и «того, кому нельзя сказать нет» (читай: поэтому я сделаю так, как он сказал, а когда в меня тыкнут, я скажу, что это он так сказал).

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

——
Поддержать канал

​​Я не могу сказать «нет» владельцу продукта. Он же владелец продукта, он главнее. (с) Часть 1.

Сегодня мы будем говорить про роли на проекте.

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

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

Но такое мнение неверное и идёт скорее из неправильного понимания роли владельца продукта, как таковой. Я бы сказала, что это скорее «особенности пост-советского рынка» и перевода Product Owner на русский.

Итак, кто такой владелец продукта согласно фреймворку, из которого роль и появилась в общей и широкой практике?

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

Что, просто стекхолдер? Ключевой, но просто стекхолдер?

Как же так вышло, что Владелец продукта стал богом, которому нельзя сказать нет? Как думаете, почему?

Порассуждаем вместе? Потом я расскажу свое мнение, в чем же причина такой иерархии, на мой взгляд, и всегда ли она такая.

И как у вас отношения с владельцем продукта? Он главнее? 💬👇

——
Поддержать канал

​​Как формировать бэклог продукта, если ресурсы ограничены? Один из подходов. Часть 2.
(48 секунд)

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

1️⃣ Выстроенная иерархия в бэклоге. В данном случае предлагалась следующая-классическая:

Epics → Features → US (как уровень бэклога, а не как формат описания)

2️⃣ Определяем, что означает каждый уровень (да, далеко не все понимают, чем эти уровни отличаются).

В рамках проекта из кейса было предложено сильно упрощённое описание, чтобы никого не путать:

Epics — ключевые сущности (объекты)) = существительные (например: Активности)

Features — действия, которые можно делать с сущностями + касающиеся сущностей = глаголы (например, Создание сущности)

US — более низкоуровневые действия неких бизнес-ролей в системе, закрывающие их потребности. (например, «Я, как менеджер проекта, хочу создать активность, заполнив необходимую информацию о ней, чтобы в дальнейшем оперировать этой активностью в системе в рамках её жизненного цикла.»)

Важные комментарии в отношении US, которые мы давали:

1️⃣ Наша цель формирования US — посмотреть, что мы закрываем потребности бизнес-ролей в рамках выделенных фич (потребности были выявлены на этапе глубинных интервью).

2️⃣ Наши US — высокоуровневые, и для передачи их в разработку будет необходимо их уточнять, сплитить и детализировать с помощью AC уже на этапе delivery.

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

——
Поддержать канал

​​Как формировать бэклог продукта, если ресурсы ограничены? Один из подходов. Часть 1.
(20 секунд)

Недавно у меня был интересный кейс.
Дискавери на 2 месяца. Изначальная формулировка цели: будем формировать бэклог системы и выбирать продукт, который удовлетворяет нашим запросам.

По факту оказалось, что на дискавери мы будем не только бэклог описывать, но и формировать to be бизнес-процессы и методологию, а уже потом думать о встраивании системы в эти БП.

Сюрприииииз.

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

С первых же недель нашего дискавери стало понятно, что у нас не будет времени на формирование такого ТЗ.

Можно ли его написать в одного аналитика за 2 месяца? Да, можно, если сильно напрячься.

Можно ли его написать в одного аналитика за 2 месяца, если на этого же аналитика навесить плюсом выявление и отрисовку as is, формирование to be и описание методологии? Нет, нельзя.

Владелец продукта упирается, что в компании у них принято вот так.

Что бы Вы делали в такой ситуации? 💬👇

——
Поддержать канал

История про то, как знать в теории — это хорошо, но уметь перекладывать теорию на практику — необходимо.

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

Человека брали, чтобы он смоделировал бизнес-процесс As Is. Вопросы на собеседовании задавали именно на эту тему. Что такое бизнес-процесс As Is, зачем его моделируют, знаешь ли нотацию BPMN, из чего она состоит и т.д.

Человек теорию знал на 5. Радости не было предела.

Но когда человек пришёл в команду и ему сказали, что надо смоделировать As Is, он спросил: а что, нарисованного ничего нет? А я раньше так не пробовал, мне раньше всегда что-то нарисованное уже давали и я уточнял. А как с нуля?

Так родился этот гайд. Но это не просто пошаговая инструкция, КАК качественно смоделировать любой As Is бизнес-процесс, но и реальный перечень вопросов, которые нужно задать, чтобы его выявить. Всё на блюдечке с оформленной каемочкой, как обычно. Те, кто покупали предыдущие материалы, знают, что все материалы не просто ценные, но и в «корпоративном стиле» канала, чтобы визуально тоже было удобно, просто и красиво.

Успехов и пусть вас никогда не застунут врасплох интересные задачи!

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

​​Переход от As Is процесса к To Be. На что обратить внимание, чтобы не построить сферический процесс в вакууме?
(49 секунд)

Итак, вам предстоит преобразовать процесс из текущего состояния в некое состояние To Be.

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

1️⃣ Чёткое определение точки А или As Is процесса. Если неправильно определить текущее состояние или определить его на недостаточно глубоком уровне, то, вероятнее всего, хорошего to be у вас не выйдет. Как минимум потому, что будет сложно определить правильные точки и глубину изменений.

2️⃣ Кто заказчик и заинтересованные лица процесса? Достигаются ли их цели текущим процессом? + Ролевая модель в As Is процессе. (Править ролевую модель, помимо процесса, всегда крайне неприятно и болезненно. Важно понимать, придётся ли и оценивать риски. Будьте внимательны в этой части!)

3️⃣ Цель перехода от As Is к To Be. Зачем хотим поменять текущий процесс? (В идеале должен случиться некий маппинг между пунктами 2 и 3, т.е., например, хотим преобразовать процесс так, чтобы достигать целей заказчиков процесса, которые не достигаем сейчас).

4️⃣ Контекст (окружение) , в котором сейчас существует As Is процесс. Очень важно, чтобы целевой процесс в этот контекст (окружение) вписался, чтобы его можно было внедрить.

5️⃣ Правильное определение зон As Is процесса, не подлежащих изменениям по каким-то критичным причинам.

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

Что скажете? Сталкивались с проектированием to be процесса? Какие ещё вещи отнесли бы к разряду критичных при проектировании? 👇💬

——
Поддержать канал