В чем состоит Change Management на проекте?

Change Management на проекте

Change Management — это процесс контролирования изменений в требованиях, дизайне и коде проекта. Без этого проект становится хаосом.

Определение

Change Management — это набор процессов и процедур для:

• Предложения изменений
• Оценки влияния изменений
• Одобрения / отклонения изменений
• Документирования изменений
• Коммуникации изменений команде

Почему это важно

Без Change Management:

• Разработчик меняет требование "на лету"
• Никто не знает, что изменилось
• Возникают конфликты (другой разработчик делал другое)
• План проекта становится неправильным
• Бюджет и сроки сбиваются
• QA тестирует неправильное
• Клиент удивлён результатом

С Change Management:

• Все изменения документированы
• Влияние оценено заранее
• Управление бюджетом и сроками
• Все на одной странице
• Меньше surprises

Процесс Change Management

Шаг 1: Proposal (Предложение)

Любой может предложить изменение:

• Клиент: "Хотим ещё функцию X"
• Разработчик: "Это требование нереалистично"
• QA: "Нашли баг, нужно менять дизайн"
• BA: "Требование противоречиво"

Форма должна содержать:

• Что нужно изменить
• Почему нужно (бизнес обоснование)
• Кто предложил
• Когда предложено

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

BA анализирует:

• Как это повлияет на другие требования?
• Какой объём работы? (effort)
• Какие сроки? (timeline)
• Какой cost? (бюджет)
• Какие риски?
• Какие resources нужны?

Результат: Change Request Form с оценкой

Шаг 3: Decision (Решение)

Change Control Board (CCB) обсуждает:

• Насколько критично это изменение?
• Есть ли budget?
• Есть ли время?
• Какой ROI?
• Соответствует ли проекту?

Варианты решения:

• Одобрить (Accept) → добавить в plan
• Отклонить (Reject) → отправить обратно
• Отложить (Defer) → на следующую версию
• Условно одобрить (Conditional) → если есть resources

Шаг 4: Implementation (Реализация)

Если одобрено:

• Обновить требования
• Обновить design
• Обновить schedule
• Коммуницировать команде
• Разработчики реализуют
• QA тестирует

Шаг 5: Documentation (Документирование)

• Записать изменение
• Ссылка на original requirement
• Кто одобрил, когда, почему
• История всех изменений

Change Control Board (CCB)

Высший орган, который принимает решения о изменениях.

Типичный состав:

• Project Manager (chair)
• Product Owner / Client representative
• Technical Lead
• BA
• QA Lead
• (иногда) Finance для крупных changes

Полномочия:

• Одобрять / отклонять изменения
• Переоценивать приоритеты
• Решать конфликты
• Управлять scope

Типы изменений

1. Requirement Changes (изменения требований)

Примеры:

• Клиент хочет ещё фичу
• Требование противоречиво, нужно уточнить
• Требование устарело, нужно удалить

Процесс:

• BA анализирует
• CCB одобряет / отклоняет
• Update backlog

2. Scope Changes

Примеры:

• Расширить проект (больше функций)
• Сузить проект (удалить функции)
• Изменить граници проекта

Влияние: На сроки и бюджет

3. Design Changes

Примеры:

• Новый дизайн UI
• Новая архитектура
• Новая БД схема

Кто одобряет: Technical Lead + Client

4. Schedule Changes

Примеры:

• Сроки меняются (deadline раньше / позже)
• Фазы переставляют
• Dependencies меняются

Кто одобряет: PM + Client

5. Resource Changes

Примеры:

• Нужны новые люди
• Люди уходят из проекта
• Смена технологий

Кто одобряет: PM + HR

Пример: Real-world Change Request

Ситуация: Середина проекта, вроде всё идёт по плану.

Клиент: "Ребята, нам нужно добавить двухфакторную аутентификацию!"

Шаг 1: Proposal

Change Request #CR-001
Дата: 2025-03-26
Предложил: Клиент (Sales Manager)

Описание: Добавить 2FA (SMS + Email) для аутентификации
Причина: Конкуренты это имеют, клиенты просят

Шаг 2: Analysis (BA)

Влияние на требования:
- Новые требования для 2FA логики
- Изменение User регистрации
- Изменение login flow

Оценка:
- Effort: 2 недели (backend 1 неделя, frontend 1 неделя)
- Cost: $15,000 (зарплата разработчиков)
- Risk: высокий (security critical feature)
- Resources: нужен security специалист для review

Влияние на schedule:
- Было 2 недели на тестирование, теперь 1 неделя
- Deadline может сойти на нет или нужен overtime

Влияние на бюджет:
- Дополнительно $15,000
- Total project: было $100k, теперь $115k

Шаг 3: Decision (CCB Meeting)

Присутствуют: PM, Product Owner, Tech Lead, BA, QA Lead

PM: "2FA это must-have для нас?"
PO: "Да, конкуренты это имеют, потеряли 2 клиента"
Tech Lead: "Это безопасное изменение, сделаем. Но нужен security review"
BA: "2 недели работы, $15k, высокий риск безопасности"
QA: "Нужна дополнительная неделя на тестирование security"

Решение: ACCEPT WITH CONDITIONS
- Добавить 2FA
- Нанять security consultant для review
- Сдвинуть deadline на 3 недели
- Бюджет +$20k (включая consultant)

Шаг 4: Implementation

- Update requirements document
- Update project schedule (Gantt chart)
- Update backlog
- Tell team in standup
- Разработчики работают
- QA тестирует
- Security consultant ревьюит

Шаг 5: Documentation

Change Log:

Change #CR-001: 2FA Authentication
Status: Implemented
Date Proposed: 2025-03-26
Date Approved: 2025-03-27
Date Completed: 2025-04-10

Approved By: CCB
Implementation Cost: $20,000
Schedule Impact: +3 weeks

Related Requirements: REQ-AUTH-01, REQ-AUTH-02, REQ-SECURITY-01

Severity Levels

Не все изменения одинаковы. Обычно есть уровни:

Critical (Срочное)

• Блокирует проект / продакшен
• Нужно решить сразу
• CCB собирается экстренно
• Примеры: Security bug, клиент требует urgent

High

• Значительное влияние
• Нужно решить в течение дня
• Примеры: Новая бизнес-требование

Medium

• Обычное изменение
• Решается на регулярном CCB
• Примеры: Улучшение UI

Low

• Минорное изменение
• Может быть одобрено BA без CCB
• Примеры: Опечатка в требовании

Типичные ошибки

Ошибка 1: No Change Management (Chaos)

❌ "Давайте просто добавим это"
✅ "Предложим это через CR, оценим, одобрим, потом добавим"

Ошибка 2: Change Management слишком строгий

❌ 5 недель на одобрение простого изменения
✅ Low severity changes одобряются быстро (день)

Ошибка 3: Забывают документировать

❌ "Я помню, что изменили"
✅ Всё документировано в change log

Ошибка 4: Разработчики игнорируют Change Management

❌ "Я просто сделаю это, потом расскажу"
✅ Все изменения через формальный процесс

Инструменты

• Jira (для tracking)
• Confluence (для документирования)
• Sharepoint
• Trello (для малых команд)
• Notion
• Google Forms (для proposal)

Вывод

Change Management важен потому что:

• Контролирует scope creep
• Управляет бюджет и сроки
• Документирует все решения
• Предотвращает chaos
• Улучшает коммуникацию

BA часто отвечает за Change Management процесс.