На какие документы PM опирается в работе кроме ТЗ?

Документы, на которые опирается PM в работе помимо ТЗ

Помимо технического задания (ТЗ), проектный менеджер в IT опирается на целый комплекс документов, которые формируют управленческую инфраструктуру проекта. Эти документы обеспечивают контроль, коммуникацию, планирование и качество. Я разделю их на ключевые категории, соответствующие областям управления проектами.

1. Планирование и управление исполнением

В этой категории находятся "живые" документы, которые постоянно актуализируются.

• Устав проекта (Project Charter) – это базовый документ, официально запускающий проект. Он фиксирует высокоуровневые цели, ключевых участников, основные риски и бюджетные рамки. Устав предоставляет PM полномочия и является отправной точкой для всех последующих планов.
• План управления проектом (Project Management Plan) – это основной комплексный документ, объединяющий все нижестоящие планы. Он описывает, как будут осуществляться процессы управления: коммуникацией, рисками, качеством, изменениями и т.д.
• Диаграмма Ганта (Gantt Chart) / Календарный план – визуальное представление расписания проекта с зависимостями задач. Часто поддерживается в специализированных инструментах (Jira, MS Project).
• Дорожная карта продукта (Product Roadmap) – стратегический документ, показывающий этапы развития продукта на долгосрочной перспективе, связывающий бизнес-цели с релизами.

gantt
    title Пример дорожной карты проекта (высокоуровнево)
    dateFormat  YYYY-MM-DD
    section Фаза 1: Исследование
    Анализ рынка           :2024-01-01, 30d
    Формирование требований :2024-01-31, 20d
    section Фаза 2: Разработка
    Прототипирование       :2024-02-20, |14d
    Бэкенд разработка      :2024-03-06, 30d
    Фронтенд разработка    :2024-03-06, 25d

2. Управление требованиями и изменениями

ТЗ — лишь основа, но требования живут и меняются.

• Бэклог продукта (Product Backlog) – в Agile (Scrum) это приоритизированный список всех функциональных и не функциональных требований к продукту. Для каждого элемента (Epic, Story) описывается ценность для пользователя.
• Реестр изменений (Change Request Log) – формальный журнал всех запросов на изменение требований, бюджета или сроков. Каждый запрос имеет статус (открыт, одобрен, отклонен) и impact analysis.
• Матрица трассировки требований (Requirements Traceability Matrix) – таблица, которая связывает первоначальные требования с конкретными задачами, тест-кейсами и конечными компонентами продукта. Это инструмент для проверки покрытия и управления изменениями.

3. Управление коммуникацией и отчетность

Эти документы обеспечивают прозрачность для стейкхолдеров.

• План коммуникаций (Communication Plan) – определяет, какая информация, в какой форме, какому кругу лиц и с какой периодичностью будет предоставляться (например, weekly статус-отчеты для команды, monthly презентации для спонсора).
• Отчеты о статусе проекта (Status Reports) – регулярные сводки о прогрессе, ключевых достижениях, отклонениях от плана (по срокам, бюджету, scope) и планах на следующий период.
• Реестр стейкхолдеров (Stakeholder Register) – список всех лиц, заинтересованных в проекте, с указанием их роли, уровня влияния, ожиданий и предпочтительных каналов коммуникации.

4. Управление рисками и качеством

Проактивное управление неопределенностью и стандартами.

• Реестр рисков (Risk Register) – основной документ для управления рисками. Для каждого идентифицированного риска фиксируется:

    *   Описание и категория.
    *   Вероятность и воздействие (проставляется оценка).
    *   Статус (активный, мониторится, закрыт).
    *   Ответственный владелец.
    *   План реагирования (mitigation или contingency plan).

• План управления качеством (Quality Management Plan) – описывает стандарты качества (например, критерии приемки), процессы проверки (тестирование, ревью кода), используемые инструменты и метрики (например, количество дефектов).
• План тестирования (Test Plan) – детальный документ от QA-лида или тест-менеджера, описывающий стратегии, среды, расписание и ресурсы для тестирования продукта.

5. Управление поставками и ресурсами

Документы для работы с внешними партнерами и внутренними ресурсами.

• Контракты и соглашения (Contracts / SLA) – юридические документы с подрядчиками, поставщиками облачных услуг или внешними разработчиками, фиксирующие объем услуг, сроки, стоимость и критерии качества.
• План управления ресурсами (Resource Management Plan) – описывает потребность в человеческих ресурсах (разработчики, дизайнеры, аналитики) по фазам проекта, их роли и уровень занятости. Часто интегрируется с календарным планом.
• Матрица ответственности (RACI Matrix) – таблица, которая проясняет роли участников для ключевых задач или процессов: кто Ответственный (R) за исполнение, кто Подотчетный (A) за утверждение, кто Консультируемый (C) и кто Информированный (I).

Заключение

Таким образом, опытный PM работает не с одним ТЗ, а с системой взаимосвязанных документов, которая:

• Фиксирует базовые решения (Устав, План управления проектом).
• Обеспечивает оперативное управление (Бэклог, Реестр рисков, Календарный план).
• Контролирует изменения и качество (Реестр изменений, Матрица трассировки, План тестирования).
• Документирует коммуникацию и отчетность (План коммуникаций, Статус-отчеты).

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