Сколько времени занимает утверждение артефактов подготовленных на discovery?

Управление временем утверждения артефактов Discovery-фазы

Вопрос о сроках утверждения артефактов, подготовленных на этапе discovery (предпроектное исследование), является одним из ключевых для планирования проекта. Прямого и универсального ответа не существует, так как сроки зависят от сложного переплетения факторов. В среднем, если говорить об одном артефакте (например, техническом задании), процесс может занимать от 3-5 рабочих дней до нескольких недель.

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

Ключевые факторы, влияющие на сроки утверждения

1. Состав и зрелость заинтересованных сторон (стейкхолдеров):

    *   **Количество:** Чем больше отделов (бизнес-заказчик, маркетинг, юристы, безопасность, разработка, поддержка) вовлечено, тем дольше цикл согласования.
    *   **Полномочия:** Наличие единого **владельца продукта (Product Owner)** с четкими полномочиями принимать решения ускоряет процесс. Если такого лица нет, артефакт "ходит по кругу" между равнозначными руководителями.
    *   **Готовность к сотрудничеству:** Культурный и процессный аспект. Если в компании исторически царит недоверие между отделами, каждый пункт будет оспариваться.

1. Сложность и новизна проекта:

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

1. Качество подготовленных артефактов:

    *   Четкие, структурированные документы на общепринятом языке (например, user stories, UML-диаграммы, прототипы) снижают количество вопросов. Артефакты, которые я считаю обязательными для согласования:
        *   **Видение продукта (Product Vision)**
        *   **Границы проекта и основные требования (Scope & High-Level Requirements)**
        *   **Карта стейкхолдеров и их интересов**
        *   **Предварительная оценка рисков**
        *   **Прототипы или модели ключевых процессов (UX/UI)**
        *   **Предварительная оценка бюджета и сроков (Roadmap)**

1. Определенность процессов в компании:

    *   Прозрачный, документированный процесс с назначенными ответственными (RACI-матрица) и использованием систем управления процессами (например, Jira Workflow для этапов документа) кратно сокращает время. В хаотичной среде сроки непредсказуемы.

Оптимизация процесса: практические методы Project Manager'а

Как руководитель проекта, я активно управляю этим процессом, а не просто жду. Вот мой стандартный подход:

1. Четкое определение формата и инструментов утверждения. Еще до начала discovery мы согласовываем: "Утверждение — это подпись в Confluence или одобрение в виде комментария в Jira-задаче? Есть ли юридическая виза?".
2. Создание и соблюдение RACI-матрицы для каждого артефакта. Кто отвечает (Responsible), кто утверждает (Accountable), с кем консуль тируемся (Consulted), кого информируем (Informed).

   ### RACI для Технического задания (пример)
   | Роль                 | Подготовка (R) | Утверждение (A) | Консультации (C) | Информирование (I) |
   |----------------------|----------------|-----------------|------------------|---------------------|
   | Product Owner        |                | ✅              | ✅               |                     |
   | Business Analyst     | ✅             |                 |                  | ✅                  |
   | Tech Lead            |                |                 | ✅               |                     |
   | Руководитель отдела  |                |                 |                  | ✅                  |
   

3. Проведение воркшопов по представлению артефактов, а не просто рассылка документов по почте. Прямой диалог позволяет сразу снять 80% вопросов.
4. Использование таймбоксинга. В календарь сразу ставится событие "Совещание по утверждению ТЗ" с четкой датой, к которой все должны подготовить правки. Делается это на этапе планирования discovery.
5. Эскалация задержек. Если ключевой стейкхолдер блокирует процесс, я формально информирую спонсора проекта о риске срыва сроков запуска.

Типовой временной сценарий (на примере ТЗ)

В зрелой компании с налаженными процессами:

• День 1: Рассылка финального черновика артефакта всем по RACI. Назначение совещания на День 3.
• День 2-3: Сбор предварительных комментариев в инструменте (Confluence, Google Docs).
• День 3: Проведение часового воркшопа для обсуждения спорных моментов и принятия решений.
• День 4: Внесение итоговых правок и финальная рассылка.
• День 5: Получение формальных утверждений (подписей/комментариев).

Итого: 5 рабочих дней.

В менее зрелой среде или на сложном проекте каждая стадия может растянуться, и потребуется 2-3 итерации, что займет 2-3 недели.

Вывод: Утверждение артефактов discovery — это не техническая, а коммуникационная и организационная задача. Основная роль Project Manager'а здесь — не подготовить документы (это часто делает бизнес-аналитик), а организовать эффективный процесс принятия решений, минимизирующий время на согласования и максимизирующий ясность для команды разработки. Правильно выстроенный процесс утверждения — это фундамент для предсказуемого и успешного исполнения проекта.