Потерянные версии документов, поиски актуальных планов и отчетов, несоответствие статус проекта и реального состояния... Такое знакомо многим: и менеджерам проектов, и спонсорам, и командам (которые считают, что проще написать заново). Дело не в плохих людях, а в отсутствии системы, которая учитывает статусы и этапы проектов.

Дисклеймер. Данную статью попросили написать бизнес-аналитика с большим опытом работы в проектах.

Привет, коллеги ?! Меня зовут Вячеслав Зыкин, я работаю в IT-компании, которая вела и ведёт множество проектов. Среди них есть быстрые — на квартал-два и долгоиграющие — многомесячные внедрения, проекты, вышедшие на этапы поддержки. И да, у нас с документацией до сих пор не всё хорошо. 

Чтобы структурировать свои мысли по поводу построения правильной системы документации, которая не тормозит проект, а ускоряет его, решил изложить их в виде статьи. Если вы — коллега-аналитик, ПМ, руководитель или участник проектного офиса, стейкхолдер или руководитель компании, мои рассуждения могут показаться вам интересными.

Проектная документация — реальная помощь или ненужная бюрократия

Итак, к делу. Когда мы слышим фразу «документация проектного офиса», в голове сразу оживает образ бесконечных таблиц Excel, бесчисленных папок с непонятно кем заполненными файлами и мольбы менеджеров «давайте упростим». Неудивительно, что документацию часто воспринимают как бюрократию ради отчётов.

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

Вот о чём пойдёт речь:

• Почему работа с документацией в проектном офисе всегда связана со сложностями;

• какие статусы и этапы нужно учитывать и в чем разница между ними;

• какие принципы лежат в основе системы;

• как построить «умную таблицу» документооборота, которая станет компасом для любой команды;

• пример конкретных пакетов документов на разных статусах и стадиях;

• как внедрить и поддерживать систему проектной документации.

В чем, собственно, проблема с проектной документацией

Если коротко: проекты живут своей жизнью, у каждой команды — своя динамика, а у менеджеров — способ структурировать работу. Без единого подхода документация превращается в хаос.

Что происходит, если проектный офис не ввел системных правил работы с документацией?

• Теряется информация. Люди ищут данные по встречам в Telegram, бюджеты в Excel на сетевом диске, а ключевые акты — в почте у руководителя. И не факт, что находят. А уж сколько времени на это тратится — без слёз не расскажешь.

• Сложно контролировать. Вдруг оказывается, что никто не знает, какая версия устава с одинаковым цифровым индексом (например, 3.2) актуальна.

• Отчётность не отражает реальную картину. Спонсоры недоумевают, почему в документах одно, на совещании другое, а в личном разговоре с PM — третье.

• На проекте невозможно поменять руководителя. Если ПМ внезапно уходит, проект превращается в лакированный деревянный ящик с ручками по бокам. Его остаётся только закопать в землю. Реанимация проекта после ухода руководителя требует просто несоизмеримых ресурсов.

Чтобы избежать всех этих страшных вещей, обычно разрабатывают стандарт ведения проектов и оформления документации. Но важно не наделать ошибок. И принять, как истину, следующее утверждение:  невозможно создать один шаблон документооборота для всех случаев сразу. А значит, надо делать не только шаблоны документов и типовые канбаны, но и прописывать принципы их организации.

И ещё один важный момент: у каждого проекта есть этапы управления проектом и фактические статусы проектов. Это два разных контекста, которые часто путают.

Этапы и статусы проекта: почему их нужно разделять и учитывать

Этапы проекта — это «шаги сценария», которые проходят практически все проекты (по PMI, Prince2, Agile и любым другим методологиям):

• инициация

• планирование

• исполнение

• мониторинг и контроль

• завершение

На каждом этапе свой набор документов — например, без устава нет плана, а без итогового отчёта — понимания того, что называется Lessons Learned — извлечённые уроки или, как любили говорить во времена оны, результата «разбора полётов».

