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