Блог

Бизнес-анализ

• Цветков Максим
• 07.02.2022

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

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

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

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

Ценная информация та, которая поможет понять желаемый оптимальный результат. И удостовериться, что целевое решение нас приведет к результату. И хватит ли нам ресурсов на достижение результата? Будут ли инвестиции стоить результата? Мы выясняем, в какой точке развития мы живем сейчас и к какому результату хотим прийти. И как именно придем к результату. Это называется Gap Analysis.

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

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

Цели OKR идут сверху вниз, но каждый сотрудник может переформулировать цель, чтобы она его драйвила. Руководство всегда будет за деньги и достижение KPI, сотруднику же не интересно просто увеличивать цифру на чужом банковском счету — сотрудник хочет что-то создать. Менеджер (правитель) выберет Mercedes, а эксперт предпочтет Audi. Людям интересно разное в зависимости от их профессии, именно поэтому они и освоили определенную профессию. Синхронизация разных профессий работает через метрики и бюджеты.

Бюджет это финансовый план, который устанавливается на год.
P&L — profit and loss report. Сколько потратили и сколько получили. Финансовые результаты за период.
CapEx — разовые расходы, вроде покупки офиса или принтера. Также, закупка крупного ПО, на который закладывается бюджет заранее. Крупные компании стараются уходить от CapEx, чтобы упростить подсчет баланса.
OpEx — операционные расходы, аренда офиса или зарплаты. Закупка мелкого ПО.
Commercial — затраты на маркетинг и продажи. Маркетинг это привлечение, удержание и исследование аудитории.

Сумма затрат — это все траты за указанный период, CapEx и OpEx.
Cash in — это сколько денег вы получили, например от инвестора. Любые вхождения денег.
Summ — Cash in за вычетом Суммы затрат.
Accum — сколько денег на счету компании в определенный момент времени, с учетом доходов.

На среднесрочном планировании применяется OKR, сроки реализации от месяца до квартала.
OKR это система целеполагания и достижения целей в рамках квартала. Цели (Objectives) это основная цель бизнеса, обычно это емкая и короткая фраза, например «повысить качество дизайна». И Key Results как метрики для достижения Objectives.

Более крупные сроки, например год, состоит из «спайки» более краткосрочных квартальных OKR (4 в году). Unit Objective должна обязательно быть = Global KR. Есть понятия Global OKR — Unit OKR — Team OKR.

В OKR есть правила:
1) Не более 5 целей и не более 4 метрик на каждую цель.
2) По каждой цели должны быть измеряемые результаты.
3) Цель должна быть недостижима, но команда должна достичь 60-70% от оригинальной цели.
4) OKR на всех участников.
5) Квартальные цели нельзя менять.
6) Половина целей должны быть от линейных сотрудников, а не только от руководителей.
7) В конце квартала каждый сотрудник оценивает результаты своей работы.
8) Все сотрудники знают OKR каждого сотрудника.

Пять целей должны быть правильными, если хоть в одной косяк — 20% ресурсов утилизировано без результата.

Либо Unit как современный подход, расчет на единицу клиента. LTV > CAC = не ок, а LTV < CAC = ок. Все самые распиаренные метрики именно из Unit-экономики: CAC (стоимость привлечения), ARPU (доход с пользователя), ARPPU (доход с платящего пользователя), COGS (затраты на каждой продаже), LTV, lsCOGS (затраты на первую продажу с учетом лидогенерации), fixCOGS (постоянные издержки бизнеса). А еще сверху добавляются планы по M&A. Но это мы уже уходим в сторону менеджмента, вернемся с аналитический трек.

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

Работа со стейкхолдерами

Стейкхолдерами могут являться это люди, группы людей или компании. Они могут являться benefactors — те, кто дают ресурсы, это инвесторы или руководители высокого звена. Beneficiaries — люди, которые пользуются продуктом или нуждаются в продукте для закрытия потребности. И impacted — те, на ком скажется существовании продукта в хорошем или плохом ключе. Также, стейкхолдеры это конечные пользователи, государственные регуляторы, команда разработки и поддержки.

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

Возможно, сотрудники из удаленных офисов очень недовольны всеми решениями HQ, и воспринимают любые изменения негативно. Может, сейлзы не хотят продавать лучший продукт, они хотят продавать то, что легко продать — дешевый аналог конкурентов. Поэтому выясняем и учитываем влияние разных культур, политический климат в организации. Свободно ли высказываются о своих желаниях и проблемах стейкхолдеры? Какие культурные факторы можно выявить? Какие компетенции получит компания после внедрения фичи? И чье влияние нам нужно, чтобы добиться поставленной цели. Выясняем все детали, релевантные needs, wants и data. Needs (потребности) могут основываться на опыте стейкхолдеров, состоянии индустрии. Wants же базируются на количестве стейкхолдеров, их разнообразии, иногда на культуре компании или даже целой нации.

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

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

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