Статусы проекта — это уже управленческий взгляд с точки зрения портфеля проектов. Например:

• продажа

• дизайн

• проектирование

• разработка

• внедрение

• пауза

• архив

Этапы отвечают на вопрос «где находится проект в жизненном цикле?», а статусы — «в каком состоянии проект для компании целиком?»

Почему это важно? Представим ситуацию: проект в статусе «пауза». Формально он находится в работе, но в понятиях всего портфеля он «заморожен». Это значит, что пакет документов тоже должен обновиться: отчеты прекращаются, вместо них должен появиться документ: подтверждение паузы с указанием причин и планов.

Если учесть оба слоя — этапы и статусы — мы получим гибкую систему. Она не перегружает команды лишней формальной работой, а подстраивается под реальную жизнь проектов.

Базовые принципы построения системы документации

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

Единый словарь понятий — глоссарий

В первую очередь нужно снять «конфликт определений» — ситуацию, когда люди называют одним термином разные вещи или же имеют разное понимание о них.

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

Шаблоны и инструкции

Людям проще работать, если есть готовая форма. Устав проекта, бизнес-план (смета), реестр рисков — всё должно быть унифицировано. А к каждому шаблону должна прилагаться короткая инструкция: «куда его класть», «как подписывать», «как именовать». Или же инструкция должна быть универсальна и всеобъемлюща.

Роли и ответственность

Обычно в проектах бывает такой документ «Матрица ответственности». Она может быть частью другого документа — важно, что в ней расписаны компетенции и определён порядок принятия решений по каждому слагаемому проекта.

Типовые роли «верхнего» уровня, которые есть на каждом проекте и в каждом проектном офисе.

• Менеджер проекта (PM) отвечает за актуальность документов внутри проекта.

• Менеджер проектного офиса (PMO Manager) отвечает за целостность системы.

• Стейкхолдеры и спонсоры — получают доступ к ключевым артефактам, но не вмешиваются в версионность. Обычно есть один «смотрящий», который наблюдает за проектом и докладывает остальным стейкхолдерам и спонсорам. Но может быть и иначе.

Единое хранилище (Single Source of Truth)

Сама английская фраза переводится как «единый источник истины». Не может быть, чтобы у менеджеров была своя правда, у разрабов своя, а у ПМа — тоже собственная. 

Все документы должны быть в одном месте. Это может быть база знаний в любом виде — корпоративная Wiki или платформа для управления знаниями и совместной работы — например, TEAMLY. 

Главное — одна точка правды. 

То есть, одна сущность описывается только в одном месте — документе, таблице и т.д. 

Статусы отслеживаются в своей таблице, этапы проектов — в своей. Важно, что этих таблиц только по одной и больше ни у кого ни в каком документе или в голове нет «альтернативных» данных. 

Иначе получится, что в отчёте написано одно, у ПМа в голове другое, а команде он доводит третье. Такой проект не взлетит, если только ПМ — не какой-то уникум из фильма.

Единая структура хранения документов

Есть правило: структура папок должна быть одинаковой во всех проектах. 

Простой пример построения наименований папок и документов:

[Код проекта]_[Краткое имя]_[Код папки]_[Краткое_имя папки]

Внутри же каждый документ именуется

[Код проекта]_[Код папки]_[Наименование документа]

Типовые коды папок: 

• 00_Администрирование

• 01_Устав

• 02_Планы

• 03_Отчеты

• 04_РеестрРисков

• 05_РабочаяДокументация

• 06_Закрытие

Версионность и жизненный цикл документов

Каждый документ проходит стадии: Черновик → На согласовании → Утвержден → Архив. 

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

«Умная таблица» проектного офиса

Реестр проектов компании — это основная таблица, где руководство может понять, на каком этапе находится тот или иной проект.

Статусы лучше смотреть не в таблице, а на канбане.

Разумеется, одной этой таблицей проектный офис не ограничивается. Но Реестр проектов — основная информация, по которой ориентируется руководство компании. 

