Как сократить риски при оценке проектов

7 распространенных рисков при оценке ИТ-проектов

Оценка проектов – одна из обязательных составляющих деятельности ИТ-компании, которая занимается разработкой заказного ПО, как SimbirSoft. При этом процесс оценки всегда сопряжен с рядом рисков, среди которых типичны следующие:

1. Неправильная оценка объема работ и сроков реализации проекта. Ошибки в определении требований, неполное понимание процессов и технологий, недооценка сложности задач могут привести к завышению/занижению сроков или стоимости проекта.
2. Незнание или недооценка особенностей бизнес-процессов и инфраструктуры заказчика. Отсутствие информации о существующих системах, несовместимости решений и сложности интеграции могут вызвать задержки и проблемы в ходе реализации проекта. Важно иметь этап погружения в бизнес-процессы клиента. На этапе пресейла это не всегда возможно и на это нужно закладывать дополнительное время.
3. Изменение требований и приоритетов. В ходе проекта заказчик может изменить требования и приоритеты, что объективно приведет к пересмотру сроков и/или стоимости проекта или даже к отказу от него.
4. Некачественное выполнение работ на пресейле. Недостаточная квалификация команды оценщиков, ненадлежащая проверка основных целей системы и отсутствие контроля качества также ведут к ошибкам.
5. Финансовые риски. Неадекватная оценка стоимости и неэффективное использование бюджета проекта, изменение сроков выполнения ранее оцененных задач могут привести к перерасходу бюджета и другим финансовым рискам.
6. Отсутствие понимания и поддержки со стороны заказчика. Непонимание заказчиком проекта, отсутствие его активного участия и поддержки создают риск слишком «поверхностной» оценки или ее сильного увеличения за счет компенсации рисков.
7. Отсутствие управления рисками. Неправильное управление рисками, отсутствие плана и контроля может привести к возникновению и ухудшению рисков в процессе оценки.

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

Хорошая практика – составление матрицы рисков. Она позволяет на ранних этапах подсветить проблемы и продумать альтернативные сценарии, которые позволят их избежать.

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

1. Существуют следующие методы оценки проектов:
   Алгоритмическое моделирование себестоимости реализации проектов. Примеры: модели COCOMO (1981 год, Барри Боэм) и COCOMO II (1999 год, Барри Боэм), метод функциональных точек IFPUG (1979 год, Алан Альбрехт) и другие.
2. Бенчмаркетинг. Сравнение с затратами на аналогичные продукты или проекты, которые были ранее реализованы конкурентами
3. Оценка на основе предыдущего опыта. Здесь можно использовать экспертную оценку с привлечением специалистов, которые имеют большой опыт разработки подобных систем, методы оценки по аналогии с другими проектами на основе базы накопленных оценок по типовым задачам или оценку по параметрам системы с элементами моделирования, которая позволяет построить некоторую математическую модель на основе опыта работы и ввести параметры рисков (например, метод UCP). 

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

Методы первой группы достаточно хорошо формализованы и описаны с точки зрения алгоритмов расчета и формирования оценочной стоимости в часах. Например, модель COCOMO II предполагает расчет затрат в человеко-часах по формуле:

где: PM – получаемая оценка в человеко-часах, EAF – произведение выбранных множителей трудоемкости (определяется по таблице в стандарте COCOMO II), А, B – коэффициенты, зависящие от типа проекта (также по таблице), SF – фактор масштаба (также по таблице), SIZE – объем программного продукта в тысячах строк исходного кода, который определяется методом PERT или с помощью анализа продукта методом функциональных точек IFPUG. Получить такую характеристику на этапе предварительного анализа проекта сложно. Поэтому использование методов алгоритмического моделирования имеет ряд ограничений, связанных с отсутствием необходимой информации.

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

Мы пошли по третьему пути – оценке на основе предыдущего опыта, внедрив несколько лет назад собственную автоматизированную систему поддержки оценки. 

Как устроен процесс оценки у нас 

Основная идея реализации автоматизированной системы оценки базируется на следующих принципах:

• Аккумулирование опыта решения типовых задач, оцененного в часах (планируемых и фактических) в общей базе.
• Периодическая корректировка оценки типовых задач на основе обновленной информации.
• Использование наборов готовых решений, которые связывают различные этапы реализации системы. Например, типовая функция системы имеет оценку на различных этапах – от аналитики и проектирования до реализации и тестирования.
• Оценка проекта проводится в 2 этапа. На первом детально оценивается аналитика, архитектура и проектирование системы. Этап реализации, тестирования и внедрения оценивается рамочно – для общего понимания сроков и бюджетов, которые могут корректироваться. Второй этап оценки запускается после завершения этапа аналитики и проектирования, когда команда более детальное погрузилась в проект и у нее есть понимание сроков.
  
   

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

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

• Выявить потребности заказчика, в том числе и скрытые.
• Детально понимать задачи, необходимые для реализации запроса клиента.
• Оценить трудоемкость выполнения задач и проекта в целом. Чем раньше известны реальные затраты, тем проще принять решение об участии в проекте и потом работать на нем.
• Рассчитать финальную оценку затрат.
• Продемонстрировать компетенции команды заказчику.

Результат первого этапа –  оценка проекта (детальная – для этапа проектирования и рамочная – для этапа реализации) и ряд дополнительных артефактов:

• Бизнес-концепция: 
• Цели и задачи проекта, критерии достижения 
• Стейкхолдеры, их заинтересованность и степень влияния 
• Глоссарий и роли 
• Описание процесса – бизнес-уровень 
• Описание процесса – системный уровень 
• Перспективы развития проекта 
• Функциональные требования
• Архитектурная концепция:
• Нефункциональные требования и ограничения 
• Назначение продукта, список используемых технологий
• Перечень функциональных возможностей, которые реализует продукт
• Состав и структура продукта
• Описание составных частей, их назначение и функции
• Описание порядка взаимодействия составных частей
• Описание порядка взаимодействия с внешними продуктами, которые требуют интеграции
• Протоколы информационного взаимодействия
• Описание форматов файлов, если на проекте есть обработка файлов
• Эскиз решения: архитектурный стиль и контекст системы
• Диаграммы контейнеров и потоков данных
• Диаграмма развертывания
• Иерархическая структура работ
• Roadmap
• Реестр рисков

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

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

При оценке этапа реализации мы используем метод PERT, с помощью которого вычисляется ожидаемое значение продолжительности проекта или отдельного функционального модуля – автоматически по формуле:

где: O — оптимистичная оценка длительности задачи, M — наиболее вероятная оценка длительности задачи, P — пессимистичная оценка длительности задачи.

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

Кроме этого, мы активно используем в работе подход Design API First, о котором более подробно рассказывали в блоге. 
 

Как система оценки помогает сократить риски

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

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

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