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

Большая часть материала будет интересна менеджерам проектов, но я умудряюсь применять этот инструмент и для личного целеполагания. Правда, у меня может быть проф.деформация :)

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

Сначала расскажу небольшую историю.

Я руководил большим проектом по изменению деятельности компании в соответствии с требованиями регулятора. Изменения затрагивали многие области: доработка документации по продуктам (сотни документов), изменение и переподписание договоров с партнерами (больше сотни договоров), доработка сайта, офисов компании, нескольких внутренних регламентов + массовое обучение для широких кругов сотрудников.

Работая таким широким фронтом впервые, я столкнулся с тем, что разные направления «разъезжаются»:

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

Анализируя свой опыт я понял, что:

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

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

Сначала — согласовать образ конечного результата

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

Когда я впервые приступаю к заполнению реестра результатов с коллегами, я предлагаю им представить следующую картину: «Вот мы закончили проект. Приходим довольные к руководству и кладем на стол толстую папку с результатами: „Мы сделали“. Что в этой папке?» По опыту, этот вопрос очень помогает начать разговор.

В качестве примера возьмем проект по внедрению CRM (система в которой работают продавцы) за сто миллионов рублей, хранящий миллионы записей о клиентах компании. Для каждого из результатов проекта описываем:

1. Название и расширенное описание. Например: «Модуль предиктивной аналитики». Расширенное описание: «Модуль, позволяющий на базе собранных данных сегментировать клиентов, выделять среди них группы по предпочтениям, а также прогнозировать спрос».
2. Формат. Что собой будет представлять результат? Если с модулем предиктивной аналитики более-менее понятно, что это «Модуль ИТ системы», то с инструкциями к системе уже больше нюансов. Полезно сразу обсудить, что это будут страницы в корпоративной вики, а не пдф.
3. Требования к результату. Здесь фиксируем ключевые требования: пожелания руководства, ключевых пользователей. Например: «Модуль должен предусматривать интеграцию с соц.сетями и анализ клиентских данных из соцсетей». Сразу замечу, что для полномасштабного управления требованиями нужны другие инструменты. В реестре результатов — только основные, но это уже очень полезно документировать и обсудить.
4. Поставщик. Сюда пишем тех, кто «работает руками» над получением этого результата. В нашем случае это может быть подрядчик и наш департамент ИТ.
5. Ключевые пользователи. Это те, кто выдвигает требования к результату и участвует в приемке. Для модуля предиктивной аналитики CRM системы это, скорее всего, отдел маркетинга.
6. Владелец результата. Вот здесь уже менее очевидный момент. Дело в том, что назначить «Ответственного» за результат бывает сложно: если в создании участвует пять человек, то каждый из них скорее всего будет сопротивляться, чтобы его назначили единственным ответственным. Поэтому я сформулировал роль «Владельца» как «единое окно» по данному результату, и он координирует все активности, связанные с его достижением. Это может быть любой из участников команды, но скорее всего — кто-то из ключевых пользователей.
7. Процедура приемки. Договариваемся о том, как будет происходить приемка. Здесь будет полезно написать, например, что регламент должен помимо ключевых пользователей согласовать еще и Департамент внутреннего контроля. Или что данный документ надо будет нести биг боссу, а для этого перекладывать его основные тезисы на слайды.

Реестр результатов должен жить на протяжении всего проекта

Итак, мы описали все результаты проекта. Что теперь с ними делать?

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

Проводить аудит результатов. Очень полезно в ходе проекта задаваться вопросом, насколько мы продвинулись. Для этого можно добавить в реестр столбец «статус». Особенно это полезно делать, если вы консультант: когда вы приходите к заказчику с предложением подписать на следующей неделе акты, это лучший способ спровоцировать волну комментариев и отличных идей по доработке, которых так не хватало, пока вы работали над этим результатом. Аудит готовности позволит начать этот разговор сильно раньше: «Мы считаем, что этот результат готов на 50%». «А мы — что на 15%!».

Опись результатов проекта. У меня была отличная практика: когда на моем проекте работали консультанты, мы каждому результату присвоили уникальный код — типа РН-001П — и договорились о том, что все письма, в которых они нам передают те или иные результаты, будут содержать этот код. Благодаря этому я мог мгновенно найти в почте всю релевантную переписку, а после проекта все результаты лежали в кодированных папочках, а реестр результатов превратился в опись.

В общем, прошу любить и жаловать реестр результатов. Отличный инструмент, странно, почему так редко его встречаю. Если надо, могу скинуть проверенный шаблончик. Пишите в Телегу.