Расскажи про свой опыт выявления требований

Мой опыт выявления требований

Введение

Выявление требований (Requirements Elicitation) — это, вероятно, самая критическая часть моей работы как System Analyst. Неправильно собранные требования приводят к переделкам, задержкам и дополнительным затратам. Я проводил это в проектах от стартапов до крупных корпораций.

Основные методы, которые я использую

1. Интервью (Interviews)

Процесс:

• Индивидуальные интервью со стейкхолдерами
• Один на один для откровенности
• Структурированные вопросы
• Запись (audio или notes)

Мой подход:

Проект: Система управления доставками

Участники:
- CEO: видит только high-level goals
- Head of Operations: знает процессы и боли
- Водитель: знает, что не работает на практике
- Клиент: знает, что ему нужно

Для каждого проводу отдельное интервью:

1. CEO интервью (30 мин):
   Q: Какие основные бизнес-цели на 2025?
   A: Увеличить количество заказов на 50%, снизить стоимость доставки
   
   Q: Какие боли сейчас?
   A: Конкуренты быстрее, мы теряем клиентов
   
   Q: Какой бюджет на решение?
   A: До 500k (важно для scope)

2. Head of Operations интервью (1 час):
   Q: Как сейчас идёт доставка?
   A: Система очень старая, много ручной работы
   
   Q: Какие боли?
   A: Водители не видят маршруты, много ошибок, потеря товара
   
   Q: Что будет success?
   A: Автоматизация маршрутизации, отслеживание в реальном времени

3. Водитель интервью (30 мин):
   Q: Какой интерфейс удобнее: мобильное или веб?
   A: Мобильное, я в машине, нет времени на веб
   
   Q: Какая информация тебе критична?
   A: Адреса, контакты, доказательство доставки (фото)

Инструменты:

• Zoom для remote интервью
• Запись интервью (с согласия)
• Notes в Notion / Confluence

Результат: 10-15 интервью по 30-60 мин каждое

2. Workshop'и (Requirements Workshop)

Процесс:

• Собираю 5-10 человек из разных ролей
• 2-4 часа интенсивной работы
• Совместное обсуждение и brainstorming
• Whiteboard / Miro для визуализации

Пример из практики:

Workshop: Новый процесс обработки заказов
Участники: Менеджер, Бухгалтер, DevOps, Тестировщик, Пользователь
Дата: 3 часа

1. Ледокол (10 мин)
   "Что вас больше всего раздражает в текущей системе?"
   → Все говорят свою боль

2. Визуализация текущего процесса (30 мин)
   На доске рисуем как сейчас работает
   → Выявляем узкие места и дублирование

3. Design новой flow (60 мин)
   Вместе идеём как сделать лучше
   → Priority voting: какие фичи самые важные

4. Определение требований (50 мин)
   Документирование того, что договорились
   → Каждый требует подтверждение от других участников

Результат:
- Aligned vision
- Задокументировано в режиме реального времени
- Минимум неоднозначности

3. Наблюдение (Observation / Job Shadowing)

Процесс:

• Наблюдаю реальные процессы
• Вижу боли и неэффективность
• Видно то, что люди забывают упомянуть

Пример из проекта логистики:

Время: день с водителем на доставке

Что я видел:
1. Водитель печатает адрес на GPS вручную (потеря 5 минут на заказ)
2. Фотография доставки делается на старый телефон (плохое качество)
3. Много time spent на парковку и поиск входа
4. Нет связи с диспетчером когда нужен совет

Что водитель НЕ упомянул в интервью:
- Эти проблемы он считал "нормальными"
- Не знал, что можно сделать лучше

Результат:
- Добавил требования: голосовой ввод адреса, мобильная камера, чат с диспетчером

4. Анализ документов (Document Analysis)

Процесс:

• Ищу существующую документацию
• Current Specification
• Process flows
• User manuals

Пример:

Проект: Миграция с legacy системы

Документы:
- 20-летние документы по текущей системе
- Ни один не актуален
- Но внутри есть useful info

Что я сделал:
1. Прочитал все документы (1 неделя работы)
2. Выписал "правила бизнеса" которые остаются актуальными
3. Создал современный документ требований на основе старого

Результат:
- Выявил неписаные правила (например, скидка на год мб 15%, а не 10%)
- Избежал потерь в новой системе

5. Анализ конкурентов (Competitive Analysis)

Процесс:

• Изучаю, как делают конкуренты
• Выясняю best practices в индустрии
• Идеи для требований

Пример:

Проект: E-commerce платформа

Конкуренты:
- Yandex Market
- Wildberries
- AliExpress

Что я проанализировал:
1. User flow: как быстро найти товар
   → Требование: поиск должен быть за 2 секунды
2. Checkout процесс: сколько шагов до покупки
   → Требование: максимум 3 клика до оплаты
3. Отслеживание: как отслеживается доставка
   → Требование: real-time tracking, push уведомления
4. Returns: как работает возврат товара
   → Требование: возврат в 1 клик, скан QR кода

6. Questionnaires (Анкеты)

Когда использую:

• Когда слишком много пользователей (нет время на интервью)
• Для сбора количественных данных
• Валидация гипотез

Пример анкеты:

Анкета: Что не нравится в мобильном приложении доставки?

Ответили: 500+ пользователей

Вопросы:

1. Как часто вы используете приложение?
   □ Ежедневно (45%)
   □ 2-3 раза в неделю (30%)
   □ Реже (25%)

2. Что вам НЕ нравится? (выбрать можно несколько)
   ☑ Сложный интерфейс (62%)
   ☑ Медленная загрузка (58%)
   ☑ Нет push уведомлений (44%)
   ☑ Плохой GPS (35%)

