О бизнес-анализе и не только

2021-08-09 09:13:16 Навык фасилитации. Проведение.

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

Теперь про приемы\навыки, которые помогут вам модерировать обсуждение.

1. Установите базовые правила проведения.

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

2. Визуализация в процессе

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

Вот разработчики обсуждают, какая должна быть архитектура для нового модуля системы. Один говорит: "давайте одна lambda function будет забирать данные из базы, преобразовывать их и отдавать на фронт". Пока он говорит, вы рисуете базу данных, lambda function и фронт. Второй возражает "слишком жирно будет одной lambda function и преобразовывать, и отдавать на фронт. Давайте сделаем 2 lambda functions". Вы берете маркер другого цвета и дорисовываете вторую lamda function со знаком вопроса. И спрашиваете третьего разработчика "Вася, а ты что думаешь"? Даже если Вася отвлекся, или недослушал, он посмотрел на доску - и понял, в чем вопрос.

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

А в конце встречи вы можете сфотографировать доску - и вот митинг ноутс практически и написаны.

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

3. Слышать ВСЕ аргументы

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

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

4. Уметь вовлечь каждого члена команды.

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

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

#горопека_лайфхаки #горопека_техники Открыть/Комментировать

2021-07-25 22:05:08 Навык фасилитации. Подготовка

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

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

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

Итак, подготовка.

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

1. Определить цель.
Довольно очевидный пункт, но давайте кратенько по самому важному.

Во-первых, цель нужно объяснить в начале встрече. И записать большими буквами на видном месте.
Во-вторых, часто цель нужно не только объяснить, но и продать. Дайте коллегам контекст, откуда цель взялась? Почему это для нас важно? Это значимо влияет на качество обсуждения.

Примеры целей:
○ Есть идея провести А/B тест, валидирующий такую-то гипотезу. Мы должны определить технический подход к реализации теста.
○ Скоро релиз большой фичи. Мы должны определить rollout plan.
○ По итогам последнего user research мы знаем, что 4 из 5 пользователей сталкиваются с такой-то проблемой. Цель встречи - брейншторм, как мы можем улучшить пользовательский опыт и убрать данную проблему.

2. Продумать план/агенду совещания.

Если вы проводите backlog refinement, то агенда проста: набор сторей, которые нужно зарефайнить.
Но если вы проводите брейншторм, или сессию по выработке того же rollout plan - вам нужно подумать над планом проведения. Каким именно путем за условный 1 час встречи вы придете к цели?

Например, если это брейншторм по решению проблем пользователей, то план может быть следующим:
1) объяснение проблемы с цитатами пользователей и видео момента, где пользователи сталкиваются с проблемой
2) примеры, как похожая проблема решается в других приложениях
3) важные технические ограничения
4) брейшторм идей
5) голосование участников за лучшие идеи.
6) next steps по итогам брейншторма

Качество ваших митов КРАТНО улучшиться, если вы будете продумывать ход встречи заранее.

3. Определить состав участников

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

2) Если сомневаетесь, будет ли коллеге интересно\важно поучаствовать - спросите!

3) Если у вас есть стейкхолдер control freak, и его аппрув вам необходим - приглашайте на совещание. Банальная психология - принимал участие в выработке решения, странно его не аппрувить потом.

4. Подготовить пространство для проведения.

Зависит от цели и агенды. Если это backlog refinement - может быть достаточно открыть сторю в jira/wiki, и походу встречи уточнять требования, создавать таски и т.д.

Если брейншторм из примера выше - то явно нужно подготовить miro доску: добавить исходные данные, создать фреймы, стикеры и объекты для визуализации идей, продумать способ голосования за лучшие идеи (dot-voting? встроенная фича Miro)?

Встреча в оффлайне? Убедитесь, что есть доска, фломастеры, стикеры, бумага (виски, закуска ).

Ну вот и подготовились. В следующей части пойдем проводить!
#горопека_лайфхаки #горопека_техники Открыть/Комментировать

2021-07-06 10:39:22 #горопека_обсуждение

