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

Опыт управления изменением требований (Requirements Change Management)

Это одна из самых сложных и важных задач аналитика. За 10+ лет я выработал систему, которая работает.

Реальность: требования ВСЕГДА меняются

В идеальном мире требования зафиксированы и не меняются. В реальном мире:

• Product Owner меняет приоритеты
• Бизнес выясняет, что требование неправильно
• Конкуренты выпустили что-то новое → нужны изменения
• Разработчики находят что нельзя реализовать как задумано
• Клиенты просят новое после эксперимента

Статистика из моего опыта:

• 30% requirements меняются во время разработки
• 15% отменяются полностью
• 20% появляются новые
• Только 35% остаются как было

Как я этим управляю

Правило 1: Change Control Process

Любое изменение требования проходит формальный процесс:

1. ЗАЯВКА (Request)
   ↓ (1 день)
2. АНАЛИЗ (Impact Analysis)
   ↓ (2-3 дня)
3. СОГЛАСОВАНИЕ (Approval)
   ↓ (1 день)
4. РЕАЛИЗАЦИЯ (Implementation)
   ↓
5. ВЕРИФИКАЦИЯ (Verification)

Примеры:

Произошло:

Product Owner: "Нам нужно добавить export в Excel"

Что я делаю:

1. ЗАЯВКА

Change Request CR-001: Export Orders to Excel
Разработчик: Product Owner
Приоритет: HIGH
Дата: 29 Mar 2026
Описание: Пользователи хотят скачивать заказы в Excel

2. АНАЛИЗ (я отвечаю на вопросы)

• Какие поля в Excel? (Все? Или только основные?)
• Как часто используется? (1 раз в месяц? Или каждый день?)
• Нужен ли фильтр перед export? (Экспортировать все или выбранные?)
• Форматирование Excel? (Красивый или просто данные?)
• Что если данных 100,000 строк? (Performance?)
• Лицензия на Excel library? (Open source или платная?)

3. СОГЛАСОВАНИЕ

Использование времени разработчика: 16 часов
Сложность: MEDIUM (требует нового кода)
Риск: LOW (не меняет существующую функциональность)
Приоритет: HIGH
Оценка стоимости: $2,000

Должна ли это быть версия 2.1 или может подождать версии 3.0?
Проект может потерпеть еще на 2 недели?

Все согласны → добавляем в sprint.

Не согласны → обсуждаем приоритеты.

4. РЕАЛИЗАЦИЯ

• Добавляю в Product Backlog
• Переписываю requirement
• Разработчик реализует

5. ВЕРИФИКАЦИЯ

• QA тестирует
• Проверяю что реализовано как требовалось

Пример сложного change request

Ситуация:

Мы разработали платежную систему 3 месяца. За 2 недели до launch Product Owner говорит:

"Нам нужна возможность отменять платёж через 24 часа после создания"

Это меняет:

• Схему базы данных
• Логику платежа
• Интерфейс (новая кнопка)
• Процесс возврата денег

Что я сделал:

Шаг 1: Спросил ПОЧЕМУ

Я: "Почему именно 24 часа? Почему не 48? Почему отмена вообще?"

PO: "Клиент может передумать и хочет деньги обратно"

Я: "Это требование от клиента или от бизнеса? Какой процент
платежей отменяются в конкурентах?"

ПОнял: Это критично для конкурентоспособности.

Шаг 2: Анализ влияния

Проблема: 2 недели до launch, а это 5 дней разработки

Вариант 1: Отложить launch на 1 неделю
  Плюс: Реализуем правильно
  Минус: Потеря $100k revenue

Вариант 2: Обойтись без отмены 24 часа
  Плюс: Launch вовремя
  Минус: Проиграем конкурентам

Вариант 3: Упрощённая реализация
  Плюс: Launch вовремя, есть отмена
  Минус: Ручная обработка возвратов

Вариант 4: Фаза реализации
  - v1.0 (launch без отмены)
  - v1.1 (отмена через неделю)

Шаг 3: Рекомендация

Я рекомендую Вариант 4:

"Отменяем требование из v1.0, запускаемся вовремя.
Добавим отмену в v1.1 через 1 неделю.

Получаем:
- $100k revenue от launch
- Отмена для клиентов через неделю
- Нет спешки, качество кода лучше"

Шаг 4: Согласование

Стейкхолдеры согласились.
Обновляю requirement:
- UR-050: Payment cancellation (v1.1, not v1.0)
- Сдвигаю в Backlog

Результат:

• v1.0 запустили вовремя ✓
• v1.1 через неделю с отменой ✓
• Клиент доволен ✓

Категории изменений

Type 1: Must have (критичное)

Примеры:
- Ошибка в requirement, которая привела к неправильной реализации
- Баг в коде, который нарушает requirement
- Требование регулирующего органа (GDPR, PCI-DSS)
- Критичный клиент требует изменение