Фича

Фича должна быть измерима и иметь цель. Цели задаются по SMART. Например, мы хотим улучшить быстродействие нашего продукта на 15%, чтобы улучшить UX. Измерять будем по опроснику NPS в течении ближайших 3 месяцев после запуска фичи. Или за 8 месяцев увеличить количество заказов через сайт на 50% от неавторизованных клиентов с помощью внедрения инструментов от партнеров. Тут понятно, на что влияет результат, цель конечна. Цели могут меняться, например из-за неподтвержденных гипотез, или появились гипотезы получше. Также, могут измениться внешние условия.

Все заинтересованные стейкхолдеры должны быть указаны в RACI-матрице.

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

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

• Какие ресурсы доступны и какие нужны.
• В какой последовательности нужно нанимать дополнительные ресурсы.
• Какой инструмент, кто будет валидировать качество.
• Что и с кем можно обсудить, кто за что отвечает.
• Что сложнее всего реализовать? Это зоны риска.
• Какие внешние зависимости у нас есть?
• Уметь ответить на все 5 «почему?».
• Подготовить множество документов и диаграмм, про которые поговорим ниже.

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

Получаем инсайты

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

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

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

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

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

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

После интервью кластеризуем результаты на job analysis и/или persona analysis. Персоны больше про непрямых стейкхолдеров, с которыми трудно поговорить лично. От них нам нужна точка зрения. Персоны помогают понять уровень навыков, методы работы, и построить классические User Story. Отправляем всем участникам саммари сессии, чтобы они проверили и подтвердили корректность нашего понимания. С помощью Jobs мы можем понять, какие роли влияют на проект.

Жизненный цикл проекта может быть predictive и adaptive. Predictive — все планируется заранее в деталях. Мы знаем заранее все требования и скорее всего, работаем по Waterfall. Adaptive про получение требований в процессе и адаптация своей работы под меняющееся окружение, как Agile (SPOD -> VUKA -> BANI).

Артефакты

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

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

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

Далее Process flow. Показывает, как работает бизнес-процесс, с учетом людей и систем. Такой диаграммой можно наглядно показать, как работает оператор в оффлайновой точке продаж.

Capability table это обычная таблица со списком проблем, глубинными причинами, и методами решения. Можно обогатить колонкой со сроками, статусом выполнения, приоритетом, ссылкой на таску в Jira и т.д.

Проблема	Причина	Решения
Веб-интерфейс лагает на рабочих станциях.	Слишком много данных из-за длительности операции, огромный профайл.	Перейти на нативные технологии платформы.
Не подгружаются текстуры на карте сети.	Обычные текстуры медленно заливаются на GPU.	Использовать компрессионные текстуры вместо png/jpg

Affinity diagram собирает все проблемы/решения в некие понятные группы, из которых иногда можно даже построить сценарий. Часто такая диаграмма — результат брейншторма после кластеризации и тегирования.

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

Номер решения	Кол-во голосов	Итоговое место
Solution 1	I I I	2
Solution 2	I	5
Solution 3	I I	4
Solution 4	I I I	1
Solution 5	I I	3

Принцип попарных сравнений: берем Solution 1 и Solution 2, и по каким-то критериям решаем, что Solution 1 лучше. Отдаем голос за него и ставим отметку-голос в таблице. Далее сравниваем Solution 1 и Solution 3, опять же голос уходит одному из вариантов. По аналогичному принципу работает Weighted Decision Matrix, но более гибко и справедливо. Каждому фактору добавляется вес.

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

Метрики

Бизнес-аналитик обязан уметь считать следующие метрики:

Чистая приведенная стоимость или Net Present Value = NPV > 0% = фича прибыльная. Формула для расчета NPV = Σ {Period Cash Flow / (1+R) ^ T} — initial investment. Где R = Interest Rate и T = Number of Time Periods.

Также payback period. Лучше считать годовой доход, Internal Rate Return = IRR (внутренняя норма доходности).

Cashflow — доход минус расход по временным рядам. Например, мы зарядили дорогую рекламную компанию, чтобы раскачать проект, и затем он выходит на самоокупаемость. Отчет по денежному потоку — первое, что просит C-level. И лишь потом начинают смотреть эффективность проектов, если результаты Cashflow слабые. Так что cashflow не имеет ничего общего с рентабельностью компании.

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

Артефакты и модели:

Любые ваши наработки могут использоваться как для внутренних целей, так и для презентаций наружу. Оформление и подход к хранению данных напрямую зависит от дальнейших целей и проекта. Если у вас Agile, то это user Story, Waterfall же требует User Cases. Команда разработки также обладает только той информацией, что вы задокументировали.

Goal map — очень полезны в самом начале работы. Все цели должны быть легко отслеживаемы обратно к изначальным проблемам.