Есть вопрос, который мучает меня с начала работы ментором. Можно ли научить человека системному мышлению (в адекватный промежуток времени)?

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

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

Так можно ли этому научить? Только чтобы не годами, а за 3-6 месяцев (больше никто начинающего аналитика без прогресса держать не будет)? Поделитесь своим опытом! Открыть/Комментировать

2021-07-02 15:44:07 #горопека_заметки

Когда по ходу имплентации стори вы (КОМАНДА) меняете несколько деталей, потому что так быстрее сделать или это лучше согласуется с целью стори - это Agile.

Когда вы берете в спринт сторю с high level description, и потом недоумеваете, почему она не была сделана - это не Agile. Это бардак и демотивированные инженеры. Открыть/Комментировать

2021-06-21 12:37:59 Как проверять свои требования

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

После варианта "я просто знаю" следующий по популярности - вспомнить про тестировщиков. "Я скидываю нашим тестировщиком, и они вычитывают". Я за любые peer review: коллегами БА, тестировщиками, разработчиками, whoever. Но я надеюсь, вы же не скидываете полуготовые требования на вычитку, снимая с себя ответственность? Вы же просите проверить требования, в качестве которых сами уверены?

Далее некоторые вспоминают про прототипирование и моделирование. Действительно, визуализация требований - действенный метод проверки на пропуски и противоречивость. Если у меня есть сущность с жизненным циклом - обязательно рисую State Machine Diagram. Если сложный БП - диаграмму процессов. И в довесок еще набор прототипов с обозначением основных функций и user journeys. А вообще - хотя бы таблицы и нумерованные списки используйте )))

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

Когда применять: на проектах, где много взаимозависимых функций и сущностей.

Что делать:
1. Составить чек-лист проверки новых требований
2. КАЖДУЮ СТОРЮ проверять согласно чеклисту. КАЖДУЮ.

Секрет: действительно применять. Не просто составить чек-лист, и забыть про него. Не думать "я и так его помню, не буду открывать". А прям открываете чек-лист на одном экране, сторю на другом - и по каждому пункту в чек-листе думаете, сторя затрагивает данную функциональность? у меня продуманы edge cases?
После каждого найденного пропуска в требованиях - дополнять чек-лист соответствующим пунктом.

Попробуйте применить эту очевидную технику и поделитесь фидбеком - помогло уменьшить пропуски?
#горопека_лайфхаки #горопека_техники Открыть/Комментировать

2021-05-26 12:06:57 ПМ-БА

Сколько копьев сломано на теме обязанностей и прав ПМ и БА. По долгу службы я ОЧЕНЬ ЧАСТО выслушиваю стенания коллег на тему "какой плохой у меня ПМ" - "ничего не делает", "распустил команду", "не налаживает процессы на проекте". За годы работы я сложила для себя следующей пазл, кто за что отвечает, и активно продвигаю его на своих проектах.

БА не отвечает за бюджеты и сроки. А раз не отвечает - не имеет права их обещать. Никогда, слышите, НИКОГДА не обещайте Заказчику никаких сроков, не посоветовавшись с ПМ и командой. Да, поменять текст сообщения точно не требует неделю времени. В идеальных условиях. А в реальности ПМ запланировал ротацию членов команды, или воздать на алтарь технического долга, или отпустить кого-то в отпуск. И всё это может повлиять на срок выполнения даже такой мелкой задачи.

Но БА должен знать бюджеты и сроки, чтобы управлять ожиданиями Заказчика при сборе требований. Большая боль БА: требования у Заказчика на новый Amazon, а бюджета хватает только на сайт-визитку. В таких условиях вы не можете просто документировать все хотелки Заказчика. Вы должны слаженно работать с ПМ и командой, чтобы придумывать лучшие решения в сложившихся ограничениях. И постоянно заземлять Заказчика - я понял ваши требования, а теперь давайте подумаем, что будет MVP версией в наших условиях.

БА отвечает за бизнес-ценность решения. Назвались "прокси продукт-оунером" - будьте добры, несите ответственность. Определить цель продукта; сформулировать цель спринта и сфокусировать на ней команду; приоритизировать бэклог; написать понятные и непротиворечивые стори - всё это ваши профессиональные обязанности. На одном проекте ваш Заказчик будет отличным продукт-оунером, который сам приоритизирует и сфокусирует на ценности, вам останется только детализировать стори. На другом проекте толку от Заказчика будет гораздо меньше. В любом случае, обо всем вышеперечисленном голова болеть должна прежде всего у вас, не у ПМ.

БА не должен разруливать блокеры, если они не связаны с требованиями. Если вашего ПМ не волнуют блокеры команды - у вас плохой ПМ. Не нужно взваливать на себя эту работу, нужно поднимать вопросы на ретрах и one2one с ПМ. И эскалировать дальше, если не помогает. Только прошу не путать с ситуацией, когда ПМ вас просит помочь в вопросах, в которых вы объективно можете помочь. Это он не "взаливает на вас работу", а вполне себе блокеры разруливает

БА не отвечает за мотивацию команды. Подбирать адекватные ресурсы на проект, вовремя ротировать, организовывать тимбилдинги, отпускать в отпуска - вотчина ПМ. На практике часто оказывается, что БА лучше знает о настроениях членов команды, потому что плотнее с ними работает (постоянное обсуждение требований и багов к этому располагает). В такой ситуации я всегда подсказываю ПМ "что-то Вася заскучал, ему задачи неинтересные" или "у Маши подгорает от Васи, скоро будет конфликт". Но на этом всё, дальше я ожидаю действий от ПМ.

Это основные принципы. Согласны? Или у вас другое мнение?

#горопека_о_проекте #горопека_о_пм Открыть/Комментировать

2021-04-27 15:57:27 Самый главный грех БА.

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

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

Как вы думаете, что самое разрушающее для проекта и отношений с коллегами может делать БА?

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

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

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

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

Но даже активное слушание можно натренировать, было бы желание.

А вот избавить аналитика от незыблемой уверенности, что он тут САМЫЙ умный - это вряд ли. Работали с такими? Затыкает заказчика, потому что "я уже 10 проектов в этом домене сделал, что вы мне тут ваши бизнес-требования объясняете". К команде на рефайнемент приходит уже влюбленный в свой солюшен, и никакие доводы не слушает - он же самый умный. Приходит на тренинг (надо же потешить свое эго, что с очередным дипломом я уж точно самый умный) - и на каждую фразу тренера возражения и соображения, ведь кто тут самый умный? В итоге имеем недовольного заказчика, демотивированную команду, и самое страшное - остановку в профессиональном развитии.

Так что вот он, самый главный грех БА - на мой вкус. Перестаньте считать себя самыми умными - потому что это точно неправда.
#горопека_лирика Открыть/Комментировать

2021-04-21 11:43:20 Ребята, на собеседовании в онлайн формате ВЫ ответственны за то, чтобы вас ВИДЕЛИ и СЛЫШАЛИ.

Собеседования без включенной камеры - это не выгодно прежде всего для вас. Ибо вы не можете наладить контакт с собеседником через eyes contact, улыбки и жестикуляцию . Вы сами обрекаете себя на перебивания и долгие неловкие паузы, ибо собеседник вас НЕ ВИДИТ и не может понять, вы просто задумались или уже закончили отвечать на вопрос.

Еще скажите, вы придете на оффлайн собеседование с сигаретой в руках? а не причесанные или в пижаме?

Ну и качество связи. Я понимаю, у нас всех Интернет временами сбоит, и мы не можем на это повлиять. Но вы можете (и должны) во время собеседования находиться в месте с максимально лучшим Интернетом (а не в лесу у бабушки с 3G).

Простите, бомбануло.
#кейс_собеседование #горопека_о_собеседованиях Открыть/Комментировать

2021-04-20 14:47:52 Еще один вопрос на удивление часто ставит кандидатов в тупик:"Какие есть способы документирования функциональных требований?"
Интересно, почему?
С бизнес- и пользовательскими требованиями обычно таких проблем не бывает.

