Можно ли ставить PPR перед показом требований заказчику?

Ответ: Стратегия применения PPR в контексте презентации требований заказчику

Нет, как правило, ставить PPR (Preliminary Project Review, Предварительный обзор проекта) перед показом требований заказчику — это неверная последовательность действий, которая может привести к значительным проектным рискам и проблемам с коммуникацией. Такой подход нарушает базовый логический цикл проекта и принципы управления требованиями.

Давайте разберем, почему это так, и какова правильная последовательность.

Почему PPR не должен предшествовать требованиям?

1. Нарушение логики цикла требований: PPR — это оценочная и планировочная веха, цель которой — утвердить план проекта, бюджет, сроки и выделить ресурсы на основе ПРОРАБОТАННЫХ и СОГЛАСОВАННЫХ требований. Требования — это исходные данные для PPR. Представить на PPR план без четкого понимания что мы делаем — значит строить дом без проекта фундамента.

2. Риск создания плана-«фантома»: Если команда проводит PPR на основе своих внутренних, неподтвержденных заказчиком гипотез о требованиях, результатом становится план, не имеющий под собой реального основания. Это приводит к:

    *   **Неверной оценке сроков и бюджета.**
    *   **Некорректному подбору команды и технологий.**
    *   **Неизбежным пересогласованиям и конфликтам** после первого же представления требований заказчику, когда выяснятся расхождения.

1. Подрыв доверия заказчика: Представление заказчику сначала «утвержденного» внутреннего плана (результата PPR), а потом — самих требований выглядит как попытка навязать решение. Заказчик справедливо спросит: «Как вы могли что-то планировать, не обсудив со мной детали?». Это вопрос транспарентности (прозрачности) процесса.

Правильная последовательность работы с требованиями и PPR

Классический и наиболее эффективный процесс выглядит так:

1. Сбор и анализ требований (Requirements Elicitation & Analysis):

    *   Сессии с заказчиком и стейкхолдерами.
    *   Создание **бэклога продукта (Product Backlog)** или **спецификации требований к программному обеспечению (SRS)**.
    *   Приоритизация (например, методом **MoSCoW** или **Value vs. Effort**).

1. Валидация и согласование требований с заказчиком:

    *   **Показ требований в удобном формате:** пользовательские истории, прототипы (wireframes, mockups), диаграммы вариантов использования (Use Case Diagram).
    *   **Подписание документа (Requirements Sign-off)** или достижение консенсуса в рамках Agile-подхода. Это ключевая точка принятия решения: «Да, это то, что нам нужно».

1. Технический анализ и предварительное планирование (Pre-PPR):

    *   Архитектурный анализ, оценка усилий командой, выявление технических рисков.
    *   **Формирование высокоуровневой дорожной карты (High-Level Roadmap)** и **оценки бюджета**.

1. Проведение PPR (Preliminary Project Review):

    *   **Цель:** утвердить план, бюджет, сроки и выделить ресурсы **для реализации УЖЕ СОГЛАСОВАННЫХ требований**.
    *   **Участники:** руководство компании, ключевые стейкхолдеры, PM, архитектор, тимлиды.
    *   **Результат:** утвержденный устав проекта (Project Charter) или паспорт инициативы, дающий зеленый свет на полномасштабную разработку.

graph TD
    A[Начало] --> B[Сбор и анализ <br/>требований с заказчиком];
    B --> C[Валидация и согласование <br/>требований с заказчиком];
    C --> D{Требования согласованы?};
    D -- Нет --> B;
    D -- Да --> E[Технический анализ <br/>и предварительная оценка];
    E --> F[Проведение PPR с руководством<br/> на основе согласованных требований];
    F --> G[Утверждение плана, <br/>старт проекта];

Исключения и гибридные подходы

В некоторых сценариях элементы PPR могут обсуждаться раньше, но это не отменяет необходимости первичного согласования границ проекта:

• Очень крупные проекты или RFP (Request for Proposal): Вы можете провести предварительный PPR для оценки принципиальной возможности взяться за проект, но его итогом будет не план, а решение об участии в торгах и предварительная грубая оценка (Rough Order of Magnitude — ROM), которая имеет погрешность ±50%.
• Agile/Итеративные модели: Формальный PPR может отсутствовать. Его заменяет постоянное взаимодействие с заказчиком и поэтапное финансирование (например, на каждую итерацию/спринт). Однако даже здесь перед первым спринтом проходит планирование релиза (Release Planning) на основе согласованного бэклога, что по сути является аналогом PPR.

Практический вывод для Project Manager

Ваша ключевая задача — сделать требования максимально осязаемыми и достичь их формального (или неформального, но четкого) согласования ДО того, как вы просите у руководства денег и ресурсы на полноценную реализацию. PPR — это не начало диалога о проекте, а его кульминационная точка на стартовой фазе, когда все входные данные собраны, проанализированы и утверждены сторонами. Ставя PPR перед показом требований, вы превращаете его из инструмента управления в источник будущих проблем, переделок и конфликтов.