Пошаговая инструкция для бизнес-аналитика (часть 1)

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

Процитируем Руководство BABOK® и выделим части, на которые особенно хочется обратить внимание:

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

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

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

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

…

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

Вчера в телеграм-канале обсудили что такое User Story и Use Case и Нужно ли писать и user story и use case или достаточно чего-то одного. После прочтения выдержки из BABOK® должно стать понятно зачем нужны стори.

А ваши бизнес-аналитики делают то, что выделено жирным шрифтом?

Если да, отпишитесь в комментариях. Предположу, что вы либо работаете в ТОП-10 банков, Яндексе и подобных крупных компания или это значит ваша команда очень крута ❤

Продолжим диагональное изучение BABOK®:

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

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

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

🥐 Функциональные требования: описывают возможность, которой должно обладать решение с точки зрения поведения и информации, с которой решение будет работать. (комментарий: они же станут разделом 4.2 в ТЗ и их выполнение придется потом продемонстрировать на приемо-сдаточных испытаниях)

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

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

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

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

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

Стейкхолдер (англ. stakeholder), также заинтересованная сторона, причастная сторона, участник работ, роль в проекте — лицо или организация, имеющая права, долю, требования или интересы относительно системы или её свойств, удовлетворяющих их потребностям и ожиданиям (ISO/IEC/IEEE 15288:2015, ISO/IEC 29148:2011:6).В стандартах системной и программной инженерии (ISO 15288, ISO 29148 и т. д.) стейкхолдерами считаются (комментарий: список сокращен, первоисточник и полный список доступны в интернете):

⭐ Клиент - получает продукт, созданный по итогам деятельности

⭐ Разработчик - осуществляет разработку в течение жизненного цикла

⭐ Пользователь - получает пользу от использования системы

⭐ Производитель - отвечает за производство, бюджет, ресурсы, удовлетворение клиента и выполнение работ

⭐ Сопровождающая сторона - выполняет поддержку системы либо оказывает сопровождение

⭐ Прочие - техподдержка, инструкторы и т. п.

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

Самый сложный разговор, на наш взгляд, возникает при общении со стейкхолдерами типа Пользователь. Если круг потенциальных пользователей ограничен (продукт для внутреннего потребления какой-то компании), то как минимум известны или доступны контакты конкретных людей с ролью Пользователь, их можно опросить, составив некий опросник-анкету и собрать первичные данные и далее приходить с уточняющими вопросами. Но если продукт предназначен для открытого рынка (мобильное приложение банка, портал страховой компании и.т.д), то необходимо провести целое исследование и выявить портрет потенциального клиента. К очень крупных компания этими исследованиями занимаются целые команды продуктовых аналитиков и если вам удастся послушать лекции про их опыт работ – используйте эту возможность, это действительно интересно! Но если вы команда обычных ребят, которым такая роскошь как продуктовый анализ недоступна, то не стоит даже и пытаться?

Как вы наверное уже догадались, наш девиз - do your best (в английском варианте это звучит точнее).

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

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

Цитата из цитаты 👆: «Бизнес-анализ помогает предприятию формулировать потребности и обосновывать изменения».

Задайте Пользователю вопросы:

❔Какой программой вам нравится пользоваться вне работы? Почему?

❔За что вас хвалит ваш руководитель? (а потом спросите у самого руководителя, что его нравится в работе сотрудников – наших пользователей и что не устраивает).

❔Приходится ли вам задерживаться на работе? Как вам кажется почему?

❔Что бы хотелось делать быстрее?...

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

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

Чтобы понять почему не стоит спрашивать «в лоб» поставьте себя на место человека, от которого вы пытаетесь получить информацию. Вы работаете, вас устраивает должность, зарплата, вы привыкли делать свою работу и не планируете ничего менять, но тут приходит незнакомец и требует честно и развернуто рассказать, что в работе плохо. Сможете ему ответить? Я – нет! Возможно я найду пару незначительных моментов, которые дам ему в качестве ответа, чтобы от меня отстали, но пускаться в длительный анализ общих проблем… мне это не нужно, я не заинтересована в этом участвовать, потому что в целом меня все устраивает.

А была ли у вас история, когда на старте работ заказчик приносил ТЗ с функциональными требованиями, а к концу выполнения работ передумывал и отказывался принимать работы по ТЗ?

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

Жизнь богаче любой теории, НО! кто нам помешает стремиться к идеалу?