Привет, Хабр!

Меня зовут Маргарита, я аналитик в департаменте e-commerce в «КОРУС Консалтинг». 

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

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

Почему план может не сработать

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

Вот основные причины нарушения плана, с которыми я сталкивалась:

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

  • Слишком оптимистичный план, в котором на каждую крупную тему выделена одна встреча (или меньше) и не заложен риск не успеть обсудить все вопросы.

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

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

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

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

Как составить надежный план: 8 шагов

Шаг 1. Определяем список функциональных блоков

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

  • Документация от заказчика. Иногда клиент уже имеет описание видения будущей системы или регламенты текущей работы.

  • Собственный опыт. Полезно вспомнить предыдущие проекты или обратиться к коллегам. Часто в компании можно найти подобный опыт и получить консультацию.

  • Референсы конкурентов, которые можно изучить.

  • ИИ также подскажет типовые блоки.

После предварительного изучения важно провести установочную встречу с заказчиком. На ней делается общий обзор проекта:

  • Цели, ожидаемый результат

  • Верхнеуровневый набор процессов и основных функций (например, регистрация, обработка заявки и др.)

  • Ожидаемый заказчиком список ролей, которые будут использовать систему (клиент, менеджер, администратор и др.) 

  • Ожидаемый заказчиком список интеграций с внешними системами (с ERP по заявкам, с CRM по клиентам и др.)

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

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

Шаг 2. Формируем список тем к обсуждению 

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

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

Если обобщить, обычно я выделяю такие темы встреч: 

  1. Основные роли пользователей в системе, их авторизация и регистрация

  2. Основные бизнес-процессы или функциональные блоки, каждый является отдельной темой

  3. Доступная функциональность для каждой роли 

  4. Прочие требования. 

В e-commerce проектах дополнительной темой является каталог продукции. В других областях могут быть свои темы, которые важно проработать отдельно.

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

Шаг 3. Определяем порядок тем

Основная идея: пройти по модели Вигерса (принятая в ИТ классификация требований) от бизнес-требований к пользовательским и затем к функциональным. Иными словами:

  1. Начать коммуникацию с заказчиком с бизнес-процесса

  2. Затем совместно обсудить наполнение интерфейсов пользователей всех ролей 

  3. Далее самостоятельно (или вместе с командами разработки смежных систем) описать техническую часть — хранение, обработку и передачу данных. 

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

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

Шаг 4. Планируем обсуждение каждого основного процесса на двух встречах

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

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

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

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

Шаг 5. Добавляем дополнительные встречи

Если мы знаем, что на проектах всегда что-то может пойти не по плану, то мы можем это предусмотреть. Я планирую встречи для обсуждения открытых вопросов через каждые 3-4 встречи по основным темам и в конце, после последней встречи. Это создает резерв для продолжения обсуждения тех тем, на которые не хватило времени или новых (не учтенных в плане) требований.

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

Шаг 6. Определяем даты и время встреч

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

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

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

Шаг 7. Согласовываем план с заказчиком

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

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

  • Увеличить срок и проработать тему сразу

  • Сохранить срок и заменить одну из тем в плане на новую

  • Сохранить срок и отложить новую тему на будущие этапы.

Шаг 8. Добавляем встречи в календарь 

Лучше сразу забронировать время в календаре, направив всем участникам приглашения на несколько встреч вперед. Если не сделать этого заранее, может быть сложно найти доступный всем слот.

Основные рекомендации по планированию встреч с заказчиком

Резюмирую рекомендации из моего подхода к составлению плана-графика встреч с бизнес-заказчиком:

  1. В начале важно уделить время созданию примерного списка нужных функциональных блоков и сформировать из него список тем к обсуждению.

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

  3. Каждый бизнес-процесс лучше обсуждать на двух разных встречах, чтобы иметь возможность проанализировать и доработать его.

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

  5. Эффективнее всего проводить встречи по 1,5 часа с перерывом не менее чем один день.

Пример плана

Далее приведу пример плана-графика встреч по сбору требований к маркетплейсу, который составлен по описанным 8 шагам.

А какие лайфхаки для составления плана встреч с бизнес-заказчиком по сбору требований есть у вас? Буду очень рада узнать о вашем опыте в комментариях

Комментарии (0)