Сент. 12

Как избежать неправильного оценивания проектов

Насколько точные у вас эстимейты?
Мы очень тщательно проанализировали проект и уверены в оценке.
А если у проекта будет фикс-прайс, вы готовы подписать такой контракт?
Упс...

Всем привет! Меня зовут Наталья, я Delivery Program Manager. Мне очень часто приходится сталкиваться со следующими вопросами:

Как рассчитать длительность нового проекта?
Как проэстимировать новый продукт, с которым мы еще никогда не сталкивались?
Как оценить проект с высоким уровнем точности?
Как сохранить актуальность оценки при изменениях в проекте?
Как оценивать в условиях неопределенности?
Как понять, что в оценке, которая предоставлена командой, что-то не так?

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

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

Переоценка проекта может привести к проигрышу в тендере или к недоверию клиента. Частое непопадание в свои же эстимейты приводит к обоснованному давлению со стороны клиента для снижения оценки.

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

Многие знают о золотом треугольнике «скоуп — время — деньги», из которого рассчитывается качество проекта. Если исходить из этого, точность оценки зависит от нескольких факторов, как то:

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

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

Процесс оценки

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

Прежде чем ответить, как оценить проект, нужно понять, что мы оцениваем.

Первый шаг — определить Project & Product Scope

Для начала нужно определить скоуп выполняемых работ и ограничения. Для этого:

Определяем одного или нескольких стейкхолдеров, которые могут выступать в роли владельца продукта (Product Owner).
Обсуждаем с Product Owner скоуп продукта: что должно быть сделано, какой функционал ожидается, какие бизнес-потребности должен покрыть этот продукт. Таким образом мы формируем Product Scope.
На основании Product Scope создаем скоуп проекта — Project Scope — то, как мы будем реализовывать требуемый функционал. На этом этапе можно предварительно оценить сроки и стоимость проекта (L0 estimates).

Если нам нужны точные оценки длительности работ, то опускаемся еще на один уровень ниже — иерархической структуры работ (Work Breakdown Structure — WBS). Разделение задач на этом уровне позволяет правильно оценить временные ресурсы и стоимость проекта.

Основываясь на своей практике, могу сказать, что на первых двух этапах очень важно писать задачи не только In Scope, но еще и Out of Scope. Если вы хотите узнать, как Out of Scope — требования могут повлиять на проект, рекомендую посмотреть ролик Portfolio.

А еще важно проработать нефункциональные требования, которые также могут сильно повлиять на окончательное время исполнения проекта.

Следующий этап — собрать команду для оценки

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

Если проект нестандартный для PM или компании, нужно собрать группу экспертов (по технологиям и/или по доменной области), которые помогут в оценке.

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

Основные челленджи при оценке экспертами:

Привлечение экспертов, которые не имеют опыта в оценке работ по проекту. Они могут сказать, что нужно учесть при планировании (построить WBS), но не смогут оценить затраты по времени.
Эксперты-оптимисты недооценивают сложность работ и дают заниженные оценки.
Эксперты-перестраховщики сильно переоценивают проект и дают завышенные оценки.
Опора на оценку сеньоров, которые оценивают «под себя» и не могут давать оценку работ с учетом того, что на проекте будут мидл- или джуниор-разработчики/тестировщики.

Поэтому PM важно подбирать сбалансированную команду.

Когда у нас уже есть скоуп работ и группа экспертов, можно перейти к вопросу, как оценить проект.

В чем измеряется длительность проекта или задачи

Единицы измерения могут быть разными, и об этом важно договариваться с самого начала.

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

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

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

Сторипойнт = длительность задачи × сложность задачи × неопределенность

Более детально можно ознакомиться с техникой, почитав о Planning Poker.

При этом длительность проекта можно рассчитать, используя такие метрики, как velocity и capacity команды: первые спринты рассчитываются исходя из capacity, после 3-го спринта уже достаточно статистики по средней velocity команды, чтобы оценить, сколько спринтов необходимо для завершения разработки продукта.

Более детально об опыте работы в Scrum-командах я расскажу в отдельной статье.

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

Нюансы работы с фикс-прайс-проектами будут разобраны в отдельной статье, где я расскажу, как это работает на практике.

Как измеряются проекты

Идеально делать разработку и, соответственно, оценку работ в 3 этапа:

Подготовка дизайна будущего продукта.
Построение архитектуры продукта или системы и описание функциональных/нефункциональных требований.
Разработка самого продукта на основе уже готовой архитектуры.

Первый пункт оценить проще, чем оценить всю работу с нуля, как и дать оценку по разработке на основании готовой архитектуры. Но и вероятность того, что клиент согласится на такую разбивку работ, пока мала. Чаще всего клиент приходит с пожеланиями «сделай мне то — не знаю что, но прямо сейчас». Варианты быстрой оценки есть тут.

На этом этапе может быть достаточно L0 estimates, которые можно рассчитать, используя ROM (Rough Order of Magnitude), особенно если это влияет на годовое планирование и приоритизацию roadmap продукта. При этом очень важно помнить, что, указывая приблизительные оценки, нужно акцентировать внимание на допущениях, которые могут увеличить длительность проекта.

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

Методы оценки проекта, которые мы используем в командах

