Материал подготовлен для будущих учащихся на курсе «Руководитель IT проектов».

Приходилось ли вам когда-нибудь оценивать программный проект, толком не зная требований? Ситуация знакомая: приходит менеджер со словами «Слушай, у нас тут новый проект…» — и ждет от вас прогноз по срокам разработки, бюджету и нужным ресурсам до следующего совета директоров.

В Agile-командах мы чувствуем себя комфортно со сторипоинтами (story points) при планировании спринтов. Мы знаем свой объём работ, скорость, загрузку. В двухнедельных циклах всё работает более-менее предсказуемо. Но руководству нужны конкретные даты и деньги. Ситуация становится ещё сложнее, когда у нас есть только расплывчатое представление о том, что вообще нужно построить, нет команды, нет данных по скорости, нет исторических данных о похожих проектах — только видение проекта, если повезет, пара документов и вайрфреймов — и руководитель, которому нужен ответ.

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

Приведу конкретный, пусть и воображаемый, пример. Средняя по размеру производственная компания захотела систему управления запасами. Им нужно было отслеживать сырьё, управлять отношениями с поставщиками, контролировать уровни запасов, интегрироваться с существующими системами и формировать отчёты для команд по закупкам. Звучит как типичная система управления запасами. Но «типичная» совсем не означает «простая» — и уж точно не означает, что объём работ не разрастётся.

Декомпозиция

Первое, что нужно сделать, — разложить задачу на «функции», которые вы реально в состоянии осмыслить. Но с декомпозицией есть важный нюанс: существует «золотая середина». Если брать слишком крупные куски, вроде «разработать систему управления поставщиками» как одну функцию, вы по сути просто гадаете. Это может занять от недели до трёх месяцев — в зависимости от того, что именно подразумевается под «управлением поставщиками». Если брать слишком мелко и дробить всё на функции по 1–2 человеко-дня, вы фактически возвращаетесь к водопадной модели — больше времени уйдёт на планирование, чем на разработку.

Для меня хорошо работает такой диапазон: от 3–5 человеко-дней до максимум 15–20 человеко-дней (1–2 спринта). Если я не могу оценить что-то в пределах 15–20 человеко-дней, это нужно дробить дальше. Понятно, что на практике часто попадаются функции и на 1–2 человеко-дня, но это не проблема, пока мне не приходится оценивать сотни таких мелких элементов — я не хочу превращать оценку в водопад с 500 крошечными функциями и неделей только на то, чтобы их оценить, при этом всё равно оставшись в тумане неопределённости. В другую сторону та же логика: иногда я могу оценить функцию и в 30+ человеко-дней, но только если у меня есть исторические данные по аналогичным задачам.

Кто вообще занимается этой декомпозицией? Зависит от компании. В больших организациях этим занимаются бизнес-аналитики, в небольших — чаще всего сами разработчики. И это нормально, но вот распространённая ошибка: разработчики начинают дробить работу на чисто технические задачи. «Спроектировать схему базы данных», «реализовать REST API», «создать доменную модель». Но современные системы обычно так не планируют. Не поймите меня неправильно — эти задачи вполне уместны на уровне детальной декомпозиции внутри одной функции, уже в процессе разработки, но представить себе реальный сценарий, где вы заранее проектируете полную схему базы данных под все функции, довольно сложно. В реальном мире вы делаете функции итеративно. Поставляете ценность — и база данных эволюционирует по ходу дела. Поэтому лучше думать в терминах того, что пользователь действительно может делать: «пользователь может создать аккаунт и войти в систему», «сотрудник может принять и обработать поступившую на склад поставку», «менеджер может сформировать отчёты для команд по закупкам» и так далее.

Разумеется, бывают исключения. Нужно настроить CI/CD-пайплайны. Нужно сконфигурировать инфраструктуру. Настроить логирование, мониторинг и всё в этом духе. Это вполне легитимные технические задачи, которые обычно выполняются в начале проекта. Оценивайте их отдельно или вместе, опираясь на прошлый опыт, — большинство инженеров примерно представляют, сколько у них уходит времени на типовую настройку в их окружении.

Когда я занимаюсь декомпозицией сам (на практике это случается не так уж часто, потому что в моей текущей компании этим в основном занимаются бизнес-аналитики), я сначала думаю в терминах модулей или функциональных областей. Для нашей системы управления запасами это могут быть: «Управление пользователями», «Каталог товаров», «Управление запасами», «Заказы на закупку», «Управление поставщиками», «Интеграция с ERP», «Отчётный дашборд», «Панель администратора» и т.п. А уже потом я дроблю каждый из этих модулей дальше. Например, «Управление запасами» может включать: «Сотрудник может принять и обработать поступившую на склад поставку», «Пользователи могут просматривать текущие уровни запасов и их расположение», «Складской персонал может перемещать товары между локациями», «Менеджеры могут корректировать количество товара для списания повреждённых или утерянных позиций» и так далее. Каждая из этих формулировок описывает действие пользователя, а не работу разработчика.