Действие: Реализуем немедленно, даже если задержит другое

Type 2: Should have (важное)

Примеры:
- Клиенты просят новый feature
- Конкурент выпустил что-то лучше
- Performance улучшение

Действие: Добавим в next sprint/версию

Type 3: Could have (желательное)

Примеры:
- Улучшение UI
- Дополнительные отчёты
- Интеграция с новым сервисом

Действие: В backlog, когда будет время

Type 4: Won't have (отклоняем)

Примеры:
- Из scope и не критично
- Требует слишком много работы
- Не соответствует стратегии

Действие: Документируем почему отклонили

Инструменты управления изменениями

1. Change Log (документирую все изменения)

## Change Log

### v2.1 (Release: 15 Apr 2026)

CR-001: Export to Excel
- Added Excel export button
- Filters before export
- Changed: Users can now export 50,000 rows (before: 10,000)

BR-002: Payment cancellation
- Added 24-hour refund window
- Changed: Payment status enum (added "refunded")
- Impact: Database migration required

### v2.0 (Release: 1 Apr 2026)
- Initial release

2. Traceability Matrix (связь requirement → code)

| Requirement | Test Case | Code | Status |
|---|---|---|---|
| UR-050 | TC-050a, TC-050b | PaymentController.java | ✓ Done |
| UR-051 | TC-051a | ExportService.java | ✓ Done |
| UR-052 | TC-052a, TC-052b | ValidatorService.java | ⏳ In Progress |

Это гарантирует что ни одно requirement не забыто.

3. Change Request Template (форма для изменений)

CR-###: [Title]
Author: [Name]
Date: [Date]
Priority: [MUST/SHOULD/COULD/WONT]

Description:
[Что нужно изменить и почему]

Current state:
[Как сейчас]

Desired state:
[Как должно быть]

Impact:
- Development effort: X hours
- Risk: [LOW/MEDIUM/HIGH]
- Affected modules: [List]
- Database changes: [YES/NO]

Approval:
- Product Owner: [YES/NO]
- Tech Lead: [YES/NO]
- Project Manager: [YES/NO]

Ошибки, которые я совершал

Ошибка 1: Слишком гибкий к изменениям

Локальный Product Owner просит добавить что-то →
Я сразу говорю "да" → 
Разработчик дезориентирован → 
Сроки ползут

Лучше: "Добавим в backlog, обсудим приоритеты на planning"

Ошибка 2: Не анализирую impact

PO: "Измени цвет кнопки с синего на красный"
Я: "Ок" →
Разработчик: "Нужно менять 50 мест в коде" →
"Почему это 8 часов? Просто цвет!"

Лучше: Анализировать ДО согласования

Ошибка 3: Не документирую

ПО просит изменение → я согласился → 
Через месяц забываем что обсуждали →
Разработчик не знает был ли это change

Лучше: Всё в документах, даже small changes

Ошибка 4: Не управляю scope creep

Начал с 10 requirement →
Проектный процесс → +15 новых →
Делаю всё →
Проект на 6 месяцев задержался

Лучше: Быть ЖЁСТКИМ с scope. Новое = в next версию

Best Practices

1. Зафиксируй scope ДО разработки

"Что входит в v1.0? Что в v1.1?"
Это спасает от 80% проблем.

2. Всегда спрашивай ПОЧЕМУ перед анализом

"Зачем нам это требование?"
"Кого это благодарит?"
"Какой это даёт результат?"

3. Анализируй impact ПЕРЕД согласованием

"Это 5 часов? 50 часов? Меняет архитектуру?"
Это влияет на решение.

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

CR-###, date, who requested, why, impact
Это спасает потом от "А я помню что-то другое..."

5. Управляй ожиданиями

"Нет времени на это в v1.0, но добавим в v1.1"
"Это требует 2 недели разработки, готовы ждать?"
Тогда никого не удивляет результат.

Итоговая статистика моего управления изменениями

Проект A (10 месяцев, 50 requirement)
- Изменений: 14 (28%)
- Отмен: 3 (6%)
- Новых: 5 (10%)
- Задержка: 0 недель (всё по плану)
- Клиент доволен: ✓

Проект B (БЕЗ Change Control)
- Изменений: 35 (70%)
- Отмен: 8 (16%)
- Новых: 40 (80%)
- Задержка: 8 недель
- Клиент недоволен: ✗

Разница: наличие Change Control Process.

Вывод

Управление изменением требований — это не противление изменениям, а управляемая адаптация:

• Анализируем impact ДО решения
• Документируем ВСЁ
• Управляем scope и приоритеты
• Коммуницируем ожидания
• Делаем это систематически, не хаотично

Это экономит деньги, время и спасает от разочарования.