Этап планирования

Этап планирования — это переход от идеи «что мы хотим сделать» к достаточно конкретному ответу:

Что именно делаем, кто делает, когда, за сколько, с какими рисками и как поймём, что проект завершён успешно?

Например, возьмём IT-проект: разработка интернет-магазина.

1. Определяем содержание проекта — Scope

Сначала определяем, что входит в проект, а что нет.

Например:

Входит:

• каталог товаров;
• категории;
• поиск;
• карточка товара;
• корзина;
• оформление заказа;
• личный кабинет;
• административная панель;
• интеграция с платежной системой.

Не входит:

• мобильное приложение;
• программа лояльности;
• рекомендации товаров;
• интеграция с 1С на первом этапе.

Это важно, потому что без границ проекта требования будут постоянно расширяться.

В PMBOK это связано с Scope Management.

2. Собираем требования

Теперь выясняем, что именно должны получить пользователи и заказчик.

Например:

Пользователь должен иметь возможность добавить товар в корзину.

Это можно превратить в более конкретные требования:

REQ-001
Пользователь может добавить доступный товар в корзину.

Условия:
- товар должен быть в наличии;
- пользователь может выбрать количество;
- количество не может превышать остаток.

Результат:
- товар появляется в корзине;
- отображается его количество;
- рассчитывается стоимость.

Для IT-проектов требования часто оформляют как:

• User Story;
• Use Case;
• Functional Requirement;
• Acceptance Criteria.

3. Создаём WBS

После того как понятно что делать, разбиваем проект на части.

Например:

Интернет-магазин
│
├── 1. Анализ
│   ├── 1.1 Требования
│   ├── 1.2 Use Cases
│   └── 1.3 Архитектура
│
├── 2. Backend
│   ├── 2.1 Авторизация
│   ├── 2.2 Каталог
│   ├── 2.3 Корзина
│   ├── 2.4 Заказы
│   └── 2.5 API
│
├── 3. Frontend
│   ├── 3.1 Каталог
│   ├── 3.2 Карточка товара
│   ├── 3.3 Корзина
│   └── 3.4 Checkout
│
├── 4. Интеграции
│   └── 4.1 Платёжная система
│
└── 5. Тестирование
    ├── 5.1 Unit tests
    ├── 5.2 Integration tests
    └── 5.3 Acceptance testing

Это Work Breakdown Structure.

Именно здесь проект начинает превращаться из абстрактного «сделать магазин» в набор управляемых работ.

4. Оцениваем работы

Для каждой работы определяем:

• сколько времени потребуется;
• какие ресурсы нужны;
• кто будет выполнять;
• от чего зависит работа.

Например:

При этом нельзя просто сложить все числа.

Например:

Авторизация
     ↓
Каталог ──────┐
              ↓
             API
              ↓
           Frontend
              ↓
           Checkout
              ↓
       Payment integration

Некоторые работы выполняются параллельно, некоторые — последовательно.

5. Создаём расписание

Теперь определяем:

когда начинается и заканчивается каждая работа.

Например:

Неделя 1
├── Требования
├── Архитектура
└── UI дизайн

Неделя 2
├── Backend: авторизация
├── Backend: каталог
└── Frontend: каталог

Неделя 3
├── Backend: корзина
├── API
└── Frontend: карточка товара

Неделя 4
├── Checkout
├── Payment
└── Integration testing

В классическом PMBOK это относится к Schedule Management.

6. Планируем ресурсы и команду

Определяем:

Project Manager
       │
 ┌─────┼──────────┐
 │     │          │
Backend Frontend   QA
  2       1        1

И кто за что отвечает.

Например:

Здесь важно отличать:

кто выполняет работу от кто отвечает за результат.

7. Планируем стоимость

Если проект коммерческий, рассчитываем стоимость.

Например:

Backend:
20 дней × $200 = $4,000

Frontend:
15 дней × $180 = $2,700

QA:
8 дней × $150 = $1,200

Infrastructure:
$300

----------------
Итого: $8,200

Плюс может быть резерв:

$8,200 + 15% reserve
≈ $9,430

8. Планируем риски

Для IT-проектов это очень важная часть.

Например:

Например:

Риск: платёжная система не поддерживает необходимый сценарий.

Не просто записываем его, а планируем реакцию:

Проверить API
      ↓
Сделать маленький prototype
      ↓
Если API не подходит
      ↓
Выбрать альтернативный способ оплаты

Это уже Risk Management.

9. Планируем качество

Нужно заранее определить:

Что значит «сделано хорошо»?

Например:

Backend:
- unit test coverage ≥ 70%
- API отвечает < 300 ms
- нет Critical bugs

Frontend:
- работает Chrome/Firefox
- responsive
- нет Critical UI bugs

Checkout:
- невозможно оформить заказ без товара
- невозможно заказать больше остатка
- платеж корректно обрабатывается

То есть качество не проверяется только в конце — критерии качества определяются во время планирования.

10. Планируем коммуникации

Кто и что должен получать от проекта.

Например:

Developer → PM
ежедневно → статус

PM → заказчик
раз в неделю → progress report

QA → Developer
при обнаружении → bug report

PM → Management
раз в 2 недели → project status

Это Communications Management.

11. Планируем изменения

Очень важный момент.

Предположим, через две недели заказчик говорит:

«А давайте ещё добавим мобильное приложение».

PMBOK-подход не означает:

«Нет, нельзя».

Вместо этого изменение проходит через процесс:

Change Request
      ↓
Анализ влияния
      ↓
Scope + Time + Cost + Risk
      ↓
Решение
      ↓
Approved?
   /       \
 Yes        No
 ↓          ↓
Update      Reject
plan

Например:

Мобильное приложение добавляет 6 недель и $12,000.

После этого заказчик принимает решение уже понимая последствия.

В итоге получается Project Management Plan

Все эти вещи вместе образуют план управления проектом.

Условно:

                 PROJECT PLAN
                      │
       ┌──────────────┼──────────────┐
       ↓              ↓              ↓
     Scope          Schedule        Cost
       │              │              │
       ↓              ↓              ↓
   Requirements      WBS          Budget
                      │
       ┌──────────────┼──────────────┐
       ↓              ↓              ↓
     Quality        Risks        Resources
       │              │              │
       └──────────────┼──────────────┘
                      ↓
               Communications
                      ↓
                  Changes