В идеальном мире заказчики приходят с четкими требованиями, понятной задачей и полным пониманием того, что они хотят получить. Но в реальности часто бывает иначе:
«Хочу сайт… или приложение?.. Не уверен. Просто чтобы удобно было»
Что делать аналитику, когда информация расплывчата, требования противоречивы, а порой вообще отсутствуют.
ДАВАЙТЕ РАЗБИРАТЬСЯ.
Почему это происходит? 🧐
1) Заказчик сам ещё не до конца понял потребность — просто чувствует, что что-то работает не так.
2) Бизнес находится в стадии экспериментов, и продукт пока не определён.
3) Изменения на рынке требуют гибкости => стратегия меняется прямо в процессе.
КАК РАБОТАТЬ В ТАКОЙ СИТУАЦИИ?
1. Задавай уточняющие вопросы и всегда ставь под сомнение хотелки бизнеса
Спрашивай открытые вопросы:
– «Для кого вы делаете этот продукт?»
– «Какие проблемы он должен решить?»
– «Что будет считаться успешным результатом?»
💡 Используй метод 5 почему — чтобы докопаться до сути проблемы
2. Предложи MVP (минимально жизнеспособный продукт)
Если сложно описать всё сразу — начни с малого. Предложи реализовать базовый функционал и протестировать его с пользователями.
Это помогает:
– Увидеть, что действительно нужно
– Избежать переплат за ненужные фичи
–Быстро получить обратную связь
3. Работай с гипотезами
Если информации мало — работай с предположениями. Например:
Гипотеза: пользователи будут чаще пользоваться приложением, если добавить push-уведомления
Тогда ты можешь:
1) Реализовать функцию
2) Измерить метрики
3) Подтвердить или опровергнуть гипотезу
4. Применяй разные методы исследования
– Интервью с ключевыми стейкхолдерами
– Анализ конкурентов и аналогов
– Работа с пользователями
– Мозговые штурмы с командой
5. Фиксируй допущения и риски
Когда много неопределённости — важно честно указать, что часть требований основана на предположениях.
Это позволяет:
– Управлять ожиданиями
– Вовремя скорректировать направление
– Защитить себя и команду от обвинений
Полезные инструменты 🥁
1) User Story Mapping — для визуализации функционала.
2) Kano Model — чтобы понять, какие фичи важны.
3) MoSCoW Method — для приоритизации задач.
4) Prototyping (Figma, Balsamiq) — показать, как может выглядеть решение, до написания кода.
ГЛАВНОЕ ПРАВИЛО:
Не бойся задавать глупые вопросы. Лучше уточнить сейчас, чем переделывать потом.
ВЫВОДЫ:
1) Работа в условиях неопределённости — норма, а не исключение.
2)Твоя задача как аналитика — привести хаос к структуре.
3) Чем больше ты умеешь слушать, задавать вопросы и выдвигать гипотезы, тем ценнее ты для проекта.
Если заказчик "плавает", не молчи — предложи план действий. Проведи воркшоп, сделай драфт требований, покажи примеры.
Действуй как партнёр, а не исполнитель.
