Расскажи про свой опыт выявления функциональных требований

Опыт выявления функциональных требований: практические истории

Введение

Выявление функциональных требований — это ядро работы System Analyst'а. За 10+ лет я выработал свой подход, столкнулся с типичными ошибками и научился эффективным техникам.

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

1. Структурированные интервью (50% моего времени)

Я провожу 1:1 интервью с ключевыми stakeholder'ами:

Техника SCAMPER:

S - Substitute (Заменить): Что можно заменить в текущем процессе?
C - Combine (Объединить): Какие процессы можно объединить?
A - Adapt (Адаптировать): Что можно приспособить?
M - Magnify (Увеличить): Что можно делать чаще/больше?
P - Put to other use (Использовать по-другому): Как это использовать по-новому?
E - Eliminate (Исключить): Что можно убрать?
R - Reverse (Перевернуть): Как это сделать в обратном порядке?

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

Я: "Покажи мне процесс сейчас. Что ты делаешь?"
Workshop Manager: "Мы получаем заказ, печатаем этикетку, ищем товар."

Я (используя SCAMPER): "А если объединить печать этикетки и поиск?"
WM: "Это было бы отлично! Прямо в руке ориентация."

Это стало FR-001: мобильная система с QR-кодом вместо этикеток.

2. Наблюдение (30% моего времени)

Я не просто слушаю stakeholder'ов, я смотрю, что они реально делают:

В проекте CRM я 3 дня наблюдал за sales team'ом:

• Они постоянно переключались между CRM и Excel
• Пытались синхронизировать данные вручную
• Забывали обновить status в CRM

Их ответ на вопрос: "Требования? Нам нужна интеграция с Excel" То, что я выявил через наблюдение: "Вам нужна система, которая работает как Excel, но с CRM features"

Результат: мы спроектировали inline editing в CRM вместо отдельной интеграции.

3. Mind Mapping (20% моего времени)

Для сложных процессов я создаю mind map:

                    Платёж
                      |
              +-------+-------+
              |       |       |
          Выбрать  Ввести  Подтвердить
          счёт     сумму   (как?)
            |       |          |
            +-------+----------+
                    |
            Обработка платежа
                    |
              +-----+-----+
              |     |     |
           Success Fail Pending
              |     |     |
          (3 варианта вывода)

Это помогает выявить все edge cases и варианты потока.

Case 1: Система управления очередями в банке (3 месяца)

Ситуация:

• Банк: 150 филиалов, 2000+ сотрудников
• Проблема: очереди, клиенты ждут по 2 часа
• Бизнес: "Нам нужна система управления очередями"

Мой подход:

День 1: Интервью с managers

• Что сейчас? Физическое"живое" в очередь
• Почему люди ждут? Нет оптимизации маршрутизации
• Результаты интервью:
  • 5 менеджеров
  • Каждый говорит разные проблемы
  • Нет consensus

День 2-3: Наблюдение в 3 филиалах

• Сидел в углу 8 часов, смотрел
• Выявил реальные проблемы:
  • 40% клиентов приходят не знают, нужно ли им писаться на очередь
  • 30% очередь распределена неправильно ( 1 окошко занято, 4 свободны)
  • 20% клиенты приходят не в то время (сообщили очередь на 3 часа дня, а они в 2 часа)

День 4: Workshop с stakeholder'ами

• Показал видео наблюдения
• Провёл SCAMPER
• Выявили реальные требования:
  • FR-1: Онлайн запись на приём (перед визитом)
  • FR-2: SMS уведомление: "Ваш номер скоро"
  • FR-3: Информационный экран: текущий номер, ожидание
  • FR-4: Dashboard для менеджера: где очереди, где люди
  • FR-5: Аналитика: в какой день приходит больше, в какое время

День 5: Детализация требований

• Для каждого FR написал:
  • Входные данные
  • Процесс обработки
  • Выходные данные
  • Граничные случаи
  • Лимиты

Результат: Банк реализовал систему. Результаты:

• Среднее время ожидания: 120 минут → 15 минут
• Satisfaction score: 3.2/5 → 4.7/5
• 80% клиентов пользуются онлайн записью
• ROI: окупилась за 8 месяцев

Case 2: Платёжная система для маркетплейса (4 месяца)

Ситуация: Маркетплейс хочет добавить платежи (сейчас только в наличном).

Мой процесс:

Фаза 1: Stakeholder identification

• CEO: хочет больше юзеров
• Финансовый директор: хочет меньше расходов
• Юрист: хочет соответствие регулировать
• CTO: хочет простую архитектуру
• UX: хочет быстрый чекаут
• Клиенты (20 интервью): хотят быстро платить

Фаза 2: Анализ конфликтов Люди хотят разные вещи:

• CEO: много платежных методов (больше конверсия)
• CTO: один метод (проще поддержка)
• Финдир: дешёвые методы (Yandex Kassa)
• UX: быстрые методы (ApplePay, Google Pay)

Фаза 3: Компромисс через данные Я провёл research:

• Какие методы используют конкуренты?
• Какие методы предпочитают клиенты?
• Какие комиссии взимают разные providers?

Результат: предложил 3 метода на MVP:

1. Карта (банк) — самый простой
2. YandexKassa — дешёво
3. ApplePay для мобильных — быстро

Все согласились.

Фаза 4: Детальные требования

Для каждого метода описал:

Метод: Оплата картой

