Мы продолжаем рассказывать о том, как управлять изменениями. На практике управление изменениями включает анализ их влияния, адаптацию плана проекта, эффективную коммуникацию, работу с рисками и взаимодействие с экспертами. Четкое документирование и согласование изменений помогают минимизировать хаос и сделать проект гибким, но при этом сохранить управляемость.

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

Зачем так сложно

Что такое контроль изменений

Как договариваться об изменениях

Как бюрократия помогает сэкономить деньги

Зачем так сложно

Изменения это неизбежная, и, даже необходимая часть жизнедеятельности любого бизнеса. По статистике KPMG, до 96 процентов всех организаций проходят какой-либо процесс изменений. Основными причинами называют изменения в глобальной экономике, растущую конкуренцию, меняющуюся демографию, поведение и ожидания клиентов.

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

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

Что такое контроль изменений

Контроль изменений это процесс, в ходе которого изменения в документах (о чем договорились на бумаге?), результатах (чего хотим достичь?) или исходных данных, связанных с проектом, определяются, документируются, утверждаются или отклоняются. Такое определение дает Институт управления проектами (PMI), который является крупнейшей всемирной профессиональной ассоциацией проектных менеджеров.

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

• Документы — чтобы помнить, о чем договорились.
• Результаты — чтобы не потерять цель проекта.
• Исходные данные — чтобы учитывать ресурсы и реальность.

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

Весь процесс начинается, когда кто-то предлагает внести какие-либо изменения в проект. Эти запросы и называются Request for Change (RFC — запрос на изменения).

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

Request for Change — это формальный запрос, который фиксирует причину изменения, его последствия и решение о внедрении. Документ нужен не только для того, чтобы добавить бюрократии или найти ответственных за раздутый бюджет, но и нередко является инструментом защиты проекта от хаотичных изменений. Он позволяет не просто зафиксировать запрос, но и показать, зачем это изменение нужно, что оно даст, и какие ресурсы потребует. RFC помогает избежать ситуаций, когда кто-то просто “решил, что так будет лучше”, не учитывая сроков, бюджета и возможных проблем.

Управляемый хаос: зачем проектному менеджеру знать про изменения

Как и в случае с требованиями к программному обеспечению Request for Change является “кирпичиком” изменений. Нередко запросы на изменения ложатся в основу действующего проекта и даже могут стать целым новым проектом, превратившись в Хартию проекта. Например, так появилась функция «Сторис» в социальных сетях: 

Пользователи социальных сетей выражали желание делиться моментальными фотографиями и видео, которые исчезают через определенное время. Этот запрос привел к появлению функции «Сторис» сначала в Snapchat, а затем и в других платформах, таких как Instagram и Facebook.​

Как договариваться об изменениях

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

Исходные параметры проекта:

• Срок разработки: 4 месяца
• Ресурсы: 5 разработчиков (3 backend, 2 frontend), 1 дизайнер, 1 PM, 1 QA
• Финансы: бюджет 50 000$ (включая разработку, тестирование и инфраструктуру)

Изначально план монетизации строился на комиссии с бронирований:

• Базовая модель: кафе платят фиксированную комиссию за успешную бронь (например, $0.50–$1 за каждое бронирование через приложение).
• Дополнительные опции: возможность продвигать кафе в поиске (платное продвижение в каталоге).
• Долгосрочная цель: масштабирование на разные города и расширение функционала.

Этот вариант выглядел простым и понятным, но уже в процессе работы маркетинг заметил несколько проблем:

1. Комиссия с бронирований — низкомаржинальная модель. Чтобы выйти в плюс, нужно очень много бронирований.
2. Кафе не очень мотивированы платить за пустую бронь. Если клиент не пришел, заведение теряет деньги, но все равно платит комиссии.
3. Конкуренты предлагают больше. Другие сервисы уже внедряли предзаказ блюд, что делало их более ценными для ресторанов.

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

Маркетинговая команда решила оформить RFC, потому что добавление предзаказа блюд — это не просто небольшая доработка, а значимое изменение, влияющее на проект на нескольких уровнях. Оно затрагивает бизнес-логику (рост выручки и скорости обслуживания), техническую реализацию (новый API, интеграция с кафе), UI/UX (обновление интерфейса бронирования) и потенциально влияет на сроки и бюджет.

