В прошлом посте мы разобрали проблему full-scale старта. В этом разберем самый главный вопрос: А с чего же начать?
Ответ на этот вопрос давно известен, но почему-то этот шаг очень часто пропускают или не уделяют должного внимания. Этот ответ — бизнес-анализ. Чем тщательнее вы проведете бизнес-аналитику в начале, тем более качественным будет проект.
Задача: взять видение и превратить его в очертания системы.
🔪 Рубим «хотелки»
Это самый болезненный процесс. Необходимо определить границы проекта, разобраться в функциональности, которая будет необходима для MVP, а самое главное — определить метрики, по которым мы поймём, что наш старт прошёл удачно.
1️⃣ Определяем границы (project scope)
На данном этапе мы определяем, что именно должно входить в первую версию, а что может подождать. Важно определить жёстко и безжалостно. Если возникает лёгкое сомнение, то этот функционал точно стоит вынести из границ проекта.
Полезные инструменты на данном этапе — методы приоритезации MoSCoW, ICE, RICE.
2️⃣ Ищем стейкхолдеров и задаём вопрос «Зачем?»
Стейкхолдеры — это все те, кто заинтересован в разрабатываемой системе или кто будет с ней взаимодействовать:
- Бизнес-заказчик.
- Будущие пользователи.
- Юристы (если есть какие-то юридические тонкости в работе системы).
- Техподдержка (потом им же отдуваться).
Наша задача — прийти к каждому заинтересованному и спрашивать «Зачем?» до тех пор, пока не докопаемся до сути (практика трёх «зачем» или пяти «почему»).
Вопросы, которые убивают большую часть первоначального объёма работы:
- Зачем нам эта функциональность? Какую бизнес-цель она закрывает?
- Что будет, если этой функциональности вообще не будет через год?
- Какой минимальный кусок ценности мы можем отдать пользователю за 2–3 месяца?
- Какие метрики изменятся после запуска (конкретные числа)?
3️⃣ Определяем метрики успеха
Без измеримых целей мы не поймём, удачный ли был запуск или нет. Если мы не сможем измерить систему, мы не узнаем, какой эффект она принесёт нам.
Примеры хороших метрик на старте:
- 🎯 500 активных пользователей в первые 60 дней.
- 🎯 Конверсия из регистрации в первую транзакцию ≥ 18%.
- 🎯 Среднее время выполнения ключевого сценария ≤ 45 секунд.
- 🎯 Снизить количество звонков в поддержку по таким-то вопросам на 40%.
4️⃣ Что должно получиться на выходе
В идеальном случае на выходе мы должны получить несколько документов, каждый максимум 1–2 страницы:
📄 1. Видение проекта (Vision Statement), в идеале — хорошо сформулированный 1 абзац.
📊 2. Верхнеуровневая диаграмма контекстов — квадратики/стрелочки, в идеале — доска с Big Picture Event Storming.
📋 3. Границы проекта (Scope) — что входит, что не входит, список ключевых сценариев.
📏 4. Три-пять ключевых метрик успеха.
⚠️ 5. Ключевые ограничения проекта (3–5) — бюджет, сроки, инфраструктура, технологии.
👤 Кто это делает?
На этом этапе идеальная связка: техлид + продакт-менеджер (или очень подкованный аналитик). Бизнес-аналитик или системный аналитик, который может хорошо выявлять ключевые требования, особенно если видение очень размытое.
Техлид здесь нужен, чтобы сразу откинуть технически нереализуемые или запредельно дорогие идеи. На этом этапе мы экономим миллионы, просто не давая плохим идеям попасть в код.
Вывод
Бизнес-анализ на старте — это способ за 2–4 недели понять, стоит ли вообще вкладывать миллионы в разработку. Без чётких границ любая команда превратит проект в «зоопарк фич», а бюджет — в дым.
Подпишись на мой telegram-канал
#management #mvp #poc