В каком документе прописано от чего отталкиваться команде

В каком документе прописаны основы для работы команды в проекте?

В управлении IT-проектами существует четкий иерархический набор документов, который служит основой (baseline) для всех дальнейших действий команды. Ключевым документом, от которого «отталкивается» команда, является Устав проекта (Project Charter). Однако он не работает в isolation — он является частью более широкой системы документов, которую я детально разберу ниже.

1. Project Charter: Фундаментальный документ для команды

Это официальный документ, выпускаемый спонсором или ключевыми стейкхолдерами. Он авторизует начало проекта и дает Project Manager полномочия использовать ресурсы. Для команды Charter является первоисточником ответов на вопросы: «Что мы делаем?», «Зачем?» и «В каких границах?».

Ключевые элементы Charter, критичные для команды:

• Цели и бизнес-потребности проекта: Высокоуровневые цели, которые объясняют ценность проекта для бизнеса.
• Предполагаемые результаты (Deliverables): Что именно должно быть создано (например, «мобильное приложение с функционалом А, Б, С»).
• Высокоуровневые требования: Ключевые ограничения и критерии успеха.
• Основные стейкхолдеры: Кто является клиентом, спонсором, ключевыми пользователями.
• Высокоуровневые риски: Первоначальные известные риски.
• Общий бюджет и сроки: Финансовые и временные рамки.

Для команды Charter — это стратегический compass. Он не содержит технических деталей, но дает контекст и направление. Если команда начинает делать что-то, не соответствующее Charter, это прямой сигнал о отклонении от первоначальных целей.

# Пример структуры Charter (высокоуровнево)
**Project Title:** Разработка CRM-системы "SalesFlow"
**Business Case:** Увеличить конверсию лидов на 15% за счет автоматизации процесса продаж.
**Key Deliverables:** 
1. Веб-интерфейс CRM для менеджеров.
2. REST API для интеграции с сайтом.
3. Мобильное приложение для просмотра данных.
**High-Level Constraints:** Бюджет не более $500k, запуск первой версии (MVP) к Q3 2024.
**Primary Stakeholders:** Виктор Петров (Sponsor), отдел продажей (клиенты).

2. Документы, которые детализируют Charter для операционной работы команды

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

• Управление требованиями (Requirements Management):

    *   **Документ требований (Requirements Document) или Backlog (в Agile):** Здесь требования из Charter детализируются в функциональные (что система должна делать) и нефункциональные (performance, security) требования. Это **основа для разработки**.

```python
# Пример записи требования в виде User Story (Agile)
class UserStory:
    id = "US-101"
    title = "Как менеджер продаж, я хочу видеть историю взаимодействий с клиентом"
    acceptance_criteria = [
        "Отображается список всех звонков и email по клиенту",
        "Дата и тип взаимодействия отображаются для каждого события",
        "Можно добавить новое взаимодействие из этой же view"
    ]
    priority = "High"
```

• Управление содержанием (Scope Management):

    *   **План управления содержанием проекта (Scope Management Plan)** определяет, как содержание будет определяться, документироваться и контролироваться.
    *   **Диаграмма WBS (Work Breakdown Structure)** — это **основа для планирования задач и распределения работы в команде**. Она декомпозирует высокоуровневые deliverables из Charter на manageable work packages и tasks.

```mermaid
graph TD
    A[CRM Система SalesFlow] --> B1[Веб-интерфейс];
    A --> B2[REST API];
    A --> B3[Мобильное приложение];
    B1 --> C1[UI/UX Дизайн];
    B1 --> C2[Frontend Разработка];
    B1 --> C3[Backend Интеграция];
    C2 --> D1[Реализация компонента списка клиентов];
    C2 --> D2[Реализация формы добавления сделки];
```

• Управление коммуникациями (Communications Management):

    *   **План коммуникаций (Communications Plan)** — документ, который для команды определяет **форматы, частоту и каналы** отчетности и обсуждения работы (daily stand-ups, weekly reports, инструменты типа Slack/Jira).

3. Как это работает в Agile и классических (Waterfall) методологиях

• В Agile (Scrum, Kanban): Charter остается стратегическим документом. Основным операционным документом для команды становится Product Backlog, который является живым развитием требований. От него «отталкиваются» при планировании каждого Sprint, создавая Sprint Backlog. Цели Sprint (Sprint Goals) часто напрямую связаны с целями из Charter.
• В Waterfall или гибридных моделях: Charter является входным документом для создания детальных спецификаций (Software Requirements Specification, SRS) и плана проекта (Project Plan), которые затем служат жесткой baseline для команды.

Заключение и рекомендации

Таким образом, команда отталкивается от комбинации документов:

1. Устав проекта (Project Charter) — для стратегического контекста и легитимности.
2. Документ требований / Backlog — для понимания того, что строить.
3. WBS / Sprint Backlog / План проекта — для понимания того, как и в какой последовательности работать.

Критически важная практика: Нельзя просто дать команде Charter и сказать «делайте». Charter должен быть разъяснен (kick-off meeting), а его ключевые элементы должны быть трансформированы в операционные документы, которыми команда пользуется ежедневно. Также эти документы должны быть живыми — изменения в них (через процессы Change Control) должны коммуницироваться команде, чтобы она всегда работала с актуальной и авторизованной baseline.