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

2022-06-30 12:40:36 ​​CJM. Кому? Зачем? Когда?
(40 секунд)

Customer Journey Map (дословно: карта пути клиента) — очень модный и популярный артефакт, которым часто балуются и ux-дизайнеры, и ux-исследователи (если они отделены от дизайнеров), и product managers, и бизнес-аналитики, в конце концов, тоже в стороне не остаются.

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

CJM — это диаграмма или набор диаграмм, визуализирующий этапы, которые проходит пользователь при взаимодействии с компанией/сервисом.

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

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

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

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

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

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

Что в итоге отображается на классической CJM:

• Этапы пути клиента от точки N в точку M;
• Точки контакта клиента с компанией (каналы коммуникации);
• Ожидания, мотивы, эмоции от получения результата.

Как вы думаете, почему этот инструмент стал в итоге таким популярным в IT у UX-дизайнеров и Product Managers? И с какими основными сложностями/проблемами/минусами этого артефакта можно столкнуться? Открыть/Комментировать

2022-06-22 13:26:56 ​​FoMO и FoBO. Где связь с soft skills?
(48 секунд)

Давайте сегодня посмотрим на 2 ситуации:

Case 1: Вы с коллегой, который пришел в компанию примерно в одно время с вами, идете на обед. И во время обеда коллега по секрету рассказывает вам, что совсем скоро получит повышение до senior бизнес-аналитика. А вы тем временем все еще middle, и о повышении с вами никто не разговаривал. Что вы почувствуете?

Case 2: Вы давно хотите купить квартиру, пусть будет, в Турции. Подобрали хороший вариант, который устраивает вас по всем параметрам. И цена в целом очень даже хорошая. Но ситуация такова, что платеж за квартиру должен пройти в долларах, а доллар сейчас довольно не стабилен. Будет ли посещать ваc мысль: «А что если я куплю сегодня, а завтра доллар будет еще меньше? Сколько я потеряю, если так произойдет? А если послезавтра будет еще меньше? Может быть подождать еще немного?» и как эти мысли отразятся на ваших решениях?

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

FoMO (fear of missing out) — это чувство беспокойства, которое посещает вас при мысли о том, что кто-то живет лучше, интереснее, насыщеннее, чем вы.

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

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

Подвох в субъекте рефлексии. При правильной рефлексии субъектом являетесь вы и все, что связано ТОЛЬКО с вами: ваши желания, ваши действия, ваше будущее, в то время как при FoMO субъектом является кто-то другой и сравнение вас с этим другим (всегда не в вашу пользу).

FoBO (fear of better option) — это страх упустить потенциально лучшую возможность, который мешает вам принимать решения и ограничивает в действиях.

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

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

Давайте подумаем, как эти два синдрома могут влиять на вас, как на профессионала, и на ваш карьерный путь? Открыть/Комментировать

2022-05-18 12:29:32 ​​Нотация для описания доменной модели (концептуальной модели данных). Нотация Чена.
(23 секунды)

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

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

Если вам нужен более (менее) стандартизованный подход — это тоже нормально.

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

Кратко посмотрим на стандартную нотацию для описания доменных моделей (ER-диаграмм) — нотация Питера Чена.

Нотация Питера Чена является ключевой и наиболее часто используемой для описания ER-диаграмм, так как именно Питер Чен предложил саму модель сущность-связь.

Ключевые правила:

• Сущность или объект обозначают прямоугольником.

• Отношения обозначают ромбом.

• Атрибуты объектов обозначают овалом.

• Каждый атрибут может быть связан только с одной сущностью.

• Если сущность связана с отношением, то их связь обозначается прямой линией со стрелкой. Необязательная связь обозначается пунктирной линией.

Плюсы:

• Легко повысить / понизить уровень детализации (добавив / убрав атрибуты, например).

