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

А если изменений избежать невозможно, то ими надо эффективно управлять. В предыдущих материалах мы рассказывали про управление изменениями, и что будет, если этим не заниматься. Отдельно мы раскрыли тему контроля изменений (это тоже управление изменениями, но только теми, которые касаются отдельного проекта) и запросов на изменения.

В этой статье мы расскажем про журнал изменений (Change Log). Именно в этот документ проектный менеджер будет собирать все поступившие “поздние хотелки”, все запросы и, что немаловажно, обоснования для изменений в проекте. В начале проекта журнал изменений помогает команде не сбиться с курса, а в конце — понять, как проект оказался в его текущем состоянии. Этот инструмент обеспечивает прозрачность процесса и помогает команде и заинтересованным сторонам быть в курсе всех модификаций проекта.​

Что такое журнал изменений?

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

Для кого ведут журнал изменений

Как вести журнал изменений

Что такое журнал изменений?

Журнал изменений, согласно гиду PMBOK (Project management body of knowledge — свод знаний о проектном менеджменте) это полный список изменений, внесенных в ходе проекта, и их текущий статус. Изменением может быть модификация итогового продукта (вместо одного делаем другое) компонента плана проекта (теперь работаем по-другому) или плана проекта в целом.

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

Change Log или, в нашем случае Change control log — журнал контроля изменений — ключевой инструмент записи изменений и управления процессом измененй. Он помогает обосновать каждое увеличение расходов, каждое развертывание дополнительных ресурсов, каждую дополнительную задержку в график. Можно использовать сложную проектную систему, а можно и обойтись простой таблицей. Все зависит от размера проекта.

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

В зависимости от методологии и типа проекта вместо журнала изменений могут использоваться другие инструменты для управления изменениями. В Agile-подходе, например, изменения фиксируются в бэклоге продукта (product backlog) и проходят через итерационные обновления – приоритизируются на встречах backlog refinement или sprint planning.

В DevOps и CI/CD-процессах изменения фиксируются в системах контроля версий (Git, GitLab, Bitbucket) и автоматизированных пайплайнах, а их история доступна через pull requests и release notes. В корпоративных и контрактных проектах вместо Change Log часто применяют Change Request Register – документ, формализующий запросы на изменения с их обоснованием и финансовыми оценками. Таким образом, выбор инструмента зависит от уровня контроля и прозрачности, необходимого в конкретной команде и проекте.

Для кого ведут журнал изменений

Самым главным читателем журнала изменений будет проектный менеджер, которому нужно управлять процессом. Достаточно часто изучать документ будут члены команды и стейкхолдеры. Помимо этого, журнал изменений нужен чтобы информировать пользователей о просиходящем в проекте — особенно если разрабатываемый софт уже выпущен для первых потенциальных клиентов.

Любовь с первой итерации: зачем нужны сторонники продукта

Многие любители видеоигр регулярно сталкиваются с журналом изменений в виде патч-ноутов, где разработчики сообщают о правках баланса, исправленных багах или новых функциях. Например, в многопользовательской игре могут ослабить слишком мощное оружие или переработать механику персонажа, чтобы сделать геймплей честнее. Пользователи офисных программ видят журнал изменений в обновлениях вроде «Теперь в таблицах можно использовать умные формулы» или «Исправлен баг с зависанием при экспорте PDF». Аналогично, в мобильных приложениях для фитнеса могут изменить логику расчета калорий или добавить новый режим тренировок, а интернет-магазины пересматривают алгоритмы рекомендаций товаров. Во всех этих случаях журнал изменений помогает пользователям и командам понимать, что именно обновилось и как это повлияет на работу с продуктом.

Журнал изменений отражает полную эволюцию продукта с момента начала его разработки на текущий день. Он также:

• Улучшает пользовательский опыт – пользователи понимают изменения и используют ПО без неожиданностей.
• Повышает видимость – облегчает поиск новых функций и исправлений, привлекает больше пользователей и обратную связь.
• Упрощает коммуникацию – позволяет быстро информировать команды и заинтересованных лиц об обновлениях.
• Облегчает устранение проблем – ускоряет поиск и исправление багов благодаря централизованной документации изменений.
• Улучает документацию – фиксирует историю проекта, повышая прозрачность и удобство анализа прошлых решений.

Как вести журнал изменений

Эксперты советуют делать документ простым для понимания. Обычно журнал изменений ведется в обратном хронологическом порядке — самые “свежие” события указываются наверху. Изменения группируются по дате (все что произошло в тот день) и по команде, которая их внесла (изменения от контент-команды, изменения от дизайнеров, разработчиков и т.д).

В зависимости от сложности проекта журнал может быть кратким или подробным. Так Институт проектного менеджмента (Institute project management) в своем шаблоне ограничивается идентификатором, датой, запрашивающим (кто запросил изменение), описанием изменения, влиянием на объем, стоимость и сроки, статусом одобрения (принято или не принято изменение) планом внедрения и итоговой ситуацией.

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

Более подробный журнал контроля изменения включает в себя следующее:​

• Идентификатор изменения: уникальный номер или код для каждого изменения (это поможет удобству поиска и управления изменениями в будущем).
• Дата: даты предложения, одобрения и завершения изменения.​
• Запрашивающий: кто предложил изменение
• Описание изменения: краткое изложение сути изменения.​
• Причина изменения: обоснование необходимости внесения изменения.​
• Приоритетность: оценка приоритетности изменения.
• Анализ влияния: оценка потецниального влияния изменения на состояние проекта
• Статус: текущее состояние изменения (например, предложено, одобрено, отклонено, выполнено).​
• Ответственный: лицо или команда, ответственные за реализацию изменения.​
• План внедрения: как изменение будет внесено в случае одобрения
• Статус внедрения: информация о ходе внесения изменения
• Итоговая ситуация: документация внесенного изменения, включая оценку после внедрения, с анализом эффективности

Рассмотрим пример разработки мобильного приложения для бронирования столиков в кафе из нашей предыдущей статьи. Там мы рассказывали, что в процессе работы команда получает запрос на добавление функции предзаказа блюд. Запрос поступает в виде Request for change (запроса на изменение). Он фиксируется в журнале:​

• Идентификатор: RFC-2025-001
• Дата предложения: 04.03.2025
• Запрашивающий: Менеджер по продукту
• Описание: Добавление функции предзаказа блюд при бронировании столика
• Причина: Повышение ценности сервиса и конкурентоспособности
• Приоритетность: Высокая
• Анализ влияния: Увеличение сроков на 3 недели, доп. затраты $10,000
• Статус одобрения: Одобрено
• План внедрения: Разработка и тестирование за 3 недели
• Ответственный: Команда разработки
• Статус внедрения: В процессе
• Итоговая ситуация: Функция внедрена, положительные отзывы пользователей

Сам исходный RFC можно сохранить в системе управления проектами, а в журнале изменений дать на него ссылку — которой и будет наш идентификатор RFC-2025-001. Произошедшее можно записать и еще короче:

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