Как правильно оценивать сроки IT-проектов

Меня зовут Александр, я CTO компании AppFox. Мы более 10-ти лет занимаемся заказной разработкой и также имеем собственные продукты.

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

Вспомните, когда вы только начинали изучать свой первый язык программирования и пошли решать задачи на Codewars (если, конечно, в то время он уже был). Насколько точно вы могли прогнозировать сроки решения задачи? Скорее всего, вилка ответов могла расходится от «Я решу эту задачу за 1 час» до «Я не решу эту задачу никогда». Что-то изменилось с тех пор? Я говорю не о сложности задач, которая, несомненно, изменилась за время вашей карьеры, а о прогнозировании сроков.

Оценка будущих работ занимает много времени, раздражает и даже демотивирует команду. Но, к сожалению, без нее никуда. Большинство заказчиков с вами не захотят иметь дело, если вы заявите, что не используете предварительную оценку задач. Кроме того, в последнее время заказчики хотят сделку. Т.е. фиксированную стоимость конечного продукта.

Хочу сразу оговориться, что под заказчиком я подразумеваю не только стороннего клиента компании, но также product manager, CEO и вообще любого представителя бизнеса, который в вашей компании имеет полномочия добавлять таски на доску.

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

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

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

Аутсорс или продукт

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

В аутсорсе от оценки зависит прибыль и удовлетворенность клиента, а в продукте — эффективность инвестиций и выживаемость компании на рынке.

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

Главное отличие в том, что в аутсорсе оценка часто фиксируется в контракте, а в продукте может корректироваться. Но в любом случае, если разработчики систематически ошибаются в сроках, это подрывает доверие к команде.

Уровень детализации ТЗ и «коэффициент неопределенности»

Конечно, точная оценка начинается с точного ТЗ. Чем подробнее — тем лучше. Но давайте будем честны: в реальных проектах полностью исчерпывающее ТЗ — это редкость. Его либо нет вообще, либо оно слишком общее, либо требует стольких усилий на составление, что становится экономически невыгодным.

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

Итак, в реальности ТЗ никогда не бывает идеальным:

1. Чрезмерная детализация требует много времени, а бизнес редко готов за это платить.
2. Разработчик может не учесть скрытые сложности, даже если задача кажется знакомой.
3. Технический долг и legacy-код вносят неожиданные задержки.

Что делать?

1. Декомпозировать задачи на подзадачи (4-12 часов на каждую).
2. Проводить оценку в несколько этапов: грубая прикидка → уточнение после анализа.
3. Закладывать буфер на «неизвестные неизвестности» (обычно +30%).

Демо, прототип, MVP, research, proof of concept и проблемы масштабирования

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

Представьте себе, что вы разрабатываете нейросеть для обучения пользователей языку Лики (естественный язык из семейства Торричелли в Папуа — Новой Гвинее). Вам и вашей команде кажется очевидным, что это - задача на Research. Вы называете сроки и успешно укладываетесь в них. Но, к вашему удивлению, вместо восхищения, что «продукт научился говорить на языке папуасов и почти не ошибается», на вас сыпется шквал негодования, так как представители бизнеса ожидали от вас готовый продукт с оптимизацией ресурсов на AWS. Не называю имен компаний и реальной цели продукта, но это — действительный кейс.

Нужно чётко различать:

1. Демо — для демонстрации идеи, часто без полноценной логики. Включает в себя демонстрацию основных функций и возможностей продукта.
2. Прототип — для теста ключевых механик и UX/UI. В отличие от демо, разрабатывается на технологиях, выбранных для основной реализации проекта. Например, если вы выбрали Go для бэкенда, а React для фронтенда, то демо вы можете набросать и на Django (для скорости разработки), а прототип в идеале должен быть разработан на Go и React.
3. MVP — минимально работающий продукт для первых пользователей. Ключевой момент — в MVP должны отсутствовать всевозможные заглушки, недоработки и тупиковые механики. Это - минимальная, но вполне рабочая версия продукта, которая нередко имеет и монетизацию.
4. Proof of Concept (PoC) — проверка возможности реализации идеи на уровне базовой версии.

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

Как избежать проблем?

