В идеальном мире IT-проекты завершаются с минимальным количеством трудностей или вовсе без проблем и сразу же приводят к успеху. Компания выпускает финальный продукт, передает его пользователям — и всё, дело сделано. В реальности же все происходит иначе. Часто оказывается, что проект закончен, но перерасход времени и бюджета сопровождал вас на каждом этапе.
Проблемы могут быть техническими (например, недостаток опыта у подрядчика), но чаще всего причиной становятся плохая коммуникация и неэффективное управление процессами. Какие-то нюансы не были учтены, важные детали остались незамеченными, или кто-то из участников просто не понял друг друга. В результате итоговый продукт не оправдывает ожиданий, а ценность проекта снижается. В таких случаях приходится вносить правки в объем работ и Спецификацию требований программного обеспечения (Software Requirements Specification или SRS). Эти правки называются запросами на изменения (Change Requests), и порой их накапливается огромное количество.
Каждый такой запрос нужно тщательно анализировать, ведь его реализация может отодвинуть дату релиза. Если правка одна, решение принять проще. Но если их собирается целый список, все заинтересованные стороны должны совместно определить, как сбалансировать количество новых функций и разумные сроки выпуска. Учитывая, что запросы могут появляться на любом этапе разработки, крайне важно постоянно отслеживать затраты времени и бюджета, а также прогнозировать завершение проекта. Именно для таких целей отлично подходит EVM (Earned Value Management), так же известный как Метод освоенного объема.
Зачем нужен EVM? Основная цель и показатели
EVM, или Метод освоенного объема, — это метод управления проектами, который чаще всего является частью комплексных систем, включающих инструменты управления задачами, диаграммы Ганта и системы отчетности сотрудников. Зачастую компании используют отдельные модули от разных поставщиков, что усложняет их интеграцию. Это же касается и инструментов мониторинга, которые тоже часто приобретаются у сторонних разработчиков. Однако если речь идет об управлении небольшим ИТ-проектом, можно создать собственную систему EVM, используя, например, Google Sheets или Microsoft Excel.
Главная задача Метода освоенного объема — сопоставить фактический прогресс выполнения проекта (EV, Earned Value) с запланированным (PV, Planned Value) и затраченными ресурсами (AC, Actual Cost). После этого можно прогнозировать сроки завершения проекта и его финальную стоимость.
Таким образом, для оценки текущего состояния проекта важно учитывать следующие метрики:
Показатель | Описание | Формула | Интерпретация |
| Отклонение графика (Schedule Variance или SV) | Фактические отклонения во времени, которые в основном представляют собой разницу между фактическим прогрессом и запланированным прогрессом на текущий момент | SV = EV — PV | Если SV > 0, проект идет с опережением графика. Если SV < 0 — с отставанием |
| Индекс отклонения графика (Schedule Variance Index или SPI) | Отклонение в 250 часов может быть критичным для небольшого проекта, но может быть не столь важным для более крупного. Именно поэтому также используется SPI, который измеряет отношение фактического прогресса к запланированному | SPI = EV / PV | Если SPI > 1, проект идет быстрее графика. Если SPI < 1, значит, есть задержки |
| Отклонение бюджета (Cost Variance или CV) | Фактическое отклонение бюджета | CV = EV — AC | CV > 0 — проект приносит больше ценности, чем затрачено ресурсов. CV < 0 — перерасход бюджета |
| Индекс выполнения стоимости (Cost Performance Index или CPI) | Показывает, насколько эффективно используются средства | CPI = EV / AC | Если CPI > 1, проект использует бюджет эффективно. Если CPI < 1, возможен перерасход |
Существуют также другие прогнозные показатели, основанные на первоначальной оценке (IE):
- Прогноз до завершения (Estimation to Completion или ETC) — сколько еще нужно потратить до завершения проекта (ETC = IE — EV);
- Прогноз по завершении (Estimate at Completion или EAC) — сколько проект будет стоить по завершении (EAC = AC + ETC);
- Ожидаемая дата завершения (Estimated End Date или EED) — прогнозируемая дата окончания проекта.
Эти показатели позволяют не только контролировать ход выполнения работ, но и делать прогнозы.
Что выбрать: время или деньги?
Теперь, когда мы разобрались с основами, давайте посмотрим, как EVM можно использовать на практике.
При использовании Метода освоенного объема (EVM) менеджер проекта должен учитывать и бюджет, и сроки. Обычно расчеты ведутся в деньгах, ведь команде нужно платить. Однако деньги — это по сути человеко-часы, умноженные на ставку. Значит, EVM можно считать и в часах. Рассмотрим плюсы и минусы каждого варианта.
Расчет EVM в деньгах
Если говорить о преимуществах такого подхода, то вы получаете максимально точные расчеты с учетом тех данных, которые вы учитываете.
Что насчет недостатков? Нужно учитывать, что финансовые документы являются строго конфиденциальными, и доступ к ним имеют только определенные сотрудники, а это значит, что у вас будет небольшой круг людей, с которыми вы сможете обсудить проект. Кроме того, довольно сложно проанализировать, как запрос на изменение может повлиять на график и бюджет проекта, не показав прогнозные расчеты в EVM. В результате это может привести к принятию неправильных решений и высоким затратам на проект.
Расчет EVM в часах
Что касается такого подхода, то он имеет ряд преимуществ. Прежде всего, он не требует высокого уровня конфиденциальности. Таким образом, если возникают вопросы по проекту, срокам или смете, менеджер проекта может вовлечь в процесс больше людей для поиска оптимального решения.
Представим, что реализация всех запросов на изменение может увеличить бюджет до 10%. В этом случае менеджер проекта должен вовлечь в процесс всех заинтересованных сторон, чтобы выяснить, какие именно запросы на изменение следует выбрать для расчета еще одной выгодной суммы. Более того, его легко рассчитать, потому что вам просто нужно обрабатывать часы из сметы и отчетов, сделанных проектной командой.
Однако у такого подхода есть и недостаток — сложнее учитывать разницу в оплате сотрудников с разными ставками. Многие команды заходят в тупик, узнав об этом минусе. Но давайте попробуем мыслить нестандартно.
Выбор не имеет значения
Совершенно очевидно, что с помощью Метода освоенного объема вы не сможете получить абсолютно точную оценку. Тем более, этот подход не предназначен для этого. Его задача — показать общую картину и тенденцию. Несущественные погрешности, не влияющие на понимание общей ситуации на проекте, вполне допустимы. Следовательно, вы можете легко перейти на подход подсчета EVM в часах, если учитывать среднюю ставку по роли.
Допустим, у вас есть несколько разработчиков с разными тарифами. Когда вы рассчитываете их среднюю ставку на основе задач, которые они должны выполнить по проекту. Это и будет средняя ставка по роли. И тогда не будет имеет значения, как оценить EVM, в деньгах или в часах. Правда, нужно учитывать, что при выборе подхода, основанного на часах, просчетов может быть больше, но рисков будет меньше, чем от неправильного принятия решений. Именно поэтому в ИТ-проектах лучше рассчитывать в часах или даже в стори поинтах (story points), если они используются в вашей оценке.
Как использовать EVM на практике?
Нужно понимать, что у каждого проекта есть объем работ, бюджет и сроки. В противном случае это просто процесс, а не проект. Таким образом, можно оценить объем (в часах или стори поинтах) на основе функционала продукта. Выбор между часами и стори поинтами зависит от бухгалтерского учета фактических затрат (Actual Cost или AC). Например, если вы берете AC компонента из отчетов, составленных сотрудниками, и данные указаны в часах, то следует выбрать часы.
Давайте рассмотрим на примере. Возьмем часы за выбранный показатель.
Когда проект стартует, его объем работ заносится в EVM-документ. В случае, когда компонентов продукта много, их необходимо агрегировать. В колонке Planned(h) указываем ожидаемое время реализации компонентов. EVM текущего проекта готов. При реализации проекта, сотрудники заполняют репорты и отмечают сделанные компоненты. Проектному менеджеру остается внести все эти данные в EVM, включая:
- Status — сделан компонент или нет;
- Earned(h) — готовность. Можно использовать часы или проценты в зависимости от выбранного командой показателя;
- Actual(h) — фактически затраченное время.
В зависимости от размеров проекта обновления могут вноситься ежедневно, в конце спринта или по завершении запланированного этапа. Согласно внесенным данным рассчитываются следующие показатели в EVM:
- SPI — соблюдаются ли сроки;
- CPI — не выходит ли проект за рамки бюджета;
- EED — когда проект реально будет завершен.
Если данные показывают отклонения, необходимо найти причину и скорректировать работу.
Как учитывать запросы на изменения?
В идеальном мире подрядчик (нанятая команда IT-аутсорсинга) и компания-клиент совместно обсуждают объем работ, четко фиксируют требования и договариваются о сроках и бюджете. В этом случае перед менеджером проекта стоит простая задача — заполнить документ EVM и проверить, чтобы каждая строка была «зеленой».
В реальной жизни самый первый запрос на изменение появляется сразу после завершения первой демо-версии продукта, после результатов первого запланированного этапа. С каждой новой версией демо появляется все больше запросов на изменения, их количество увеличивается, а бюджет и сроки проекта не готовы к таким изменениям. Поэтому, во избежание недопониманий или ложных ожиданий, необходимо следовать Методу освоенного объема.
Все запросы на изменение оцениваются, распределяются по приоритету и затем включаются в EVM. Руководитель проекта проводит встречу с заинтересованными сторонами, чтобы показать изменения в графике и бюджете в зависимости от необходимых ресурсов на реализацию изменений. Цель такой встречи – определить, какие из них стоят того, чтобы сдвинуть сроки и увеличить бюджет. Учитывая, что любая корректировка, сделанная в EVM, меняет все показатели, дискуссия получается достаточно предметной, позволяя каждому участнику увидеть новые даты завершения проекта. В конце встречи у всех формируются одинаковые ожидания от проекта и они способны ухватиться за объем задач (которые необходимо выполнить), сроки их выполнения и расходы.
Достичь ожидаемых целей намного сложнее, если оценка превышает сроки и бюджет проекта.
Как достичь ожидаемых целей с EVM?
«Невозможно решить проблему на том же уровне, на котором она возникла. Нужно стать выше этой проблемы, поднявшись на следующий уровень», — сказал однажды Альберт Эйнштейн.
Итак, давайте поднимемся немного выше и посмотрим на проблему под другим углом. Вот что нужно учитывать:
- Оценка показателей (эстимейт) – это прогноз. Мы ожидаем достичь результата в заданное время, основываясь на определенных обстоятельствах, включенных в оценку усилий. Однако не все в этом мире связано с вашим проектом, мир скорее будет диктовать свои условия.
- В ИТ-индустрии оценочные показатели обычно создаются в соответствии с объемом проекта, который состоит из ожиданий каждой стороны. Это означает, что фактическая стоимость разработки проекта неизвестна, но может быть где-то близка к эстимейту.
- Некоторые «нужные» функции на деле оказываются не так уж и важны и могут понадобиться только на этапе разработки идеи. На практике большинство из них будут неактуальны, и пользователи ими пользоваться не будут. Поэтому нет необходимости воплощать все функции в реальность или делать какие-то из них по-другому. Реальная необходимость компонентов будет выявлена в ходе выполнения проекта и тестирования демо-версии продукта.
Именно поэтому в случае незначительного превышения эстимейта, мы рекомендуем расставлять приоритеты функций продукта и работать по контрактной модели «Бюджет с плавающим объемом работ» или Budget with the Float Scope (BFS). Важно уложиться в бюджет и сроки без существенной потери стоимости результата. Следуя этой модели, вы также включаете все компоненты в документ EVM. Все основные функции находятся в разработке, в то время как интеграция всех будущих компонентов (а также запросов на изменение) обсуждается с заинтересованными сторонами для понимания их влияния на бюджет и сроки. Успех проекта, который следует модели гибкого бюджета, вполне возможен с EVM.
Рекомендуем прочитать Порхай как бабочка, жаль как пчела: Как гибкий бюджет меняет мнение о разработке продукта
В заключение
Можно справляться с неконтролируемым ростом рамок проекта или следовать BFS модели и без использования Метода освоенного объема, но только в том случае, если ваш проектный менеджер — волшебник. Но много ли таких людей вы знаете? Поэтому мы рекомендуем не рисковать своими деньгами и репутацией и просто следовать тактике регулярного менеджмента.
Если вы хотите узнать больше об услугах, которые мы предоставляем, и о том, по каким контрактным и проектным моделям мы работаем с нашими клиентами, свяжитесь с нами. Мы поможем вам разработать лучшее программное решение для вашего бизнеса.
