Оценка трудозатрат для аналитика

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

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

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

Если говорить о методах оценки трудозатрат, то их принято разделять на три большие группы:

1) Экспертные методы оценки предполагают оценку опытными людьми – экспертами, которые опираются на свои знания и опыт при оценке.

2) Формальные модели предполагают оценку трудозатрат согласно формулам (например, COCOMO). В моей практике формальные модели встречались не очень часто.

3) И комбинации из формальных оценок и оценок, данных экспертами.

Чаще всего мне приходилось использовать экспертные методы оценки. К ним относится хорошо знакомый многим аналитикам метод разбиения аналитических задач на более мелкие задачи и их последующая оценка. Таким образом, получается СДР (структурная декомпозиция работ), затем более мелкие задачи и оцениваются –  получается суммарная оценка работ.

При этом СДР согласно своду знаний по управлению проектами (PMBOK – project management body of knowledge) должна:

• описывать содержание работ с необходимой точностью,
• определять весь объем работ,
• формироваться в виде иерархической структуры,
• представлять объем работ по сводной задаче как перечень работ, имеющих измеримый или сравнимый результат (подзадачи должны быть примерно равными по трудозатратам),
• иметь объективный или измеримый результат, который рассматривается как результат работ по сводным задачам или как совокупность результатов.

 

Причем, в качестве способа декомпозиции задач можно рассматривать как разделение на модули и функции системы, так и разработку определенных аналитических артефактов. В таком случае подзадачами для СДР могут быть: проанализировать и описать определенное число бизнес процессов, создать определенное число UML моделей, разработать матрицу трассируемости, создать словарь данных и т.д.

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

Конечно, недостатком всех экспертных методов является субъективность предоставляемых оценок. Однако такие методы являются достаточно простыми, и поэтому широко распространёнными.

В качестве одной из формальных моделей для оценки можно упомянуть анализ вариантов использования (use cases). Для этого надо разработать варианты использования для задач, которые надо оценить. Далее проводится определенная работа с этими вариантами использования: определяется число действий в диалоге пользователя и системы, оценивается сложность варианта использования и т.д. После этого применяются статистические данные, согласно которым на реализацию одного варианта использования в среднем затрачивается определенное количество человеко-часов (желательно при этом использовать собственную статистику). Если принять, что от этой цифры только 30-60% затрачивается на анализ, можно получить оценку на анализ данного варианта использования. Просуммировав такие оценки для всех вариантов использования можно получить оцениваемые трудозатраты на аналитику.

На одном из проектов, где я была аналитиком, для оценок использовали метод трех точек (оценка PERT – Program/Project Evaluation and Review Technique). При использовании данного метода экспертом дается три оценки для каждой задачи:

1) Ожидаемая (наиболее вероятная) оценка – оценка длительности задачи по наиболее ожидаемому сценарию выполнения задачи.

2) Оптимистичная оценка – длительность задачи основывается на оптимистичном сценарии выполнения задачи.

3) Пессимистичная оценка – длительность задачи основывается на пессимистичном сценарии выполнения задачи.

Тогда вычислить наиболее вероятные трудозатраты можно по формуле: (оптимистичная оценка + 4*вероятная оценка + пессимистичная оценка) /6.

Преимуществом данного метода считается учет рисков и относительная простота. К недостаткам относят невысокую точность и необходимость иметь полную информацию о планируемых работах.

Методы оценки  в гибких методологиях разработки

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

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

1) Один из самых известных способов – оценка задач в story points. При этом могут использоваться покерные карты для планирования (planning poker) или оценка относительно идеальной маленькой задачи.

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

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

2) Задачи также можно оценивать в «идеальных» часах. Под идеальными человеко-часами принято понимать время, затраченное на выполнение работы, если бы сотрудник не тратил время на инсталляцию нужного в работе ПО, не было бы праздников и отпусков, никто бы не болел и  все бы всегда высыпались, не было бы работы с документами, разговоров с коллегами и т.д. чего в реальном мире не бывает.

3) Для совсем грубой оценки можно использовать майки (S, M, L, XL, etc.). Для этого на каждую задачу исходя из ее размера (сложности) как будто одевается майка соответствующего размера. То есть на простую задачу «одевается майка» S, а на очень сложную – XXXL.

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

Рекомендации и советы

1) Для проверки полученной оценки можно использовать другой метод оценки трудозатрат. Точное совпадение вряд ли будет, но если числа будут существенно отличаться – это повод перепроверить расчеты.

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

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

3) Не забывайте учитывать, оценивать и при необходимости включать в итоговую оценку риски.

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

4) Учитывайте методологию проекта и являются ли команды и заинтересованные лица сильно удаленными друг от друга географически – это может увеличить время на коммуникацию.

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

Еще один эффект – это «иллюзия планирования» (люди считают, что самый реалистичный сценарий развития событий совпадет с самым оптимистичным сценарием).

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

6) Также на оценку трудозатрат может оказывать влияние эффект привязки, при котором оценка смещается в сторону начального приближения.

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

К слову, одним из достоинств покера для планирования является минимизация последствий этого эффекта вследствие того, что оценки даются командой независимо друг от друга (карты выкладываются одновременно).

Об авторе

Тарасюк Надежда, участник сообщества analyst.by.

Ведущий специалист – около 7-лет опыта в бизнес анализе.