Многие компании не уделяют документированию должного внимания, поскольку на это требуется достаточно много времени и клиент не всегда готов платить.

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

Рассмотрим минимальный набор документов, которые должен быть на каждом проекте:

✔️ Устав проекта (Project Charter) – фиксирует партнерство между исполнителем и клиентом. Устав, как правило, разрабатывается менеджером проектов. Цель создания документа – подтверждение запуска проекта, предоставление менеджеру проектов полномочий в использовании ресурсов компании, в планировании, исполнении проекта и контроля над ним.

✔️ План управления проектом – это документ, подробно описывающий, как проект будет выполняться, каким образом будет происходить мониторинг и контроль как отдельных этапов, так и проекта в целом.

✔️ Бизнес-требования (Business Requirements Document (BRD)) – детализируют бизнес-решения для проекта, включая документацию о потребностях и ожиданиях клиента. Как правило, основываются на использовании User Stories (короткие и простые описания фич).

✔️ Техническое задание (спецификация, SOW) – оговоренный набор требований к продукту, утвержденный заказчиком и компанией исполнителем (функциональные требования, которые должны быть реализованы разработчиками, чтобы пользователи могли выполнить свои задачи в рамках бизнес-требований).

✔️ Реестр заинтересованных сторон (Stakeholder Map) – по каждому стейкхолдеру описывается: фамилия, имя и отчество; должность; степень влияния; степень важности; «состояние» стейкхолдера (Работа со стэйкхолдерами); за что отвечает в проекте, а также перечень вопросов, которые с ним можно обсуждать; каналы коммуникации; контактные данные;

✔️ Матрица влияния стейкхолдеров на проект (Работа со стэйкхолдерами);

✔️ Communication Plan Matrix – содержит: тип информации, которой необходимо делиться с заинтересованными сторонами (Status Reports, Status Updates, результаты митингов и др.); цель ведения коммуникации; кто ответственный за доставку информации; кто получатель; способ и формат предоставления необходимой информации: телефонный звонок, e-mail, видеоконференция, сообщение в канале, отчет, презентация, и т.д.; с какой периодичностью и в какое время необходимо предоставлять информацию;

✔️ Расписание проекта (Project Schedule) – список контрольных событий и дат их реализации;

✔️ Meeting Notes (Kick off Meeting, Planning Meeting, Stand-up Meeting, Retrospective) – фиксация результатов любых встреч, которые касаются обсуждения вопросов, связанных с проектом.

✔️ Матрица ответственности по проекту – фиксация степени ответственности каждого члена команды за реализацию определенных функций.

✔️ Реестр рисков (Risk Register) – содержит сведения об идентифицированных рисках проекта, а также список возможных мер реагирования на риски. В документе отражается: номер; дата внесения; название риска; подробное описание; кто ответственный за управление риском; точки уязвимости (первопричины); вероятность возникновения риска; степень влияния на проект; стратегии снижения риска; тенденции риска.

✔️ Матрица вероятности и воздействия (матрица рисков) – включает критерии оценки рисков, а именно: уровень ущерба от реализации риска и вероятность наступления рискового события в течении определенного периода времени. В начале составляется шкала воздействия рисков (на примере «стоимость»: незначительное увеличение стоимости – показатель воздействия очень низкий (0,05), увеличение стоимости <10% – показатель воздействия низкий (0,1), увеличение стоимости 10-20% – показатель воздействия умеренный (0,2), увеличение стоимости 20-40% – показатель воздействия высокий (0,4), увеличение стоимости >40% – показатель воздействия очень высокий (0,8)), далее определяется вероятность возникновения риска и ожидаемое значение риска (произведение вероятности на воздействие). И такой анализ происходит по каждому риску.

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

✔️ Risk Log – заполняется лишь в том случае, если пришлось воспользоваться реестром рисков и последовать рекомендациям, которые в нем описаны. В документе отражается: номер; дата возникновения; название риска; подробное описание; кто идентифицировал; кто ответственный за устранение; приоритет; степень влияния на проект; рекомендуемые действия; статус; дата закрытия.

✔️ Issue Log (Incident Report) – это документирование события, которое нарушило нормальную работу какой-либо системы (процесса и т.п.), и того, как эта ситуация была обработана. В документе фиксируется: номер инцидента; дата возникновения; название; подробное описание; кто идентифицировал; кто ответственный за устранение; приоритет; степень влияния на проект; рекомендуемые действия; статус; дата закрытия.

✔️ Журнал изменений (иногда называют Change Requests) – фиксация запросов на изменение какого-либо функционала продукта. Запрос на изменение часто возникает, когда клиент хочет что-то добавить или изменить, после того, когда уже все требования были согласованы. Такое изменение может включать в себя дополнительную функцию, настройку или расширение функционала. Поскольку запросы на изменение выходят за рамки соглашения, это обычно означает, что клиент должен будет заплатить за реализацию данного функционала дополнительно. Как правило, Change Requests содержит: наименование проекта; порядковый номер риквеста; наименование запроса; дату запроса; описание запрашиваемых изменений; причину внесения изменений; влияние изменений на: существующие требования, график выполнения работы, стоимость проекта.

✔️ Weekly Project Status Report – фиксация раз в неделю: достижений за прошлую неделю; невыполненных тасков на прошлой неделе; проблем, с которыми столкнулась команда на прошлой неделе; номеров Change Requests, которые появились за неделю; планов на следующую неделю; Upcoming Milestones (не все упоминать, а ближайшие 2-3 этапа); новых рисков; показателей по ключевым метрикам (Мониторинг и контроль выполненных работ по проекту).

✔️ Документация от тестировщиков (Test Plan и т.п.).

✔️ Руководство пользователя – документ, оказывающий помощь пользователю в процессе эксплуатации системы.

✔️ Руководство администратора – документ, оказывающий помощь не только в процессе эксплуатации системы, но и в ее установке и настройке.

Более подробную информацию по данному вопросу вы сможете получить у нас, пройдя наши курсы (ShBP Academy).