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

2021-05-12 11:39:17 ​​Разница между Requirements Gathering и Requirements Elicitation.
(24 секунды)

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

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

Gather — собирать
Elicit — выявить

Уже чувствуете разницу? Нет?

Давайте проведем параллель.

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

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

С требованиями — то же самое.

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

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

И чем же вы все-таки занимаетесь? Requirements Elicitation или Requirements Gathering? Открыть/Комментировать

2021-05-05 10:46:24 ​​Приоритезация не работает! Что делать?
(28 секунд)

К сожалению, с тем, что приоритезация «не работает», сталкиваются не только начинающие бизнес-аналитики, но и более опытные коллеги.

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

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

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

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

4. Неправильно выбранная техника приоритезации (техники — это хорошо, но только в том случае, если вы и основные стейкхолдеры хорошо с ними знакомы или готовы учиться, во всех остальных случаях — пожертвуйте «техникой из учебника» ради приоритезированных требований: лучше просто пронумеровать требования по важности (другому критерию) 1, 2, 3, n, чем не приоритезировать вовcе или сделать это неверно).

Что делать, если приоритезация не работает?

1. Перестать винить «странную и ненужную приоритезацию» («да кому она вообще нужна, и так разберемся!» — плохой подход).

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

3. Сформулировать варианты устранения причины (лучше в формате: план А; если не сработал план А, то план Б).

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

2021-04-28 14:33:20 ​​Общие этапы процесса выявления требований. В чем заключается работа бизнес-аналитика на этих этапах?
(27 секунд)

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

Подготовка к сбору требований

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

Задачи бизнес-аналитика:

• Изучить домен;
• Проанализировать стейкхолдеров;
• Спланировать ожидаемые результаты (документы) этапа сбора требований;
• Выбрать техники, которые будут использоваться для сбора требований;
• Подготовиться к командировке к заказчику (при необходимости);
• Подготовить сопроводительные материалы.

Сбор требований

Основная цель этапа: выявить основные требования к системе.

Задачи бизнес-аналитика:

• Провести сбор требований согласно планам и с использованием выбранных техник;
• Зафиксировать результаты сбора требований в ожидаемых выходных документах.

Утверждение собранных требований

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

Задачи бизнес-аналитика:

1. Предоставить заказчику результаты сбора требований в любом комфортном для всех виде, при этом обязательно также в письменном;
2. Получить фидбэк от стейкхолдеров на полученные требования;
3. Внести корректировки в требования при необходимости;
4. Получить подтверждение от заказчика, что все собранные требования удовлетворяют его потребностям (обязательно в письменном виде!). Открыть/Комментировать

2021-04-21 10:14:52 ​​Что такое аналитическое мышление и как понять, обладаете ли им вы?
(24 секунды)

Аналитическое мышление или аналитические способности — это основной инструмент бизнес-аналитика для выполнения своих рабочих обязанностей. И если однажды на собеседовании вас спросят про ваш основной инструмент работы, смело называйте аналитическое мышление, а не JIRA и Confluence.

BABoK раскрывает нам это понятие через несколько ключевых навыков:

1. Креативное мышление — способность генерировать новые идеи для решения проблем и сложный ситуаций, а также в поиске альтернативных решений;

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

3. Обучаемость — способность быстро и безболезненно погружаться в новые знания и домены, а также преобразовывать эти знания в понимание, как принести пользу компании и заказчику;

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

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

Если каждый из этих навыков — про вас, поздравляю! У вас большие шансы на успех!
Если нет, то теперь вы знаете, что необходимо подтянуть, чтобы аналитическое мышление стало вашим главным козырем за место под солнцем. Открыть/Комментировать

2021-04-14 09:40:05 ​​Чек-лист эффективного совещания или 13 правил, которые всегда важно помнить.
(30 секунд)

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

Я подготовила правила, которые помогут вам не растеряться и не превратить совещание в потерянное время:

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

2. Определить цель совещания.

3. Правильно подобрать время и временные рамки совещания.

4. Подготовить техническое оборудование / место встречи.

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

6. Заранее подготовить agenda и обязательно поделиться ей с другими участниками.

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

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

9. Пригласить только тех, кто действительно заинтересован в теме, а не массовку.

10. Продумать, как создать комфортную атмосферу на совещании.

11. Соблюдать тайминг совещания.

12. Выносить на отдельные встречи офф-топ темы.

13. Спланировать окончание совещания, подведение итогов и последующие шаги.

Расскажите о ваших правилах эффективных митингов. Какие приемы используете, чтобы встреча прошла идеально? Открыть/Комментировать

2021-04-07 10:52:03 ​​Дескоупинг и его роль в жизни бизнес-аналитика.
(24 секунды)

Дескоупинг — процесс нечастый, это вам не увеличение скоупа.

Но когда он случается, чувства бизнес-аналитик, как правило, испытывает довольно смешанные. Связано это с несколькими причинами:

1. Бизнес-аналитик выявлял требования, формулировал их и коммуницировал с заказчиком. Даже получал на них конферм. А потом вдруг функционал просят выпилить из скоупа проекта.

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

