Управление проектами - это философия управления, а не инструмент или техника
Управление проектамиГлоссарийФорумКонтакты

Предсказание затрат Support Costs

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

Данная статья предоставляет методологию, которая поможет вам лучше представлять и тем самым планировать этап поддержки доступных широкой публике продкутов. Но сначала давайте определим некоторые термины, которые важны для понимания данной статьи.

Сопровождение

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

Сопровождение может быть разделено на три категории:

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

Адаптируемое сопровождение включает в себя изменения системы для того, чтобы она работала в различной среде, такой как другая сетевая топология, платформа или операционная система. Примером будет изменение разработчиком Java-метода, который работает на BEA WebLogic, но не на IBM Websphere.

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

Повышение качества

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

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

Поддержка

Поддержка определена в качестве суммы усилий сопровождения и улучшений, выполненных после того, как продукт стал доступен. Другими словами, поддержка включает все действия, которые выполняются после того, как продукт стал общедоступен.

Методология

Простые правила могут быть приняты для оценки затрат на поддержание в определенных проектах. К примеру, годовые затраты на поддержание статического веб-сайта после его публикации более или менее равны затратам на его разработку. Другими словами, при разработке статического веб-сайта вы, потратив $10,000, можете ожидать затрат в $10,000 на его поддержание.

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

Различные модели были разработаны на протяжении нескольких лет для предсказания затрат на поддержания на основании плотности дефектов (к примеру, кривые Raleigh, анализ Weibull), подсчет количества строк кода (KLOC) и усилия для разработки. К сожалению, данные модели также имеют свои недостатки. Многие из них слишком неточные или сложные для того, чтобы их учить. Более того, некоторые настолько сложны, что вам придется приобрести приложение за несколько тысяч долларов и вносить 100 и более параметров для того, чтобы оно вычислило усилия, необходимые на поддержание продукта.

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

Модель Боэма

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

Формула Боэма заключается в следующем:

AME = ACT X SDT, где...

  • AME - является годичными усилиями на поддержание, измеряемыми в человеко-месяцах.
  • ACT - является годичным трафиком изменений, который представляет часть требований исходного продукта, которые прошли некоторые изменения во время типичного года посредством добавления или модификации.
  • SDT - это время разработки ПО в человеко-месяцах.

Допустим, проект по разработке ПО требовал 100 человеко-месяцев усилий, и было спрогнозировано , что 15% всего кода будет изменено в год. Основная оценка годичных усилий поддержки (AME) будет равна:

AME = 0.15 x 100 = 15 человеко-месяцев

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

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

Допустим, в прошлой системе факторами, которые имели наибольшее влияние на затраты поддержания, были сложность продукта (CPLX), которая очень высока, и доступность поддержки со стороны сотрудников (AEXP), которая очень низка.

Если CPLX = 1.30 и AEXP = 1.29, то тогда:

AEM = 15 x 1.30 x 1.29 = 25.2 человеко-месяцев.

Прогнозирование улучшений

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

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

Вывод

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

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

Более того, убедитесь, что у вас есть команда профессионалов, которая может реализовать запросы на изменения, требуемые клиентом, но не относитесь к ним как к затратам, поскольку они на самом деле это источник дохода.

 

Предложения

Copyright ©2014, PMToday.ru. При копировании материалов наличие прямой индексируемой ссылки на сайт обязательно.