Задавать вопросы — это основной способ сбора информации и один из важных навыков аналитика. Существуют разные виды вопросов. Наиболее простая классификация выделяет вопросы: закрытые и открытые. Открытые вопросы начинаются с вопросительных слов: "кто", "что", "где", "когда", "как", "почему". Они помогают получить развёрнутые ответы и новые знания, в отличие от закрытых вопросов, на которые можно получить только односложный ответ (Да или Нет). Чем больше открытых вопросов будет задано в интервью, тем больше информации можно получить.
Это выглядит совершенно базовым знанием (а так и есть), при этом знать и иметь навык совсем не одно и то же. Когда вы сидите перед респондентом и у вас несколько секунд, чтобы сформулировать вопрос, легко ли вам выбрать именно открытый вопрос? Я знаю за собой такую черту — я быстро сбиваюсь на закрытые вопросы, если я устала, волнуюсь или что-то отвлекло. Это потому, что навык открытых вопросов даже за много лет применения еще не стал совсем базовым в моей голове. В ИТ очень долго было принято задавать закрытые вопросы, чтобы быстрее подтвердить ожидаемое решение и заказчик «не придумал лишнего». Это приемлемо, если вам нужно подтвердить уже обсужденные договоренности, но совсем не годится для понимания контекста задачи и потребностей заинтересованных сторон.
Чтобы сформировать навык можно потренироваться закрытые вопросы переформулировать в открытые.
🔸Закрытый вопрос: Должен ли пользователь вводить пароль?
🔸Открытый вопрос: Как пользователю будет предоставляться доступ к данным?
Может быть много вариантов открытых вопросов для одного и того же закрытого. Давайте посмотрим как переформулировать вопрос, чтобы придать ему открытость: «Должна ли система автоматически сохранять результаты работы пользователя каждые 15 минут?»
Тут я должна признаться, что эти задачки взяты из книги Майка Кона «Пользовательские истории. Гибкая разработка программного обеспечения». Автор предлагает переформулировать вопрос в «Что пользователи будут делать, если система "упадет" во время их работы в ней?». В таком построении вопросов я вижу нюанс, из-за которого не назвала бы этот подход универсальным. Вопросы вида «Что будут делать» и «Как должно работать» вынуждают собеседника проектировать решение и/или строить предположения о будущем. Не всегда респондент имеет достаточно насмотренности или экспертизы в ИТ-решениях, чтобы сказать что-то действительно отвечающее его реальным потребностям. При этом нередко собеседники опасаются выглядеть недостаточно экспертными и не готовы честно сказать "как раз от вас я и жду предложений". В ответ вам предложат решение, не потому, что оно хорошо отвечает задачам пользователей, а просто говорящий где-то его видел и считает интересным. В итоге аналитик рискует потратить время на разбор этой информации или пойти по ложному пути. Поэтому, выбирая вопросы по схеме "как должно работать", нужно иметь представление о знаниях собеседника и готовность дальше развить разговор и объективно проверить результаты. Речь идет о вопросах вида:
Как часто должна система сохранять результаты работы?
Как система должна вести себя в отношении возможной потери результатов работы пользователя в случае сбоя или ошибки?
Кто должен выполнять сохранение результатов работы пользователя, учитывая возможность нештатных ситуаций?
Как на ваш взгляд должны сохраняться введенные данные?
Когда думала о вариантах вопросов, вспомнила еще одну книгу. Синди Альварес «Как создать продукт, который купят». В этой книге есть пример, в котором автор проговорила с респондентом как важна для него безопасность данных. А после (цитата)
«предложила ему $50, если он напишет девичью фамилию своей матери и номер карты социального страхования. Не раздумывая, тот достал шариковую ручку и потянулся к листу бумаги.» Если вам почему-то нужно спросить об ожиданиях или намерениях собеседника, то нужно помнить, что его поведение и контекст задачи могут в реальности отличаться от ожиданий. Например, вас может подвести формулировка «Достаточно ли, чтобы каждые 15 минут в системе сохранялись результаты вашей работы?». Не только потому, что по сути она закрытая и наводит на конкретный вариант решения, но и потому, что ответ чаще всего будет из области предположений и ожиданий.
Я бы предпочла такие варианты переформулировки:
Как вы действуете, если во время работы пропадает доступ к данным?
Как происходит процесс ввода информации?
Какую часть информации вы обычно готовы потерять в случае сбоя при длительном редактировании документа?
Почему именно такие? Задача бизнес-аналитика на интервью - понять особенности деятельности собеседника, его реальное поведение и контекст задачи. Свои ожидания и понимание решения он скорее всего постарается вам сообщить и без дополнительных вопросов. Поэтому в общем случае лучше спросить о том, с чем он реально сталкивается, а не о том, что он собирается делать или думает, что ему нужно делать.
В завершение хочу выразить благодарность всем подписчикам Телеграмм-канала Про_БА, которые предлагали разные варианты формулировок открытых вопросов!
