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

2022-09-01 09:30:07 ​​«Разрастание» требований. Что это такое и что с этим делать?
(20 секунд)

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

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

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

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

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

Управляйте разрастанием требований: постарайтесь смапить новые/измененные требования на бизнес-цели проекта, ограничения, стратегию и критерии успеха. Если вы не можете найти, к чему привязать данное требование, то скорее всего оно будет «out of scope» в текущей ситуации. Стратегия работы с такими требованиями, которые не попадают в текущий скоуп, должна быть спланирована и заапрувлена менеджером проекта и стороной заказчика.

Если же на предыдущем этапе маппинг случился, то постарайтесь оценить, как новая информация повлияет на различные параметры проекта: на сколько вырос скоуп (можно в процентах), на сколько это отразится на сроках + попросите помощь у менеджера, чтобы оценить импакт на бюджет.

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

Что делаете вы в подобных ситуациях, если сталкивались с ними? Открыть/Комментировать

2022-08-25 09:28:02 ​​Ключевые отличия в сборе требований к существующей и к новой системе.
(16 секунд)

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

Давайте в комментариях подумаем, зачем нам вообще собирать требования к существующей системе? В каких ситуациях нам придётся это делать?

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

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

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

Возможность анализировать реализованные интерфейсы и взаимодействия пользователей с системой в реальном времени. Тут, думаю, и расшифровывать нечего.

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

На сколько мой «топ» различий совпадает с Вашим? Открыть/Комментировать

2022-08-17 11:27:07 ​​Что делать, если выстроенных процессов на проекте нет и не предвидится или процессы не работают?
(58 секунд)

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

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

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

Если менеджер проекта вас не слышит или не воспринимает, возможных выходов у вас 3: пытаться налаживать процессы в обход менеджера (идея заведомо провальная в 99% случаев), смириться и временно не вмешиваться, выжидая момент, или же менять проект.

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

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

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

Помните: никто не любит, когда тыкают пальцем в них, поэтому тыкайте в себя.

Например, «Я заметила, что в конце почти каждого спринта, когда команда уже почти закончила работать над задачами, у нас случаются срочные изменения требований. Иногда они значительные, иногда нет. Меня беспокоит, что мы вынуждены в конце спринта резко менять требования в процессе их реализации. Я не успеваю их правильно обработать и достаточно провалидировать в условиях экстренной ситуации, это может повлечь за собой вот такие риски: ... . Может быть я попробую описать процесс запроса на изменения требований, в котором мне было бы комфортно работать и мы обсудим его с тобой, внутри команды и с заказчиком?»

Обратите внимание, что в данной ситуации, вероятнее всего, больше всего импакта случается на команду разработки (которая в быстром темпе должна переделывать свою работу, чтобы успеть до конца спринта/демо и не разочаровать заказчика) и на взаимоотношения команды и заказчика, (команда раздражается необходимости экстренных переделок, а заказчик все равно на демо недоволен, потому что в сжатые сроки качество оставляет желать лучшего), но говорить о своих предложениях мы все равно будем стараться из позиции «на МЕНЯ и МОЙ результат это влияет плохо», если хотим сохранить хорошие взаимоотношения.

Расскажите, считаете ли вы процессы на вашем проекте идеальными? Почему?
Пытались ли вы влиять на их качество? Получалось? Открыть/Комментировать

2022-08-03 10:36:23 ​​Анализ влияния изменений. Кто делает и зачем?
(48 секунд)

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

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

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

Итак, алгоритм действий для бизнес-аналитика, если пришел менеджер проекта с запросом на изменение требований:

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

2. Если ответ на предыдущий вопрос: «Проанализировал», уточните, где это зафиксировано и в каком виде. (Спойлер: «у меня в голове» — не подходит. Если нигде не зафиксировано, предложите свою помощь в том, чтобы это зафиксировать, заодно — продемонстрируете свою квалификацию и заслужите уважение и доверие.)

3. Если на пункт 1 менеджер говорит, что он «не успел» проанализировать/зафиксировать или ожидал это от вас, то вам и карты в руки. Необходимо определить все артефакты, которые нужно будет поправить в соответствии с потенциально измененными требованиями.

4. После того, как вы определили на что и как повлияет изменение требований, СРАЗУ подготовьте хотя бы верхнеуровнево задачи на команду, которые вам понадобятся, чтобы эти изменения внести. Таким образом, при необходимости, можно будет легко их проэстимировать (хотя бы high level) и оценить потенциальный объем работ.

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

Note 2: У Вигерса есть список вопросов, ответы на которые необходимо найти, чтобы правильно обработать потенциальные изменения и оценить их влияние. Настоятельно рекомендую, если сталкиваетесь с такой задачей на практике в первый раз.

У вас был опыт анализа влияния потенциальных изменений? Какие инструменты и артефакты используете чаще всего? Открыть/Комментировать

2022-08-02 11:46:19 ​​Анализ влияния изменений. Кто делает и зачем?

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

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

Как вы считаете, такой подход имеет место быть? Открыть/Комментировать

2022-07-28 11:54:28 ​​Доменный эксперт (SME, эксперт предметной области) = бизнес-аналитик. Так ли это?
(72 секунды)

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

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