Выходим за рамки одной оценки

Итак, вы разложили работу на задачи. Дальше начинается тот этап, где большинство оценок превращается в хаос, — когда нужно приписать этим задачам числа. Наивный подход — просто прилепить к каждой задаче одно число по трудозатратам. «Сотрудник может принять и обработать поступившую на склад поставку? 10 человеко-дней». Но это не оценка, а догадка, замаскированная под точность.

Здесь на сцену выходит PERT. Вместо одной цифры по трудозатратам вы даёте три: оптимистичную, реалистичную и пессимистичную. Каждое число отражает отдельный сценарий, и само продумывание этих трёх вариантов делает ваши оценки куда более адекватными.

Вернёмся к функции «Сотрудник может принять и обработать поступившую на склад поставку».

• Оптимистичный сценарий. Базовый приём поставки с ручным вводом количества, простой поиск товара по артикулу (SKU), обновление остатков в базе данных, печать простой квитанции. Это версия «всё идет по плану, неприятных сюрпризов нет, объём работ не раздувается». В реальности почти никогда так не бывает, но теоретически может. 4 человеко-дня разработки (это просто пример, я не знаю реальных цифр для этой функции ?, звучит как 1–2 дня на бэкенд и 2 дня на фронтенд).

• Реалистичный сценарий. Теперь добавляем сканирование штрихкодов, проверку соответствия закупочному заказу (purchase order), учёт расхождений, когда фактически полученное количество не совпадает с ожидаемым, процесс проверки качества, автоматические уведомления поставщику и нормальные следы аудита. Именно это вы, скорее всего, и будете делать на практике, потому что всё перечисленное — не «приятные дополнения», а базовые требования для любого реального склада. 9 человеко-дней разработки (ещё одна примерная оценка).

• Пессимистичный сценарий. Всё вышеперечисленное плюс фотофиксация повреждённых товаров и процессы согласования для расхождений по дорогостоящим позициям. Это версия «добавили всё, что только разумно будет добавить к этой функции». 12 человеко-дней разработки (опять же, цифра для примера).

В подходе PERT ожидаемые трудозатраты рассчитываются так:

Для функции «Сотрудник может принять и обработать поступившую на склад поставку»:

Обратите внимание, что формула смещена в сторону реалистичной оценки — так и задумано. Оптимистичный и пессимистичный сценарии считаются скорее крайностями, а реалистичный — тем, что происходит чаще всего. Существуют вариации метода PERT с другими коэффициентами, но этот вариант — самый распространённый.

Рассмотрим ещё один пример — поиск по товарам.

• Оптимистичный сценарий. Базовый поиск по ключевым словам, фильтр по категориям, вывод результатов в виде сетки, добавление пагинации. Просто «чтобы работало». 3 человеко-дня разработки.

• Реалистичный сценарий. Полнотекстовый поиск с учётом релевантности, несколько осмысленных фильтров, варианты сортировки. 5 человеко-дней разработки.

• Пессимистичный сценарий. Зависимости между фильтрами, оптимизация производительности для 100 000+ SKU (артикулов). 8 человеко-дней разработки.

Что включать в пессимистичные оценки? Техническую сложность, требования к производительности, сложности интеграции. Но не стоит включать внешние зависимости вроде «ждём доступа к API» или «юридический отдел очень долго согласует». Это уже проектные риски, а не факторы оценки трудозатрат. Обрабатывайте их отдельно, иначе ваши оценки станут непригодными для использования.

Также крайне важно явно определить и зафиксировать, что именно вы оцениваете. Вы оцениваете чистое время разработки, а тестирование и документацию добавляете сверху в процентах? Разделяете бэкенд, фронтенд и тестирование в отдельных оценках? Включаете ли вы код-ревью, развёртывание и интеграционные работы? Нет «правильного» или «неправильного» подхода, но вы обязаны быть последовательными и чётко описывать границы оценки.

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

Добавление уровней уверенности

Теперь, когда у нас есть ожидаемые оценки, нужно как-то количественно описать нашу неопределённость. PERT даёт нам наиболее вероятные трудозатраты, но насколько мы в них уверены? Чтобы ответить на этот вопрос, нужно сначала посчитать стандартное отклонение. Стандартное отклонение, σ (сигма), показывает, насколько фактические трудозатраты, скорее всего, будут отклоняться от ожидаемых. σ вычисляется так:

Для наших примеров:

Приём грузов:
? = (12 − 4) ÷ 6 = 1.33 человеко-дня

Функция поиска:
? = (8 − 3) ÷ 6 = 0.83 человеко-дня

Ожидаемая оценка, полученная по формуле PERT, даёт примерно 50% уверенности. Чтобы повысить уровень уверенности, нужно добавить к ожидаемому значению несколько стандартных отклонений. Эти множители называются z-оценками (z-scores, в одностороннем варианте для наших оценок). Ниже — несколько типичных z-значений и соответствующих им уровней доверия:

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