Но стоит ли расстраиваться? Конечно, нет.

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

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

Причины дескоупинга бывают следующие:

1. Устаревшие требования (если проект довольно долгий, а сфера динамично меняющаяся, то такое бывает часто).

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

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

4. Непопадание в рамки проекта (грубо говоря, команда не успевает сделать то, что изначально планировалось: довольно характерно для fixed price agile проектов, поскольку вначале функциональность не проработана по требованиям детально и сложно ее точно оценивать). Открыть/Комментировать

2021-03-31 11:22:22 ​​Вам письмо: «Мы тут подумали, а давайте…» или почему с ответом лучше не торопиться.
(17 секунд)

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

Пятничный вечер у нас, раннее утро у американского заказчика. Уже собираюсь уходить на выходные, как в почту прилетает письмо от заказчика с пометкой «ASAP»(as soon as possible) и очень знакомым каждому аналитику содержанием: «Мы тут подумали, а давайте добавим в скоуп фичу N, только срочно, прям в этот спринт, она очень нам нужна. Мы уже обсудили это со всеми стэкхолдерами.»

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

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

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

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

До митинга час. Наливаю себе кофе и начинаю готовить тезисный план (обязательно готовлюсь ко всем важным переговорам).

За полчаса до митинга прилетает письмо от заказчика: «А мы пообщались еще раз внутри и решили, что нам эта функциональность вообще не нужна, отмени митинг, пожалуйста. Хорошего дня!»

Конечно, эту функциональность позже мы все равно обсудили, на всякий случай, чтобы быть on the same page, но эта ситуация показала мне главное: «Никогда не торопись с ответом. Дай людям время подумать.»

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

2021-03-24 15:28:43 ​​Что такое эффективная коммуникация и как добиться того, чтобы коммуникация была эффективной?
(23 секунды)

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

А теперь задайте себе вопрос: каждая ли ваша коммуникация эффективна?

Если вы ответили — да, то вы обманули. А обманывать самого себя — очень плохо.

Но если хотя бы в 80% случаев ваша коммуникация эффективна — вы действительно очень хороший специалист.

Итак, что же делать, чтобы повысить процент эффективной коммуникации?

1. Выявить и определить цель коммуникации по SMART (например, «Выявить не менее трех поинтов для улучшений взаимодействия на проекте во время 1 to 1 митинга 10/03, чтобы определить, какие сложности во взаимодействии проектной команды есть на текущий момент.»

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

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

4. Выстроить комфортные взаимоотношения в начале коммуникации (Small Talk, комплимент и т.д.).

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

6. Слушать и слышать вторую сторону.

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

8. Обязательно подводить итоги встречи, подтверждая главные договоренности.

9. Проводить внутреннее ревью коммуникации, чтобы посмотреть, какие цели были достигнуты, а какие – нет.

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

2021-03-17 17:45:01 ​​Топ-3 challenges, с которыми ежедневно сталкивается бизнес-аналитик, и как с ними справиться.
(19 секунд)

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

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

Выполнимость — одна из ключевых характеристик хороших требований.

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

Обработка возражений, недовольств и конфликтов.

Как правило, бизнес-аналитик в команде — это самый главный переговорщик и третье лицо в большинстве конфликтов наравне с проектным менеджером. А еще психолог и иногда даже психиатр.

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

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

Постоянная коммуникация нон-стоп.

Совет здесь один: обязательно выделяйте себе «тихие» часы и возьмите за правило их соблюдать в обязательном режиме. Даже если у вас сработала нотификация, а вы случайно прочитали вопрос, который вам показался пустяковым, и ответ займет буквально 3 секунды — не отвечайте. Любые коммуникации в «тихие» часы — табу. Открыть/Комментировать

2021-03-10 11:30:06 ​​«Что делать, если я найду какие-то сценарии, не описанные в источнике требований, или расхождения в сценарии и реализации?»
(23 секунды)

Именно с этим вопросом ко мне недавно пришел опытный тестировщик.

Даже не знаю, мыло с веревкой тебе приготовить? — подумала я и ответила: «Хорошо, что ты спросил, потому что однажды «неописанные требования» ты точно найдешь.»

Давайте будем честны.

Какова вероятность найти несостыковки в быстро меняющихся требованиях и не столь быстро изменчивой реализации? Высокая.

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

Какова вероятность, что сработает человеческий фактор и я что-то пропущу? Конечно, и такая вероятность есть.

Что делать в таком случае? Оставаться человеком.

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

Именно для этого у нас и работает команда РАЗНЫХ специалистов, каждый из которых может внести свой вклад в развитие продукта.

Что тогда делать тестировщику? Прийти и спросить.

Именно для этого у нас есть груминги и ревью требований. Чтобы отлавливать и обсуждать такие моменты. Именно для этого мы проводим каждодневные стендапы. В конце концов, именно для этого придумали Teams или Skype. Чтобы просто спросить.

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

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

И так и хочется спросить: «Что делать, если я использую разные техники сбора требований, а требования никто не знает?» Открыть/Комментировать