Многие думают, что работа бизнес-аналитика начинается с интервью, воркшопа, user story или описания процесса. На практике все ломается гораздо раньше.
Не на этапе формулировки требований. Не на этапе согласования. И даже не на этапе передачи в разработку.
Самый частый провал начинается в тот момент, когда аналитическая работа вообще не была спроектирована.
Это выглядит знакомо почти каждому, кто работал в проектах или продуктовых командах:
- бизнес-аналитик уже «собирает требования», но никто не договорился, в каком формате они нужны
- список стейкхолдеров есть, но реальные решения принимают совсем другие люди
- изменения прилетают бесконечно, потому что не определено, кто и как их утверждает
- важные договоренности живут в чатах, созвонах и чужой памяти
- качество бизнес-анализа оценивается по принципу «ну вроде справились»
В итоге команда уверена, что проблема в людях, в коммуникации или в том, что «бизнес сам не знает, чего хочет». Но корень часто оказывается глубже: не настроена сама система бизнес-анализа.
Главная ошибка в восприятии роли аналитика
У многих компаний и даже у части самих бизнес-аналитиков есть опасная привычка: воспринимать бизнес-анализ как набор реактивных действий.
Нужно что-то уточнить? Позвали бизнес-аналитика. Нужно описать процесс? Позвали бизнес-аналитика. Нужно разобрать требования? Позвали бизнес-аналитика. Нужно поговорить с бизнесом? Ну вы поняли, где там бизнес-аналитик?
То есть бизнес-аналитик превращается в универсального переводчика между всеми сторонами, но при этом редко получает возможность задать базовые правила работы, а именно:
- как именно будет проводиться бизнес-анализ
- кто должен участвовать
- кто принимает решения
- как оформляются изменения
- где хранится и как живет аналитическая информация
- по каким признакам вообще можно понять, что бизнес-анализ работает хорошо
Без этого бизнес-аналитик почти неизбежно начинает жить в режиме постоянного и героического латания дыр.
Почему требования сами по себе не спасают
Очень часто команда начинает нервничать только тогда, когда требования противоречат друг другу, теряются, постоянно переписываются или всплывают новые вводные в последний момент.
Но требования редко становятся такими сами по себе.
Обычно за этим стоит один из пяти системных сбоев:
1. Не выбран подход к аналитической работе
В одном проекте нужна более формализованная модель: с явными артефактами, статусами, согласованием и фиксированными точками принятия решений.
В другом важнее скорость, короткие итерации и быстрое уточнение гипотез.
Если это не определено заранее, каждая сторона начинает ожидать свой собственный формат работы. Бизнес ждет один результат, разработка другой, менеджмент третий. Бизнес-аналитик оказывается между ними и начинает закрывать несовместимые ожидания вручную.
2. Стейкхолдеры определены поверхностно
Наличие списка участников еще не означает, что вы понимаете реальный баланс влияния.
В любой инициативе есть как минимум несколько разных ролей:
- источник потребности
- носитель экспертных знаний
- пользователь будущего решения
- человек, который реально принимает решение
- человек, который может все заблокировать
- человек, который внешне не участвует, но потом приходит на финальном этапе и переворачивает стол
Если бизнес-аналитик не разобрался в этой конфигурации заранее, то «сбор требований» превращается в сбор случайных мнений.
3. Нет правил принятия решений
Это одна из самых дорогих проблем.
Когда не определено, кто утверждает требования, кто согласует изменения, кто решает спорные вопросы и как работают приоритеты, бизнес-анализ теряет управляемость.
Тогда проявляются типичные симптомы:
- любая новая идея становится срочной
- любое пожелание внезапно воспринимается как обязательство
- команда движется дальше без реального согласования
- на позднем этапе находится стейкхолдер, который говорит: «Я такого не подтверждал»
4. Информация есть, но ей невозможно пользоваться
У большинства команд информация вроде бы и не теряется. Она просто расползается по разным местам:
- часть в таск-трекере
- часть в документации
- часть на почте
- часть в чатах
- часть в голове самого бизнес-аналитика
- часть в протоколах встреч
- часть в презентациях
- а часть просто нигде
Формально следы остаются. Практически это уже не система, а информационный туман.
5. Никто не оценивает эффективность самого бизнес-анализа
Если команда анализирует продукт, процессы, сроки, риски, но не анализирует собственную практику, то одни и те же ошибки воспроизводятся снова и снова.
Например:
- бизнес-аналитик поздно подключает нужных людей
- документы постоянно требуют переработки
- согласование идет слишком долго
- артефакты слишком громоздкие или, наоборот, слишком сырые
- ключевые решения не фиксируются
- все это повторяется из проекта в проект, но не становится предметом для улучшения
Что отличает зрелого бизнес-аналитика
Зрелый бизнес-аналитик отличается не только тем, что умеет хорошо собирать и описывать требования.
Он умеет сделать еще одну важную вещь: настроить среду, в которой бизнес-анализ вообще становится управляемым.
То есть он работает не только с содержанием требований, но и с архитектурой самой проводимой им работы:
- определяет подход
- проектирует взаимодействие со стейкхолдерами
- помогает выстроить контур решений
- задает правила управления аналитической информацией
- смотрит на бизнес-анализ как на профессиональную систему, которую можно и нужно улучшать
И вот именно на этом уровне бизнес-анализ перестает быть обслуживающей функцией и становится полноценным управленческим инструментом.
Почему эта тема особенно важна сейчас
Чем сложнее среда, тем дороже обходится отсутствие порядка в бизнес-анализе.
А среда сегодня почти везде сложная:
- больше изменений
- больше зависимостей
- больше цифровых решений
- больше распределенных команд
- больше стейкхолдеров
- больше конфликтующих между собой ожиданий
- меньше терпимости к ошибкам и задержкам
В таких условиях бизнес-аналитик, который просто «умеет описывать требования», уже недостаточен.
Нужен такой бизнес-аналитик, который умеет настраивать систему работы так, чтобы команда не жила в бушующем пандемониуме с красивыми документами.
С чего начать на практике
Даже без масштабных реформ можно проверить себя по пяти вопросам:
- Понятно ли, как именно в этой инициативе будет вестись бизнес-анализ?
- Ясно ли, кто реально влияет на требования и решения?
- Определено ли, кто утверждает, меняет и приоритизирует требования?
- Можно ли быстро найти актуальную аналитическую информацию и понять ее статус?
- Есть ли у команды хоть какие-то признаки, по которым можно судить, что бизнес-анализ производится эффективно?
Если хотя бы на два вопроса ответ неочевиден, значит проблема, скорее всего, не в одном документе и не в одном воркшопе. Проблема в том, что сама работа по проведению бизнес-анализа не собрана в систему.
Где можно ознакомиться с этой темой глубже
Я подготовил большой подробный разбор третьего раздела BABOK, который как раз посвящен планированию и мониторингу бизнес-анализа.
В полной статье разобраны главы 3.1-3.5:
- планирование подхода к бизнес-анализу
- планирование вовлечения заинтересованных сторон
- планирование руководства бизнес-анализом
- планирование управления информацией бизнес-анализа
- определение возможностей улучшения эффективности бизнес-анализа
Там же я показываю, почему этот раздел многие недооценивают, хотя именно он в свою очередь задает фундамент всей аналитической работы, и даю практический инструмент, который можно использовать в реальной работе с инициативой.
Если вы хотите перейти от режима «собираю требования по ситуации» к более зрелой и управляемой аналитике, этот материал точно стоит прочитать полностью.