В идеальном мире заказчики приходят с четкими требованиями, понятной задачей и полным пониманием того, что они хотят получить. Но в реальности часто бывает иначе: «Хочу сайт… или приложение?.. Не уверен. Просто чтобы удобно было»

Что делать аналитику, когда информация расплывчата, требования противоречивы, а порой вообще отсутствуют.

ДАВАЙТЕ РАЗБИРАТЬСЯ.

Почему это происходит? 🧐

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)Твоя задача как аналитика — привести хаос к структуре.
2. Чем больше ты умеешь слушать, задавать вопросы и выдвигать гипотезы, тем ценнее ты для проекта.

Если заказчик "плавает", не молчи — предложи план действий. Проведи воркшоп, сделай драфт требований, покажи примеры.

Действуй как партнёр, а не исполнитель.