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

Методология идентификации рисков на старте проекта

Идентификация рисков на начальном этапе — это системный процесс, который я выстраиваю как комбинацию проактивных методик и коллективного экспертного анализа. Ключевой принцип: «риск — это неопределённое событие, которое в случае наступления повлияет на цели проекта». На старте мы фокусируемся на неопределённостях, способных повлиять на достижение целей по содержанию, срокам, бюджету и качеству.

Ключевые методы и подходы

Я использую структурированный комплекс методов, адаптируя их под контекст проекта:

1. Проведение стартовых workshops с привлечением ключевых стейкхолдеров

    *   Сессии мозгового штурма с использованием техник (**аналогия с прошлыми проектами**, **check-lists**, **анализ предположений** из устава и бизнес-кейса).
    *   Категоризация рисков по группам (технические, управленческие, организационные, внешние) для системного покрытия.

1. Анализ документации и контекста

    *   Детальный разбор **устава проекта (Project Charter)**, **технического задания (SOW)** и **бизнес-требований** на предмет скрытых допущений и противоречий.
    *   **SWOT-анализ** (Strengths, Weaknesses, Opportunities, Threats) проекта и команды.
    *   **Анализ стейкхолдеров** для выявления рисков, связанных с ожиданиями, коммуникацией и вовлечённостью ключевых фигур.

1. Экспертные интервью и исторические данные

    *   Консультации с техническими лидерами, архитекторами, опытными разработчиками и тестировщиками.
    *   Обращение к **реестрам рисков и урокам (Lessons Learned)** завершённых проектов. В идеале — создание и ведение организационной базы знаний.

Практическая реализация: Risk Breakdown Structure (RBS) и регистр рисков

Я начинаю с создания Иерархической структуры рисков (Risk Breakdown Structure, RBS), которая служит каркасом для мозгового штурма. Например, для IT-проекта:

graph TD
    A[Риски проекта] --> B[Технические]
    A --> C[Управленческие]
    A --> D[Организационные]
    A --> E[Внешние]

    B --> B1[Сложность/новизна технологий]
    B --> B2[Производительность/масштабируемость]
    B --> B3[Интеграции с legacy-системами]

    C --> C1[Оценки сроков/бюджета]
    C --> C2[Изменения требований]
    C --> C3[Коммуникации]

    D --> D1[Доступность/компетенции команды]
    D --> D2[Приоритизация ресурсов]
    D --> D3[Уровень зрелости процессов]

    E --> E1[Действия поставщиков/вендоров]
    E --> E2[Изменения регуляторных требований]
    E --> E3[Рыночные факторы]

На основе RBS и результатов воркшопов формируется первичный реестр рисков (Risk Register). Я настаиваю на том, чтобы для каждого риска сразу фиксировались не только описание и категория, но и причина (root cause), потенциальное воздействие на цели проекта, и, по возможности, предполагаемые реакции (страхование, смягчение, принятие, передача).

Пример фрагмента реестра в табличном виде:

Критически важные риски для IT-проектов

На старте я уделяю особое внимание нескольким универсальным для IT-сферы категориям:

• Риски, связанные с требованиями: неполные, противоречивые или постоянно меняющиеся требования.
• Риски интеграции: особенно при работе с унаследованными системами (legacy) или внешними API.
• Риски команды: нехватка компетенций, размытая ответственность, зависимость от узкого специалиста (single point of failure).
• Риски поставщиков: срывы сроков вендорами, качество предоставляемых услуг или компонентов.

Итог: Идентификация рисков на старте — это не разовое мероприятие, а запуск непрерывного процесса управления рисками. Цель — не составить исчерпывающий список (это невозможно), а создать проактивную культуру в команде, выявить и начать мониторинг наиболее критичных «подводных камней», способных сорвать успех проекта. Сформированный на старте реестр становится живым инструментом, который регулярно пересматривается и актуализируется на протяжении всего жизненного цикла проекта.