3. Что было бы самым полезным улучшением?
   (открытый вопрос - сотни ответов)

Результат:
- Приоритезировал features по popularity
- Начал с самых болючих проблем

7. Прототипирование (Prototyping)

Когда использую:

• Когда требование неясно или спорно
• Для валидации с пользователями
• Для выяснения деталей

Пример:

Проблема: Дизайнер и Бизнес спорят о том, как должна выглядеть форма

Решение:
1. Создал 3 варианта в Figma (2-3 часа работы)
2. Показал пользователям (5 тестовых юзеров)
3. Спросил: какой вариант вам нравится и почему?

Результат:
- 4 из 5 выбрали вариант 2
- Это пресекло спор
- Требование: "Форма должна выглядеть как в Варианте 2"

8. Use Case Modeling

Процесс:

• Для каждого main actor создаю use cases
• Описываю happy path и alternate flows
• Выявляю edge cases

Пример:

Use Case: Create Order

Actor: Customer
Precondition: Customer logged in, item in cart

Main Flow:
1. Customer clicks "Checkout"
2. System shows delivery options
3. Customer selects delivery address
4. System calculates shipping cost
5. Customer confirms order
6. System saves order → SUCCESS

Alternate Flows:
- A1: Customer edits address during checkout
- A2: Delivery is not available for selected address
- A3: Customer abandons cart (timeout)
- A4: Payment fails

Result: Список требований на основе каждого сценария

Мой процесс в целом (18+ месячный проект)

Фаза 1: Initial Discovery (неделя 1-2)
├─ 10-15 интервью с ключевыми стейкхолдерами
├─ 1 большой workshop
├─ Анализ документов
└─ Результат: High-level vision, scope, risks

Фаза 2: Detailed Elicitation (неделя 3-6)
├─ Observation / Job shadowing
├─ Competitive analysis
├─ Small workshops по каждому модулю
├─ Анкеты для 100+ пользователей
└─ Результат: 150+ детальных требований

Фаза 3: Requirements Refinement (неделя 7-8)
├─ Прототипирование спорных требований
├─ Use case modeling
├─ Валидация с пользователями
├─ Priority voting (Moscow method)
└─ Результат: Prioritized requirements document

Фаза 4: Ongoing Discovery (постоянно)
├─ Еженедельные синхронизации
├─ Уточнение по мере разработки
├─ Изменения в scope
└─ Результат: Актуальные требования

Инструменты, которые я использую

• Notion/Confluence: документация требований
• Miro: whiteboarding и visualization
• Figma: прототипирование
• Google Forms: анкеты
• Zoom: интервью и workshop'и
• JIRA: tracking требований
• PlantUML: UML диаграммы

Challenges и как я их решаю

Challenge 1: Стейкхолдеры не знают, что им нужно

Проблема: "Сделайте систему лучше" - слишком расплывчато

Решение:
1. Use five whys technique
   Q: Почему текущая система плохая?
   A: Медленная
   Q: Почему медленная?
   A: Много кликов
   Q: Сколько кликов сейчас?
   A: 10
   Q: Сколько должно быть?
   A: 3
   → Требование: "Процесс должен занимать максимум 3 клика"

2. Show competitor examples
   "Вот как это сделано у конкурента"
   → Дает идею

3. Протипирование
   "Вот так может выглядеть"
   → Стейкхолдер говорит "да" или "нет"

Challenge 2: Conflicting требования от разных стейкхолдеров

Problem:
CEO: "Нужна скидка для всех до 50%"
CFO: "Мы разоримся, максимум 15%"

Решение:
1. Документирую обе позиции
2. Делаю impact analysis
   - Скидка 50% → profit -45%
   - Скидка 15% → profit -2%, но customer satisfaction ↑ 30%
3. Предлагаю компромисс
   - Скидка 15% базовая
   - Скидка 25% для VIP
   - Скидка 35% в промо период
→ CEO и CFO согласны

Challenge 3: Requirements меняются по пути

Решение:
- Использую версионирование требований (v1.0 → v1.1 → v2.0)
- Документирую ПОЧЕМУ изменилось
- Обновляю all related documents
- Коммуницирую команде
- Оценка impact: как это влияет на timeline?

Lessons learned из 10+ лет практики

1. Best Requirement = написано на примерах

   ❌ "Система должна быть быстрой"
   ✓ "GET /orders/{id} должен вернуть ответ за < 200ms"
   

2. Слушайте users, не стейкхолдеров

   • Реальные users знают боли лучше всех
   • CEO может упустить детали

3. Спросите "why" минимум 5 раз

   • На поверхности лежит симптом
   • Корень проблемы глубже

4. Документируйте assumptions

   • Каждое требование имеет assumption
   • Документируйте их
   • Later problems = неправильные assumptions

5. Итеративность лучше чем perfection

   • Сначала MVP требования
   • Потом refine
   • Не зацикливайтесь на деталях

Результат моего процесса

Обычно я производю:
- 20-30 страниц Functional Requirements
- 40-60 Use Cases
- 8-10 diagrams (ER, Sequence, Activity)
- 150+ детальных требований в JIRA
- Risk register с 20+ risks
- Prioritized features list
- Acceptance criteria для каждой feature

Это обеспечивает:
- Clear scope
- Минимум surprises во время разработки
- Easy testing (каждое требование → test case)
- Меньше переделок

Выявление требований — это искусство и наука одновременно. Важно слушать, задавать вопросы, и помнить, что требования — это начало хорошего проекта.