Итак, вот как это работает для нескольких функций:

1. Рассчитайте суммарные ожидаемые трудозатраты по всем функциям:

2. Рассчитайте суммарное стандартное отклонение по всем функциям (фичам):

Обратите внимание, что мы возводим в квадрат каждое стандартное отклонение, складываем их, а затем извлекаем квадратный корень из суммы.

3. Чтобы получить окончательную оценку, добавьте произведение z-оценки и стандартного отклонения к общей ожидаемой трудозатрате:

Пример: предположим, что у модуля «Управление запасами» есть следующие функции:

• Сотрудники склада могут принимать и обрабатывать входящие поставки: 8,67 человеко-дня, σ = 1,33

• Пользователи могут просматривать текущие остатки и их расположение: 5 человеко-дней, σ = 1,2

• Складской персонал может перемещать товары между локациями: 4 человеко-дня, σ = 1,1

Шаг 1: Суммарные ожидаемые трудозатраты = 8,67 + 5 + 4 = 17.67 человеко-дней

Шаг 2: Суммарное стандартное отклонение = √(1.33² + 1.2² + 1.1²) = √4.42 = 2.1 человеко-дня

Шаг 3: Оценка для разных уровней уверенности:

• 50% уверенности: 18 человеко-дней (без дополнительного буфера)

• 80% уверенности: 17.67 + (0.84 × 2.1) = 19.43 ≈ 20 человеко-дней

• 90% уверенности: 17.67 + (1.28 × 2.1) = 20.36 ≈ 21 человеко-дней

• 95% уверенности: 17.67 + (1.65 × 2.1) = 21.14 ≈ 22 человеко-дней

Сообщение о неопределенности

Когда вы показываете оценки вместе с уровнями уверенности, вы даёте не просто числа — вы предлагаете основу для осознанного принятия решений. Вместо того чтобы говорить: «На “Управление запасами” уйдёт 18 дней» и надеяться на лучшее, вы можете сказать: «Я ожидаю 18 дней, но это всего 50% уверенности. Если нужен уровень 80%, планируйте 20 дней. Для 95% уверенности закладывайте 22 дня». Это куда лучше, чем делать вид, что неопределённости не существует.

Такой подход меняет сам характер разговоров о проекте. Вместо споров о том, «правильная» оценка или «неправильная», вы обсуждаете готовность к риску и бизнес-приоритеты. Стартап может согласиться на 60% уверенности, чтобы двигаться быстрее и идти на осознанные компромиссы, тогда как регулируемая отрасль может требовать 95% уверенности, чтобы всё работало максимально надёжно. Математика остаётся той же, но бизнес-решение становится явным. Когда стейкхолдеры понимают, что более высокая уверенность предполагает больше времени и бюджета, они могут осознанно выбирать компромиссы, а не просто требовать невозможной точности.

Советы

• Не проводите оценку в одиночку. По возможности привлекайте к оценке тех, кто будет реально выполнять работу, а если это невозможно — добавьте хотя бы 1–2 человека, которые смогут оспорить ваши предположения. Их опыт и знания помогут сделать оценки точнее.

• Документируйте допущения. Фиксируйте, что входит в оценку, а что нет, какие у вас предположения по технологии, интеграциям, сценариям для оптимистичных, реалистичных и пессимистичных оценок — всё.

• Неопределённость будет всегда. Используйте здравый смысл, делайте допущения, записывайте их и двигайтесь дальше с оценками. В ходе проекта пересматривайте свои предположения и держите фактический объем работ как можно ближе к изначальному.

• Не будьте излишне пессимистичны во всех оценках. Пессимистичные сценарии — это крайности, а не типичный случай. Какие-то отдельные функции действительно могут выйти за рамки пессимистичной оценки — это нормально, но в среднем весь проект будет ближе к вашей общей оценке.

• Не забывайте про накладные расходы. Обязательно учитывайте оверхед (overhead): код-ревью, тестирование, Scrum-церемонии и те самые «быстрые синки», которые иногда съедают половину дня. Решите, хотите ли вы включать это в оценку явно или добавлять процентом сверху. Обычно можно ожидать около 30–40% дополнительного времени на тестирование и код-ревью и 10–20% — на встречи.

• Используйте исторические данные. Если у вас есть данные по похожим прошлым проектам, используйте их, чтобы проверить свои оценки на здравый смысл. Если исторических данных нет — самое время начать их собирать.

И последнее, но не менее важное

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

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

• 22 декабря, 19:00 — Проектный менеджер 2026: успешная карьера в эпоху ИИ. Записаться

• 14 января, 19:00 — ИИ в управлении проектами: в чем ИИ действительно может помочь руководителю проектов. Записаться

• 22 января, 19:00 — Анти-паттерны управления: почему «помощь» заказчиков убивает проекты и как вернуть контроль. Записаться