Выявление и приоритизация требований
На странице
Порядок работы
Хороший аналитик не начинает с вопроса «какие нужны кнопки». Последовательность такая:
- Проблема. Что болит и почему это важно сейчас?
- Цели и метрики. Как поймём, что стало лучше? Цель должна быть измеримой.
- Стейкхолдеры. Кого это касается, кто принимает решения, кто будет пользоваться?
- AS-IS. Как процесс устроен сейчас и где именно теряется время, деньги или качество?
- TO-BE. Как процесс должен работать после изменений?
- Требования. Что нужно от системы, чтобы перейти от AS-IS к TO-BE?
- Приоритизация и согласование. Что делаем в первую очередь и что не делаем вовсе?
Докопаться до причины: 5 почему
Пример: «Нам нужна CRM».
- Почему? — Менеджеры теряют заявки.
- Почему теряют? — Заявки приходят в почту, мессенджеры и по телефону, общего списка нет.
- Почему это плохо? — Около 15% заявок остаются без ответа, клиенты уходят к конкурентам.
Теперь понятна настоящая цель: снизить долю необработанных заявок с 15% до 2%. Возможно, для этого хватит единого входящего ящика и уведомлений, а полноценная CRM не нужна.
Стейкхолдеры
Матрица влияния и интереса
| Низкий интерес | Высокий интерес | |
|---|---|---|
| Высокое влияние | Держать в курсе, удовлетворять | Ключевые игроки, плотно вовлекать |
| Низкое влияние | Мониторить | Информировать |
RACI
Матрица ответственности по задачам. Responsible — делает. Accountable — отвечает за результат, у каждой задачи такой человек ровно один. Consulted — с ним консультируются. Informed — его информируют.
Техники выявления
| Техника | Когда подходит |
|---|---|
| Интервью | Нужно глубоко понять позицию конкретного человека или эксперта |
| Воркшоп | Нужно быстро согласовать позиции нескольких сторон |
| Наблюдение (job shadowing) | Люди не могут сами описать, как работают, или процесс состоит из привычных действий |
| Анализ документов | Есть регламенты, старое ТЗ, законодательство, существующая система |
| Анкетирование | Много пользователей, нужна статистика, а не глубина |
| Прототипирование | Пользователи плохо формулируют, но хорошо реагируют на увиденное |
| Анализ интерфейсов и данных | Интеграция с существующими системами |
На интервью задавайте открытые вопросы («расскажите, как вы…»), просите показать на реальном примере и всегда переспрашивайте своими словами, чтобы проверить понимание.
Артефакты
- Vision & Scope — видение продукта и границы проекта: что входит и что не входит.
- BRD (Business Requirements Document) — бизнес-требования, цели, стейкхолдеры, процессы.
- SRS / ТЗ — детальные функциональные и нефункциональные требования к системе.
- Бэклог с user story — в Agile-командах.
- Глоссарий — единый словарь терминов, снимает половину недопониманий.
Приоритизация: MoSCoW
- Must have — без этого релиз не имеет смысла.
- Should have — важно, но можно временно обойтись.
- Could have — желательно, если останется время.
- Won't have (this time) — явно не делаем в этот раз.
Другие техники: Kano (базовые, ожидаемые и восхищающие функции), RICE (Reach × Impact × Confidence / Effort), WSJF в SAFe, матрица «ценность / трудозатраты».
Кейс: «Сделайте нам CRM»
Структура хорошего ответа на собеседовании:
- Уточнить проблему: что сейчас не так, какие потери, почему именно сейчас.
- Цели и метрики: конверсия заявки в сделку, время реакции, доля потерянных заявок.
- Стейкхолдеры: руководитель продаж, менеджеры, маркетинг, бухгалтерия, ИТ, безопасность.
- Техники: интервью с руководителем, наблюдение за работой менеджеров, анализ текущих таблиц и каналов.
- AS-IS: заявки разбросаны по каналам, статусы ведутся в Excel. TO-BE: единая воронка, автоназначение, напоминания.
- Решение: готовая CRM или своя разработка, интеграции с сайтом, телефонией и 1С.
- MVP: что войдёт в первый релиз и как измерим успех.
Конспекты статей по теме
Подробные конспекты полезных статей. В конце каждого есть ссылка на оригинал и автора.
- Выявление и сбор требований к ПО — ultimate guide — Вадим (Noveo), публикация Елизаветы Ржевской
- Методы сбора требований, или «Как понять, что хочет заказчик?» — SSul (SimbirSoft)
- Интервью vs семинар: ТОП-5 техник взаимодействия со стейкхолдерами — Анна Вичугова (Школа анализа и проектирования ИС)
- Требования не меняются, это мы их недовыявили — Юрий Куприянов (systems.education)
- Рекомендации по сбору и приоритизации требований для бизнес-аналитика — Дмитрий Сушков (WMT Group)
- Метод MoSCoW: как применять для приоритизации задач — Марина Лужецкая (Kaiten)