Вести журнал изменений особенно важно в трёх контекстах. В разработке ПО он нужен, чтобы пользователи и команда понимали, что вошло в релиз. В конструкторской документации он обеспечивает дисциплину внесения правок по ГОСТ и связку с извещениями об изменении. В проектной документации и управлении проектами он помогает фиксировать запросы на изменения и оценивать их влияние на ход работ. В этой статье рассмотрим все три сценария.
Что такое журнал изменений
Журнал изменений — это хронологический реестр всех изменений, внесённых в документ, систему или продукт. Его основная задача — сохранять историю изменений. Журнал фиксирует:
- предмет изменений (что было изменено),
- время изменений (когда это произошло),
- автора изменений (исполнителя),
- причину изменений (почему изменение понадобилось),
- инициатора изменений (кем оно было согласовано или утверждено).
По сути, это механизм, который делает работу прозрачной и воспроизводимой. Без него сложно провести аудит, восстановить ход решения, подтвердить соответствие требованиям или объяснить команде, почему в текущей версии именно такие правки.
Представим ситуацию: заказчик и проектное бюро работают в рамках большого EPC-контракта. Заказчик присылает замечания к выданной документации — каждый комментарий фиксируется в журнале изменений проекта: номер, дата получения, суть замечания, затронутый раздел, ответственный исполнитель и статус обработки. После внесения правок статус обновляется: «принято», «принято частично», «отклонено», «выполнено». Заказчик видит, как отработан каждый комментарий, а проектное бюро может доказать, что изменения не только внесены, но и согласованы. Без журнала комментарии теряются, одна правка появляется в нескольких местах без единого номера, а финальное согласование остаётся под вопросом.
У журнала изменений есть две принципиально разные формы. Первая — технический, внутренний журнал, который ведут разработчики, инженеры, проектные менеджеры. Он содержит формальные записи, номера извещений, ссылки на задачи и подписи. Вторая — пользовательский журнал изменений (changelog), который видят конечные пользователи продукта. Такой журнал оформляется проще: с версиями, датами и понятными категориями изменений.
Журнал изменений в разных контекстах
В конструкторской документации
В конструкторской документации журнал изменений регулируется нормативно. Актуальный стандарт — ГОСТ Р 2.503-2023 (действует с 1 марта 2024 года, заменил ГОСТ 2.503-2013). Для проектной документации применяется ГОСТ Р 21.101-2020.
Основанием для записи в журнал служит извещение об изменении (ИИ) — документ, в котором зафиксированы причина, срок и порядок внесения изменений в подлинники. Именно ИИ делает каждое изменение прослеживаемым до первичного документа.
В журнале указывают: номер извещения об изменении, дату записи, обозначение документа, характер изменения, исполнителя и подпись. Для проектной документации ГОСТ Р 21.101-2020 предусматривает форму 11 (Приложение П) с обязательными графами: номер изменения, дата, номер тома, обозначение документа и листа, содержание замечаний экспертизы, содержание изменения, должность и фамилия лица, внёсшего изменения, отметки о согласовании и о внесении изменений в подлинники.
Пример строк журнала КД (ИИ — извещение об изменении):
| № п/п | Номер ИИ | Дата | Обозначение документа | Характер изменения | Исполнитель | Подпись |
| 1 | ИИ-14/26 | 12.03.2026 | КД-01.03.05 | Уточнён размер посадочного отверстия с Ø10 до Ø9,8 | Иванов И.И. | Иванов |
| 2 | ИИ-15/26 | 18.03.2026 | СП-02.01 | Добавлена позиция 7, изменено количество крепежа | Петрова А.В. | Петрова |
| 3 | ИИ-16/26 | 25.03.2026 | ЧТ-04.12 | Исправлена маркировка материала детали | Сидоров К.К. | Сидоров |
Каждая запись должна быть конкретной и однозначной — для инженера и для проверяющего это официальный «след» принятого решения.
В разработке программного обеспечения
В IT-среде журнал изменений чаще называется changelog и представляет собой файл или страницу с историей версий продукта. Обычно это CHANGELOG.md в корне репозитория или отдельный раздел в системе документации.
Наиболее распространённый ориентир — стандарт Keep a Changelog. Он не является формальным ГОСТом, но стал де-факто отраслевым стандартом, потому что предлагает удобную и понятную структуру. Изменения группируются по категориям: Added, Changed, Deprecated, Removed, Fixed, Security.
Связь с семантическим версионированием (SemVer) принципиальна. Формат major.minor.patch показывает значимость изменений: major — крупные несовместимые изменения, minor — функциональное расширение без нарушения совместимости, patch — исправления и небольшие доработки.
Хороший журнал изменения программ не просто перечисляет факты, а отражает логику релиза. Если в релизе появилась новая функция, исправлен критический баг и изменён алгоритм кеширования — это должно быть показано в понятных блоках, а не спрятано среди коммитов.
В проектной документации и управлении проектами
В проектах журнал изменений фиксирует не столько изменения документа, сколько запросы на изменение и управленческие решения по ним. Это особенно важно там, где любое изменение может затронуть сроки, бюджет или объём работ. В записи указывают: дату, инициатора, описание изменения, предполагаемое влияние на проект и статус — одобрено, отклонено или на рассмотрении.
Журнал становится частью процесса управления изменениями: помогает не потерять контекст — почему проект пошёл по новому пути, кто инициировал пересмотр требований, когда было принято решение. При закрытии проекта журнал регистрации изменений проекта служит основанием для финальной оценки, а при аудите — доказательством того, что изменения проходили через управляемую процедуру.
Требования к ведению
К журналу изменений применимы общие правила — независимо от контекста: КД, разработка ПО или управление проектами.
- Своевременность. Запись вносится в момент изменения, а не задним числом.
- Полнота. Запись содержит достаточно информации, чтобы её понял человек, не участвовавший в обсуждении.
- Однозначность. Формулировки конкретные: не «улучшена производительность», а «время загрузки страницы снижено с 4 до 1,2 секунды».
- Хронологический порядок. В пользовательском changelog новые записи размещают сверху, в техническом журнале КД — нумеруют последовательно.
- Неизменяемость. Уже внесённая запись не редактируется. Если обнаружена ошибка — исправляют новой записью, а не переписыванием старой.
Оформление журнала
Оформление зависит от среды, но логика общая.
Бумажный журнал по ГОСТ — официальный документ с таблицей, обязательными реквизитами, нумерацией страниц и подписями ответственных лиц. Важны не только сами записи, но и форма их представления: понятно, кто отвечает за изменение, на каком основании оно внесено и как связано с первичным документом.
Электронный журнал в разработке ПО — CHANGELOG.md в корне репозитория. Структура Keep a Changelog хорошо работает, когда журнал должен быть одновременно машинно обрабатываемым и удобным для чтения.
Журнал в системах управления проектами — набор полей или карточек: инициатор, описание, статус, влияние на сроки и бюджет.
Типичные ошибки, которые снижают ценность журнала:
- слишком общие формулировки, не позволяющие понять суть правки,
- игнорирование «мелких» изменений — они накапливаются и становятся проблемами,
- расхождение между записью в журнале и тем, что реально изменено.
В результате журнал изменений процессов формально существует, но не выполняет свою функцию.
Примеры журналов изменений
Пример 1 — фрагмент технического журнала КД
Записи привязаны к конкретным извещениям об изменении и содержат точные технические данные — обозначение документа, характер правки, исполнителя. Никаких «обновлена документация» или «исправлены ошибки».
| № п/п | Номер ИИ | Дата | Обозначение документа | Характер изменения | Исполнитель |
| 1 | ИИ-14/26 | 12.03.2026 | КД-01.03.05 | Уточнён размер посадочного отверстия с Ø10 до Ø9,8 | Иванов И.И. |
| 2 | ИИ-17/26 | 02.04.2026 | МС-01.07 | Изменена масса изделия в спецификации: с 4,35 до 4,12 кг | Петрова А.В. |
| 3 | ИИ-19/26 | 14.04.2026 | СБ-02.01 | Добавлена деталь поз. 12 в сборочный чертёж | Сидоров К.К. |
Пример 2 — фрагмент changelog для ПО (формат Keep a Changelog)
## [1.4.0] - 2026-05-20
### Added
- Новый API endpoint для выгрузки отчётов в CSV.
### Fixed
- Исправлен баг при авторизации через SSO, из-за которого сессии
завершались преждевременно.
### Changed
- Обновлён алгоритм кеширования: время ответа страницы отчётовснижено с 4 до 1,2 секунды.
Такой формат сразу показывает, что появилось, что исправилось и что изменилось — без необходимости разбирать историю коммитов.
Инструменты для ведения журнала изменений
| Категория | Примеры | Для чего |
| Документация и публикация | Документерра, Confluence | Ведение структурированных страниц, версионирование, публикация changelog для внутренней или внешней аудитории |
| Системы контроля версий | Git, CHANGELOG.md, GitHub Releases | Ведение релизной истории в связке с исходным кодом |
| Управление проектами | Jira, Asana, MS Project | Ведение журнала регистрации изменений к проекту, отслеживание статусов и влияния изменений на план |
| Электронный документооборот | 1С:Документооборот, Directum | Формальное хранение извещений об изменении, согласований и связанных документов |
| Специализированные сервисы | Headway, Beamer | Публикация пользовательских release notes для SaaS-продуктов без сложной ручной вёрстки |
Документерра — платформа с встроенным версионированием документации, где история изменений фиксируется автоматически. Подходит как для ведения внутреннего технического changelog, так и для публикации пользовательских release notes в составе справочного портала продукта.
Для разработки ПО оптимальна связка Git + CHANGELOG.md; для проектов — системы управления задачами с настраиваемыми полями статусов; для КД и СЭД — решения, поддерживающие согласование и хранение извещений об изменении.
* * *
Журнал изменений — это память проекта или продукта. Он сохраняет не только список правок, но и логику принятия решений: кто изменил, когда и почему. Правильно оформленный журнал сокращает число вопросов, упрощает коммуникацию и защищает команду при аудите.
Для конструкторской документации журнал должен опираться на ГОСТ Р 2.503-2023 и фиксировать извещения об изменении. Для разработки ПО — быть читабельным и соответствовать логике релизов по стандарту Keep a Changelog. Для проектов — давать менеджеру или главному инженеру полную картину по каждому запросу на изменение.
ЧаВо
Git log — это автоматическая история коммитов, которую генерирует система контроля версий. Она содержит технические записи разработчиков, нередко в виде «fix», «wip» или «minor changes». Журнал изменений (changelog) — это человекочитаемый документ, составленный намеренно: он объясняет, что изменилось с точки зрения пользователя или команды, а не как именно это было реализовано в коде. Один не заменяет другой.
Да. Именно внутренние документы чаще всего правятся без формальной фиксации, что и приводит к ситуациям «кто последний редактировал — непонятно». Даже простая таблица с датой, автором и кратким описанием правки даёт команде возможность ориентироваться в истории документа без личных переписок.
Извещение об изменении — это документ, который фиксирует причину, срок и порядок внесения изменений в конструкторские подлинники. По ГОСТ Р 2.503-2023, ИИ — стандартное основание для записи в журнал. При этом для документации опытного образца или изделий единичного производства допускается вносить изменения непосредственно по журналу изменений, без выпуска ИИ, при условии, что изделие изготавливается только в одной организации.
Оптимальная частота — при каждом значимом релизе. Для SaaS-продуктов с непрерывной разработкой это может быть еженедельно или раз в две недели. Не стоит копить изменения за месяц и выпускать один большой список — пользователи перестают его читать. Лучше короткие и регулярные записи, чем редкие и исчерпывающие.
Зависит от аудитории. Для пользовательского changelog — только если баг был заметен пользователю. Для внутреннего технического журнала — да, всё, что меняет поведение системы, должно быть зафиксировано, даже если правка занимает одну строку кода.
В формальных журналах (КД, СЭД) — нет. Если обнаружена ошибка в записи, оформляют новую запись с пометкой «исправление к записи № …». Это сохраняет аудиторский след. В пользовательском changelog небольшие опечатки допустимо исправлять молча, но изменение содержания записи — например, уточнение того, что именно было исправлено, — лучше сопроводить пометкой «обновлено».
Добавьте в каждую запись changelog ссылку или номер задачи (например, #1234 или JIRA-567). Это позволяет быстро перейти от описания изменения к полному контексту: обсуждению, техническому решению и тестированию. Многие команды автоматизируют этот процесс через CI/CD-пайплайн, который формирует черновик changelog из закрытых задач релиза.
Для проектной среды — отдельный журнал на каждый проект обязателен: смешивать изменения разных проектов в одном реестре значит потерять прослеживаемость. Для продуктовой разработки с несколькими компонентами — зависит от архитектуры: монорепозиторий обычно ведёт один changelog на весь продукт, раздельные репозитории — каждый свой.
