Outstaffing. Критерии приемки.

Продолжая начатую ранее тему о сервисной природе разработки ПО (см. Делаем проекты или предоставляем сервис?) хочу ее продолжить. Сразу скажу, к чему относится и к чему не относится данный материал.

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

НЕ ОТНОСИТСЯ к ярко выраженной проектной деятельности (определены начало и конец проекта, требования, бюджет) и-или присутствует контракт типа Fixed Price. А в этом случае делается проект.

Речь пойдет о критериях приемки такого сервиса (aka SLA), точнее о количественном определении так называемого performance (качество и количество работы). Количественное определение – использование данных, метрик, KPI, фактов и т.п. Или, другими словами, как объективно понять, что работа делается хорошо.

Основной вопрос – а зачем это надо? Тут может быть несколько вариантов, причем и по «и» и по «или» принципам:

  • Есть договоренности с заказчиком (в том числе контрактные) об ожидаемых параметрах performance-а
  • Есть внутренние корпоративные ожидания об ожидаемых параметрах performance-а
  • Есть конкуренты, делающие подобную работу, т.е. надо понимать, что мы не хуже, стремиться к лучшему
  • Есть, как ни странно :), желание выявлять и устранять проблемы до их возникновения, а не заниматься пожаротушением
  • Есть необходимость адекватной аттестации персонала, т.е. основанной в т.ч. на показателях performance-а, а не на субъективных ощущениях. Таким образом думающие, ответственные, производительные сотрудники оцениваются по заслугам и имеют больше перспектив
  • Есть система премирования, которая в отсутствии объективных показателей становится деморализатором
  • Есть (а вот это уже совсем странно :)) потребность улучшать рабочие процессы, например, уменьшить стоимость, увеличить «отдачу», улучшить качество и т.п.

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

Собственно примеры критериев:

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

Пример из реальной жизни. Для работ по поддержке продукта, где в команду поступают запросы на мелкие улучшения и на устранение дефектов были выбраны и настроены следующие метрики: среднее количество закрытых запросов на человека в месяц, % возвращенных (т.е. дефектных) запросов, загрузка команды. Для каждой метрики были определены допустимые пределы, основанные на ожиданиях заказчика и performance-е конкурирующих команд. Метрики регулярно собираются, анализируются, и по результатам принимаются решения.

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

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

Позволю себе в контексте данной темы еще раз сослаться на справочный источник из предыдущей статьи, но теперь уже на конкретные разделы – «Quantitative Work Management» и «Measurement and Analysis», Модель «CMMI for Services, Version 1.3» (http://www.sei.cmu.edu/library/abstracts/reports/10tr034.cfm).

Tags: , ,

Comments are closed.