• Легко «стандартизировать» связи между объектами и, например, вынести их в легенду, оставив на диаграмме только ромбы разных цветов (уменьшает количество текста и повышает читабельность (важно: видов связей должно быть 5+-2, чтобы человек мог их запомнить)).

• Легко читается и не требует особых знаний для ее построения.

• Не содержит в себе «таблиц» (что иногда смущает и воспринимается как отсылка к реляционным БД).

Минусы:

• Может быть скептически воспринята людьми, привыкшими к диаграммам с «таблицами».

• Может быть перегружена элементами, что усложнит чтение диаграммы (за счет того, что все элементы отображаются фигурами).

• Может выглядеть слишком «мультяшно», если увлечься. Открыть/Комментировать

2022-04-20 10:30:22 ​​Доменная модель. Что это такое и зачем?
(18 секунд)

Сталкивались ли вы с тем, что членам команды разработки не хватает «контекста»? Вроде бы четко прописано, что делать, но вот понимания полного нет?

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

Конечно, можно воспользоваться и простым текстовым описанием или ссылочкой на статью / видео о домене в Google, но, во-первых, какой программист любит читать?) А во-вторых, всегда лучше иметь под рукой один артефакт, покрывающий все необходимые области знания о домене.

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

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

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

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

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

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

Что важно?

1. Четко определить цель построения доменной модели.

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

3. Выбрать нотацию (определить легенду для модели) и поставить себе рамки построения модели.

Дальше посмотрим на нотации, которые применяются для построения доменных моделей и обсудим их преимущества и недостатки. Открыть/Комментировать

2022-03-30 10:52:55 ​​Внутренние и внешние user story. Что это такое и зачем?
(21 секунда)

На своем личном опыте я ни раз сталкивалась с тем, что User Story часто интерпретируют как короткую формулировку намерения пользователя (описываемую с точки зрения конечного пользователя) и того, что продукт должен сделать для него.

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

На некоторых проектах я видела, как подобные «технические» задачи пытаются впихнуть в user story для конечных пользователей для того, чтобы не светить их заказчику и не провоцировать его на вопросы.

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

К чему мы приходим?

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

Поэтому имеет смысл разделить US на две условные группы:

• Внутренние (невидимые для конечного пользователя)
• Внешние (видимые для конечного пользователя, как правило, именно их мы пишем от лица конечного пользователя)

Пример внешней, привычной нам US:

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

Пример внутренней US:

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

Давайте обсудим:

Считаете ли вы правильным и необходимым формулирование внутренних US или и без них хорошо живется? Открыть/Комментировать

2022-03-23 10:18:00 ​​Вопросы клиенту. Могут ли вопросы показать вашу квалификацию?
(18 секунд)

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

Сегодня будем говорить о кейсе из реальной жизни.

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

Первая фаза — Discovery.

Собираемся командой, делим между собой устройства и формируем список вопросов, на которые нам нужно найти ответы в рамках Discovery.

Какой следующий шаг?

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

Примеры вопросов:

• Для чего нужно это устройство?
• Какое business value оно приносит покупателям?
• В каких отраслях используется?

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

У меня ушло 5 минут, чтобы найти информацию об устройствах на официальном сайте заказчика. Еще 1 час, чтобы ее просмотреть, проанализировать и сформировать ответы на базовые вопросы + отметить отдельные вещи, которые являются моими предположениями и на которые нужен дополнительный конферм.

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

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

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

2022-03-16 10:23:23 ​​Определение контекста и границ для задачи. Пример.
(27 секунд)

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

Сначала определяем контекст:

Что?

• Отчет о том, что команда сделала в этом спринте.

Для кого (хотя бы потенциально)?

• Для руководителя, для менеджмента со стороны заказчика;

• Означает, что низкоуровневые вещи и детали, скорее всего, их не интересуют.

Зачем?

• Руководитель: чтобы менеджить velocity команды;

• Mенеджмент со стороны заказчика: чтобы увидеть, какая часть от общего скоупа еще НЕ выполнена и оценить, сколько еще нужно будет заплатить денег.

