Интервью - инструмент, который называют чаще всего, когда говорят о выявлении требований. Но если все им владеют, почему по-прежнему никуда не делись вопросы разрыва между реальностью внедренных приложений и ожиданиями пользователей? Потому что интервью требует подготовки и имеет свои риски.
Правильное использование важно, еще и потому, что это дорогой подход. Нужно определить цели, адресно выявить респондентов, выделить время всех участников: аналитика и респондента. Ветераны вспомнят времена, когда аналитики были так суровы, что не доверяли видеосвязи и ездили в другие города и страны ради единственной встречи. Представляете цену вопроса? Ошибки на любом этапе приводят к удорожанию и искажению результатов. Где-то на конференции услышала: «Мы провели интервью, где все вопросы были с вариантами ответов». То есть вместо качественного исследования получился опрос с затратами равными интервью и скорее всего недостаточной выборкой респондентов. В итоге - сожженное время и недостоверные выводы.
На мой взгляд, основная сложность интервью для выявления требований - несоответствие целей и ожиданий сторон. Это почти как в семейной жизни: кто-то к вечеру устал на работе, а кому-то именно этим вечером очень нужен освежающий отношения конфликт 😊
«Мне расскажут правду». Люди говорят не то, что делают, а то, что помнят. Бывает, что хотят выглядеть умно или просто говорят социально одобряемое. Аналитики при этом чувствуют себя обманутыми и жалуются на незрелость пользователей или заказчиков. Мне запомнился такой комментарий под моей статьей на Хабре
Типичные ответы моих пользователей (которые не меняются уже пару десятков лет) :
Как вы действуете, если во время работы пропадает доступ к данным? - Звоню знакомому ИТ-нику / ИТ-директору.
Как происходит процесс ввода информации?- Руками.
Заказчик тоже чувствует себя обманутым - он ожидает, что придет мастер и все починит, а на вопросы он ответил честно и что еще нужно?
Респонденты не всегда могут дать развернутый технологичный ответ, а если и скажут что-то на айтишном, не факт, что хорошо понимают сказанное. Например, я не смогу ответить стоматологу, если он начнет меня спрашивать каким материалом заменить пломбу? а на вопрос, что я делаю, если зуб болит, отвечу - записываюсь к врачу... такой вот незрелый пациент из меня 🤷♀️
«Мне расскажут всё». Эксперт упускает «очевидные» для него детали, которые для аналитика - чёрные ящики. В итоге один остается при мнении, что узнал все, а другой - что рассказал все, но при этом оба не слишком продвинулись к результату. Так можно с большим опозданием обнаружить, что «ID клиента» - это не UID, а номер паспорта или телефона 😉
Сбор мнений вместо изучения контекста. Бывает, что аналитик приходит за решением, а не за проблемой. Вместо «Как вы сейчас работаете?» звучит «Как вам хотелось бы работать?». Итог - сбор субъективных пожеланий, а не фактов. Когда заказчики или пользователи потом видят этакие хотелки на экране, они обычно пугаются. У них-то было ожидание, что их мнение превратится в удобное решение, а спрашивают просто для информации.
Еще важно понимать, чье именно мнение и по какому вопросу прозвучало на интервью. Скажем, мнение финансового директора о распределении бюджета важнее услышать, чем мнение вашего соседа по столу по тому же вопросу.
Мало того, что мы шлём не то и не тем, так это ещё и не доходит (из Смешариков)
В общем случае не достаточно одного только интервью, чтобы сделать выводы - нужно поговорить с ИТ-поддержкой, понаблюдать за работой пользователя (если покажут), посмотреть логи систем (если есть), в регламенты заглянуть, данные поискать.
В следующий раз, готовясь к интервью, спросите себя: что я хочу узнать? могу ли я это узнать другим способом? я буду собирать мнения или изучать контекст? Это сэкономит кучу времени.
📚Дополню тему несколькими публикациями:
● Ошибки при проведении интервью с пользователями
● Интервью на удаленке
● Как ID клиента оказался номером телефона и вдвое увеличил стоимость задачи
● Какие вопросы?
● Кейс. Подготовка к интервью
#инструменты #интервью