Как оценить стоимость разработки быстрее: разбираем метод оценки по UCP

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

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

Темой этой статьи стал еще один популярный способ оценки — оценка по UCP. Начнем с краткого описания метода, далее расскажем, как мы его под себя адаптировали и какие проекты подходят для такой оценки.

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

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

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

Метод оценки проектов по UCP

Метод оценки проектов по UCP был предложен Густавом Карнером в 1993 году во время работы в компании Objectory Systems, предшественнице Rational Software и IBM. 

Автор предложил оценивать затраты на разработку информационной системы (далее — ИС) с разных сторон, учитывая вес параметров следующих групп в баллах:

• Функциональные параметры (UUCP): кто и что может делать в ИС. 
• Технические параметры (TCF): сложность архитектуры, требования к безопасности, производительности и нагрузке, эффективность работы пользователя, переиспользование кода, наличие адаптива, удобство интерфейса, доступность системы для одновременной работы пользователей и прочее.
• Факторы окружения (ECF): погружение команды разработки в предметную область, наличие опыта разработки аналогичных систем, уровень квалификации, возможность подключения специалистов на полный рабочий день, уровень мотивации команды проекта и ее слаженность, стабильность требований к разрабатываемому решению и прочее.

Работа по оценке методом UCP делится на два этапа:

1. Unadjusted — проработка ролей в системе и Use Cases (вариантов использования). На этом этапе необходимо составить списки:

• UAW: количество действующих лиц в ИС (акторов) и их способ взаимодействия с системой (через UI, посредством API или доступ по FTP, например)
• UUCW: количество и сложность Use Cases

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

2. На следующем этапе необходимо расставить вес всех параметров в группах Unadjusted, технические факторы и факторы окружения. Мы, например, применяем такие коэффициенты:

• Простой Use Case (1-3 шага) — 5 баллов, сложный (7-11 шагов) — 15 баллов. 
• Взаимодействие с системой по API — 1 балл, с помощью UI — 3 балла.
• Для технических факторов и факторов окружения мы используем баллы: 0-3-5.
  Чем больше суммарный балл, тем сложнее система и выше итоговая оценка проекта.

Наше допущение при составлении списка Use Cases: пишем их от лица пользователей: неодушевленные участники информационного обмена участвуют в Use Cases как «шаги». Например, «Я как пользователь могу посмотреть штрафы, пришедшие от ГИБДД»

Также в этом методе присутствуют дополнительные множители — «вес факторов», которые мы использовали для адаптации этого метода оценки под наши реалии. Об этом — ниже.

Чем нас привлек метод оценки по UCP и как его использовать

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

Метод оценки по UCP чаще других используется для быстрой оценки продуктовых проектов. Для сравнения: экспертная оценка потребует в разы больше затрат за счет подключения экспертов различных направлений для ее проработки.  

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

Чтобы научиться давать релевантные оценки методом UCP, мы начали с таких шагов, как обратный инжиниринг и А/Б-тестирование. Но сначала нам нужно было выбрать несколько десятков оцененных классическим (экспертным) способом проектов, которые подходили бы под следующие критерии:

• тип проекта = аутсорс («проект под ключ»)
• проект с нуля — не доработка, не модификация и прочее
• проект, который включает все этапы разработки — от аналитики до DevOps
• все специалисты наши и все, что заложено в проект, делает наша команда

И заново оценить их, но уже по UCP. Вполне ожидаемо, что цифры у нас сошлись не сразу. И нам пришлось подстраивать под себя:

• правила создания списка UC и простановку их «сложности»
• «вес факторов»

Это было достаточно просто, поскольку в классическом методе оценки мы используем разбивку фичей на «эпики» — по сути те же Use Cases в методе UCP, а вес достаточно легко менять в таблице. Таким образом, мы получили Excel-файл, где модератору достаточно внести список Actor’ов и Use Cases, а все остальные параметры оставили на уровне «рекомендованных» для наших процессов ведения проекта.

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

• классическая оценка экспертами 
• оценка по UCP

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

• оценок по фиксированной стоимости
• аудитов и отдельных видов работ на проекте
• доработок за другой командой — помним, что по UCP мы оцениваем только «проекты с нуля»

Разберем на примере кейса. Задача — создать платформу библиотеки ассетов для разработчиков игр.

На этапе предварительной оценки вместе с заказчиком мы выделили MVP (Minimal Viable Product, минимально жизнеспособный продукт), сформировали фич-лист и на его основе составили перечень Use Cases. Этот кейс был той самой проверкой на «боевых» — реальных запросах. Мы максимально детально подходили к оценке и прорабатывали все очень подробно, чтобы потом могли разобраться, если что-то в оценке пойдет не так. После того, как обучили модераторов и поставили оценку по методу ucp на поток, такой детализации не потребовалось. Модератор оценки, как правило, на основе своего опыта продумывает шаги Use Case и проставляет сложность без детального описания и Use Case-диаграммы. 

Шаблонное описание Use Case для такого метода оценки выглядит следующим образом:

Во время тестирования метода мы описывали все Use Cases по такому шаблону (примечание: сейчас уже так не делаем). Затем присвоили коэффициент сложности для каждого Use Case в зависимости от количества действий.

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

В каких случаях можно использовать этот метод

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

• это стартап и заказчику нужен примерный ориентир по затратам на проект
• проект представляет из себя «классическую разработку» без дополнительных требований к отдельным видам работ. Например: к архитектуре, как в банках, к дизайну с wow-эффектом и анимации, как в играх, без ТЗ по ГОСТ, как в госсекторе и прочее.
• клиент — не из ИТ и не может дать ничего, кроме бизнес-требований.

Метод оценки по UCP подходит для определения примерной оценки проектов. После проведения предпроектного этапа аналитики или предпроектного обследования потребуется переоценка объема разработки. 

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

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

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

Термины и обозначения:

• UUCP — Unadjusted Use Case Points — нескорректированные сценарии использования 
• UUCW — Unadjusted Use Case Weight — нескорректированный вес вариантов использования 
• UAW — Unadjusted Actor Weight — нескорректированный вес актора, учитывает количество и сложность акторов 
• TCF — Technical Complexity Factor — коэффициент технической сложности. 
• ECF — Environmental Complexity Factor — коэффициент сложности среды.