Оценка времени — это борьба с неопределенностью и для исполнителя, и для менеджера.

Непредвиденные обстоятельства могут возникнуть где угодно: исполнитель дал слишком оптимистичный прогноз, или наоборот, закончились запасы кофе и энергии, на ЦОД упал метеорит, а вместо нового раздела понадобился целый сайт.

Как правило, менеджер проекта отталкивается от оценки эксперта. Но на проект могут повлиять не совсем очевидные факторы:

• Выбор технического решения. Если у команды нет опыта работы с выбранными для проекта технологиями, изучать их придется на ходу;
• Специфика бизнеса заказчика, если исполнитель впервые сталкивается с этой сферой. В план придется заложить время на изучение особенностей;
• Погрешность в оценке из-за необходимости консультации и обсуждения задач;
• Налаживание коммуникации в случае, если под проект собралась новая команда или часть работы выполняется совместно с другим агентством;
• Стабилизация: код-ревью, тесты, возможные баги, выявленные на этапе тестирования, корректировка дизайна в конце каждого этапа. На это приходится еще 20–25% запланированного времени.

А также важные детали:

• Получение доступов;
• Покупка SSL-сертификата;
• Требования к хранению данных и возможные изменения законодательства в этом вопросе;
• На этапе запуска — согласование с App Store и Google Play (в конце года может занять до месяца).

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

По принципу аналогии

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

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

Задачи разбиваются на меньшие, чтобы оценить их как можно более точно. Чем более точная оценка требуется, тем меньше задачи, на которые нужно разбить проект. Общий срок их выполнения равняется общему сроку проекта. Это стратегия “сверху вниз”, она занимает больше всего времени, чтобы подготовиться, но включает все компоненты и дает наиболее точные цифры.

Если задача очень объемная, ее в любом случае придется разбивать на более мелкие и оценивать по компонентам. Как минимум, весь проект надо разделить на три части: разработку дизайна, верстку и тестирование. В зависимости от наличия или отсутствия CMS, форм обратной связи, добавляется программная часть.

Три компонента (PERT или Project Evaluation and Review Technique)

Этот метод увеличивает точность во много раз, т.к учитывает погрешность от неопределенности и строится по математической формуле вероятности. Дается три оценки: оптимистическая, пессимистическая и самая вероятная. Учитывается максимум факторов, в итоге получается оценка без погрешностей и с возможными рисками, что особенно значимо для крупных проектов со многими вводными. Но на три варианта оценки уйдет больше всего времени.

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

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

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

Стори-поинты

Формула, по которой ставятся стори-поинты, основана на предыдущем опыте. Надо посчитать, сколько часов нужно для разработки одного поинта. Таким образом можно оценить весь объем работ в бэклоге до начала проекта. Часто весь бэклог неизвестен, но можно дать достаточно точную оценку. В стори-поинтах удобно оценивать типовые проекты и измерять производительность команды.

Практика Далее

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

Мы работаем над крупными проектами, поэтому у нас нет коробочных решений, каждый раз проект разрабатывается под конкретного заказчика.

Кроме консультации с экспертами, опираемся на опыт и статистику, декомпозируем проект.

Один из способов оценки, который хорошо работает для нас — это Planing Poker. Мы обычно работаем по Kanban, но этот метод взяли из Scrum. Впервые его предложил Майк Кон в книге Agile Estimation and Planning . В традиционном scrum-покере свою оценку дают все участники команды: дизайнеры, разработчики, тестировщики. Мы проводим покер планирования для оценки задач внутри команды разработки. Для покера используются карты, похожие на игральные. Цифры на картах — это оценка в стори-поинтах, где один стори-поинт — это 8 часов. Менеджер рассказывает о задаче, после чего участник команды кладет рубашкой вверх карту со своей оценкой в стори-поинтах. Карты открывают все одновременно, потом идет еще один этап обсуждения, т.к. вся команда должна прийти к единой оценке задачи.

После такой оценки разработки мы добавляем время на code review и тестирование, консультации, встречи, фикс возможных багов.

Подстраховаться, но не слишком

Исполнитель может перестраховываться, закладывая дополнительное время, или даже умножая на два. А менеджер накинет еще больше для учета риска. Тогда проект превратится в неповоротливого монстра.

Поэтому нужно понять, на чем основана оценка эксперта, чтобы заложить объективную оценку.

Чек-лист для оценки проекта:

1. Собрана вся информация о задачах и зафиксирована с клиентом: список функциональностей, референсы и т.д.
2. Эксперт дал свою оценку.
3. Задачи декомпозированы.
4. Заложено время исполнителя на консультации и встречи, коммуникацию внутри команды. Это 15–20% общего времени.
5. Добавлен коэффициент на риски.
6. Выдвинуты примерные сроки реализации.