Оценка проектов и задач через шкалу сложности (по аналогии со шкалой Бофорта)

Оценка сложности — одна из самых болезненных тем в управлении ИТ-проектами и разработкой. За 15 лет я пробовал оценивать проекты через часы, водопад, стори поинты и еще тцать разных способов. И в итоге собрал гибрид, который оказался достаточно простым для понимания и показал себя хорошо на практике за последние 3 года.

Шкала Бофорта адаптированная под ИТ проекты
Шкала Бофорта адаптированная под ИТ проекты

Классические ошибки:

  • Менеджеры и заказчики хотят «примерно понять», во сколько это обойдётся и сколько займёт.
  • Команда даёт слишком оптимистичные оценки или, наоборот, сильно страхуется.
  • Отсутствует единый язык между бизнесом и исполнителями.
  • Сложность проекта резко растёт нелинейно, а большинство людей мыслят линейно.

Чтобы решить эти проблемы, удобно использовать относительную шкалу оценки, построенную по принципу чисел Фибоначчи (1, 2, 3, 5, 8, 13…). Такая шкала естественным образом отражает рост неопределённости и рисков при увеличении сложности.

Мы взяли за основу шкалу Бофорта — известную метеорологическую шкалу, где сила ветра оценивается не по точной скорости, а по наблюдаемым эффектам. Точно так же мы будем оценивать проекты и задачи — по их «видимому воздействию» на команду, ресурсы, риски и сроки.

Шкала сложности проектов

Это примерная средняя шкала для горизонта планирования — до 1 года. Она может адаптироваться под специфику конкретного проектного офиса.

0 баллов — Штиль

  • Проект который давно перешел в разряд продуктов или сервисов - условно постоянная работа состоящая из коротких задач и фикса багов
  • Особенности: текущие сервисы, мелкие доработки, улучшения

1 балл — Легкий

  • Длительность: 1–2 месяца
  • Юнит: Инхаус команда
  • Риски: низкие
  • Стек: Zero/Low-code
  • Особенности: настройка системы, простой функционал, минимальные интеграции

2 балла — Умеренный

  • Длительность: 2–3 месяца
  • Юнит: Инхаус команда
  • Риски: низкие
  • Стек: Low-code
  • Характеристика: средние по объёму задачи с интеграциями

3 — Средний

  • Длительность: 3–5 месяцев
  • Команда / юнит: Инхаус команда
  • Риски: средние
  • Стек: Low-code + отдельные кастомные модули
  • Характеристика: значимый проект с заметным влиянием на бизнес

5 — Сложный

  • Длительность: 5–8 месяцев
  • Команда / юнит: Инхаус или Инхаус + подрядчик
  • Риски: средние / высокие
  • Стек: Code-driven (кастомная разработка)
  • Характеристика: сложная архитектура, высокие требования к производительности/безопасности

8 — Шторм

  • Длительность: 8–12 месяцев
  • Команда / юнит: Инхаус + подрядчики
  • Риски: высокие
  • Стек: кастомная разработка
  • Характеристика: крупный проект с множеством интеграций, неизвестными факторами

13 — Ураган

  • Длительность: > 12 месяцев
  • Команда / юнит: Вендоры + крупные подрядчики
  • Риски: очень высокие
  • Стек: сложный кастом + новые технологии
  • Характеристика: трансформационные проекты, высокая неопределённость

Правило использования:

  • Проекты 13 баллов крайне нежелательны. Рекомендуется разбивать на несколько проектов максимум по 8 баллов.
  • Идеальный размер проекта для одной команды — 3–5 баллов.
  • 8 баллов — уже требует очень сильного проектного управления.

Адаптированная шкала для задач (горизонт планирования — 2 недели)

Для задач по проекту мы адаптируем шкалу, сохраняя принцип Фибоначчи.

0 баллов

  • Длительность: до 1 дня
  • Описание: быстрые правки, документация, подержать на контроле какой то вопрос

1 балл

  • Длительность: 1–2 дня
  • Описание: простая задача с понятным решением

2 балла

  • Длительность: 2–3 дня
  • Особенности: стандартная задача

3 балла

  • Длительность: 3–5 дней
  • Описание: требует анализа, возможны небольшие неизвестные

5 баллов

  • Длительность: 5–8 дней
  • Описание: сложная логика, интеграции, есть вопросы

8 баллов

  • Длительность: 8-14 дней
  • Риски: высокие
  • Описание: большая задача, высокая неопределённость

13 баллов — разбить или перевести в эпик

  • Длительность: > 2 недель
  • Риски: высокие
  • Нужно переводить в проект или декомпозировать

Рекомендации по задачам:

  • Стараться выдерживать длину задач до 14 дней - до 8 баллов
  • В конце месяца или спринта собираться и обсуждать истории которые оказались длиннее 14 дней

Как внедрять эту шкалу

  1. Калибровка — проведите 1-2 сессии Planning Poker с командой на уже выполненных задачах/проектах.
  2. Единый язык — всем (PM, разработчики, заказчик) нужно понимать, что значит «5-балльный проект» или задача на 8 баллов.
  3. Ограничение WIP — не брать в работу больше одного проекта 8+ баллов одновременно.
  4. Регулярный ретро-анализ — после завершения проекта/итерации сравнивать первоначальную оценку с реальностью.
Оценка проектов и задач через шкалу сложности (по аналогии со шкалой Бофорта)

Итого

С точки зрения управления ИТ‑проектами эта шкала даёт общий язык и предсказуемость: вы заранее понимаете уровень неопределённости, нужную силу управления (роль PM, частоту синков, глубину планирования), реалистично выставляете ожидания по срокам и бюджету, и снижаете риск “незаметного” разрастания объёма за счёт простого правила — всё, что тянет на 13, надо дробить, а 8+ вести как отдельный риск‑проект с усиленным контролем.

22
11