#мысливслух #мифы
Ради красоты заголовка позволила себе немного рискованную формулировку. Плохо, если даже на уровне метрик продукта никто из заинтересованных сторон не понимает, к чему нужно прийти. Другая крайность - считать, что заинтересованные стороны должны уметь сформировать запрос на самом детальном уровне. При этом за термином «заказчик» может потеряться часть заинтересованных сторон, пара слов об этом в Дзене
В реальности сформировать запрос во всех деталях означает провести работу по оптимизации процессов и проектированию функциональности. Заказчик не обязан иметь навыки анализа предметной области, оптимизации процессов и проектирования систем. Кто-то признаётся в этом честно, а кто-то старается играть роль адепта технологий. Я однажды услышала: «Мне все понятно, у меня же муж айтишник!»
Ваш потребитель лучше всех знает, что мешает ему в его собственном мире. Но это не значит, что он может облечь свое знание в слова.
(Синди Альварес «Как создать продукт, который купят»)
Из своего опыта заметила:
📍Заказчик не знает чего хочет - значит вы, как БА, можете смело применять многие исследовательские инструменты, об этом пару слов писала в этом посте. Можно искать и предлагать свои варианты решения, есть шанс, что это примут с интересом и даже благодарностью (особенно, если заказчик не претендует на роль ИТ-эксперта)
📍Когда клиент слишком хорошо знает, чего хочет — будьте бдительны, может быть ему это не нужно, но обнаружите вы это уже после внедрения. Лучше проверить гипотезы заинтересованных сторон через прототип или модель процесса, на которой видны возможные сценарии
📍Переменчивость запросов заинтересованных сторон может быть связана с недоверием к вам или ко всей команде разработки. Для выстраивания доверия помогают открытость и управление ожиданиями сторон. Важно не создавать завышенных ожиданий заинтересованных сторон и по возможности объяснять шаги работы над задачей ⚙️