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

2021-08-06 10:47:24 BA GIRL | Бизнес-аналитик в IT pinned a photo Открыть/Комментировать

2021-08-06 10:46:58 2 Days Offer для бизнес-аналитиков

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

Пройдите два коротких интервью в один день и получите оффер от X5 Group. 34 продукта, 123 проекта, 324 IT-системы на поддержке — в компанию входят все «Пятерочки», «Перекрестки», «Карусели» и «Чижики» страны.

Отправьте заявку до 12 августа, а лучше — прямо сейчас https://your.gms.tech/v/l12KpiW4 Открыть/Комментировать

2021-08-04 11:28:35 ​​Почему важно видеть полную картину системы, а не концентрироваться только на отдельных фичах?
(28 секунд)

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

«Почему никому, кроме бизнес-аналитика, не интересно знать полную информацию о системе и понимать всю функциональность? А главное: как заинтересовать команду в продукте, который делаем?»

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

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

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

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

3. Команда не хочет думать.

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

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

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

За эти полгода были испробованы разные техники и подходы, чтобы поделиться знаниями с командой: 3 раза изменили формат описания требований (в надежде, что ребята начнут читать), рисовали mind maps и полные user flow с мокапами системы, проводили митинги с рассказами о персонах, их потребностях и use cases, проектировали value canvas и делали митинги ревью/демо.

Стало ли понимание проекта у команды лучше? Нет, я бы не сказала.

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

2021-06-30 10:54:25 ​​Декомпозиция/слайсинг фичи. Часть 2.
(27 секунд)

«Зачем слайсить фичу?»

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

Итак, ответ на этот вопрос идет к нам из понимания классических принципов Agile.
Попробуйте сейчас вспомнить цель Agile команды. Вспомнили? (если нет, пора перечитать Manifesto for Agile Software Development)

Цель Agile команды — это доставить максимально возможную ценность с наименьшими затратами.

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

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

Возникает вопрос: как успеть разработать фичу, чтобы уложиться в две недели итерации?

Ответ: послайсить фичу.

Обратите внимание на ключевой момент, о котором часто забывают: доставить ЦЕННОСТЬ.
Именно поэтому при слайсинге важно помнить и валидировать уровень декомпозиции вопросом: а несет ли это ценность?

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

Если ответ «Нет», то здесь уже начинается trade-off (торг/поиск компромисса) между удобством разработки и необходимостью принести ценность. Открыть/Комментировать

2021-06-23 10:53:04 ​​Декомпозиция/Слайсинг фичи. Часть 1.
(38 секунд)

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

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

• А почему вот это мы слайсим, а это нет?

• А почему мы не можем вот так декомпозировать, так же меньше получается?

• А зачем нам тратить на это время команды, ты что, сама не можешь?

• А ты пойдешь потом это обсуждать с заказчиком?

И финальное:

• А почему мы решаем, что в скоупе MVP, а что нет?

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

И давайте начнем мы не с самого слайсинга, а с разницы между feature и user story.

Несколько ключевых поинтов о feature, которые ее определяют:

1. Это важная для бизнеса часть, ценность которой осознает заказчик. Как правило, расставить приоритеты заказчик способен только на этом уровне;

2. Могут захватывать и покрывать несколько ролей, сценариев и сторей;

3. Несколько команд/людей могут работать над одной и той же фичей, если грамотно ее разделить.

Что же такое слайсинг?

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

Итак, перед тем, как начать декомпозировать фичу, важно ответить на самый главный вопрос: «Зачем ее слайсить?»

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

2021-06-16 11:12:49 ​​Классическая структура change request. Шаблон.
(7 секунд)

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

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

Сделать жизнь легче поможет шаблон, представляющий собой набор важной информации о Change Request.

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

Оставляю комментарии для вопросов и предложений.
Вам полезны такие шаблоны? Открыть/Комментировать

2021-06-09 10:30:57 ​​Основная цель бизнес-аналитика на проекте — минимизировать риски, связанные с разработкой ненужного или неправильного функционала.
(16 секунд)

Как эти риски минимизирует бизнес-аналитик для команды разработки — понятно (предоставляя требования), но вот как самому бизнес-аналитику минимизировать такой риск для своей собственной работы, разрабатывая требования?

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

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

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

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

Способы валидации, которые может использовать бизнес-аналитик для минимизации рисков:

1. Обсуждение внутри девелопмент команды.

2. Обсуждение с более опытными коллегами.

3. Обсуждение с внешними экспертами (аккуратно с NDA).

4. Привлечение на проект SME.

5. Анализ конкурентных продуктов и смежных областей.

6. Анализ уже существующих систем у заказчика.

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

2021-06-02 12:31:16 ​​Деловая коммуникация. Почему писать «Привет» отдельным сообщением – плохой тон?
(28 секунд)

Спойлер: никогда так не делайте!

Квалифицированный специалист в наше время немыслим без soft skills. Хочется вам этого или нет, но акценты на командную работу и внутрикомандное взаимодействие накладывают свой отпечаток на качества, которые сейчас ищут компании в сотрудниках.

Навык коммуникации — один из самых важных. Вы можете быть сколько угодно великолепным бизнес-аналитиком, обладать широким спектром hard skills, но если вы не обладаете достаточно развитым навыком коммуникации, то увы, но хорошая карьера в крупных IT компаниях вам не светит.

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

Я хотела сегодня подсветить несколько правил деловой коммуникации:

1. Никогда не пишите письма/сообщения, состоящие из одного слова. Да, даже есть вы пишете не в почту, а в Teams, Skype, Slack. Человек, которому вы пишете, тратит на вас свое рабочее время и меньше всего ему хочется прочитать от вас «Привет», а потом еще 5 минут смотреть, как вы набираете текст. Уважайте коллег.

2. Никогда не используйте caps lock. Такой шрифт интуитивно воспринимается как агрессия. Если не хотите подорвать отношения со второй стороной коммуникации, учитесь выделять важное в тексте другими способами.

3. Постарайтесь не использовать разговорных сокращений имен при обращении к коллегам: «Оль», «Вань», «Тань». «Оля», «Ваня», «Таня» — может быть, если вы получили на это согласие человека. Во всех остальных случаях — «Ольга», «Иван», «Татьяна». Для примера, иностранные коллеги со стороны заказчика уточняли у меня голосом, могут ли они обращаться ко мне при общении «Настя», даже несмотря на то, что я сама так представилась на встрече, потому что в деловой переписке я всегда подписываюсь полным именем.

Буду рада, если вы дополните правила или опишите ситуации, которые нельзя допускать в деловой коммуникации. Открыть/Комментировать

2021-05-26 10:31:15 ​​Техники организации эффективного коммуницирования требований. 3W и 3R.
(24 секунды)

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

Но как же правильно коммуницировать требования?

Вне зависимости от метода, который вы выберете для коммуницирования требований (созвоны, e-mail, etc.), вам на помощь придут техники организации эффективного коммуницирования требований: 3W и 3R, которые, на самом деле, очень похожи.

Используя технику «3W» при организации коммуницирования, ответьте на три вопроса:

1. Who? – Кто должен быть включен в коммуникацию?

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

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

Техника «3R» очень похожа на предыдующую и определяет нам три фактора, влияющие на эффективное коммуницирование требований:

• Right People (Правильные участники)
• Right Thing (Правильные темы/вещи)
• Right Time (Правильное время)

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