Методы сбора требований: как и когда спрашивать, как и когда слушать, а когда просто дать людям самим все написать
Всем привет!
Сегодня у нас тема про выявление требований, потому что что? Правильно, потому что мы знаем, что требования нужно именно выявить, а не просто собрать, как грибы на полянке, а еще мы знаем, где во всем этом роль проектного менеджера
Поэтому сегодня мы говорим про роль бизнес-аналитика, его задачи, и конкретные инструменты: под разную задачу, разную глубину, разный контекст. И все по порядку, как мы любим.
В чем задача бизнес-аналитика при выявлении требований?
Если мы посмотрим в Свод знаний по бизнес-анализу (Business Analysis Body of Knowledge, BABOK), то увидим, что у бизнес-аналитика есть задачи:
- Выявление и определение бизнес-потребностей, то есть БА может понять, идентифицировать и описать реальную проблему и / или возможность бизнеса, которая требует проведения каких-либо изменений
- Выявление и сбор требований, то есть БА может понять, идентифицировать и собрать явные и неявные требования, используя различные методы (интервью, опросы, воркшопы, анализ документов и т.д.)
И вот получается, что тут нам очень важно понимать: в каком ракурсе мы работаем, как бизнес-аналитик, и в каком контексте (какой у нас тип компании из корпоративной культуры, ее оргструктуры и каких-то инструментов, а также, что это за компания и в каких условиях она работает, это B2B / B2C / B2G, технологичная ли она, и др. вопросы).
В Business Analysis Body of Knowledge (BABOK) понятие ракурса относится к ключевым и предполагается, что он задает фокус, инструменты, техники, роли и ожидаемые результаты анализа. Ракурсом могут быть Agile, Business Intelligence, Информационные технологии, Бизнес-архитектура, Управление бизнес-процессами и т.д.
Например:
Ракурс Бизнес-архитектура (когда мы смотрим на моделирование бизнеса в целом: связь между стратегией, процессами, людьми, технологиями), и у нас есть задача определить бизнес-потребности.
Как это может выглядеть? Бизнес-аналитик изучает стратегию компании по выходу на новые рынки и текущие возможности бизнеса (системы и процессы). Аналитик может выявить в ходе изучения, что существующая ИТ-инфраструктура не масштабируется для поддержки международных операций (например, сайт, чат-боты, CRM, системы оплат), и определить потребность в изменении ИТ-инфраструктуры, процессов и систем для выхода на новый рынок
Смекаете?
То-то же. Давайте дальше, добавим немножечко про контекст. Контекст у нас может быть внешний (что влияет на компанию, где мы работаем снаружи: политика, экономика, социалочка, технологии, помочь нам собрать такую информацию может PEST-анализ) и внутренний (когда влияют изнутри люди, инструменты, оргструктура и культура, эту информацию собираем с помощью COPS-анализа)
Чтобы этот контекст понимать, мы можем посмотреть в эти анализы, сделать какие-то выводы, и подобрать для себя подходящий конкретно нам в роли бизнес-аналитика инструмент. Как нам это сделать?
Давайте начнем с того, что сначала посмотрим, а какие есть вообще инструменты и способы собрать информацию
Какие способы есть для выявления и сбора требований?
Мы решили узнать у заинтересованных сторон, что же им нужно, что же им требуется, что у них не получается делать так, как они хотели бы делать, в этом нам может помочь:
- интервью (анкетирование) — это сбор информации от участников процесса с помощью вопросов
- наблюдение — это сбор информации от участников процесса с помощью … наблюдения. Садитесь рядом и смотрите за тем, как конкретный человек выполняет конкретные действия и фиксируете их, в процессе задаете вопросы (немножко интервью, получается)
- анализ документов — это посидеть, почитать описание процесса, документы, которые появляются в ходе выполнения процесса и сформулировать представление о состоянии, проблемах, возможных улучшениях
- воркшоп — это сбор информации с помощью какой-то активности, типа мозгового штурма, есть некий регламент проведения и роли для участников
Что нам нужно знать об этих способах? В первую очередь, что все они применяются в отношении какого-то процесса и людей, занятых на этом процессе (или нескольких). То есть стейкхолдерам не нравится, что низкие показатели продаж, значит, мы сначала пойдем и соберем информацию, а что там вообще в продажах происходит.
Опрос (интервью, анкетирование)
Интервью, анкетирование — это техники, которые относятся к методу исследования в виде опроса (подушню немножечко). Опрос предполагает, что мы устно или письменно задаем вопросы определенной выборке людей, чтобы собрать какую-то информацию. Интервью предполагает, что это устная беседа с одним конкретным представителем выборки, а анкетирование — это письменный сбор данных с какой-то группы.
В интервью мы можем использовать как закрытые, так и открытые вопросы, но предпочтение отдаем открытым (они требуют развернутого ответа, описания, объяснения, начинаются с «Расскажите», «Как вы думаете / считаете», «Почему» и т. д.). В анкетах предпочитаем закрытые, так как на большую выборку людей проще обработать результаты от вопросов в духе «Оцените от 1 до 5, где 1 = плохо, а 5 = хорошо, этот пример закрытого вопроса».
Помимо этого есть рекомендации избегать наводящих вопросов, которые подталкивают к определенному ответу (правда же, что мои статьи лучше и лучше?), ну и всяческие принципы типа прозрачности, однозначности, понятности и т. д.
Я обычно провожу интервью ДО того как читаю существующие документы (регламенты, должностные инструкции), почему? Потому что так я не давлю на опрашиваемых сотрудников своим представлением о процессе. Я только слушаю, я не оцениваю то, насколько описываемый бизнес-процесс близок к тому, что был на бумаге. Я не поправляю, не влезаю, не замечаю отклонений / несостыковок (я о них не знаю), и поэтому не представляю угрозы, не становлюсь причиной для стресса у опрашиваемых участников.
Наблюдение
Тут понятно, что мы смотрим, как именно работают участники процесса / стейкхолдеры, какая-то выборка людей, которые представляют для нас интерес.
Я наблюдаю так: сажусь рядом и смотрю за работой, прошу научить меня так, как если бы я была новичком на этой должности и мне нужно было бы завтра работать самой на этом самом месте, фиксирую время на выполнение задач, фиксирую порядок действий, фиксирую особенности поведения человека, если есть возможность, то отмечаю когнитивную нагрузку (звонки, подходы коллег к столу поговорить / уточнить / спросить).
Если я не могу сидеть рядом, то я записываю встречу, где мне показывают экран и все программы, в которых работает человек и показывает свои типовые действия, да, это тоже валидно, но обычно это работает на тех местах, где я уже знаю, как работает процесс in general / в общем и целом, и я могу опираться на свой опыт, наблюдая за нюансами / особенностями.
На выходе от наблюдения у нас чаще всего могут быть записи о ходе процесса, таймлайны (карты дня / карты недели / карты занятости сотрудника), в которых указаны временные интервалы на выполнение задач / границы выполнения каждого их этапов процесса и т. д., могут быть списки инструментов и их характеристики, характеристика окружения (техника, персонал, рабочее место и его качество: температура, свет, удобство стола / стула, сменной одежды, места для приема пищи и так далее).
Наблюдение должно очеловечивать собранную информацию и давать нам представление, где влияние человека на процесс, а где сам процесс.
Анализ документов
Я обычно смотрю на документацию после интервью / наблюдения, чтобы у меня была возможность увидеть и сопоставить описание процесса существующее и то, которое я составила на момент наблюдения / опроса, чтобы увидеть расхождения между бумагой и практикой, совпадения, понять, почему появились расхождения, почему совпадения есть, еще полезно понять, почему нет документации, если ее нет (там и описывать толком нечего, или всем и так все понятно, или никому до этого не было дела, что теперь, писать задним числом что ли?).
В документах мне нужны: даты составления / изменения, ответственные, инструменты, требования жесткие к процессу (например, со стороны регулирующих органов), метрики и правила их расчета, регулярность обновления документации, правила хранения.
Можно смотреть на документацию ДО опросов, до наблюдения, до воркшопов, но тогда у вас есть все шансы давить на изучаемых стейкхолдеров / участников процесса тем, что вы будете подмечать расхождения и тыкать в них пальцем, что резко снизит вашу привлекательность как человека, которому можно честно рассказать, что ж там происходит, а не собранная правильно информация не станет правильными и полными требованиями!
Воркшопы
Как я сказала в определении, это некая активность, которую вы придумали, чтобы собрать информацию о проблеме, требуемом решении, потребностях стейкхолдеров. Здесь вы ограничены толькой вашей фантазией и глубиной требуемой активности (какую задачу по размеру на воркшопе вы хотите порешать).
Обычно на воркшопах удобно решать вот эти задачи:
- согласовать единое понимание и первопричины проблемы / ситуации
- поиск и согласование подходящего решения для выявленной проблемы / ситуации / негативного паттерна
- поиск и согласование подходящего сценария использования какой-то позитивной ситуации (мы часто не знаем, что делать с добром и как его приумножить)
Воркшопов по типам не так много, чаще это либо формат мозгового штурма, либо более формализованные встречи, типа когда генерация идей идет по сценарию работы над CJM, JTBD, анализа конкурентов.
Например, мы понимаем, что у нас есть проблема: отделы направляют в отдел ИТ хаотичные запросы на доработку внутренней ссамописной корпоративной системы, а рабочая группа (часто это представители бизнеса + ИТ) пытается расставить приоритеты, но! Нет дорожной карты, нет критериев ценности, кто громче скажет из представителей бизнеса о своей хотелке, тот и главный приоритет.
В результате доработки носят точечный характер, не закрывают корневые проблемы, а ИТ воспринимается не как поставщик продукта, услуги, а как «песни по заявкам на школьной дискотеке».
Чтобы вывести команду из этого порочного круга, можно провести целевой воркшоп: собрать поток запросов за квартал / месяц от разных руководителей, чтобы они наклеили или написали все эти запросы на стикерах на доску, поделив при этом на кучки «отчеты», «интеграции», «ошибки», «новые поля» и т. д. А рядом выписать стратегию и ее основные направления, и то как предполагается на тактике / операционке достигать эту стратегию.
Дальше дать руководителям разных отделов совместно поработать над всеми этими запросами сообща, отвечая на вопросы:
- Сколько из этих запросов повторяются из месяца в месяц?
- Сколько из этих запросов — костыли к текущей системе, а не развитие и соответствие стратегии?
- Если бы мы решили эти запросы сегодня, то решили бы мы проблему навсегда или просто отсрочили ее?
И другие похожие вопросы.
И вот пускай они моделируют альтернативу:
✨ как выглядела бы работа, если бы система управлялась как продукт, с владельцем, видением, дорожной картой и прозрачными правилами приоритетов ✨
Цель в таком случае у воркшопа не навязать продуктовую модель, а помочь участникам самим увидеть ее ценность через анализ своих же запросов, проблем и стратегии. В итоге получили бы требования к ним же самим же по переходу на продуктовую разработку + понимание истинных потребностей бизнеса, зашитых в стратегию и тактику.
Воркшоп ли это? Да. Имеет ли он стандартизированный какой-то формат? Нет. Собирали бы требования к продукту, то могли бы организовать в формате поиска оптимального пути пользователя через CJM, был-бы воркшоп через формат.
Такие дела!
Как понять, какой метод выявления и сбора требований использовать?
Вот тут вот мы возвращаемся к нашему контексту и подбираем инструмент с учетом контекста, но! Мы еще и помним про принцип брать данные оттуда, где они есть, а не искать их там, где их нет.
- Люди легко говорят — проводим опросы (интервью и анкеты), они нам расскажут.
- Люди мало говорят, но легко что-то делают — мы наблюдаем, исследуем артефакты от их работы в виде документов.
- Люди много взаимодействуют друг с другом — отлично, у нас будут воркшопы.
- Люди не знают, что нам рассказать, что дать посмотреть или что делать, — подбираем точечно через комбо из интервью, анализа, наблюдения, воркшопа.
Это про то, где лежат данные.
А контееееееееееееекст? Контекст чуть поширше.
Мы смотрим на наши результаты анализа компании внутри и снаружи, и потом как понимаем!
На примере COPS-анализа блока культуры сейчас давайте подберем:
- Если культура в компании открытая, доверительная, поощряется инициатива → люди готовы говорить честно, предлагать идеи, спорить, участвовать → используем воркшопы, интервью → получаем не просто выявленные требования, а совместно выстроенное, провалидированное, верифицированное решение выявленной проблемы
- Если культура в компании закрытая, есть страх высказываться, сверху все решают не спросив низы, → люди не скажут правду в лицо → используем наблюдение, анализ документов, аналитику, анонимные анкеты с закрытыми вопросами
На примере блока про людей давайте тоже посмотрим:
- Если персонал компетентный, технически грамотный, умеет формулировать → можно использовать технические интервью, совместное проектирование прототипов / моделей решений для поиска идей → так получится выявить и собрать требования на уровне реализации, а не абстрактных хотелок
- Если персонал перегружен, не имеет нужной квалификации, высокая текучка → люди не могут тратить время на анализ, погруженность, у них нет времени, у них есть текучка с костылями, которые делают больно → используем наблюдение без дергания сотрудников, упрощенные опросы в 1-2 вопроса, логи по системам для аналитики → получаем список костылей, болей, проблем, где понимаем, что отсутствие боли и костыля наше требование
Смекаете?
И так по всем направлениям. Контекст помогает нам решить, что мы берем из инструментов и как адаптируем, потому что использовать не адаптированный инструмент в голом виде грешно для хорошего бизнес-аналитика!
Собственно, на этом мои полномочия все. Могу предложить вам разобрать детально план воркшопа из примера выше. Надо?
Пишите мне комментарии, задавайте вопросы и подписывайтесь на канал: