Как сократить риски при оценке проектов
В статье расскажем, как построен процесс оценки проектов в компании SimbirSoft, какие инструменты и методики мы используем и как минимизируем риски
Руководитель архитектурного комитета ИТ-компании SimbirSoft, кандидат технических наук. Опыт работы в ИТ – более 22 лет, из них 16 лет — в проектировании ИТ-архитектуры.
7 распространенных рисков при оценке ИТ-проектов
Оценка проектов – одна из обязательных составляющих деятельности ИТ-компании, которая занимается разработкой заказного ПО, как SimbirSoft. При этом процесс оценки всегда сопряжен с рядом рисков, среди которых типичны следующие:
- Неправильная оценка объема работ и сроков реализации проекта. Ошибки в определении требований, неполное понимание процессов и технологий, недооценка сложности задач могут привести к завышению/занижению сроков или стоимости проекта.
- Незнание или недооценка особенностей бизнес-процессов и инфраструктуры заказчика. Отсутствие информации о существующих системах, несовместимости решений и сложности интеграции могут вызвать задержки и проблемы в ходе реализации проекта. Важно иметь этап погружения в бизнес-процессы клиента. На этапе пресейла это не всегда возможно и на это нужно закладывать дополнительное время.
- Изменение требований и приоритетов. В ходе проекта заказчик может изменить требования и приоритеты, что объективно приведет к пересмотру сроков и/или стоимости проекта или даже к отказу от него.
- Некачественное выполнение работ на пресейле. Недостаточная квалификация команды оценщиков, ненадлежащая проверка основных целей системы и отсутствие контроля качества также ведут к ошибкам.
- Финансовые риски. Неадекватная оценка стоимости и неэффективное использование бюджета проекта, изменение сроков выполнения ранее оцененных задач могут привести к перерасходу бюджета и другим финансовым рискам.
- Отсутствие понимания и поддержки со стороны заказчика. Непонимание заказчиком проекта, отсутствие его активного участия и поддержки создают риск слишком «поверхностной» оценки или ее сильного увеличения за счет компенсации рисков.
- Отсутствие управления рисками. Неправильное управление рисками, отсутствие плана и контроля может привести к возникновению и ухудшению рисков в процессе оценки.
Какого результата разработки ожидает заказчик? Как правило, хочет реализовать продукт, отвечающий всем заявленным требованиям, в срок и в рамках бюджета . Однако, если заказчик и команда разработки работали недостаточно слаженно, реальность может отличаться. Самые частые риски – задержка срока, перерасход бюджета, проблемы с качеством и/или функциональностью системы, с репутацией компании и в итоге к оттоку клиентов. Поэтому важно проводить тщательную оценку, обозначать все риски и учитывать их при планировании и выполнении проекта.
Хорошая практика – составление матрицы рисков. Она позволяет на ранних этапах подсветить проблемы и продумать альтернативные сценарии, которые позволят их избежать.
Популярные методы оценки: их особенности и ограничения
- Существуют следующие методы оценки проектов:
Алгоритмическое моделирование себестоимости реализации проектов. Примеры: модели COCOMO (1981 год, Барри Боэм) и COCOMO II (1999 год, Барри Боэм), метод функциональных точек IFPUG (1979 год, Алан Альбрехт) и другие. - Бенчмаркетинг. Сравнение с затратами на аналогичные продукты или проекты, которые были ранее реализованы конкурентами
- Оценка на основе предыдущего опыта. Здесь можно использовать экспертную оценку с привлечением специалистов, которые имеют большой опыт разработки подобных систем, методы оценки по аналогии с другими проектами на основе базы накопленных оценок по типовым задачам или оценку по параметрам системы с элементами моделирования, которая позволяет построить некоторую математическую модель на основе опыта работы и ввести параметры рисков (например, метод UCP).
Для такой оценки необходимо где-то хранить опыт предыдущих работ: в головах экспертов, в системе или опираться на открытые источники информации о трудозатратах.
Методы первой группы достаточно хорошо формализованы и описаны с точки зрения алгоритмов расчета и формирования оценочной стоимости в часах. Например, модель COCOMO II предполагает расчет затрат в человеко-часах по формуле:
где: PM – получаемая оценка в человеко-часах, EAF – произведение выбранных множителей трудоемкости (определяется по таблице в стандарте COCOMO II), А, B – коэффициенты, зависящие от типа проекта (также по таблице), SF – фактор масштаба (также по таблице), SIZE – объем программного продукта в тысячах строк исходного кода, который определяется методом PERT или с помощью анализа продукта методом функциональных точек IFPUG. Получить такую характеристику на этапе предварительного анализа проекта сложно. Поэтому использование методов алгоритмического моделирования имеет ряд ограничений, связанных с отсутствием необходимой информации.
Методы бенчмаркинга также имеют ограничения, связанные с рядом моментов. Во-первых, информация о реальных затратах на продукт не всегда доступна и достоверна. Во-вторых, создание системы, которая представляет собой полный аналог, разработанный конкурентами, неактуально. В-третьих, всегда следует учитывать специфику своего опыта и наработок, особенности команды и другие факторы.
Мы пошли по третьему пути – оценке на основе предыдущего опыта, внедрив несколько лет назад собственную автоматизированную систему поддержки оценки.
Как устроен процесс оценки у нас
Основная идея реализации автоматизированной системы оценки базируется на следующих принципах:
- Аккумулирование опыта решения типовых задач, оцененного в часах (планируемых и фактических) в общей базе.
- Периодическая корректировка оценки типовых задач на основе обновленной информации.
- Использование наборов готовых решений, которые связывают различные этапы реализации системы. Например, типовая функция системы имеет оценку на различных этапах – от аналитики и проектирования до реализации и тестирования.
- Оценка проекта проводится в 2 этапа. На первом детально оценивается аналитика, архитектура и проектирование системы. Этап реализации, тестирования и внедрения оценивается рамочно – для общего понимания сроков и бюджетов, которые могут корректироваться. Второй этап оценки запускается после завершения этапа аналитики и проектирования, когда команда более детальное погрузилась в проект и у нее есть понимание сроков.
![Как сократить риски при оценке проектов](https://s.rbk.ru/v1_companies_s3/media/news_body_images/86bb2273-c5de-4722-a32a-6f1b77ceb34e.jpg)
Особенно важным является первый этап, когда необходимо определить общую концепцию системы, ее основные функциональные части, нефункциональные требования и ограничения, которые влияют на сроки и бюджет. Если того требует проект, мы проводим предпроектное исследование. Для этого формируется команда из архитектора, аналитика, руководителя проекта и дизайнера, если требуется разработка интерфейса.
Несмотря на дополнительные затраты, проведение предпроектного исследования позволяет уже на этапе пресейла:
- Выявить потребности заказчика, в том числе и скрытые.
- Детально понимать задачи, необходимые для реализации запроса клиента.
- Оценить трудоемкость выполнения задач и проекта в целом. Чем раньше известны реальные затраты, тем проще принять решение об участии в проекте и потом работать на нем.
- Рассчитать финальную оценку затрат.
- Продемонстрировать компетенции команды заказчику.
Результат первого этапа – оценка проекта (детальная – для этапа проектирования и рамочная – для этапа реализации) и ряд дополнительных артефактов:
- Бизнес-концепция:
- Цели и задачи проекта, критерии достижения
- Стейкхолдеры, их заинтересованность и степень влияния
- Глоссарий и роли
- Описание процесса – бизнес-уровень
- Описание процесса – системный уровень
- Перспективы развития проекта
- Функциональные требования
- Архитектурная концепция:
- Нефункциональные требования и ограничения
- Назначение продукта, список используемых технологий
- Перечень функциональных возможностей, которые реализует продукт
- Состав и структура продукта
- Описание составных частей, их назначение и функции
- Описание порядка взаимодействия составных частей
- Описание порядка взаимодействия с внешними продуктами, которые требуют интеграции
- Протоколы информационного взаимодействия
- Описание форматов файлов, если на проекте есть обработка файлов
- Эскиз решения: архитектурный стиль и контекст системы
- Диаграммы контейнеров и потоков данных
- Диаграмма развертывания
- Иерархическая структура работ
- Roadmap
- Реестр рисков
Для реализации архитектурной концепции мы используем методологию ADD (Attribute-Driven Design), которая представляет итерационный процесс проектирования ПО на основе архитектурно значимых требований. Примеры таких требований, распределенных по группам, приведены ниже.
Для реализации архитектурной концепции мы используем методологию ADD (Attribute-Driven Design), которая представляет итерационный процесс проектирования ПО на основе архитектурно значимых требований. Примеры таких требований, распределенных по группам, приведены ниже.
![Как сократить риски при оценке проектов](https://s.rbk.ru/v1_companies_s3/media/news_body_images/b31a0fd6-cbf3-4a4b-ac49-46adc7601bde.jpg)
При оценке этапа реализации мы используем метод PERT, с помощью которого вычисляется ожидаемое значение продолжительности проекта или отдельного функционального модуля – автоматически по формуле:
где: O — оптимистичная оценка длительности задачи, M — наиболее вероятная оценка длительности задачи, P — пессимистичная оценка длительности задачи.
Это уравнение представляет собой средневзвешенное значение, где наиболее вероятная оценка длительности имеет в 4 раза больший вес, чем оптимистичная и пессимистичная оценки. Такой подход помогает предотвратить сильный перекос в каком-то из направлений.
Кроме этого, мы активно используем в работе подход Design API First, о котором более подробно рассказывали в блоге.
Как система оценки помогает сократить риски
Возвращаясь к рискам, обозначенным в начале статьи, проанализируем, каким образом они меняются при использовании подобной системы оценки и общего подхода, который описан в статье.
![Как сократить риски при оценке проектов](https://s.rbk.ru/v1_companies_s3/media/news_body_images/9b43ef5e-ad6f-4667-9fb1-94baf0ae4b26.jpg)
Подводя итог отмечу, что использование автоматизированной системы поддержки оценки проектов позволяет достичь следующих преимуществ:
- База данных нормо-часов, которая строится на основе реализации типовых задач на проектах, позволяет получить средневзвешенную оценку без привлечения экспертов, что значительно сокращает время расчета и экономит время специалистов.
- На выходе получается детальная и развернутая спецификация, которая содержит все виды работ с описанием и указанием количества часов.
- В настоящий момент с помощью данного инструмента рассчитано более 1000 проектов и это число постоянно растет.