Чего он хочет? Как провести интервью с заказчиком, чтобы быть с ним на одной волне

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

В большинстве случаев интервью используется в комбинации с другими техниками:

• опрос;
• брейншторм;
• наблюдение;
• визуализация (прототипы, use case);
• документно-ориентированные техники.

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

Лайфхаки для успешного проведения интервью

1. Определите роли в команде

Когда мы говорим про бизнес, состоящий из нескольких представителей (product, owners, ЛПР, участники команды разработки со стороны стейкхолдера), важно «застолбить» зоны ответственности участников.

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

Чтобы ее составить, нужно:

— определить участников проекта;

— расставьте напротив каждого его роль: аналитик, продакт, разработчик, конечный пользователь (если имеется);

— укажите каналы связи, а также ограничения, если они есть (например, продакт доступен с 09:00 до 18:00 по Москве). Уважайте границы каждого человека и держите баланс;

— проставьте приоритеты / «вес людей» на проекте. Они могут выражаться в числовом выражение (от 1 до 5), помечены цветовыми маркерами или сопровождаться описанием. Главное, чтобы эти показатели отражали значимость человека на проекте, а также подсказывал, к кому можно прийти за помощью в той или иной ситуации.

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

2. Установите формат общения

Очень важно при знакомстве с клиентом проговорить формат дальнейшего общения. Согласуйте с ним:

— периодичность и длительность встреч;

— состав участников совещаний на основе матрицы ролей;

— формат общения: личный встречи, гугл-миты, диалоги в мессенджерах.

3. Готовьте резюме

Перед встречей с заказчиком согласовывайте как минимум за день время и тему разговора. Удобнее это делать в общих чатах. Можно добавить соответствующий хэштег (например, #ПредстоящаяВстреча).

Тему разговора достаточно объявить верхнеуровнево, без детализации. Она поможет вам подготовиться к встрече, а заказчику настроиться на разговор.

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

— дату проведенной встречи;

— принятые решения;

— дополнительные договоренности («отложенные решения» или задачи, требующие новой информации);

— предварительную дату следующей встречи.

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

4. Задавайте правильные вопросы

Вопросы для интервью должны быть:

А. Понятными

Б. Короткими

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

Хорошо, если ваш вопрос укладывается в простое: должны ли пользователи получать уведомления об изменениях в приложении и уметь их настраивать?

Полезно также использовать подводку к вопросу («давайте обсудим процесс авторизации в нашем приложении»). Если ваш собеседник склонен углубляться во все вопросы и часто отходит от темы, то подводка будет лишний раз напоминать ему о сути встречи и разговора.

5. Налаживайте взаимопонимание

Чтобы выстроить гармонию в общении с заказчиком:

Выявляйте «боли» и опасения клиента

Пример из практики Mad Brains: заказчик был против авторизации, но после разговора с аналитиком выяснилось, что он, скорее, боится большого количества экранов и усложнения пользовательского пути.

Мы предложили сделать авторизацию отдельной вкладкой, не блокирующей основной бизнес-флоу. Клиент остался доволен.

Будьте вовлеченными

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

Вот конкретный пример. В том году я и коллеги начали разрабатывать приложение для мусульман, на проекте я была аналитиком. На первой же встрече заказчик признался, что очень расстроен, что я не мусульманка. Надо было «налаживать мосты». Пришлось не один вечер посвятить изучению Ислама, намазов и их разновидностей. И уже через пару недель мы заговорили на одном языке.

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

Уважайте заказчика

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

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

Демонстрируйте уверенность

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

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

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

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

6. Визуализируйте

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

Кейс с проекта Mad Brains: командой обсуждали доработку экрана (не хватало атрибутивного состава), решали, какие данные добавить и как выводить. Встреча была тяжелая, никто не понимал, как точно это должно выглядеть.

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

7. Готовьтесь к интервью

Что это значит?

• Изучайте предметную область, в которой будет разрабатываться проект. Это поможет лучше ориентироваться в потребностях бизнеса и терминологии заказчика. 
• Подготовьте свою концепцию проекта. Встречаются клиенты, которые сами не знают, чего хотят: сделайте мне правильно, неправильно не делайте. Поэтому схема с концепцией будущего проекта упростит встречу не только вам, но и заказчику. На своих проектах я обычно накидываю схему в Miro, где фиксирую функциональный состав с комментариями/кратким описанием. 
• При наличии документации на проекте очень важно с ней ознакомиться. Когда вы понимаете, о чем пойдет речь, будет гораздо проще составить тот же концепт.
• Составьте список вопросов. Он поможет вести встречу по сценарию «вы рассказывайте, а я послушаю», ведь суть интервью — задать вопросы и получить на них ответы. Плюсом будет создать общий документ с заказчиком, где вы сможете оставлять вопросы, часть из которых разбираются на встречах, а на другую часть заказчик сам сможет отвечать по мере возможности.

8. Определите критерии успеха

Важный момент в работе с бизнес-заказчиками — определить, как именно оценивать успех проекта. Если для разработчиков критериями является DOD (Definition of Done), то для бизнеса более значимыми являются финансовые показатели: увеличение воронки, приток платёжеспособной аудитории, уменьшение зависимостей (от других компаний/внешних систем/наемного персонала), повышение точности аудита.

Определите метрики, которые будете использовать для отслеживания критериев успеха: Яндекс/Google-аналитика, обратная связь от конечных пользователей и т.д.

Проверьте гипотезы перед разработкой: соберите минимальный набор функционала и отслеживайте его применение/востребованность на рынке.

9. Определите скрытые и нефункциональные требования

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

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

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

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

1. Вопросы по нагрузке системы, особенно связанные со спецификой бизнеса и сезонностью: например, если система используется только в будни, тогда можем ли мы позволить себе выкатки/релизы в выходные?
2. Внешние ограничения на нашу систему по типу НПА, локализации (если выходим на международные рынки). Если мы ограничены в ресурсах, то не стоит вкладываться в использовании дорогостоящих технологий отказоустойчивости и безопасности. Для начала можно сделать систему проще, чтобы проверить гипотезу и дать «пощупать продукт».
3. Сроки хранения данных. 
4. Нормативно-правовые акты и ограничения.
5. Локализация.
6. Бюджет. Важное уточнение: заказчик не всегда понимает, что поддержка каких-то функций стоит дорого, особенно в случае с безопасностью и отказоустойчивостью. Вы должны проинформировать о рисках и прямом влиянии объема функционала на рост бюджета. 
7. Наличие инфраструктуры у заказчика. Если у заказчика уже есть свои мощности, лучше узнать сразу, чтобы не тратить время на ненужную работу. Какие-то данные могут уже быть в сервисах заказчика, что сокращает затраты на базовый функционал и позволяет быстрее собрать то, что нужно.

Продуктовый подход

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

Для того, чтобы избежать неоправданных ожиданий, нужно:

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

Вместо итогов. Помните: в глазах любого бизнес-заказчика его продукт – это самое важное, что вы могли делать в своей жизни. Самое прорывное и уникальное. Так что наберитесь терпения, искренне погружайтесь в предметную область и интересуйтесь деталями. Будьте вежливы, уважительны и открытыми. Эффективных интервью и успешных вам проектов!