Какие ожидания от результата?

• Руководитель: из отчета легко поймет, упала ли velocity в этом спринте и нужно ли ему предпринимать действия;

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

Где я могу взять необходимую информацию?

• Посмотреть в JIRA;

• Спросить у каждого разработчика, сколько задач он закрыл за этот и предыдущий спринт.

Как я могу это сделать?

• Рассказать на словах;
• Показать в JIRA;
• Отправить письмо с текстовым описанием;
• Найти темплейт для такого репорта и заполнить его;
• Создать темплейт для такого репорта и заполнить его.

Границы:

• Буду делать репорт только для своего руководителя и удовлетворяющий только его целям (потому что он меня попросил, общаться с заказчиком – это его задача, а не моя, и карьерный рост меня не интересует). Следовательно, мне надо просто сравнить velocity команды в этом и в нескольких предыдущих спринтах;

• На проекте есть трекинговая система и ее поддерживают в актуальном состоянии. Следовательно, я могу использовать ее и не тратить время разработчиков;

• Сделаю скрины из JIRA, потому что видела, что там есть такая информация в стандартных отчетах JIRA и отправлю письмом (потому что темплейта внутри компании для такого репорта нет, а сама я сделать не могу/не хочу; голосом не получится, потому что у руководителя в расписании нет времени на созвон).

Видите ценность определения контекста и границ? Что будет, если я их не определю с самого начала для этого конкретного примера?

• Начну распыляться, включу в отчет ненужную информацию и не включу нужную;

• Не попаду в уровень детализации информации и сделаю отчет на 100 страниц с детальным описанием задач и скоупа;

• Не попаду в ожидания руководителя с форматом отчета;

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

Вывод: ВСЕГДА необходимо думать о контексте и определять границы, чтобы качество вашей работы удовлетворяло принимающую сторону и совпадало с ожиданиями заинтересованных сторон. Открыть/Комментировать

2022-03-10 11:38:10 ​​Контекст и его важность. Границы.
(22 секунды)

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

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

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

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

Что такое контекст и границы?

Контекст — это ситуация, окружение или набор условий, фактов и обстоятельств, в окружении которых происходит событие или существует какое-то явление/объект.

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

Как определять контекст и границы?

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

Контекст:

1. Что нужно сделать?
2. Для кого вы это делаете? Что это означает?
3. Зачем ему это и какую цель он преследует? (каждому из для кого)
4. Какие ожидания от результата? Каким должен быть результат? (каждому из для кого)
5. Как вы можете это сделать? (ресурсы, подходы, артефакты)

Границы:

• Что из пунктов выше вы действительно можете/должны/собираетесь покрыть своим решением, когда сделаете задачу?

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

А пока расскажите, думаете о контексте и границах, когда делаете какую-то задачу или сразу начинаете делать? Открыть/Комментировать

2022-02-02 11:32:58 ​​Работать надо качественно. В чем ошибка?
(31 секунда)

У меня всегда была установка «Работать надо качественно!». Но действительно ли «качественно» — это некий абсолют?

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

Ответ оказался прост. Но дошел до меня спустя более 5 лет опыта.

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

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

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

Давайте на примере разбирать.

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

Что я могу сделать?

1. Поговорить с ним, объяснить, в чем проблема, и предложить потенциальное решение. Например, предложить согласовывать план митингов, чтобы друг другу не мешать.

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

Риски: ухудшатся отношения с менеджером.

3. Пункт 2 не сработал, и руководство менеджера оказалось противным и ничего делать не собирается. Я могу сменить проект. Риски: поиск нового проекта может затянуться, и я буду сидеть на бенче.

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

5. Пункт 4 не сработал, потому что открытых вакансий сейчас мало и мне ничего не подошло.

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

Дальше вопрос только в том, как можно постараться нивелировать последствия такого ограничения.

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