Метод	Преимущества	Ограничения	Рекомендации
Экспертная оценка	используется предыдущий опыт для более точной оценки; можно покрыть достаточно большой спектр проектов; можно достаточно быстро получить предварительные оценки; также можно получить количественные оценки.	необходимо найти эксперта в доменной области или в разработке похожих проектов; точность оценки зависит от компетентности эксперта; можно достаточно быстро получить предварительные оценки; субъективность метода.	декомпозировать задачи до уровня WBS; привлекать нескольких экспертов и сравнивать результаты их оценки; дополнительно использовать другие техники, например PERT.
Метод PERT	используется в проектах, где предсказать продолжительность проблематично. Для расчета используется оценка 3 значений: оптимистического (наилучшего), ожидаемого (вероятного) и пессимистического (наихудшего); устанавливается последовательность выполнения действий и их взаимосвязь; часто используется в инновационных проектах.	громоздкость схемы сетевого графика; требует много времени и средств на поддержание в актуальном состоянии; связи и последовательность действий не всегда бывают точно отображены; используются только зависимости «финиш — старт».	использовать как хороший инструмент визуализации целей и задач; совмещать с другими техниками; привлекать экспертов для оценки задач.
Метод «по аналогии»	установление аналогии позволяет использовать известные части прошлых проектов; обычно является менее дорогостоящим, чем другие инструменты; оценка по аналогии предпочтительна в том случае, когда детальная информация о проекте отсутствует.	субъективная оценка, основанная на гипотезах; аналогию нельзя использовать при исследовании объектов и систем управления принципиально новых объектов, процессов, ситуаций, не имеющих аналогов в базе знаний; необходимо учитывать черты как сходства, так и различия между неизвестными и известными элементами.	накапливать базу знаний и описанных case study; документировать оценки проекта, к которым привлекаются внешние эксперты (метод экспертной оценки). При недостатке аналогичных проектов подобная статистика может помочь для верхнеуровневой оценки.
Метод Use Case Points	удобен для описания функциональных требований к системе; дает возможность провести быструю оценку; хорошо подходит для несложных алгоритмов.	неудобен при описании нефункциональных требований системы; необходимо знать стандартные сценарии работ; точность зависит от эксперта (аналитика).	использовать для несложных систем, в которых можно прописать алгоритмы действий.

Повышение точности оценок

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

Предполагаемая длительность проекта на основании полученных оценок

Длительность проекта можно рассчитать по следующему алгоритму:

определить скоуп выполняемых работ в текущем релизе*;
приоритизировать выполнение задач*;
проанализировать зависимости между задачами;
составить план проекта с учетом необходимой последовательности задач;
проставить все праздники и выходные дни;
распределить задачи среди всех участников команды.

* На этом этапе уже готово.

После этого очень высока вероятность того, что придется начать планирование и расчеты заново.

В PMBoK эта последовательность зациклена, потому что при добавлении факторов расчета (таких, как человеческий ресурс или бюджет) они же становятся и ограничениями проекта.

Основные ошибки при расчете длительности проекта:

не учитываем праздники и отпуска;
не закладываем 20% времени, которое тратится на коммуникацию внутри команды и с заказчиком;
не добавляем резерв на риски (а порой и риски не просчитываются);
не добавляем резерв на сложность и комплексность задач;
не учитываем зависимости от third party.

И теперь, когда у нас есть план выполнения проекта, мы отмечаем на графике Milestones & Deadlines. Следующий шаг — начинаем думать, как сокращать сроки, потому что не вписываемся в дедлайн или бюджет :)

Сокращение длительности проекта

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

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

Критический путь

«Критический путь — непрерывная последовательность задач в плане-графике от его начала и до конца, требующая наибольшего времени».

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

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

Один из вопросов на интервью: Если вам удалось в 2 раза уменьшить длительность каждой задачи текущего критического пути, то как изменится длительность всего пути?

Правильный ответ: минимально. Даже если вы нарисуете на экране ноутбука сокращение длительности проекта в 2 раза, в реальности вы вряд ли получите эти сроки.

Очень хорошая книга по этой теме — «Критическая цепь» Элияху Голдратта. Книга идет очень легко, можно прочитать за вечер или два.

Мониторинг критического пути

Постоянный контроль и проверка критического пути и статуса задач на нем.
Контроль и проверка статуса задач, близких к критическому пути, — так называемых околокритических задач.
Работа с рисками, связанными с критическими и околокритическими задачами.

И все же как можно сократить длительность проекта? Оптимально выбрать один из следующих вариантов:

Перенести часть задач на другой релиз.
Нанять более сильную команду для реализации проекта.
Увеличить команду до старта проекта.
Предложить POC или MVP.

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

Для сокращения длительности критического пути можно использовать методы «Ускорение» или «Сжатие», если на вашем проекте это возможно.

Метод	Идея	Недостатки
Fast Tracking («Ускорение»)	Задачи на критическом пути выстраиваются параллельно, а не последовательно, хотя планировалось выполнять их последовательно.	повышенные переработки, что приводит к увеличению стоимости; разработка «заглушек» или «костылей», что тоже приводит к увеличению стоимости; увеличение рисков.
Crashing («Сжатие»)	Увеличение количества людей на задачах критического пути за счет других задач проекта. Стоит помнить о пословице «9 женщин не родят ребенка за 1 месяц». В любой задаче есть предельное количество исполнителей, после которого длительность не сокращается, а начинает увеличиваться.	неоптимальность распределения задач, что приводит к росту стоимости и снижению эффективности; увеличение объема коммуникаций; удвоение исполнителей задачи может привести к блокировке выполнения этой задачи.

Итоги

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

Старайтесь делить скоуп продукта на относительно понятные части, которые проще оценить (WBS).

Не забывайте о допущениях и деталях Out of Scope, которые стоит прописать в контракте, особенно если у вас фикс-прайс-проект.

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

«И да пребудет с вами сила!»