Какие процессы точно должны быть в управлении проектом?

Ключевые процессы управления проектом

Управление проектом, особенно в IT, представляет собой структурированный комплекс процессов, направленных на достижение целей проекта в рамках заданных ограничений (сроки, бюджет, качество). Основные процессы можно систематизировать по группам, как это рекомендует PMI (Project Management Institute) в своем стандарте PMBOK, однако с адаптацией к специфике IT-проектов. Я выделяю следующие обязательные группы процессов.

1. Процессы инициации проекта

Это фундамент, на котором строится весь проект. Здесь определяются не просто «что делать», а зачем и для кого.

• Определение бизнес-потребности и целей проекта: Формулировка проблемы или возможности, которую проект должен решить. Цели должны быть SMART.
• Разработка Устава проекта (Project Charter): Документ, официально запускающий проект, определяющий его высокоуровневые цели, рамки, ключевых участников и полномочия менеджера проекта. В IT часто дополняется первыми набросками технического видения.
• Идентификация ключевых стейкхолдеров: Определение всех лиц и групп, влияющих на проект или зависящих от его результата (клиенты, конечные пользователи, спонсор, команда, операционный персонал).

**Пример структуры Устава проекта в IT:**
* **Проект:** Разработка мобильного приложения для онлайн-банка.
* **Бизнес-цель:** Увеличение количества транзакций через мобильные каналы на 25% в течение года после выпуска.
* **Основные требования:** Авторизация, просмотр счетов, платежи, Push-уведомления.
* **Предварительные рамки:** Не включает функционал инвестиций и кредитов.
* **Спонсор:** Директор по цифровым продуктам.
* **PM:** Иванов А.А., с полномочиями по формированию команды и контролю бюджета до 5 млн руб.

2. Процессы планирования

Планирование в IT — это не создание раз и навсегда застывшего плана, а разработка динамичной модели проекта, которая будет постоянно адаптироваться.

• Планирование содержания и создание WBS (Work Breakdown Structure): Декомпозиция всей работы проекта на управляемые компоненты — задачи. В IT это часто выглядит как иерархия: Проект -> Эпики -> Фичи -> Задачи разработки/тестирования.
• Планирование сроков: Разработка календарного плана (Ганта), определение зависимостей задач, оценка их длительности и построение критического пути.
• Планирование бюджета и ресурсов: Оценка затрат (человеческие ресурсы, инфраструктура, лицензии), формирование бюджета и плана распределения команды (разработчики, тестировщики, дизайнеры, аналитики).
• Планирование качества: Определение стандартов качества (например, процент покрытия кода тестами, критерии приемки) и процессов его контроля (ревью кода, тестирование).
• Планирование коммуникаций: Определение, кто, какую информацию, когда и в какой форме получает. План включает регулярные встречи команды (daily stand-ups), отчеты для стейкхолдеров, ревью с клиентом.
• Планирование управления рисками: Систематическая идентификация потенциальных рисков (технологические, интеграционные, ресурсные), их анализ (вероятность и воздействие) и планирование ответных мер (стратегии избегания, передачи, снижения или принятия).
• Планирование управления изменениями: Установка формального процесса (Change Request Process) для оценки и утверждения любых изменений в содержании, сроках или бюджете проекта.

3. Процессы исполнения и контроля

Это «двигатель» проекта, где планы воплощаются в жизнь под постоянным наблюдением.

• Координация и руководство командой: Набор команды, развитие, мотивация и обеспечение эффективной совместной работы. В современных IT-проектах это часто включает внедрение Agile/Scrum практик.
• Управление качеством исполнения: Выполнение запланированных действий по обеспечению качества (тестирование, инспекции).
• Распределение информации: Обеспечение коммуникации согласно плану — проведение встреч, отправка отчетов.
• Контроль выполнения проекта: Сравнение фактического прогресса (завершенные задачи, потраченные средства) с базовым планом с помощью регулярного отслеживания (tracking). Ключевые инструменты:

    *   **Анализ отклонений (Variance Analysis):** По срокам и бюджету.
    *   **Ключевые показатели эффективности (KPIs):** Например, скорость команды (velocity), количество открытых дефектов.

• Контроль качества: Проверка результатов работы на соответствие установленным критериям.
• Управление рисками и изменениями: Мониторинг рисков и запуск ответных действий при их возникновении. Обработка запросов на изменения через формальный процесс.

# Пример простого скрипта для отслеживания прогресса по задачам (концептуально)
tasks = {
    'Разработка API платежей': {'planned_days': 10, 'actual_days': 12, 'status': 'done'},
    'Интеграция с банковским ядром': {'planned_days': 15, 'actual_days': 8, 'status': 'in progress'},
    'Разработка UI': {'planned_days': 20, 'actual_days': 0, 'status': 'not started'}
}

total_variance = 0
for task, data in tasks.items():
    variance = data['actual_days'] - data['planned_days']
    total_variance += variance
    print(f"Задача: {task}, Отклонение от плана по времени: {variance} дней")

print(f"Суммарное отклонение по проекту: {total_variance} дней")

4. Процессы завершения проекта

Проект должен быть закрыт формально, а не просто «закончен».

• Финальная приемка продукта/результата: Официальное подтверждение ключевыми стейкхолдерами (чаще всего клиентом или спонсором), что все требования выполнены и продукт готов к использованию или передаче в эксплуатацию.
• Административное закрытие: Закрытие всех контрактов, финансовых счетов проекта, архивирование документации.
• Передача знаний и продуктов: Передача итогового продукта, документации и знаний эксплуатационной или сервисной команде.
• Финальная оценка и отчет: Подготовка итогового отчет о проекте (финансовые итоги, достижение целей, извлеченные уроки).
• Release и пост-релизная поддержка: В IT это часто означает не просто передачу, а деплой в production и планирование первых циклов поддержки (гипер-каре).

Почему все эти процессы обязательны?

Отсутствие любого из этих блоков процессов создает критический риск для проекта:

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

В современных гибких (Agile) методологиях эти процессы не исчезают, но становятся более итеративными и адаптивными. Например, планирование и контроль происходят в каждом коротком цикле (спринте), а инициация и завершение могут относиться как к целому продукту, так и к отдельной инкрементальной версии (release). Однако их суть и необходимость остаются неизменными.