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

2022-01-12 11:57:50 Reporting. Письменная отчетность о результатах работы команды. Пример отчета «Release Notes».
(25 секунд)

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

Итак, небольшое напоминание о самом репорте:

1. Goal: to inform key stakeholders about new features on UAT and request their feedback

2. Report name: UAT Stage News MM dd, yy; ex: UAT Stage News Dec 13,2021

3. Format: e-mail with confidential restrictions

4. Frequency: each two weeks (after deploying new release version to UAT)

5. Audience:
• High-level stakeholders (are interested just in product progress)
• Several end-users (wants to know what new features appeared)
• Internal project team (to keep them in context)

6. Content:
• New features in release (short description, screenshot, important details) — not more then 3
• Additional small improvements in release (short statements)
• Expectations for future release (short most important statements)
• Request for feedback to new features

7. Style: Formal/Semi-formal English

8. Accountable/Responsible: BA Lead/Any BA

9. Notes: Mandatory approving with BA Lead

В прикрепленном файле вы найдете пример подобного репорта, конечно, не из реальной практики. В качестве системы для примера я взяла всем знакомый Telegram и давайте посмотрим, как мог бы выглядеть подобный репорт для одного из релизов.

Буда рада обсудить подобные типы репортов: нужны ли они и на сколько сложно, на ваш взгляд, их составлять? Может быть что-то лишнее или чего-то не хватает в таком типе репорта?

P.S. у Telegram есть канал Telegram Tips, в который питчат новые фичи с описанием и мини-видео инструкциями. Если собрать в письмо их описания и немного докрутить, то можно представить отличный репорт. У них получается очень классно. Советую обратить внимание и взять для себя на заметку, что так тоже можно и нужно делать. Открыть/Комментировать

2021-12-15 12:23:27 ​​Reporting. Письменная отчетность о результатах работы команды. Чек-лист планирования.
(63 секунды)

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

На своем опыте я обычно делю репортинг на 2 части: демонстрация результатов команды заказчику и отчет о работе бизнес-аналитика (BA команды).

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

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

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

Итак, отчетность кастомеру сразу поделим еще на две категории: устная и письменная.

Устная — это митинги / личные встречи / on-site работа.

Письменная — это репорты в стандартизованном виде документов, которые каким-то образом отправляются заказчику (например, отправляем e-mails или выкладываем на Confluence).

У каждой категории есть свои особенности. Начнем с письменной отчетности.

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

1. Прояснить цель / цели отчетности.

Например: информировать ключевых стейкхолдеров о новых фичах на UAT и запрашивать фидбэк на них.

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

Например: patch notese-mail / 1 раз в спринт после нового релиза на UAT / основные получатели: Иванов И.И, Смирнов Т.Т. со стороны заказчика; в копию письма: внутренняя команда проекта.

3. Определить контент каждого репорта и уровень детализации.

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

4. Также определите стиль написания отчета.

Как правило, письменная отчетность требует более формального стиля написания, но уровень формальности — индивидуальный для каждого отчета).

5. Определить дополнительные запросы к получателям, если необходимо.

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

6. Не забыть добавить отметки о конфиденциальности, если это необходимо.

7. Подготовить темплейт отчета, если есть такая возможность.

8. Определить необходимость внутреннего согласования отчета в команде, и если необходимо согласовании, то с кем именно, например, с BA Lead или PM.

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

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

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

Теперь ваша очередь: пишете отчеты о результатах работы команды? В каком виде? Открыть/Комментировать

2021-12-08 10:52:18 ​​Сегодня у нас будет первая попытка новой рубрики на канале: «Книги в цитатах».
(39 секунд)

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

Как всегда я буду рада обсудить с вами цитаты в комментариях.

Первая книга: «Твоя бизнес-модель. Системный подход к построению карьеры.» Александр Остервальдер и Ив Пиньё.

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

«По­де­ли­те лист А4 на сле­ду­ю­щие блоки:
- Что вы из себя пред­став­ля­е­те и чем об­ла­да­е­те.
- Чем вы за­ни­ма­е­тесь (ос­нов­ные виды вашей де­я­тель­но­сти).
- Что вы де­ла­е­те для людей в раз­лич­ных на­прав­ле­ни­ях вашей де­я­тель­но­сти?
- Кому имен­но по­лез­но то, что вы де­ла­е­те?
- Каким об­ра­зом вы об­ща­е­тесь с лю­дь­ми и как до­но­си­те до них свою цен­ность?
- Ваши до­хо­ды.
- Ваши траты.»

«Ваша ре­аль­ность должна стро­ить­ся на стыке того, что вам нра­вит­ся, и того, что несет цен­ность для дру­гих.»

