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

​​Интеграционные сценарии. Что такое и при чем тут аналитик?
(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

Ценность функционала. Почему о ней важно говорить и писать в постановках на разработку?
(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 процесса? Какие ещё вещи отнесли бы к разряду критичных при проектировании? 👇💬

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

​​«Иногда команде нужен психолог, а потом уже бизнес-аналитик.» История из практики.
(52 секунды)

Итак, что же произошло, когда задали вопрос «Расскажите, шаг за шагом, как в последний раз вы осуществляли процесс N.»?

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

Идея 1.

«Классика» автоматизация хаоса даёт автоматизированный хаос." Очень грамотный комментарий! Действительно, очень часто принято во всем винить отсутствие автоматизации. «Вот была бы у нас система, вот тогда бы все заработало!» Спойлер, нет, не заработает, если проблемы сильно глубже.

Идея 2.

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

Идея 3.

«У них наверно за все отвечает один человек, а остальные работают. В итоге понимание как должно быть и как есть не сходится.» / «Я понял, они час спорили с ПМ как оно работает на самом деле.» Очень похожие по смыслу комментарии. Я бы даже вынесла это в отдельный тип проблем с условным названием «на бумаге/у руководства процесс X, а у выполняющих рук процесс Y». Чаще всего это даже не связано с «отсутствием процессов», потому что на бумаге-то обычно процесс есть и весьма понятный, а с некорректным внедрением процесса в команду, если его никто не выполняет.


Ну и очень близкие к правде ответы:

«Тот кого спросили рыдал 30 минут?»/ «Человек матерился и плакал, что процесса нет и он страдает каждый раз?»

На самом деле причин того, что мы выпали из скрипта несколько:

1️⃣ Люди не готовы были разложить свои действия на последовательные шаги, потому что для них весь процесс был «кашей».

2️⃣ У людей действительно сильно «болело», и вместо того, чтобы говорить о самих шагах и последовательности, они сразу же уходили глубоко в проблемы, смешанные с негативными эмоциями, которые изливались непрерывным потоком и не поддавались модерации, пока человек не выскажется полностью.

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

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

​​«Иногда команде нужен психолог, а потом уже бизнес-аналитик.» История из практики.
(28 секунд)

Случился тут один проект в большооооой компании с долгой-долгой историей. Хотели ребята систему себе разработать. Пришли в одну аутсорс компанию и попросили себе бизнес-аналитика.

Бизнес-аналитика им дали. Хорошего бизнес-аналитика. Они со своей стороны на проект даже Product Manager выделили. Хорошего PM, кстати, что редкость.

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

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

Драфт CJM набросали, скрипт глубинного интервью спроектировали.

Собрались на интервью.

Задали на интервью первый вопрос, и выпали из цели и скрипта на 30 минут.

Знаете, каким был вопрос?

«Расскажите, шаг за шагом, как в последний раз вы осуществляли процесс N.»

Как думаете, почему выпали из скрипта?👇💬

​​Почему у кого-то получается, а у кого-то нет? Истории "жизненного" анализа.
(58 секунд)

Почему у кого-то получается, а у кого-то нет? Задавались ли вы когда-нибудь этим вопросом?

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

А тут вдруг вчера она у меня спрашивает, кем я работаю. Я по привычке начинаю объяснять простыми словами, а она мне говорит: «да вы не объясняйте, я знаю, кто это. У меня образование «IT в бизнесе» в Политехе» (кто не знает, Политех — это очень серьёзный университет в Санкт-Петербурге).

Выяснили, что учили её внедрять SAP на предприятия, а закончила она его ещё в 2013 и никогда по специальности не работала.

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

Аналитик вошел в чат и решил покапать вглубь. Вспомнила технику 5 почему, чтобы разобраться, почему же не случилось у человека дружбы с IT.

Диалог дословно (5 почему?):

— Почему вы не пошли работать по специальности?

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

— А почему не пошли на стажировки?

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

— Ладно, а почему не стали что-то смежное смотреть, куда было легче без опыта попасть? Может быть через тех.поддержку?

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

— Т.е. вы просто не стали искать других вариантов входа? Почему?

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

Бинго! 5 почему в реальной жизни. Не получилось, потому что и не хотелось никогда!

Как Вам история? 💬👇

P.s. в конце концов девушка сказала, что она бы сейчас хотела быть в IT. Догадываетесь почему?

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