Воспитываем Заказчика или что написать в уставе проекта, чтобы согласовать ТЗ быстро и просто

Из серии «Наболело» или «Рабочие будни бизнес-системного аналитика в B2B-разработке».

Очередной проект, в котором со стороны Заказчика много (>3) согласующих лиц, на каждой итерации согласования документа прилетают отдельные файлы с комментариями от каждого, исправления внесены прямо по тексту (иногда даже не в режиме правки, а «по живому»), изобилие противоречащих друг другу возражений на любой вкус и увлекательные «междусобойчики» в комментариях.

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

Что сделать, чтобы исправить ситуацию или хотя бы уменьшить вероятность её возникновения в будущем?

Прихожу к выводу, что Заказчиков нужно воспитывать, причем начиная задолго до активного взаимодействия проектных команд. Идеально строить взаимодействие так, чтобы со стороны Заказчика была единая точка входа, например, руководитель проекта. Тогда все артефакты можно отправлять в письмах с одним адресатом в поле «Кому», и обсуждение разногласий и сроков вести с этим единственным человеком. Такую схему работы я бы формализовала в уставе проекта:

• Изменения в текст документов должны вносить только сотрудники Исполнителя. Заказчик не должен вносить изменения в текст документов, а замечания, вопросы и комментарии должен оформлять как примечания к тексту (MS Word: вкладка «Рецензирование», пункт меню «Создать примечание»; или выделить фрагмент текста, нажать правую кнопку мыши и выбрать из контекстного меню пункт «Создать примечание»).
• Если в согласовании документа участвуют несколько сотрудников Заказчика, то перед передачей его Исполнителю все правки и комментарии должны быть собраны в одном документе. При этом в передаваемом документе должны отсутствовать противоречащие друг другу замечания, а также элементы внутренней переписки между сотрудниками Заказчика.
• Комментарии к тексту документа должны четко отражать суть замечания. Например, если в тексте документа допущена ошибка, то в комментарии должно быть написано, в чем именно она заключается, и как ее нужно исправить. Пример: некорректно — «Написано неправильно»; корректно — «В списке ролей пользователей ошибочно указан секретарь, нужно исключить».
• В случае нарушения указанных правил сотрудниками Заказчика, документ не принимается Исполнителем и возвращается Заказчику для доработки. При этом сроки текущей стадии и всего проекта смещаются на количество дней, соответствующее простою, без применения штрафных санкций к Исполнителю.