Документирование в проектном управлении: просто или гибко?

Автор публикации: Мария Романова, к.э.н, член Правления Ассоциации управления проектами «Совнет», владелец продуктов надзорных процессов ЦБ РФ, эксперт Мирового Банка, IPMA/СОВНЕТ уровень A, PMP@ PMI, АСP@PMI

Материал взят из телеграм-канала Сообщества Практиков Проектного Управления.

С появлением гибких технологий, принципов и правил Agile Манифеста документирование перестало быть приоритетным. Однако как в ИТ, так и в других сферах без правильно организованного процесса документирования невозможно управлять проектом, найти последние версии и понимать, что написано в коде или в какой части создаваемого продукта совершена ошибка, и, соответственно, понять, как ее исправлять. С ответственностью вообще становится сложно, так как нет зафиксированного описания кода/продукта, соответственно, не с кого спрашивать. Распределение в Jira по задачам не дает четкого распределения ответственности и Владелец продукта должен решать что делать и несет глобальную ответственность за продукт.

Чаще всего документация ведется в Confluence, задается структура документов, настраивается логика работы с документами и, конечно, все документы должны быть доступны из поиска (в соответствии с правами доступа).

Определяется роль технического писателя и его загрузка, нужен ли он на полную ставку или можно «расшаривать» ресурс. Если нет технического писателя, то назначается аналитик как ответственный за направление документирования. Правила и процедуры описываются в регламенте/положении о проектной деятельности организации.

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

Принципы, которые лежат в основе гибкого мышления, например, «Рабочее ПО превыше всеобъемлющей документации», сфокусированы на создании ценности для клиента. Это значит, что время, которое тратится на проект, должно быть направлено на ценность для Владельца продукта. Это относится и к документации. Переход к гибким и гибридным методам управления проектами означает, что надо переосмыслить способ документирования, чтобы избежать расходы на то, ценность чего может не быть востребована. Однако это не означает, что документирование низкоприоритетная задача, ее можно сделать когда-то потом или вообще это не делать. После того как MVP одобрен и включен в финальный продукт, задачи по документированию становятся приоритетными.

Конечно, для проектов надо определяться с составом документации - какие справочники, руководства, описания комплексов задач нужны и сколько стоит создание данной документации. Определить ресурсы по ее разработке и актуализации, вести по документации учет и контроль разрабатываемых продуктов, их обновлений. Особенно это важно, если продукты кроссфункциональные или относятся к высокорискованным. Но если это просто ИТ-продукты, через год найти кто разработал данную функциональность продукта, как ее поддерживать, на что она влияет без документации невозможно. А если сотрудники уволились и их знания более не являются активами организации, то надо переделывать продукт или нанимать бывших сотрудников на ГПХ, слишком дорогие оба варианта.

В общем я ЗА документирование и в сбалансированном виде с выделенными ресурсами считаю это обязательным условием для ведения успешных проектов и продуктов. С какими ситуациями вы сталкивались и чему это вас научило? Какая ваша точка зрения?