В реестре проектов есть колонка «Ответственный ГИП» - кажется, самое простое поле в таблице: одно имя, один проект. На практике это поле устаревает быстрее остальных. Разбираем, почему так происходит и что с этим делать.
Как это выглядит на практике
ГИП увольняется или переходит на другой проект. Кто-то должен вспомнить и поправить ячейку в реестре - в отпускной таблице, в презентации для директора, в карточке проекта на портале, если он есть. Обычно правят одну таблицу и забывают про остальные три. Заказчик звонит человеку, который проект уже не ведёт третий месяц.
Почему это поле ломается первым
Дело не в невнимательности. Смена ГИПа - это не изменение одной ячейки, а событие с историей: кто вёл проект раньше, что уже решено, какие вопросы открыты, что обещано заказчику. Таблица умеет хранить только текущее состояние - «сейчас ответственный Иванов» - и не умеет хранить «до 14 марта вёл Петров, потом передал по акту, вот что было на момент передачи».
Когда система хранит только факт, а не историю, любое изменение факта означает ручную правку везде, где этот факт продублирован. Чем больше мест дублирования - тем быстрее расхождение.
Что теряется при передаче
Три вещи обычно теряются вместе со сменой ГИПа, если передача не формализована.
Контекст решений. Почему раздел спроектирован именно так, а не иначе - в переписке предыдущего ГИПа, которая новому не видна.
Открытые обязательства. Что обещано заказчику на последнем совещании, какие сроки согласованы неформально - живёт в голове, не в системе.
Ответственность за прошлые решения. Если через полгода всплывает вопрос по разделу, непонятно, к кому он на самом деле относится - к тому, кто сейчас числится ГИПом, или к тому, кто реально его вёл на момент решения.
Что нужно вместо одной ячейки
Ответственный - это не атрибут проекта, а роль с историей. Для каждого проекта должно быть видно не только «кто сейчас», но и весь список: кто вёл, с какой даты по какую, по какой причине сменился. Передача - отдельное действие, а не перезапись поля: новый ГИП принимает проект осознанно, и в этот момент можно зафиксировать открытые вопросы, а не потерять их вместе со старым чатом в мессенджере.
Отдельно - уведомления. Если ГИП сменился, все, кто завязан на проект (бухгалтерия, смежники, секретариат для переписки с заказчиком), должны узнать об этом одним действием, а не из разговора в коридоре.
Вывод
Поле «ответственный ГИП» кажется простым ровно до первой смены. История назначений и формальная передача - не бюрократия ради бюрократии, а единственный способ не терять контекст проекта вместе с уходящим сотрудником. В Atlas PM ответственность за проект и разделы ведётся с историей - подробнее на странице функционала, живой пример - в демо-среде.