Перевод статьи «How to estimate time for a project/task accurately».
Большинство людей не умеет адекватно подходить к оценке времени на выполнение задач. В результате происходят ситуации, когда «дедлайн подкрался незаметно».
Люди пытаются перестраховаться и закладывают дополнительные 500% времени «просто на всякий случай» – и этого все равно оказывается недостаточно. Менеджеры, в свою очередь, стараются сжать «заведомо раздутые сроки», чтобы иметь возможность пообещать клиенту что-то более приемлемое (это обычная менеджерская болезнь). У разработчиков есть своя «болячка» – тенденция бормотать что-то невнятное вместо озвучивания конкретных цифр.
Сам я (и уверен, вы тоже) ненавижу вопросы вроде «Когда будет готово?», но без них не обойтись в любом проекте, который кем-то контролируется.
Итак, чтобы точно определить время, которое понадобится вам или вашей команде на выполнение определенной работы, нужно сделать некоторые приготовления.
Шаг 1. Выяснение требований клиента
Если вы не знаете, куда плывет корабль, вам не удастся прикинуть, сколько времени займет путешествие.
Начните с определения всех видов работ, которые нужно будет сделать в ходе проекта. Сюда относятся как функциональные, так и нефункциональные требования. Порой это сложно сделать за один раз и, возможно, этот процесс придется проводить итеративно.
Убедитесь, что вы учли время на встречи, отчеты, коммуникацию, тестирование другие действия, критически важные для успеха проекта.
Шаг 2. Расположите эти действия по порядку
Теперь составьте список всех действий, которые вам нужно будет совершить, расположив их по порядку, в котором они будут происходить.
На этом этапе не нужно прописывать, сколько времени займет каждое действие. Однако, вы можете сделать пометки о каких-то важных дедлайнах. К примеру, до начала интеграции вам может понадобиться готовая документация какого-нибудь компонента системы.
Шаг 3. Управление рисками
Составьте список всех предположений, исключений и ограничений, которые могут возникнуть.
На начальном этапе проекта необходимо провести мозговой штурм для определения рисков. Ошибочно предполагать, что в вашем проекте рисков нет. Если вы их не видите, значит, просто смотрите не в том направлении.
Не определив и не измерив риски, вы больше не будете контролировать проект и время, необходимое для его завершения. Вы будете полагаться на удачу, а все те риски, о которых вы не подумали, могут материализоваться и увеличить время на реализацию проекта, а то и вовсе развалить его.
Шаг 4. Делаем прикидки
Есть несколько методов оценки времени.
Экспертное мнение
Оценка осуществляется с привлечением экспертов из нужной отрасли. Это может быть один «гуру» или группа разных специалистов.
Эксперты делают свои предположения относительно того, сколько времени (или денег) потребуется на осуществление задуманного. После этого вы можете вывести среднее арифметическое всех предположений и в ходе обсуждений прийти к единому мнению. Привлечение к этому обсуждению экспертов является, безусловно, более эффективным подходом. Так ваша итоговая оценка будет более точной, а в ее основе будут лежать определенные причины.
Трехточечная оценка
Это один из самых распространенных и простых методов. В рамках этого подхода определяется оптимистическая (O = Optimistic), пессимистическая (P = Pessimistic) и реалистическая / средняя (M = Middle) оценки.
Значения P, M и O определяются экспертами и выражаются в часах, днях, денежных единицах. Это может делаться в ходе обсуждений внутри команды, занимающейся проектом. Для этого задаются вопросы вроде «Сколько времени это займет при условии, что все будет идти по плану, без всяких рисков и проблем?», «Каким может быть самый плохой сценарий и сколько в таком случае потребуется времени/усилий?» и т. п. Затем полученные значения P, M и O закладываются в формулу (O + 4 M + P) / 6.
Результат вычислений дает среднюю оценку. Эта формула позволяет, с одной стороны, учесть возможные позитивные и негативные сценарии, а с другой – «сгладить» их влияние и получить более реальную оценку.
Стоимость качества
Это довольно интересный подход. Для начала, прикидки относительно времени или денег делаются только в отношении разработки функционала, без учета ошибок и проблем, как будто сразу будет получено идеальное ПО без дефектов (такой себе сферический конь в вакууме). Далее оценивается, сколько потребуется дополнительно времени и денег на реальную работу со всеми ошибками и проблемами, чтобы полученное в итоге ПО приблизилось к «идеальному» состоянию.
Оценивая стоимость обеспечения качества программного обеспечения, вы можете проанализировать и рассмотреть следующие пункты:
- Стоимость действий по предотвращению дефектов.
- Стоимость тестирования.
- Коррекция внутренних ошибок.
- Исправление проблем с интеграцией.
- Стоимость установки и конфигурации программы в условиях реального окружения и данных.
Аналоговая оценка
В рамках этого подхода мы можем учесть наш прошлый опыт в решении подобных проблем или работы над проектами. Здесь главное – найти возможные аналоги, выделить похожие задачи.
Чтобы найти похожие задачи в предыдущем опыте, можно сделать декомпозицию.
Параметрическая модель
Это один из самых точных и гибких методов оценки. Его суть в построении определенной параметризованной модели-предсказания на основе предыдущего опыта, доступных данных, параметров, статистики.
Фактически, создается специальная математическая модель, позволяющая отслеживать, как изменения финальной оценки зависят от изначальных параметров. Такую зависимость можно даже визуализировать. Это поможет проанализировать границы отклонения оценки от среднего и посмотреть, что может на это отклонение повлиять.
Оценка снизу вверх
Этот подход напоминает экспертную оценку, но в этом случае прогноз делается не для проекта в целом, а по отдельности для задач, его составляющих. Это своего рода декомпозиция проекта на разные этапы.
Выглядит это следующим образом. Мы собираем экспертные мнения, например, от специалистов по анализу, разработке, тестированию, поддержке программ. Далее мы суммируем их оценки, добавляем время на взаимодействие и получаем общий прогноз.
Другими словами, мы собираем оценки по частям, определяем, сколько потребуется времени каждому участнику процесса разработки, а затем складываем полученные результаты, принимая во внимание дополнительные риски.
Заключение
Я думаю, для более точных результатов можно использовать несколько подходов одновременно, например, оценку снизу вверх и трехточечную оценку частей проекта.
Нам нужно учить людей строить предположения, особенно в сфере IT. Это важно для успеха проекта, для успеха людей, вовлеченных в него, и, конечно, для счастья клиента.
Не всегда удается правильно интерпретировать требования заказчика, зато всегда следует ожидать каких-то изменений в существующих спецификациях.
Когда человек не хочет или не имеет времени на выяснение требований или декомпозицию проекта, вы можете услышать о различных вариантах умножения предположительной оценки на число пи (3,14) или е (2,71). Это не маленькие множители, их применение может сильно влиять на оценку. Но все это – проблема отсутствия внимания к мелочам или лени разбираться во всем вышеизложенном.
Понятно, что построение предположительных оценок требует ресурсов, иногда значительных. Но чем больше внимания уделяется мелочам, тем точнее будет прогноз выполнения проекта, особенно при наличии команды, которая уже имеет опыт подобных работ.