Реестр проектов, представленный на скриншотах, создан из шаблона Тимли, как и всё рабочее пространство. Удобно, осталось только адаптировать под принятые в компании бизнес-процессы.

Какие документы нужны на каждом статусе

На каждом этапе каждого проекта создаются разные документы и модифицируются существующие. 

Возьмём условный проект «Проект Б».

Более наглядное представление этой информации — в канбане.

Документы со статусом «Актуальный» можно и нужно использовать в работе. Документы с другими статусами — нет, но их статусы зависят от этапа, на котором находится проект. Например, представленный на скриншоте «Проект Б» пока проходит стадию инициации, поэтому для него ещё нет ни бизнес-плана, ни программы и методики испытаний (ПМИ).

Что удобно — что документ в БЗ открывается прямо из таблицы, ходить никуда не надо. И это единственное хранилище, единый источник правды для всей проектной команды, для руководства и стейкхолдеров. И да, вести «параллельную документацию» для последней категории потребителей информации — плохая идея.

Чтобы система заработала на практике, полезно зафиксировать «минимальные пакеты».

Продажа

• Заявка на проект.

• Предварительный устав / меморандум.

• Бизнес-план.

Дизайн, разработка, внедрение

• Устав проекта (утвержденный).

• Матрица ответственности.

• План управления.

• Бюджет и график.

• Еженедельные / ежемесячные отчеты.

• Протоколы совещаний.

• Реестры: рисков, проблем, изменений.

Пауза

• Документ «Приостановка проекта» с описанием текущего состояния и планов возобновления.

Архив

• Итоговый отчет.

• Акты передачи продукта.

• Lessons Learned.

• Опись архива.

Внедрение и поддержка системы

Самая большая сложность — заставить команду реально пользоваться системой. Вот четыре методики, которые помогут органично вплести систему управления документацией в бизнес-процессы компании.

1. Поэтапное внедрение

Сначала запускаем пилот на паре проектов. Там отрабатываем инструкцию, дорабатываем шаблоны. Потом масштабируем.

2. Обучение и коммуникация

Людям тяжело ломать привычки. Поэтому нужны:

• мини-инструкции в духе «шпаргалок»;

• короткие обучающие вебинары / скринкасты;

• эксперты по БЗ.

3. Мониторинг и аудит

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

4. Эволюция системы

Система документации не может быть застывшей. Раз в полгода ее стоит обновлять под новые реалии — новые типы проектов, новые инструменты.

Заключение: документация не враг, а инструмент доверия

Хорошо организованная документация, правильно встроенная в бизнес-процессы — это не тяжкое бремя пээма, а инструмент структурирования и управления проектом. 

Я не зря всё время упоминаю встраивание документации в БП компании. Без этого не работает — уже проверено на десятках проектов. Где, кстати, приходилось не раз восстанавливать статусы отдельных этапов, теряя на этом время и деньги.

И ещё одна очень важная мысль: чем проще и прозрачнее система, тем выше шанс, что ей будут пользоваться для работы, а не для отчётов. Простота достигается эволюцией и только эволюцией.

Коротко о главном

• Документация — это не бюрократия, если построить систему.

• Учет статусов (инициирован, в работе, завершен и т.д.) и этапов (инициация, планирование, исполнение, закрытие) позволяет сделать систему гибкой.

• Принципы: единое хранилище, единый словарь, шаблоны и инструкции, контроль ролей и версионности.

• Умная таблица документооборота показывает, какие документы нужны при каждом статусе.

• Внедрять систему нужно поэтапно, с обучением команды и регулярным аудитом.

• Итог: документация перестает быть бюрократией и становится источником истины и доверия.

Пока писал статью, укрепил свою уверенность в том, что правильно организованная документация облегчает жизнь всем участникам проекта. Ключевое слово здесь — «правильно». Если оформление органично встроено в бизнес-процессы и KPI сотрудников, то всё с ним будет хорошо. И с сотрудниками, проектами и компанией в целом тоже.