«Редко кому уда­ет­ся к взрос­ло­му воз­рас­ту со­хра­нить неза­ви­си­мость мыш­ле­ния — обыч­но че­ло­век на­столь­ко об­рас­та­ет на­вя­зан­ны­ми ему шаб­ло­на­ми и сте­рео­ти­па­ми, что уже и не пом­нит, что из себя пред­став­ля­ет по своей сути. В боль­шин­стве слу­ча­ев мы ре­а­ли­зо­вы­ва­ем не свои, а чужие на­деж­ды.»

«Наи­боль­шее сча­стье и удо­вле­тво­рен­ность че­ло­век ощу­ща­ет тогда, когда пе­ре­се­ка­ют­ся его ин­те­ре­сы, осо­бен­но­сти лич­но­сти и спо­соб­но­сти (врож­ден­ные или при­об­ре­тен­ные)»

«В жизни надо на­учить­ся не пы­тать­ся в еди­ный мо­мент по­лу­чить от­ве­ты на все во­про­сы. Обыч­но от­ве­ты при­хо­дят до­зи­ро­ва­но, не «оптом».»

«Сей­час на смену по­ня­тию «пла­ни­ро­ва­ние» при­хо­дит по­ня­тие «мо­де­ли­ро­ва­ние». То есть, свою жизнь в целом и ка­рье­ру в част­но­сти можно смо­де­ли­ро­вать.» Открыть/Комментировать

2021-11-17 11:09:57 ​​Рост, как навязчивая идея. Хороший soft skill или серьёзная проблема? Часть 2.
(27 секунд)

Конечно, как бизнес-аналитики, мы не делаем выводов по одному вопросу, а начинаем выяснять суть: «Расскажите, пожалуйста, почему вы хотите расти в Project Management?»

В процессе диалога выяснилось две интересные вещи:

1. Кандидат «перепутал» Project Manager и Product Manager;
2. Кандидат не понимает, почему хочет ни в Project, ни в Product Management.

Честно говоря, обе эти вещи крайне негативно повлияли на моё восприятие кандидата.

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

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

Очень хочется, чтобы вы понимали, что желание развиваться — это не про стремление к какой-то роли, которую почему-то считают «выше и важнее» (спойлер: project manager не выше бизнес-аналитика, да и product manager тоже не выше; у этих ролей просто разные векторы внимания и зоны ответственности на проекте). Точки развития — это всегда сначала анализ: зачем и в чем будет ценность, постановка краткосрочных и долгосрочных целей, поиск путей и только после всего предыдущего: действия в направлении целей.

Рост ради роста — плохая идея, которая не принесёт вам абсолютно никакого удовлетворения и не поможет вам в развитии, потому что:

«— Скажите, пожалуйста, куда мне отсюда идти?
— А куда ты хочешь попасть? — ответил Кот.
— Мне все равно — сказала Алиса.
— Тогда все равно, куда и идти, — заметил Кот.
— Только бы попасть куда-нибудь, — пояснила Алиса.
— Куда-нибудь ты обязательно попадешь, — сказал Кот.
— Нужно только достаточно долго идти.» (с)

Хотите показать свою заинтересованность в развитии на интервью? Лучше задайте вопрос про наличие ментора и возможную помощь в составлении PDP (personal development plan), если у вас его ещё нет. Открыть/Комментировать

2021-11-03 14:49:57 ​​Рост, как навязчивая идея. Хороший soft skill или серьезная проблема? Часть 1.
(20 секунд)

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

Немного вводной информации о кандидате и интервью, чтобы вы понимали общий контекст:

Кандидат с опытом работы около года собеседуется на позицию Junior BA в крупную международную IT компанию. Высшее образование с IT не связано и в целом нарабатывал все знания в основном практическим путем, случайно попав в предыдущую компанию на позицию BA. Практический опыт соответствует позиции Junior BA, теоретические знания крайне слабые.

В конце интервью по классике – серия вопросов от кандидата, и вот я слышу: «Расскажите, а как быстро я смогу вырасти в Project Manager и перейти на эту роль?»

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

Как бы вы отреагировали, расценили этот вопрос и что ответили кандидату?

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

Поэтому с опозданием, но я все-таки поздравляю нас всех с Global Business Analyst Day (1 ноября) и хочу пожелать нам двух, на мой взгляд, самых важных вещей: чтобы разработчики читали требования и чтобы была возможность спокойно выпить кофе! А со всем остальным мы с вами точно справимся! Горжусь вами и вашим желанием не погрязнуть в рутине работы, продолжая развиваться и обсуждать наши аналитические темы! Открыть/Комментировать

2021-10-27 10:48:12 ​​Описание требований в формате Use Case Scenario. Где подводные камни на практике?
(32 секунды)

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

Итак, маленькая предыстория:

На одном из проектов у Project Manager была амбициозная и изначально провальная (но учит этому только собственный опыт, к сожалению) цель: собрать настоящую самоорганизованную и высоквалифицированную скрам команду. Меня на этот проект брали на не менее амбициозную роль — Product Owner/Product Manager.

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

