Как оценивается discovery в проекте?

Как оценивается discovery в проекте?

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

Основные цели и компоненты оценки

Оценка discovery направлена на ответы на ключевые вопросы:

• Что нужно сделать? (Границы продукта и проекта).
• Как мы это сделаем? (Высокоуровневая архитектура и подход).
• Сколько это будет стоить и сколько времени займет? (Базис для коммерческого предложения и планирования).

Основные компоненты, которые необходимо оценить:

1. Анализ бизнес*контекста и проблематики: Встречи с ключевыми стейкхолдерами (C*level, будущие пользователи), изучение рынка, конкурентов.
2. Сбор и анализ требований: Формирование первичного бэклога (User Stories, эпики), определение MVP (Minimum Viable Product).
3. Техническое и архитектурное исследование: Анализ legacy*систем (если есть), выбор технологического стека, оценка интеграционных точек.
4. Оценка рисков и ограничений: Выявление бизнес*, технических, организационных и регуляторных рисков (например, GDPR).

Методы и практики оценки

Я использую следующие конкретные методы:

1. Метод декомпозиции по фазам и артефактам

Discovery разбивается на логические фазы с ожидаемыми результатами (артефактами). Оценка времени и ресурсов производится для каждой фазы.

# Пример структуры работ в днях для discovery среднего проекта
discovery_plan = {
    "phase_1_kickoff_and_context": 5,  # Страт. встречи, изучение документов
    "phase_2_requirements_workshops": 7, # Сессии с пользователями, формирование backlog
    "phase_3_technical_spike": 4,        # Анализ API, выбор технологий, прототип
    "phase_4_risk_analysis_and_reporting": 4, # Итоговый отчет, roadmap, оценка
    "buffer_for_adjustments": 3          # Бюффер на непредвиденные сложности
}
total_discovery_days = sum(discovery_plan.values())

2. Метод экспертного сравнения (Analogy Estimation)

Сравнение с аналогичными проектами из прошлого опыта. Это быстрый способ дать первоначальную оценку, но он требует детализации.

3. Оценка через story points на высокоуровневых эпиках

Даже на этапе discovery можно выделить крупные "единицы работы" (например, "Проанализировать интеграцию с CRM") и оценить их в условных story points, а затем перевести в человеко*дни, исходя из известной скорости команды на исследовательских задачах.

-- Пример таблицы для отслеживания оценки эпиков в discovery
CREATE TABLE discovery_epics (
    id INT PRIMARY KEY,
    epic_name VARCHAR(255),
    estimated_story_points INT,
    assigned_to VARCHAR(100),
    status VARCHAR(50) -- 'not started', 'in progress', 'review', 'done'
);

4. Метод трех точек (PERT – Program Evaluation and Review Technique)

Для задач с высокой неопределенностью (например, "исследование законодательных ограничений") используется формула: (Оптимистичное время + 4 * Наиболее вероятное время + Пессимистичное время) / 6 Это дает более реалистичную оценку, учитывающую риски.

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

• Количество и доступность стейкхолдеров: Если ключевые лица недоступны, процесс растягивается.
• Степень инновации проекта: Новый продукт vs. развитие существующего.
• Наличие legacy*систем и сложность интеграций: Это может потребовать отдельного технического spike.
• Ясность бизнес*целей у клиента: Если цели размыты, требуется дополнительная работа на их прояснение и формализацию.
• Регуляторные требования: Наличие требований безопасности, стандартов (например, в финтехе или медицине) увеличивает объем анализа.

Итоговые результаты и артефакты оценки

Результатом оценки discovery являются не только цифры, но и конкретные документы, которые становятся входными данными для основного проекта:

• Vision & Scope Document или Product Roadmap (высокоуровневое видение и план).
• Предварительный бэклог продукта (часто в формате эпиков и ключевых пользовательских историй).
• Техническое заключение с рекомендациями по стеку и архитектуре.
• Коммерческое предложение с оценкой стоимости и сроков следующей фазы (например, разработки MVP).
• Отчет по рискам с митигационными стратегиями.

В заключение: Оценка discovery — это динамический процесс. Я всегда настаиваю на включении буфера (buffer) в оценку (обычно 15*20%) на непредвиденные сложности и просрочки в получении информации. Четкое фиксирование границ (scope) этапа discovery в договоре или SOW (Statement of Work) защищает и команду, и клиента от "бесконечного исследования". Правильно оцененный и выполненный discovery — это инвестиция, которая многократно сокращает риски и переделки на основных этапах проекта.