1. Четко фиксировать, что входит в текущий этап.
2. Объяснять клиенту разницу между MVP и полноценным продуктом.
3. Учитывать, что код для демо часто приходится переписывать.

Потенциальные риски и неучтенные детали

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

1. Неизвестные интеграции
2. Слабая документация по API
3. Зависимость от третьих лиц
4. Задержки согласований
5. Смена требований
6. Медленный доступ к тестовым данным
7. Незрелая команда
8. Больничные, увольнения
9. Проблемы с производительностью при масштабировании.
10. Неучтенные кейсы в бизнес-логике.

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

Методы оценки проекта (PERT, Planning Poker, Wideband Delphi)

Для минимизации субъективных ошибок и неопределенности есть проверенные методы оценки сроков:

PERT (Program Evaluation and Review Technique) — это инструмент управления проектами, предназначенный для анализа сроков выполнения задач. Он был разработан в 1950-х годах для сложных проектов с высокой неопределенностью, таких как разработка ракетных систем (проект Polaris).

Основные принципы PERT

PERT помогает определить:

1. Критический путь — самую длинную цепочку задач, от которой зависит срок завершения проекта.
2. Вероятностные оценки времени — учитывает оптимистичный, пессимистичный и наиболее вероятный сценарии.
3. Риски и резервы времени — показывает, какие задачи могут быть задержаны без ущерба для проекта.

Ключевые элементы PERT

1. Сетевой график (PERT-диаграмма). Задачи изображаются в виде узлов, а зависимости между ними — стрелками. Позволяет наглядно увидеть последовательность работ.
2. Три временные оценки для каждой задачи. Оптимистичное время (O) — минимально возможный срок при идеальных условиях. Пессимистичное время (P) — максимальный срок при наихудших условиях. Наиболее вероятное время (M) — реалистичная оценка при нормальных обстоятельствах.
3. Расчет ожидаемого времени. Формула: Te = (O + 4M + P) / 6. Это средневзвешенное значение, где наибольший вес (4/6) дается наиболее вероятному времени.
4. Оценка неопределенности (дисперсия и стандартное отклонение). Дисперсия (σ²) показывает разброс возможных сроков: σ² = ((P — O) / 6)². Стандартное отклонение (σ) — мера риска: σ = (P — O) / 6
5. Критический путь (Critical Path, CP). Самая длинная последовательность задач, определяющая общий срок проекта. Если любая задача на этом пути задерживается, задерживается весь проект.
6. Резервы времени (Slack/Float). Разница между самым ранним и самым поздним началом задачи. Задачи вне критического пути могут иметь запас времени.

Пример расчета PERT

Допустим, задача имеет оценки:

1. O = 5 дней
2. M = 7 дней
3. P = 12 дней

1. Ожидаемое время: Te = (5 + 4*7 + 12) / 6 = (5 + 28 + 12) / 6 = 7.5 дней
2. Дисперсия: σ² = ((12 — 5) / 6)² ≈ 1.36

Плюсы и минусы PERT

Преимущества:

1. Учитывает неопределенность в сроках.
2. Позволяет оценить вероятность завершения проекта вовремя.
3. Дает наглядное представление о зависимостях задач.

Недостатки:

1. Требует много времени на сбор оценок.
2. Менее эффективен для простых проектов.
3. Зависит от точности экспертных прогнозов.

Отличие PERT от CPM (Critical Path Method)

1. PERT использует вероятностные оценки (O, M, P), подходит для проектов с высокой неопределенностью (например, НИОКР).
2. CPM работает с фиксированными сроками, применяется в строительстве и других предсказуемых проектах.

PERT полезен для сложных проектов, где важно оценить риски задержек. Он позволяет менеджерам планировать сроки с учетом оптимистичных и пессимистичных сценариев.

Planning Poker — используется в Agile-командах (чаще всего мы применяем именно этот метод). При оценке сметы сложные или спорные задачи помечаются в комментариях, как задачи для оценке методом покерного планирования. После чего собирается группа для проведения данного мероприятия.Planning Poker — это техника оценки задач в гибких методологиях разработки, таких как Scrum. Она помогает команде достичь консенсуса в оценке сложности задач, используя story points.

В сессии обычно принимают участие разработчики, тестировщики, аналитики и другие члены команды, которые будут работать над проектом. Для оценки используются карты с числами, например, из последовательности Фибоначчи (1, 2, 3, 5, 8, 13, 21 и т.д.).