Кстати, а как на счет того, чтобы поучаствовать в проекте из медицинского домена? Пойдете на 7 лет поучиться в медицинский, а потом еще на пару лет поработать в больнице врачом, чтобы точно понимать, какие проблемы врачей будем решать системой?

Кажется, мое мнение становится слишком очевидно.

Безусловно, это очень здорово, если вы пришли бизнес-аналитиком в медицинский домен после 7 лет в мед институте. Это ваше преимущество. Но сколько таких медиков, ставших BA в IT? А сколько IT проектов для медицинской сферы? И сколько бизнес-аналитиков требуется на все проекты, и где ж их взять, чтобы все были доменными экспертами?

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

Можно ли стать доменным экспертом, если проработать много лет бизнес-аналитиком в одном домене? Зависит от того, что понимать под экспертом предметной области (границы предметной области на разных проектах в одном домене могут сильно отличаться).

Мне нравится следующее определение SME: «Subject-matter expert (SME) — как правило, это сотрудники с глубоким пониманием определенных бизнес-функций или операций, зачастую с многолетним опытом непосредственного в них участия.»

Исходя из определения выше: может ли бизнес-аналитик стать SME? Частично — может быть, достаточно ли качественно — большой вопрос, не имея практического опыта.

Вопрос в другом: зачем бизнес-аналитику становиться SME? В чем ценность? И точно ли это необходимо и выгодно?

Итак, подведем итог моего мнения:

1. Совмещать роли SME и бизнес-аналитика можно, если вы действительно имеете достаточную квалификацию для обеих ролей.

2. Абсолютно не нужно быть изначально SME в конкретной области, чтобы успешно принимать участие в проектах в роли бизнес-аналитика.

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

4. Чтобы участвовать в ЛЮБОМ проекте в роли бизнес-аналитика, нужно знать техники и инструменты (спойлер: в том числе с помощью найденного SME или без него), которые позволят вам погрузиться в ЛЮБУЮ предметную область на достаточном для успешного ведения проекта уровне. Время и усилия, которые вам для этого потребуются, будут зависеть от множества факторов, и это нормально.

Что думаете? Готовы обсудить в комментариях и поделиться своим мнением? Открыть/Комментировать

2022-07-27 13:07:14 ​​Доменный эксперт (SME, эксперт предметной области) = бизнес-аналитик. Так ли это?

Прежде чем я поделюсь своим мнением, хочу посмотреть на ваше.

Согласны ли вы со следующим выражением:

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

2022-07-21 15:06:31 BA GIRL | Бизнес-аналитик в IT pinned «​​Коллеги, сегодня я к вам с новостями. У меня появилось немного свободного времени, и я готова брать на персональные консультации новых людей. Несколько важных моментов: 1. Помните: чем чётче запрос — тем больше ценности от консультации вы получите. …» Открыть/Комментировать

2022-07-21 15:06:23 ​​CJM и профиль персоны для продукта, которого нет. Имеет ли смысл?
(28 секунд)

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

Ответ на этот вопрос начну с профиля персоны.

Во-первых, разрабатывать новый продукт или сервис без понимания персоны — очень плохая и неграмотная идея. Разработка нового продукта имеет смысл только тогда, когда вы четко понимаете ДЛЯ КОГО вы его делаете и КАКИЕ ПРОБЛЕМЫ он будет решать у этого КОГО.

Обратите внимание, что match между ДЛЯ КОГО и ЕГО ПРОБЛЕМАМИ должен произойти обязательно, потому что очень часто этой параллели не проводят, и в итоге оказывается, что у выбранной target персоны указанных проблем и вовсе нет.

Дальше смотрим на CJM, и вспоминаем про моделирование процессов. В моделировании процессов у нас фигурируют два термина: AS IS и TO BE. То же, в целом, применимо и к моделированию CJM. В случае нового продукта, который еще не выведен на рынок, AS IS быть не может, и мы моделируем ожидаемое TO BE.

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

Единственное, на мой взгляд, очень важно не заменять, например, проектирование потока ценности для потенциального клиента и Value Proposition одной только Customer Journey Map. Все-таки цели у этих артефактов значительно отличаются.

То есть опять же: необходимо четко определять и понимать, ЗАЧЕМ вы моделируете CJM и как будете его использовать. Только тогда можно сказать, тот ли инструмент вы выбираете и удовлетворяет ли он вашим целям. Открыть/Комментировать

2022-07-13 12:02:30 ​​Коллеги, сегодня я к вам с новостями.

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

Несколько важных моментов:

1. Помните: чем чётче запрос — тем больше ценности от консультации вы получите.

2. В описании форматов вы увидите время, которое мы проведем с вами непосредственно на встрече (онлайн или оффлайн (Санкт-Петербург)), но это не означает, что мы не общаемся до и после консультации.

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

Расскажу немного о возможных форматах:

1. Постановка целей и план развития (1-1,5 часа встречи)

2. Q&A session (1 час встречи)

3. Психологическая поддержка и анализ сложностей (1-1,5 часа встречи)

4. Разбор резюме и подготовка к собеседованию (1 час встречи)

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

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

Контакт: @anastasiia255

P.s. разумеется, это никак не влияет на канал, и я продолжу делиться полезными материалами и информацией. Открыть/Комментировать