Почему это важно
Оценка нового проекта – это фундамент, от которого зависит вся дальнейшая работа по проекту. Если сильно ошибиться на старте, впоследствии будет крайне сложно уложиться в сроки, бюджет и ожидания заказчика. Именно поэтому грамотная оценка проекта – один из самых ответственных этапов.
Кто оценивает новый проект
Оценкой нового проекта обычно занимается Руководитель проекта и Технические эксперты. Идеальный вариант – в оценке участвуют те, кто уже имел опыт работы в аналогичных проектах, поскольку такие специалисты знакомы с предметной областью, знают о возможных рисках и понимают, что ожидает заказчик от нового проекта.
На чем строится оценка
Любая оценка проекта базируется на требованиях заказчика. Но тут есть важный момент – на этапе оценки проекта требования еще не полны (много неопределенностей), поэтому первичные оценки новых проектов называют примерными или грубыми, а их точность зависит от опыта специалистов, участвующих в оценке, и методов, которые они используют.
Методы оценки проекта
Экспертная оценка
Суть: спрашиваем у опытных специалистов, сколько займёт работа.
Плюсы: быстро, подходит для новых или нестандартных задач.
Минусы: сильно зависит от субъективного мнения и опыта эксперта.
Пример: архитектор говорит: «Поднять инфраструктуру займёт 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 недели». Если эти допущения не выполняются, оценка перестаёт быть актуальной.
- Что не входит в проект – крайне важный момент. Помимо описания того, что будет сделано, стоит зафиксировать, что точно не входит в оценку. При такой прозрачности заказчик четко видит границы проекта.
Выводы
Для нас, как для ИТ-компании, занимающейся разработкой на заказ, этап оценки всегда означает поиск баланса между скоростью и точностью. Можно назвать сроки «сразу и быстро», но это будут очень грубые цифры с большим запасом. А можно погрузиться в детали, задать вопросы, уточнить нюансы – и дать оценку, максимально близкую к реальности.
Мы искренне верим: открытость и совместная работа на этапе оценки – лучшее начало для успешного проекта.