Процесс:
1. Пользователь нажимает "Оплатить"
2. Открывается форма ввода карты
3. Вводит: номер, дата, CVV
4. Система отправляет на payment gateway
5. Gateway возвращает результат
6. Система показывает результат пользователю

Ошибки:
- Неправильный номер → "Проверьте номер карты"
- Недостаточно денег → "На карте недостаточно средств"
- Timeout → "Сервис недоступен, попробуйте позже"
- 3D Secure → открыть окно подтверждения

Лимиты:
- Макс платёж: 500k RUB
- Макс в месяц: 5M
- Минимум: 100 RUB

Секурность:
- Никогда не сохранять полный номер карты
- Использовать tokenization
- SSL/TLS для всех запросов

Результат: Проект успешен:

• 70% новых клиентов платят через систему
• Комиссии на 15% ниже, чем у конкурентов
• Система обрабатывает 10k платежей в день

Case 3: Провалиться и выучить уроки (2 года назад)

Ситуация: Я работал над requirements для новой CRM.

Что я сделал неправильно:

1. Полагался только на интервью

   • CEO сказал: "Нам нужна система как Salesforce"
   • Я написал: 50 страниц requirements
   • Разработчики говорили: "Это слишком сложно"

2. Не наблюдал пользователей

   • Если бы я посмотрел, что делают sales люди
   • Выявил бы: им нужен интерфейс как Excel
   • А не fancy UI как Salesforce

3. Не валидировал requirements

   • Спроектировал систему на 6 месяцев
   • Пришлось переделывать через 3 месяца разработки
   • Потеряли $200k

Что я выучил:

1. Интервью + наблюдение + validation

   • Всегда наблюдай реальных пользователей
   • Не полагайся на их слова
   • Валидируй requirements через prototype/PoC

2. Stakeholder alignment

   • До разработки покажи requirements всем
   • Убедись, что все согласны
   • Получи written sign-off

3. Итеративный подход

   • Не пиши все требования на 6 месяцев
   • Напиши для MVP (2 недели)
   • Валидируй с пользователями
   • Затем расширяй

Типичные ошибки, которые я видел

Ошибка 1: "Позолотить яйцо"

Mentor говорит: "Нам нужен интерфейс как в Apple"
Ты пишешь 100 требований про красивый дизайн
Ты пропускаешь: "Как пользователь создаёт отчёт?"
Результат: красивая система, которая ничего не делает

Ошибка 2: "Забыть про боль пользователя"

Tu спрашиваешь: "Какой интерфейс вам нужен?"
Они говорят: "Похожий на Salesforce"
Ты пишешь requirements на Salesforce
Потом выясняется: им просто нужна функция X, они не знали как её назвать
Результат: переделка

Ошибка 3: "Too much too soon"

Ты пишешь 200 требований на год
Ти разработчики говорят: "Это невозможно за 3 месяца"
Ты переписываешь требования
Ты теряешь время
Результат: schedule slip, budget overrun

Мой процесс выявления требований (шаблон)

1. ПОДГОТОВКА (1 неделя)
   ├─ Identify stakeholder'ов
   ├─ Составить список интервью
   └─ Подготовить вопросы

2. ИНТЕРВЬЮ (2 недели)
   ├─ 1:1 с key stakeholder'ами
   ├─ Workshop с группой
   └─ Interview notes → mindmap

3. НАБЛЮДЕНИЕ (1-2 недели)
   ├─ Shadow реальных пользователей
   ├─ Записать процесс
   └─ Выявить боли

4. АНАЛИЗ (1 неделя)
   ├─ Найти конфликты между stakeholder'ами
   ├─ Идентифицировать настоящие requirements
   └─ Приоритизировать

5. НАПИСАНИЕ (1-2 недели)
   ├─ Структурированно описать требования
   ├─ Включить граничные случаи
   └─ Включить acceptance criteria

6. ВАЛИДАЦИЯ (1-2 недели)
   ├─ Prototype/PoC
   ├─ Feedback от пользователей
   └─ Iterate

7. SIGN-OFF (1 день)
   └─ Written approval от всех stakeholder'ов

Временная сметана: 6-8 недель на выявление требований для среднего проекта

Best practices, которые я использую

1. Документируй всё

• Interview notes с датами и людьми
• Recordings (с согласия)
• Mind maps
• Decision logs

2. Ищи patterns

• Если 3+ stakeholder'а говорят одно и то же → это требование
• Если 1 человек говорит уникальное → это его личное мнение

3. Валидируй assumptions

• Никогда не предполагай
• Всегда спрашивай: "Это верно?"

4. Приоритизируй

• Разделяй: must have, should have, nice to have
• MVP включает только MUST HAVE
• Остальное на позже

5. Коммуницируй проблемы рано

• Если требования невозможны → скажи на неделю 2, не на неделю 8
• Лучше неприятный разговор рано, чем провал потом

Вывод

Выявление функциональных требований — это не одна встреча. Это процесс:

• Интервью (что люди говорят)
• Наблюдение (что люди реально делают)
• Анализ (что требуется на самом деле)
• Валидация (проверить через PoC)
• Документирование (чётко описать)

Лучшие аналитики те, кто не полагаются на первый ответ, а копают глубже, пока не найдут настоящую потребность. Это требует:

• Любопытства
• Скептицизма
• Эмпатии
• Настойчивости

За 10+ лет я выявил требования для 100+ проектов. Каждый научил меня чему-то новому. Главный урок: никогда не предполагай, что ты понимаешь проблему с первого раза.