На то и расчет: как оценивают проекты в ИТ-компаниях

Почему это важно

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

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

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

На чем строится оценка

Любая оценка проекта базируется на требованиях заказчика. Но тут есть важный момент – на этапе оценки проекта требования еще не полны (много неопределенностей), поэтому первичные оценки новых проектов называют примерными или грубыми, а их точность зависит от опыта специалистов, участвующих в оценке, и методов, которые они используют.

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

Экспертная оценка

Суть: спрашиваем у опытных специалистов, сколько займёт работа.

Плюсы: быстро, подходит для новых или нестандартных задач.

Минусы: сильно зависит от субъективного мнения и опыта эксперта.

Пример: архитектор говорит: «Поднять инфраструктуру займёт 3 дня», — и эта цифра ложится в план.

Аналоговая оценка

Суть: смотрим на похожие проекты в прошлом и берём оценку оттуда.

Плюсы: быстро, удобно при высокой неопределённости.

Минусы: точность зависит от того, насколько проекты действительно похожи.

Пример: если мобильное приложение с похожим функционалом делали за 3 месяца, новый проект тоже планируем примерно на 3 месяца.

Параметрическая оценка

Суть: используем формулы и метрики. Например: «разработка 1 экрана ≈ 1 день», «тестирование API метода с 5 параметрами ≈ 6 часов».

Плюсы: точнее аналоговой, так как базируется на численных данных.

Минусы: требует статистики и базы знаний.

Пример: если у нас 20 отчётов, и на разработку одного уходит 2 дня, то весь блок отчетов ≈ 40 человеко-дней разработки.

Снизу-вверх

Суть: проект дробится на задачи (декомпозируется), каждая оценивается отдельно, затем всё суммируется.

Плюсы: самый точный метод.

Минусы: очень трудоёмкий, особенно в больших проектах.

Пример: «Написать модуль авторизации — 3 дня, протестировать — 2 дня, выпустить релиз — 1 день». Складываем: 6 дней на реализацию нового модуля.

Трёхточечная оценка (PERT)

Суть: считаем три сценария:

• Оптимистичный (O)
• Наиболее вероятный (M)
• Пессимистичный (P)

Итог = (O + 4M + P) / 6.

Плюсы: учитывает неопределённость и риски.

Минусы: требует чуть больше времени на расчёты.

Пример: на задачу может уйти: минимум 2 дня, скорее всего 4 дня, максимум 10 дней. Расчёт: (2 + 4×4 + 10) / 6 = 4,7 дня.

Риски

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

Важно понимать: чем меньше ясности на старте, тем больше объём работ, который придётся добавить в оценку рисков. И наоборот – если требования чёткие, проработанные и максимально полные, рисков становится меньше, а сама оценка получается точнее и «дешевле» для заказчика.

Рамки и ограничения

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

• Ограничения – это рамки, которые влияют на реализацию: фиксированный бюджет, ограниченное количество специалистов, жёсткие сроки. Когда они указываются прямо, команда и заказчик одинаково понимают условия, в которых будет вестись работа.
• Допущения – это условия, которые принимаются за основу при оценке. Например: «Заказчик предоставит готовые тексты до начала разработки» или «Сторонняя команда будет доступна для интегро-тестирования на 2 недели». Если эти допущения не выполняются, оценка перестаёт быть актуальной.
•  Что не входит в проект – крайне важный момент. Помимо описания того, что будет сделано, стоит зафиксировать, что точно не входит в оценку. При такой прозрачности заказчик четко видит границы проекта.

Выводы

Для нас, как для ИТ-компании, занимающейся разработкой на заказ, этап оценки всегда означает поиск баланса между скоростью и точностью. Можно назвать сроки «сразу и быстро», но это будут очень грубые цифры с большим запасом. А можно погрузиться в детали, задать вопросы, уточнить нюансы – и дать оценку, максимально близкую к реальности.

Мы искренне верим: открытость и совместная работа на этапе оценки – лучшее начало для успешного проекта.