Привет, Хабр! Меня зовут Артем Евтеев, я ведущий аналитик в МТС Web Services. Кажется, каждый бизнес-аналитик (и не только) хотя бы раз в жизни слышал о книге «Разработка требований к программному о��еспечению» Карла Вигерса и Джой Битти.
В очередной раз собрался освежить в памяти теорию — и меня посетила мысль: а насколько изложенное в «инструкции бизнес-аналитика» действительно перекликается с реальностью? Как часто эта «настольная книга» подходит для решения рабочих задачах?
В жизни теория нередко сочетается с практикой. Но так ли это в профессии бизнес-аналитика в ИТ-компании — предлагаю разобраться.
Рассмотрим три основных момента:
Откуда берутся бизнес-требования.
Что они собой представляют.
Как ими управлять.
Итак, поехали!
Бизнес-требования
Ни одни требования не появляются просто так, из ниоткуда. За каждым стоит потребность. У любого бизнеса их тысячи. Это может быть увеличение выручки или эффективности сотрудников, автоматизация, снижение затрат, улучшение NPS и так далее. В рамках удовлетворения потребностей или целей и складываются бизнес-требования.
«Бизнес-требование — высокоуровневая бизнес-цель организации или заказчиков системы».
Бизнес-требования не могут быть произвольными, они должны регулироваться. Для этого существуют корпоративные правила и принципы.
«Бизнес-правило — политика, предписание, стандарт или правило, определяющее некоторые стороны бизнес-процессов».
Для наглядности предлагаю взглянуть на пример:
Бизнес-требование:
Увеличить конверсию заявок на 15% к концу отчетного периода.
Бизнес-правило:
Если сумма заказа превышает 50 000 рублей, применяется бесплатная доставка.
Как аналитик определяет бизнес-цели и бизнес-правила
В реальности за каждым требованием почти всегда стоит KPI — его спускает руководитель продукта, директор по ИТ, глава направления. И пока во время презентаций звучат красивые формулировки, в рабочем режиме команда сталкивается именно с KPI, а не с абстрактной «ценностью для бизнеса». Поэтому «нелогичные» запросы, странные приоритеты и внезапные развороты курса в середине проекта — чаще следствие не глупости, а того, что у разных людей KPI не совпадают и тянут проект в разные стороны.
В каждой организации есть свои утвержденные регламенты, стандарты и инструкции, в соответствии с которыми она осуществляет свою деятельность. Бизнес-процесс просто не будет функционировать должным образом, если все действия в рамках него не зарегламентированы или не описаны на уровне организации. Кроме того, нередко существует устная договоренность, которая соблюдается всеми участниками процесса.
Также к бизнес-правилам добавляется баланс между формальными стандартами и неформальными принципами компании. Например, команда обязана соблюдать стандарты безопасной разработки, отказоустойчивости, логирования и мониторинга. Но если разработчик знает, что его личный и командный KPI — это «закрыть столько-то задач до конца месяца», а за технический долг никого не наказывают, решение, что именно «влезет» в спринт, становится очевидным.
При этом принципы компании — это реальные ограничения. Например, «мы не можем терять данные», «мы не можем падать в прайм-тайм», «мы не можем занимать канал связи больше, чем на X%». Это рамки, в которых команда обязана существовать. Иногда именно они объясняют, почему архитектурное решение кажется избыточным или усложненным: оно отражает невидимый KPI бизнеса — не допустить сбоя или штрафа. Снаружи это выглядит как «зачем вы так усложнили?», изнутри — как попытка одновременно соблюсти стандарты компании, выполнить KPI и успеть в релиз.
Поэтому, когда мы говорим о бизнес-требованиях «в теории и на практике», важно честно отвечать на несколько вопросов:
— Чей KPI сейчас реально рулит решением?
— Как он измеряется?
— Какие стандарты мы обязаны соблюдать?
— Какие принципы ни в коем случае нельзя нарушить?
Пока эти аспекты не проговорены, требования кажутся хаотичными и противоречивыми. Но стоит связать каждое «сделайте так» с конкретным KPI или принципом — становится гораздо легче объяснить и команде, и себе, почему проект выглядит именно так, а не как в идеальных учебных примерах.
А судьи кто?
У каждой фичи и доработки есть свое «заинтересованное лицо», или стейкхолдер, — человек, группа или организация, которые активно задействованы в проекте, подвержены влиянию процесса или результата либо могут на них влиять.
Заинтересованные лица бывают внутренними или внешними по отношению к команде проекта и разрабатывающей организации:
Каждый аналитик на продукте должен (обязательно) знать и (необязательно) любить своих стейкхолдеров. Ведь именно они, как пр��вило, генерируют и валидируют требования.
Обычно на практике аналитику поступают от стейкхолдера «пользовательские требования».
«Пользовательское требование — задача, которую определенные классы пользователей должны иметь возможность выполнять в системе, или требуемый атрибут продукта».
На деле это может быть не только задача, но и функция или проверка данных внутри процесса. На их основании аналитик подготавливает функциональные требования. Это закладывает основу для дальнейшей разработки. Поэтому сбор и анализ пользовательских требований — важный и ответственный этап.
Бывает, стейкхолдеры отсутствуют либо они не заинтересованы в развитии продукта или проекта. В таких случаях можно и даже нужно проявить инициативу и взять всё в свои руки.
Сам себе стейкхолдер
Поделюсь опытом работы на продукте, где в мои обязанности входило его развитие и генерация требований. В этой ситуации я в какой-то степени сам был и заказчиком, и исполнителем. Как в таком случае выявлялись бизнес-требования и бизнес-цели?
Например, совет директоров решил уменьшить долю бумажного документооборота на 80%, оставив на бумаге только самые важные. Мы с руководителем решили эту задачу двумя интеграциями. Первая была реализована с порталом компании, откуда пользователи смогли напрямую оставлять заявки, без подачи бумажных заявлений. Вторая позволила полностью перевести документооборот с бухгалтерией в цифровой через наш продукт. Кроме того, реализованные функции облегчили ручной труд сотрудников, готовивших бумажную отчетность и отправляющих ее курьерами в бухгалтерию.
Параллельно с реализацией бизнес-целей мы пилили функциональность, которая упрощает пользователям их работу. Для этого несколько раз в месяц проводили custdev (Customer Development).
Определение требований на практике
«Совместная работа возможна только тогда, когда все участники процесса разработки знают, что именно необходимо для успеха, и когда они понимают и уважают стремление их соратников для успеха».
Наличие у стейкхолдера четких требований встречается не так часто, и его приходится вырабатывать на совместных встречах (порой повторяющихся и очень продолжительных).
Самое главное, чтобы перед началом разработки перечень необходимых пунктов был сформулирован и согласован всеми заинтересованными сторонами. Это позволит избежать возможных конфликтов в будущем, а также послужит основой для критериев приемки разработанных функций.
Конфликты между заинтересованными лицами проекта возможны. Бизнес-требования иногда отражают организационную стратегию или бюджетные ограничения, которые не всегда понятны пользователям.
«Пользователи, раздраженные тем, что менеджмент насильно внедряет новую информационную систему, не всегда хотят общаться с разработчиками ПО, считая последних предвестниками неблагоприятного будущего».
Избежать таких конфликтов помогает ясное и полное обсуждение целей и ограничений проекта, которое может убедить пользователей и предотвратить споры и обиды.
Роль custdev
Customer Development в такой модели — единственный способ не уйти в «функции ради функций». При этом плохие требования никуда не исчезают: они появляются, когда аналитик начинает придумывать решения за пользователя или не валидирует гипотезы.
Успех интервью с пользователями или заказчиками в первую очередь зависит от их заинтересованности в работе и развитии продукта. Многие пользователи не хотят оставлять обратную связь. Возможные причины — опасения, что на изучение новых функций придется потратить много времени или что они приведут к ужесточению контроля.
Когда мы проводили custdev с пользователями, почти всегда сталкивались с одной и той же реакцией: «А зачем менять? Мы же так работали десять лет, все нормально». И здесь важно донести ключевую мысль: фича не ломает привычный рабочий процесс — она его упрощает. Люди боятся, что «новое» означает «сложное», и задача аналитика — развеять этот страх. На custdev мы всегда объясняли: да, шаги будут выглядеть иначе, но итог — меньше ручной работы, путаницы, ошибок. Когда пользователь понимает, что новый механизм экономит ему время, а не отнимает, сопротивление исчезает.
Отдельная часть custdev — разговор про контроль и отчетность. Пользователи часто воспринимают их как «дополнительное давление», но для бизнеса это необходимое условие для рационального использования ресурсов. Когда система фиксирует действия, бизнес получает возможность увидеть, где возникают узкие места, где процессы тормозят, какие шаги дублируются или выполняются слишком долго.
Это позволяет понять, где можно снять нагрузку, улучшить интерфейс, перераспределить обязанности или внедрить автоматизацию. Важно объяснить, что чем прозрачнее процесс, тем легче сделать продукт удобнее и честнее — как для компании, так и для самих пользователей.
Существуют различные виды сustdev:
Глубинное интервью. Позволяет определить, какие проблемы и ошибки в продукте нужно решить и какого функционала ему не хватает.
Опросы пользователей. Позволяют понять мнение об имеющихся или новых фичах.
A/B-тесты (UX-тесты). С их помощью сравнивают разные элементы продукта — например, дизайн кнопок, баннеров на сайте и так далее — и предлагают респондентам выбрать лучшие. A/B-тесты помогают подтвердить или опровергнуть выдвигаемые в процессе аналитики гипотезы.
На этапе сбора требований и опроса пользователей может родиться много гипотез, с которыми что-то нужно делать.
«Гипотеза — это наше предположение, что какое-то изменение исходных данных приведет к ожидаемому результату».
Критерии качественной гипотезы:
У нее есть четкая цель.
Она влияет на какую-то из метрик.
Она подтверждена цифрами и данными. Если нет, то и брать ее в работу не стоит. Это слишком рискованно: на разработку будут потрачены ресурсы и команда понесет убытки при реализации бесполезных функций.
Гипотезы можно формировать:
Анализируя схожую функциональность у конкурентов. Возможно, у других продуктов на рынке есть фичи, которые могли бы повысить метрики у вас.
Проводить custdev или количествен��ые исследования.
Количественные исследования
Это еще один способ подтвердить или опровергнуть гипотезу. Так можно узнать, какая доля людей думает или действует определенным образом. Результат — выводы, основанные на числах и процентах.
Для количественных исследований подходят те же форматы, что и для custdev:
Опрос пользователей можно проводить на всех жизненных циклах продукта, чтобы проверять гипотезы или собирать отзывы о функциях сервиса. Сначала готовится список вопросов в определенном порядке, затем опрашивается несколько пользователей, содержание корректируется и раскатывается на всю выборку.
А/В-тестирование — важный инструмент в руках бизнес аналитика. Они позволяют проверить эффективности двух вариантов функции.
Порядок проведения А/В-тестирования
Подготовка
Определите, какую метрику хотите увеличить. Также нужно составить список метрик, которые будут измеряться в каждом эксперименте, потому что гипотезы могут совершенно неожиданно повлиять на другие показатели.
Сформулируйте гипотезы — чем больше, тем лучше. Постарайтесь собрать все возможные варианты того, что может повлиять на результат.
Как понять, с какой гипотезы начать тест? Например, можно проранжировать их по степени важности. Для этого все гипотезы выносим на отдельный лист и проставляем оценки от 1 до 3 — в зависимости от сложности реализации и ценности, которую, как нам кажется, они принесут.
Соберите дополнительную информацию, чтобы отсеять банальные варианты. Возможно, какие-то гипотезы уже проверялись и на них не стоит тратить время. Еще помогают убрать лишнее маркетинговые исследования аудитории и рынка.
Проверьте гипотезы на адекватность, своевременность и реалистичный профит. Учитывайте контекст — он тоже будет влиять на результаты эксперимента.
Подумайте, как повлияет тест на стратегию в целом. Поведение покупателей изменится сиюминутно или это будет планомерное и глобальное изменение?
Заранее выясните у продуктовых аналитиков, получится ли правильно оценить результаты теста.
Установите базовый показатель. Определите метрику, которую хотите увеличить. Нужно вычислить ее средний показатель за период от 1 до 6 месяцев и установить чувствительность эксперимента. Это минимальное изменение, которое можно считать достоверным при заданной статистической значимости. Статистическая значимость — это мощность и достоверность эксперимента. Их принято устанавливать в стандартных значениях от 80% и 95% соответственно.
Определите размер выборки — количество людей, которые должны поучаствовать в тесте, чтобы результаты получились достоверными. Определить ее помогают специальные калькуляторы (и раз, и два), куда можно внести средний показатель, и то, на сколько процентов мы хотим его увеличить.
Обратите внимание: чем выше ожидаемый прирост, тем меньше выборка. Чем он ниже, тем чувствительнее эксперимент, а значит, для его проверки понадобится больше пользователей. Если же установить высокий уровень прироста, то конечные результаты обеих версий будут более вариативными. Из-за широкого разброса показателя для эксперимента понадобится меньше пользователей.
Нужно найти разумный уровень минимального эффекта, при котором диапазон получаемого показателя не превышает половины базового уровня (среднего показателя). Допустим, базовый уровень — 10%. Если мы установим минимальный эффект в 5%, тест будет считаться успешным в диапазоне от 5 до 15%, то есть разброс будет слишком большим.
Начало тестирования
Эксперимент должен идти, пока все пользователи из выборки не выполнят действия. Вероятно, у вас может появиться соблазн подглядеть результаты в процессе. Этого делать не стоит, потому что в середине эксперимента они могут подтверждать вашу гипотезу, а потом окажется, что это не так. Обязательно доведите тест до конца.
Оценка результатов
Это можно сделать в том же калькуляторе. Нужно ввести полученные данные и размер выборки, а программа сама сделает вывод.
Теперь остается понять, что мы видим в результатах: причинно-следственную связь или корреляцию. И сделать выводы, проверив себя на подмену понятий. Разберемся в их отличиях:
Причинно-следственная связь — одно событие напрямую влияет на другое.
Провокационная тема письма увеличила открываемость.
Корреляция — одно событие влияет на другое, но не напрямую.
Провокационная тема письма увеличила кликабельность.
Эвристическая подмена вопроса — когнитивное искажение, при котором мы упрощаем решение.
Провокационная тема увеличивает кликабельность на 6%! Запускаем всем!
Перед тем как делать выводы, важно учитывать и анализировать все условия. Например: каков баланс групп по ключевым ковариатам? Нет ли эффекта времени рассылки? Каков эффект размера (Cohen's d)?
Также стоит учитывать эффект новизны. Новые приемы или макеты всегда немного увеличивают показатели. Независимо от того, соответствовал эксперимент ожиданиям или нет, вы получите бесценные знания о поведении своих клиентов. Эти данные можно будет использовать, чтобы увеличить ценность компании в долгосрочной перспективе.
Ошибки при проведении А/В-тестов
Тестирование на малых данных. Тогда либо результат тестов будет недостоверным, либо понадобится много времени, чтобы эксперимент оказался статистически значимым.
Не проверили изменения в метриках при неизменных исходных данных. Для этого используют A/A-тест — аудитории показывают два одинаковых варианта и отслеживают разброс результатов. Это помогает понять, насколько сегмент подходит для анализа.
Методы приоритизации и порядок оценки задач для бэклога
В теории приоритизация — это почти математическая процедура. Вспоминаем учебник: термины «приоритизация по ценности», «матрица Эйзенхауэра» звучат красиво и логично. Но в реальной жизни бизнес-аналитика в ИТ эти методы работают далеко не всегда, потому что сам бэклог — живой организм, на который влияет всё: от KPI руководства до срочных регуляторных требований, инцидента и внезапного дедлайна «сделайте к пятнице».
Тем не менее структурный подход нужен. Иначе бэклог превращается в «мешок фич», в котором никто, кроме автора, не ориентируется. На практике хорошо работает комбинированная схема, когда классические методы служат опорой, а сверху накладывается реальная продуктовая логика.
Оценка задач обычно начинается с попытки понять, какую цель закрывает каждая из них: помогает ли увеличить выручку, сократить издержки, ускорить работу пользователей или снять операционные риски. Затем команда оценивает, насколько сложна задача, что она «стоит» в плане времени, ресурсов и потенциальных последствий. И только после этого формальные методы приоритизации действительно дают пользу — они позволяют зафиксировать логику выбора, чтобы решения не превращались в набор пожеланий. Однако дальше неизбежно начинается корректировка под реальность: что-то нужно сделать срочно из-за регуляторики, что-то из-за зависимости другой команды, а что-то — из-за персонального KPI. И задача аналитика — соединить все эти факторы в осознанную стратегию развития продукта.
Пример: есть маленькая фича — обновление одного сервисного справочника. Ценность для пользователя почти нулевая, команда считает ее «мелочью». Но она блокирует интеграцию с новым партнером — ключевым KPI продуктового директора. Приоритизация в итоге простая: низкая бизнес-ценность превращается в высокий приоритет, потому что стоит на пути другой, более важной задачи.
Так в чем же суть нашей работы
Когда читаешь Вигерса, кажется, что работа бизнес-аналитика — это выверенный процесс: есть цели, требования, стейкхолдеры и методы приоритизации. В реальности же все устроено совсем иначе. Требования редко приходят в аккуратном виде, бизнес-цели прячутся за KPI руководителей, стейкхолдеры могут как помогать, так и мешать, а бэклог больше похож на поле боя, чем на стройную матрицу приоритетов.
Но именно в этом и состоит суть профессии: уметь соединять теорию с контекстом, переводить хаос в структуру, вытаскивать реальные потребности из разговоров и помогать команде принимать осознанные решения.
Пожалуй, в этом и заключается наша главная ценность: не бояться разницы между идеальными представлениями и реальностью, а уметь превращать второе в первое — шаг за шагом, фича за фичей.