Что получал в качестве информации о проекте?

Получение информации о проекте как ключевая задача PM

При начале работы над проектом, особенно в роли Project Manager, получение полной и структурированной информации является фундаментом для успеха. Мой процесс основан на концепции информационного портфеля проекта, который я формирую из нескольких ключевых источников. Этот портфель служит основой для планирования, коммуникации и управления рисками.

Основные источники информации и их содержание

Информация поступает из формальных и неформальных каналов, и я систематизирую её следующим образом:

1. Официальные документы и договоренности (формальная основа):

    *   **Контракт/Договор или Statement of Work (SOW):** Это первоисточник. Я изучаю не только технические спецификации, но и коммерческие условия, этапы оплаты, критерии приемки, штрафы и обязательства сторон.
    *   **Бизнес-кейс (Business Case):** Документ, объясняющий **ценность проекта** для компании — ожидаемую прибыль, повышение эффективности, решение проблемы. Он помогает фокусировать команду на конечной цели.
    *   **Первичное техническое задание (ТЗ) или User Stories:** Часто предоставляется заказчиком или внутренним продукт-менеджером. Это описание функциональности, но, как правило, требует глубокой аналитики и детализации.
    *   **Регламенты и стандарты компании:** Внутренние процессы (например, **SDLC** — Software Development Life Cycle), стандарты безопасности, требования к документации.

1. Коммуникация с ключевыми стейкхолдерами (неформальная, но критически важная информация):

    *   **Встречи с заказчиком (или внутренним бизнес-спонсором):** Здесь я выясняю *недокументированные ожидания*, политический контекст проекта, реальные бизнес-потребности, скрытые behind the scenes. Часто самое важное не написано в ТЗ.
    *   **Встречи с архитекторами и ведущими разработчиками:** Получение первоначальной оценки сложности, технологических ограничений, возможных рисков на уровне архитектуры и кода.
    *   **Диалог с будущей командой:** Оценка их компетенций, загрузки, интереса к проекту. Это важно для планирования ресурсов.

Процесс обработки и структурирования полученной информации

Полученные данные я не просто архивирую — я преобразую их в управляемые артефакты проекта. Вот пример моего типичного workflow после получения исходных данных:

# Пример логики анализа первоначального ТЗ (концептуально)
def analyze_initial_requirements(raw_specs, stakeholder_interviews):
    structured_requirements = {}
    
    # 1. Разделение на функциональные и нефункциональные требования
    structured_requirements['functional'] = extract_functional(raw_specs)
    structured_requirements['non_functional'] = extract_performance_security(reqs)
    
    # 2. Выявление зависимостей и связей между требованиями
    structured_requirements['dependencies'] = identify_dependencies(structured_requirements['functional'])
    
    # 3. Приоритизация на основе бизнес-кейса и собеседований
    structured_requirements['prioritized_list'] = prioritize(structured_requirements, stakeholder_interviews)
    
    # 4. Формирование списка открытых вопросов (Open Points)
    structured_requirements['open_points'] = generate_open_questions(raw_specs, stakeholder_interviews)
    
    return structured_requirements

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

• Уточненное и приоритизированное техническое задание (часто в форме Backlog в Jira/Asana).
• Первоначальный план проекта (Project Plan) с высокоуровневыми этапами, оценками и выделенными ресурсами.
• Матрица стейкхолдеров (Stakeholder Matrix) и план коммуникаций.
• Первичный реестр рисков (Risk Register).
• Список открытых вопросов (Open Points List) для дальнейшей проработки с заказчиком.

Ключевые принципы в получении информации

• Не принимаю информацию пассивно. Я активно задаю вопросы, чтобы раскрыть глубинные потребности: "Как это будет использоваться?", "Что будет, если мы не реализуем эту функцию?", "Какое самое большое ограничение?"
• Фиксирую все. Любая важная договоренность, даже в телефонном разговоре, позже оформляется в письменном виде (email, комментарий в задаче) для избежания scope creep и размывания ответственности.
• Разделяю "что" и "как". На старте проекта я фокусируюсь на получении информации о целях (what) и ограничениях (constraints). Методы реализации (how) чаще определяются вместе с технической командой позже, на основе полученных данных.

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