Потеря правки редко выглядит как катастрофа в момент, когда она происходит. Она выглядит как файл с понятным именем, который кто-то положил в папку. Проблема всплывает через две недели - на сдаче, когда выясняется, что в комплект ушла версия без учтённых замечаний. Разбираем, где именно теряются изменения и что должно быть устроено иначе.
Три ситуации, в которых пропадают правки
Двое правят одно и то же
Конструктор и его коллега получают замечания по одному разделу. Один работает от файла с сетевого диска, второй - от копии, которую скачал утром. Оба сохраняют результат. Второе сохранение перезаписывает первое, и никто этого не замечает: имя файла то же, дата обновилась, всё выглядит нормально. Обнаруживается через неделю, когда ГИП спрашивает, почему в разделе нет изменения, которое точно вносили.
Замечание пришло к версии, которой уже нет
Экспертиза даёт замечания по комплекту, отправленному в прошлом месяце. За это время раздел правили ещё дважды. Теперь нужно понять, какие из замечаний уже сняты в текущей версии, а какие нет. Без привязки замечания к конкретной версии это выясняется вручную: открыть обе, сравнить, вспомнить.
Непонятно, что изменилось между подачами
При повторной подаче нужно показать, что именно исправлено. Если история изменений нигде не велась, ответ собирается по переписке и памяти. Чем больше времени прошло, тем дороже это восстановление.
Почему папки с датами не решают задачу
Самая распространённая схема хранения выглядит так:
Раздел_КЖ_v2_финал_испр_2.dwg. Она работает, пока над разделом
работает один человек и помнит контекст. Дальше начинаются известные эффекты:
- нет единственной актуальной версии - есть несколько кандидатов, и правильный определяется опросом коллег;
- имя файла говорит о стадии правки, но не о том, чьи замечания в нём учтены;
- копия на локальном диске исполнителя живёт своей жизнью и попадает в комплект случайно;
- историю нельзя развернуть назад: старые варианты либо удалены, либо лежат вперемешку.
Ни одно из этих следствий не связано с дисциплиной сотрудников. Схема просто не рассчитана на несколько рук и на внешние замечания.
Что должна уметь система версий в проектной организации
Одна актуальная версия и полная история
Актуальная версия должна быть одна, и определяться она должна системой, а не договорённостью. Все предыдущие сохраняются и доступны: любую можно открыть, сравнить с текущей и при необходимости вернуть. Исполнитель не выбирает, от какого файла работать - система выдаёт актуальный.
Замечания привязаны к версии
Замечание относится не к разделу вообще, а к конкретной версии. Тогда при повторной подаче видно: это замечание снято в версии 4, это ещё открыто, а вот это относилось к варианту, который отменили. Список к сдаче собирается сам, а не восстанавливается по почте.
Видно, кто и что изменил
По каждой версии фиксируется автор, дата и содержание изменения. Это нужно не для контроля сотрудников, а для ответов на рабочие вопросы: почему в разделе появилось это решение, кто его согласовал, на основании какого замечания.
Что меняется в работе
Когда версии ведутся системно, меняются три вещи. Исполнитель перестаёт тратить время на выяснение, какой файл актуален. ГИП видит состояние раздела, не собирая его по людям. При повторной подаче ответ на замечания формируется из истории, а не из переписки.
Экономия здесь не в самой операции сохранения файла, а в снятых разбирательствах. В пилотном внедрении Atlas PM сбор справки по объекту - задача того же класса, где данные собираются из разных мест, - сократился с полутора часов до пяти минут именно за счёт того, что данные лежат в одном месте и связаны между собой.
Вывод
Версионность проектной документации - не про аккуратность именования файлов, а про то, чтобы актуальная версия была одна, замечания были привязаны к версиям, а история изменений оставалась доступной. В Atlas PM это модуль документооборота: хранение с версиями, маршруты согласования и права доступа по ролям. Как это устроено - на странице функционала, посмотреть на живых данных можно в демо-среде.