Чтобы структурированно зафиксировать изменение и его последствия, был составлен RFC с ключевыми разделами:

1. Описание изменения – объясняет, в чем суть (→ см. «Описание» в RFC).
2. Причина запроса – фиксирует, почему изменение важно (→ см. «Инициатор» и бизнес-влияние).
3. Анализ влияния – показывает, какие части проекта затронуты (→ см. «Технические изменения» и «Риски»).
4. Оценка затрат и ресурсов – помогает команде решить, стоит ли изменение затраченных усилий (→ см. «Оценка времени и ресурсов»).
5. Решение – фиксирует, будет ли изменение реализовано и в каком виде (→ см. «Рассматривается командой»).

RFC-2025-001: Добавление предзаказа блюд в бронирование

Номер RFC: RFC-2025-001
Дата запроса: 04.03.2025
Инициатор: Отдел маркетинга
Описание: Пользователи хотят не только бронировать столики, но и заранее заказывать блюда, чтобы сократить время ожидания в кафе.
Категория изменения: Функциональное изменение (Major Change)
Приоритет: Средний
Анализ влияния:

• Технические изменения: Необходим новый API для передачи заказов, обновление UI.
• Бизнес-влияние: Потенциальный рост бронирований, но усложнение процесса обработки заказов кафе.
• Риски: Увеличение времени на разработку, возможные задержки с интеграцией с POS-системами кафе.
  Оценка времени и ресурсов: +3 недели к срокам, потребуется дополнительный frontend и backend разработчик.
  Решение: Вынесено на обсуждение командой, требуется дополнительная оценка затрат и возможных вариантов реализации.

Новый план монетизации после изменения

С добавлением предзаказа стало возможным:
✅ Брать комиссию не только за бронь, но и за оплату заказанных блюд (например, 3-5% с суммы заказа).
✅ Продавать премиум-размещение в каталоге кафе (кафе, поддерживающие предзаказ, могут платить за продвижение).
✅ Интегрировать платные функции для ресторанов (например, аналитика по заказам и предпочтениям клиентов).

🔄 Фактически, запрос на изменение (RFC) не только повлиял на техническую часть проекта, но и заставил пересмотреть саму бизнес-модель.

Как бюрократия помогает сэкономить деньги

После реализации RFC-2025-001 документ остается важным для анализа результатов. Он позволяет сравнить прогнозы с реальными показателями: увеличилось ли число бронирований, вырос ли средний чек кафе? Эти данные помогут подтвердить или скорректировать стратегию монетизации, а также использовать их при переговорах с новыми партнерами.

• RFC также играет роль истории изменений, фиксируя, почему команда пересмотрела изначальный план. Если в будущем потребуется оптимизировать предзаказ, подключить онлайн-оплату или интегрировать с POS-системами кафе, RFC уже содержит анализ рисков и решений, что ускоряет принятие новых решений.
• Наконец, RFC становится основой для будущих улучшений. Новый запрос, например, на автоматическое подтверждение заказов, можно строить на уже проведенном анализе, а не начинать всё с нуля. Это упрощает управление изменениями и делает проект более предсказуемым.
• Без RFC изменения вносились бы хаотично: команда теряла бы контекст, решения принимались бы на эмоциях, а технические задачи могли дублироваться или противоречить друг другу. Это привело бы к задержкам, перерасходу бюджета и, возможно, провалу продукта.

В небольших командах управление изменениями достаточно гибкое и проходит через обсуждения в проектной группе. Однако в крупных компаниях изменения проходят через более сложный процесс, включающий Change Advisory Board (CAB — совет по изменениям), который оценивает влияние на стратегию, бизнес-процессы и инфраструктуру.

Также используется четкий workflow (рабочий поток) для RFC, где каждый шаг — от подачи запроса до анализа последствий — формализован. Это особенно важно, если изменение затрагивает не только один проект, но и всю компанию или ключевые IT-системы.