Проектный менеджер или бизнес-аналитик представляет задачу. Он объясняет, что нужно сделать, зачем это нужно и какие критерии приемки должны быть выполнены. Команда задает вопросы для полного понимания задачи.

Каждый участник выбирает карту с оценкой. Оценка проводится в story points, которые отражают сложность задачи, объем работы и неопределенность. Чем больше число, тем сложнее задача.

Оценка проводится анонимно. Участники не должны влиять друг на друга, поэтому карты переворачиваются одновременно.

Обсуждение расхождений. Если оценки сильно различаются (например, один участник поставил 2, а другой — 8), те, кто поставил самые высокие и самые низкие оценки, объясняют свою позицию. Это помогает выявить недопонимание или учесть аспекты, которые кто-то упустил.

После обсуждения команда снова оценивает задачу. Процесс повторяется, пока не будет достигнут консенсус.

Пример:

1. Задача: «Реализовать авторизацию через социальные сети»
2. Обсуждение: команда задает вопросы о том, какие соцсети нужно поддерживать, есть ли готовые библиотеки и т.д.
3. Оценка: участники выбирают карты (например, 3, 5, 8).
4. Обсуждение расхождений: те, кто поставил 8, объясняют, что нужно учитывать интеграцию с несколькими API, а те, кто поставил 3, считают, что есть готовые решения.
5. Повторная оценка: после обсуждения команда соглашается на 5 story points.

Wideband Delphi — это структурированный метод прогнозирования и оценки, основанный на мнении экспертов. Он был разработан в 1940-х годах корпорацией RAND для военных проектов, а затем адаптирован для управления IT- и инженерными проектами.

Основные принципы Wideband Delphi

1. Анонимность оценок – эксперты работают независимо, чтобы избежать влияния авторитетов.
2. Итеративный процесс – оценки уточняются в несколько раундов.
3. Статистическая обработка – итоговый прогноз выводится на основе медианы или среднего.
4. Обсуждение расхождений – между раундами эксперты обсуждают спорные моменты.

Ключевые этапы метода

1. Подготовка. Формируется группа экспертов (обычно 3-5 человек). Определяется задача (например, оценка сроков разработки). Подготавливаются материалы (требования, аналогичные проекты).
2. Первый раунд оценки. Каждый эксперт анонимно дает свою оценку (например, в человеко-часах или днях). Оценки собираются и анализируются (вычисляется медиана, диапазон).
3. Обсуждение результатов. Эксперты видят сводку оценок (без имен). Обсуждаются крайние значения (почему кто-то дал очень высокую или низкую оценку?).
4. Повторные раунды (2-3 итерации). Эксперты корректируют свои оценки с учетом обсуждения. Процесс повторяется, пока оценки не сходятся.
5. Финальный прогноз. Принимается итоговая оценка (обычно медиана последнего раунда).

Пример применения Wideband Delphi

Задача: оценить время разработки нового модуля ПО.

Раунд 1 (оценки экспертов в днях):

1. Эксперт 1: 15
2. Эксперт 2: 20
3. Эксперт 3: 30
4. Эксперт 4: 25
5. Эксперт 5: 10

Медиана: 20 дней Диапазон: 10–30 дней

Обсуждение:

1. Эксперт 5 объясняет низкую оценку: «Есть готовая библиотека, можно ускориться».
2. Эксперт 3 аргументирует высокую оценку: «Возможны проблемы с интеграцией».

Раунд 2 (скорректированные оценки):

1. Эксперт 1: 18
2. Эксперт 2: 22
3. Эксперт 3: 25
4. Эксперт 4: 20
5. Эксперт 5: 15

Итоговая медиана: 20 дней

Преимущества Wideband Delphi

1. Минимизирует субъективность – за счет анонимности и обсуждения.
2. Учитывает разные мнения – эксперты учатся друг у друга.
3. Гибкость – подходит для оценки сроков, бюджета, рисков.

Недостатки

1. Требует времени – несколько раундов и обсуждений.
2. Зависит от экспертов – если группа некомпетентна, оценка будет неточной.

Отличие от классического Delphi

