Какую информацию получаешь о проекте на входе?

Начальная информация о проекте: структура и критически важные данные

Когда проект поступает ко мне как к руководителю, я систематизирую поступающую информацию по нескольким ключевым блокам. Этот инциационный пакет (Project Charter Inputs) является фундаментом для всех последующих решений и планирования.

1. Бизнес-контекст и стратегическое обоснование

Это первейший и самый важный блок. Без четкого понимания «зачем» нельзя двигаться к «что» и «как».

• Бизнес-цели и измеримые выгоды (Business Case): На какую бизнес-проблему или возможность проект отвечает? Какой KPI (Key Performance Indicator) должен улучшиться (например, увеличение выручки на X%, сокращение издержек на Y%, уменьшение времени обработки заявки)?
• Видение продукта/результата (Product Vision): Какое высокоуровневое описание того, что мы создаем? Пример: «Создать единый кабинет клиента для повышения лояльности и кросс-продаж».
• Стейкхолдеры (Stakeholders): Кто является спонсором (Sponsor), заказчиком (Customer), конечными пользователями (End Users), представителями бизнес-подразделений? Их ожидания и уровень влияния.

2. Ограничения и рамки проекта (The Triple Constraint & Beyond)

Классическая триада «Сроки-Бюджет-Содержание» (Time-Cost-Scope) всегда уточняется на входе, но важно и большее.

• Предварительные сроки (Timeline): Желаемая дата запуска (Go-Live), ключевые контрольные точки (Milestones), жесткие дедлайны, связанные с внешними событиями.
• Бюджетные рамки (Budget Constraints): Утвержденный бюджет или его ориентир, модель финансирования (капитальные/операционные расходы).
• Границы содержания (Scope Boundaries): Что входит в проект, а что — категорически нет (Out of Scope). Часто описывается в виде высокоуровневых требований (High-Level Requirements) или эпиков (Epics) в методологии Agile.
• Прочие ограничения: Требования к качеству, нормативно-правовые ограничения, технологический стек, команда.

3. Ресурсная и организационная информация

План нереализуем без ресурсов.

• Доступная команда (Team): Кто уже выделен? Их роли, компетенции, уровень занятости на проекте.
• Организационная структура (Organizational Structure): В рамках какого подразделения реализуется проект? Существует ли PMO (Project Management Office)? Какие процедуры согласования и отчетности приняты в компании?
• Риски и зависимости (Risks & Dependencies): Известные на старте риски (например, зависимость от поставки оборудования от третьей стороны) и внешние зависимости (другие проекты, действия смежных отделов).

4. Технические и операционные входные данные

Особенно критично для IT-проектов.

• Существующая экосистема (As-Is Environment): Описание текущих систем, инфраструктуры, архитектуры, с которой предстоит интеграция.
• Документация и артефакты: Технические задания (ТЗ), протоколы совещаний, результаты предыдущих исследований или пилотов, контракты с подрядчиками.
• Предположения (Assumptions): Что считается истиной в отсутствие подтвержденных данных? (Например, «предполагается, что ключевой специалист будет доступен с 1 июня»).

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

Я часто создаю живой документ (Confluence, Wiki) или презентацию, которая суммирует эту информацию. Вот как может выглядеть фрагмент в виде структурированного списка:

### Проект "Внедрение CRM System X"
**Бизнес-цель:** Увеличить конверсию входящих лидов на 15% к Q4 2024.
**Спонсор:** Иванов А.А. (Коммерческий директор).
---
**Ограничения:**
*   **Срок:** Go-Live — 01.10.2024.
*   **Бюджет:** Не более 5 млн руб., включая лицензии.
*   **Содержание (In Scope):** Миграция данных из старой системы, интеграция с телефонией, кастомизация воронки продаж.
*   **Содержание (Out of Scope):** Развитие маркетингового модуля.
---
**Ключевые стейкхолдеры:**
1.  Пользователи: Отдел продаж (30 чел.), менеджер отдела — Петрова В.С.
2.  Технический владелец: Сидоров П.П. (Начальник IT-отдела).
3.  Внешний поставщик: Компания "CRM-Партнер".
---
**Известные риски:**
*   Высокий: Низкая вовлеченность пользователей из отдела продаж в тестирование.
*   Средний: Задержка поставки API-документации от "CRM-Партнер".

Что я делаю с этой информацией?

Получив эти данные, моя первая задача — не начать планировать, а провести анализ полноты и непротиворечивости. Часть данных будет противоречить друг другу (например, объем работ при заданных сроках и бюджете). После этого я инициирую серию уточняющих интервью с ключевыми стейкхолдерами, чтобы согласовать видение, расставить приоритеты и формализовать информацию в Уставе проекта (Project Charter) или его аналоге. Это и будет отправной точкой для детального планирования и запуска проекта.