Ecosystem map — визуализируем инструменты между разными инструментами, которые формируют единую картину мира.

Context diagram — показывает и системные, и человеческие интерфейсы одновременно. Обычно очень сложны и визуально, и для восприятия.

Feature model — все фичи в виде иерархии.

Scope model — показывает объемы работы.

Role model — про правила вщаимодействия в компании.

Data model — как, когда и где можно получить данные. Я часто накликиваю схему данных в hasura.io, автоматически получаю GraphQL-схемы.

Существует несколько языков для создания диаграмм: BPMN — для сложных бизнес-процессов, которые подвержены изменениям. RML — для легкого визуального представления требований под стейкхолдеров, чтобы можно было с ними легко обсуждать возникающие вопросы. SML — для анализа комплексных систем с UML. И сама UML для определения дизайн-модели, вероятно с шаблоном от Остервальдера. Или что-то более детальное с учетом денег.

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

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

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

Crow’s foot notation — стили для показания связей между нодами.

Описания сценариев

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

Описание	Пользователь находит себе вторую половинку, основываясь на данных из профиля, лайков в социальных сетях, предпочтений по контенту и объему переписки.
Актор	Пользователь
Наша выгода	Увеличение вовлечения, CSI, COR
Триггеры	Пользователь на экране «знакомства» нажимает кнопку «Найти пару».
Preconditions	У пользователя заполнен профиль и он дал доступ к своим социальным сетям.
Пост-условия	Пользователь удовлетворен найденным партнером и они общаются. Либо пользователь не доволен результатом подбора и запускает сценарий заново.

Далее идут User Story. В отличии от User Case, User Story это художественное описание сценария с точки зрения пользователя. Строится по принципу User -> Action -> Value. Как покупатель, я хочу получить товар ночью, так что я смогу продлить романтический вечер. И мы описываем критерии приемки:

• Курьеры работают ночью
• Склады разбросаны по всему городу
• Дежурный оператор на связи 24/7

Множество сторей формируются в Epic. User Story со временем меняются и не являются финальными требованиями к разработке. User Story не про требования, а про пользовательскую ценность.

Все это должно укладываться в Jira, или любой другой таск-менеджер. Один из вариантов: Epic описывает лишь что нужно сделать, а не как. Это business requirements, которые обязательно проходят Epic review. Отсутствуют технические детали, уровень стратегии, и Epic должен укладываться в один квартал.

Story описывает функциональность, и пишутся владельцем продукта, особое внимание на acceptance criteria. Реализация не должна занимать более 2 недель. И необходимы финальные дизайны, без них не удастся оценить трудозатраты. Если на реализацию требуется 2 недели и 1 день, то это две разных story. Из сторей должно быть удобно писать release notes. Помним, что 10% спринта уходит на grooming.

На уровне ниже живут задачи, они пишутся тимлидами для разработчиков. Какое API использовать или написать, какая либа.

Уход за требованиями

Требования позволяют понять, каких показателей мы хотим достичь, а по каким критериям мы поймем, что работа завершена. Если у стейкхолдеров возникают вопросы к реализованной фиче, то главный способ разрешить конфликт это согласованные бизнес-требования. Требования могут быть функциональными и нефункциональными. Функциональные описывают, что делает приложение. Нефункциональные адресованы к принципам закрытия пользовательской боли. Отдельно выделяются высокоуровневые требования про пользовательские боли (бизнес-требования), и требования от стейкхолдеров. Например, функциональные требования могут звучать так: вбить условия поездки на такси, выбрать такси из предложенных. Нефункциональные требования про доступность серверов при DAU = 1 000 000 с пиками в 9 и 18 часов, или использовать Quadtree для поиска ближайшего дрона.

В требованиях могут быть предположения: ожидаемая нагрузка 100 000 пользователь в день, и команда закроет задачу за одну итерацию. Предположения должны быть категоризированы, и перепроверяться время от времени. Требования должны быть исчерпывающе полны, консистентны, детальны, измеримы, реализуемы и тестируемы. Так, если мы делаем Instagram, то мы предполагаем 1 500 000 000 пользователей, огромные нагрузки на read, и большие на load. В среднем, в день будет загружено 3 000 000 000 фоток, 3 * 10⁹. В сутках 86 400 секунд, можно округлить до 100 000 = 10⁵. Это только read, а write может быть в 1 000 раз тяжелее. Одна фотка весит 200кб, и у нас фоток в день 3 * 10⁹ = … и так далее. Запоминать ID’шник фотографии, дату поста. Если у нас key-value, то нужно ли 2 таблицы, в одной таблице ключ это фотка, а вторая таблица ключ = пользователь. И бекап всего этого добра по правилу 3-2-1: хранить три бекапа, на двух разных девайсах, один из которых не в сети организации.

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

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

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