PO пишет требования в формате use case scenarios без привязки к конкретному UI системы.

Дальше скрам команда самостоятельно решает, как разбить этот сценарий на таски для имплементации.

Основное — каждый use case несет конкретное и понятное business value, а процесс и порядок имплементации сценария никого особо не интересует. Главное, чтобы в итоге его можно было весь пройти.

Звучит классно? О, да.

Что имеем по факту?

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

2. Команда не хочет читать много текста и разбираться в нем. Это сложно.

3. Команда не понимает, как бить сценарий на части для имплементации и пытается съесть слона целиком, что может занимать довольно продолжительное время и не один спринт.

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

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

6. Интерфейсы (макеты) — как необходимый и обязательный элемент для имплементации, иначе – ступор и истерика.

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

Но есть и определенные ситуации, где use cases, описанные в виде e2e scenarios работают хорошо:

1. Как входная информация для UX-дизайнеров. Очень классно заходит, потому что дает четкое понимание бизнес-ценности и полного сценария, а UI и UI user flow уже будут предоставлены UX-дизайнером.

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

Расскажите, был опыт описания в таком формате? На сколько легко было работать команде с таким представлением информации? Открыть/Комментировать

2021-10-20 12:02:54 ​​Взаимодействие бизнес-аналитика и UX-дизайнера. Где границы?
(12 секунд)

Командная работа — один из основополагающих концептов любой современной IT компании и, одновременно, один из главных поводов недопониманий внутри коллектива.

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

80% бизнес-аналитиков (с опытом работы от 5 лет) хотя бы однажды, но приходилось заниматься прототипированием или моделированием макетов.

90% бизнес-аналитиков, перечисляя инструменты, которыми владеют, упоминают Figma, Balsamiq, Axure RP.

Хорошо ли это? Конечно!

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

Я подготовила для вас иллюстрацию, чтобы рассказать о своем видении взаимодействия BA и UX-дизайнера на проекте. За основу взяла idef0, но если вдруг кто-то с ней не знаком – оставила маленькую подсказку в левом верхнем углу.

Готова пообсуждать ее с вами, если что-то непонятно или хочется выяснить.

Расскажите, как у вас настроено взаимодействие? И есть ли у вас вообще UX-дизайнер на проекте или бизнес-аналитик может все? Открыть/Комментировать

2021-09-22 11:59:37 ​​Синдром самозванца. Хорошо или плохо?
(15 секунд)

Этот пост не был запланирован, но очень хочется обсудить с вами эту тему. Синдром самозванца.

Чувство незаслуженности успеха, вызванное неуверенностью в своих силах и навыках - так называемый, синдром самозванца. По статистике, 70% людей однажды точно с ним сталкивались.

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

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

1. Hard skills (неуверенность в них ведёт к излишней сосредоточенности и страху допустить ошибку, что приводит к нежеланию брать на себя сложные задачи и ответственность за решения)

2. Soft skills (страх развития и постоянный поиск в себе проблем и недостатков, безусловно, влияют на качество коммуникации, на самоощущение себя в коллективе и, конечно, на моральное состояние)

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

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

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

Знаком ли вам синдром самозванца? Как справляетесь и выходите из этого состояния? Открыть/Комментировать

2021-09-08 14:53:59 ​​Декомпозиция/слайсинг фичи. Часть 3.
(20 секунд)

«Подходы»

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

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

•Горизонтальный

•Вертикальный

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

Что это значит? Это значит, что вы работаете в waterfall подходе, слайся фичу не исходя из ценности для конечного пользователя, а исходя из этапов которые фича должна пройти: анализ, бэкенд разработка, фронтенд разработка, тестирование.

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

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

•Необходимость соответсвия скоупа реальному решению

•Уменьшение скоупа, сложности или усилий на реализацию с помощью слайсинга

•Независимость разработки фич и разработки дизайна для удобства работы разных специалистов

•Возможность использования разных инструментов

•Ограничение работы, которая сейчас в прогрессе у команды

Расскажите, какие цели вы преследуете на своих проектах при помощи слайсинга? Открыть/Комментировать

2021-08-11 15:08:51 ​​Коммуникация со стейкхолдерами. Почему важно уметь располагать к себе людей? Первый лайфхак по общению со сложными стейкхолдерами.
(18 секунд)

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

Project Manager был в шоке, страдал и падал в обморок от каждого контакта с ним, и в конце концов пришел ко мне со словами: “Твоя задача найти с ним контакт и расположить его к себе.”.

Первое правило общения со всеми важными людьми: человек должен видеть перед собой человека. Не картинку, не фотографию, не презентацию, а человека. Живого. Эмоционального. Реагирующего.

Это базовая психология. Человеку всегда легче грубить, возмущаться и негативно реагировать на того, кого он не видит лично и не знает.

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

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

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

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

Какие у вас лайфхаки к поиску подхода к сложным стейкхолдерам? Открыть/Комментировать