1. Wideband Delphi включает больше обсуждений и считается менее формальным.
2. Классический Delphi чаще используется для долгосрочных прогнозов (например, в науке).

Когда применяется?

1. Для сложных проектов с высокой неопределенностью.
2. Когда нет исторических данных для статистических моделей.
3. Для снижения риска занижения/завышения оценок.

Wideband Delphi – это мощный инструмент для консенсусной оценки, особенно полезный в условиях неопределенности. Он сочетает независимость мнений с коллективным анализом, что повышает точность прогнозов. Данный метод мы использовали в проектах для Т Банк. Метод дает максимально точную оценку, но, как было указано выше, очень зависит от конкретных экспертов. Не подходит незрелым командам.

Опыт прошлых проектов

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

Опыт! = данные

1. Опыт субъективен — разработчик может помнить только самые сложные или, наоборот, простые задачи.
2. Когнитивные искажения — оптимизм (»в этот раз всё получится быстрее») или пессимизм (»в прошлый раз было сложно, значит, и сейчас будет»).
3. Изменение контекста — даже похожие задачи в новом проекте могут иметь скрытые отличия (другая архитектура, библиотеки, команда).

Какие метрики стоит собирать?

1. Запланированное и фактическое время. Сколько часов ушло на аналогичные задачи в прошлом? Насколько часто оценки оказывались заниженными?
2. Коэффициент ошибки (planning fallacy). Например, если задачи по фронтенду в среднем выполнялись на 30% дольше, чем оценивали, это стоит учитывать в новых оценках.
3. Зависимости и bottlenecks. Какие этапы чаще всего задерживали проект (ожидание ревью, тестирование, интеграции)?
4. Сложность vs. время. Разбиваем задачи по типам (CRUD, интеграция, оптимизация) и смотрим, сколько в среднем уходит на каждый тип.

Как мы применяем эти данные в AppFox?

1. Корректируем оценки. Если данные показывают, что интеграции с внешними API обычно занимают на 50% больше времени, чем предполагалось, закладываем этот буфер.
2. Используем аналогии. «Похожая задача в проекте X заняла 40 часов, но там не было авторизации — значит, сейчас нужно +20 часов».
3. Обнаруживаем паттерны. Например, если код-ревью всегда добавляет +2 дня к сроку, можно либо закладывать это время, либо менять процесс.

Пример: ретроспективный анализ оценок

Допустим, в прошлом проекте было:

1. 10 задач по 8 часов по оценке.
2. Фактическое время: в среднем 12 часов.

Вывод:

1. Команда систематически недооценивает задачи на 50%.
2. В новом проекте можно умножать первоначальные оценки на 1.5.

Проблемы и ограничения

1. Недостаток данных — если проект первый или команда новая, метрик может не быть.
2. Изменение технологий — если перешли с монолита на микросервисы, старые данные могут быть нерелевантны.
3. Разная квалификация — senior и junior будут выполнять одну задачу за разное время.

Практические советы

1. Начните собирать метрики сейчас — даже если просто записывать «план-факт» в Excel.
2. Анализируйте ретроспективы — почему оценки не совпали с реальностью?
3. Учитывайте контекст — не применяйте слепые поправочные коэффициенты, если изменились условия.

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

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

Как мы оцениваем проекты в AppFox

1. Пишем ТЗ, умеренно детализированное (чтобы заказчик понимал, на что ему ориентироваться при приемке проекта, а разработчики — какие фичи нужно реализовать)
2. Собираем данные по прошлым подобным проектам
3. Составляем смету и заносим в нее плановое время на основании собранных метрик из прошлых проектов
4. Отдаем смету на проверку и оценку разработчикам, непосредственно участвующих в данном проекте.
5. Отдаем на корректировку тимлидам и CTO. При этом работы, в которых команда сомневается или с которыми сталкивается в первый раз, помечаются для оценки посредством покерного планирования
6. Проводим покерное планирование при необходимости
7. На работы с высокими рисками закладываем дополнительные часы (20 — 50% в зависимости от сложности задач на основании метрик, перечисленных в этой статье)
8. В процессе разработки актуализируем данные по текущему проекту для использования оценки в будущих проектах

Всем добра!

И помните, ошибки в оценках неизбежны. Важно учиться на них и корректировать процесс всю жизнь)