#кейс_собеседование #горопека_о_собеседованиях Открыть/Комментировать

2021-03-21 14:11:25 Бизнес-требования.

Самая пропускаемая и непонимаемая категория требований.

В 8 из 10 случаев кандидаты на собеседованиях приводят следующие примеры бизнес-требований (далее - БТ): "Система должна позволять делать заказ на сайте", "Пользователь должен иметь возможность сгенерировать отчет".

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

Давайте вспомним, что нам говорит дедушка Вигерс о БТ: “Business requirements” refers to a set of information that, in the aggregate, describes a need that leads to one or more projects to deliver a solution and the desired ultimate business outcomes. Business opportunities, business objectives, success metrics, and a vision statement make up the business requirements.

Жирным шрифтом я выделила самые важные, на свой взгляд, части:

1. Need. Потребность. Почему вообще затеваем все эти телодвижения? Почему спонсоры готовы тратить деньги на проект? Что им болит, что решаем? Согласно BABOK, need - это один из core concept (на ряду с change, solution, stakeholder, value, context).
2. Desired ultimate business outcomes. Бизнес-результаты. Это засмартованный ответ на вопросы выше. Как мы поймем, что потребность удовлетворена? Что деньги, время и усилия потрачены не зря?
3. Set of information. Совокупность информации. Думаю, это отличительное свойство БТ. Мало просто написать бизнес-цели, нужно ПОНЯТЬ, почему они такие. Поэтому и нужно написать целый Vision and Scope документ, что подробно разобраться в предпосылках, ситуации на рынке и открывающихся возможностях, рисках, допущения, и т.д.

Мы знаем с вами следующее требование к качеству требований: проверяемость. Раз написали и взяли в работу, то должны быть способны проверить - а выполнили-то требование? И вот тут у начинающих аналитиков пазл не складывается: если БТ является совокупностью информации, то как понять, выполнили мы их или нет? Именно поэтому в узко-прикладном смысле за БТ можно принимать бизнес-цели, сформированные по шаблону "Увеличить [показатель] на Х процентов за Y месяцев после внедрения системы".

Заметили часть про "пoсле внедрения системы"? Логично, что бизнес-результат случится ТОЛЬКО после некоторого количества времени после внедрения системы. Именно поэтому кроме бизнес-цели, важно еще документировать и критерии успеха - индикаторы, которые 1) можно померить в период тестирования или вскоре после внедрения 2) непосредственно связаны с бизнес-целью, поэтому по ним можно судить, мы на пути к достижению бизнес-целей или нет?

Пример из недавней практики. Мы работаем над новой content platform, чтобы увеличить количество пользователей, приходящих на наш сайт (бизнес-цель). Для этого нужно, чтобы пользователь видел наш контент как можно выше в списке выдачи при отправке поискового запроса. Мы знаем, что performance сайта является важным критерием для определения порядка выдачи сайта, поэтому один из наших критериев успеха будет, например, Largest Contentful Paint < 1sec. Итого, увеличение количества пользователей на X процентов за Y месяцев после внедрения - бизнес цель. А Largest Contentful Paint < 1sec - хороший критерий успеха, который мы можем померить сразу после релиза любой фичи.

Итого, я хочу донести до вас следующие мысли:
1. Бизнес-требования в широком смысле - совокупность информации, которая описывает потребность и бизнес-результаты, которые мы хотим достичь.
2. В узком прикладном смысле бизнес-требования = бизнес-цели, сформулированные по шаблону "Увеличить [показатель] на Х процентов за Y месяцев после внедрения системы"
3. Поскольку достижение бизнес-целей всегда отложено во времени, важно определять критерии успеха, которые можно померить в процессе тестирования или сразу после внедрения системы.

Как у вас с бизнес-требованиями? Выявляете? Документируете? С какими проблемами сталкиваетесь? Пишите в комментариях, обсудим!

#бизнес_требования #горопека_о_продукте #горопека_о_бт Открыть/Комментировать