Продолжаю серию статей о стоимости качества. Две предыдущие: «Стоимость качества. Часть 1 – Что это такое?» и «Стоимость качества. Часть 2.1 – Зачем это надо?». В этой же статье рассмотрим «Кому это надо?». Очень рекомендую обратить внимание на предыдущие статьи, т.к. они представляют собой логическую цепочку рассуждений.

Здесь рассмотрим, в каких ситуациях следует (или не следует) озаботиться стоимостью качества и относительной величиной его доли в общем объеме работ. Давайте рассмотрим несколько вариантов. Но для начала вспомним классическую диаграмму стоимости изменений (Cost of Change), но будем ее понимать в контексте стоимости устранения дефектов, т.к. график по своей сути не меняется.

Cost of Change/Defect

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

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

Вариант 1. Проект типа Fixed Price.

Соответственно, и скорее всего, помимо бюджета четко зафиксированы объем работ и сроки. Здесь нужно в первую очередь обращать внимание на требования и критерии приемки. Оставим в стороне дискуссию о возможной неполноте и изменчивости требований, о применимости этого типа контракта, это регулируется другими механизмами. Здесь становиться очевидным, что нужно стараться минимизировать COPQ, т.к. это напрямую влияет на доход и, возможно, на штрафные санкции, и-или на расходы по гарантийным обязательствам. Но с другой стороны минимизация COPQ выражается в увеличении COQ, и тут тоже нужно не переусердствовать. На помощь приходит вышеуказанная диаграмма «Стоимость устранения дефектов». Напрашивается вывод, что имеет смысл уделить особое внимание процедурам из COQ как можно раньше. А именно – постановке процессов обеспечения качества и реализации мер контроля (инспекции спецификаций, архитектуры, кода, тестовой документации и т.п.). См. подробности в статье «Стоимость качества. Часть 1 – Что это такое?». Стоимость процедур COQ легко считается и планируется, и также легко соотносится со штрафными санкциями.

Кому это надо? Компании Исполнителю, т.к. это ее доход и репутация. Говоря о процедурах из COQ, то немного бОльший фокус должен быть на эти меры на начальных стадиях, т.к. последствия от их неприменения скорее всего аукнутся относительно бОльшими расходами на COPQ.

Вариант 2. Служба поддержки (или любая деятельность, которая по своей сути не есть проектом, а есть повседневной операционной деятельностью, или для простоты – конвейером).

Этот вариант является просто идеальной почвой для «экспериментов» по выявлению наилучшего соотношения COQ, COPQ и собственно стоимости предоставления услуг. Путем внедрения улучшений можно определить какой процесс и какое соотношение COQ и COPQ способствует наилучшему соотношению стоимости, количества и качества результатов деятельности. Под COPQ в этом случае подразумеваются переделки из-за некорректного выполнения запроса на поддержку.

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

Вариант 3. Проект или долгосрочное партнерство по контракту типа Cost Reimbursable.

Контракт Cost Reimbursable предполагает что Заказчик оплачивает исполнителю его расходы плюс прибыль. Есть несколько разновидностей. Не вдаваясь в подробности, это хорошо подходит для долгосрочного outstaffing, в основном по разработке, развитию или поддержке больших продуктов. Здесь особенность в том, что Исполнитель не очень заинтересован сокращать свои расходы, т.к. на каждый доллар расходов он получает некий % прибыли. И если у Заказчика нет жестких требований к процессам работы, то так или иначе это расслабляет Исполнителя. И этот «расслабон» по традиции уменьшает усилия, входящие в COQ и увеличивает COPQ. В таком типе взаимоотношений Заказчик обычно имеет гораздо бОльший контроль над процессами и в принятии решений, чем в Fixed Price. Поэтому…

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

Вариант 4. Деятельность или продукт для систем класса life critical или mission critical.

Здесь, очевидно, доля COQ будет (и должна быть) очень высока, причем все ее аспекты, а особенно превентивная составляющая. И она может легко превышать и собственно долю разработки и долю COPQ. Обычно только достаточно зрелые компании могут обеспечить выполнение процедур, из которых состоит COQ.

Кому это надо? И Заказчику и Исполнителю, причем для обоих фокус скорее не в снижении расходов, или в скорости работы, а в качестве (надежности) таких систем.

Вариант 5. Пилотные проекты с целью развития бизнеса.

Здесь могут быть какие угодно варианты о том, что важно или нужно. От «слепить» что-то побыстрее, до демонстрации зрелости процессов работы. Также играет роль бизнес перспектива, Исполнитель легко может сработать себе в убыток, чтобы заполучить «вкусного» заказчика. Говоря о COQ и COPQ для этого варианта, и основываясь на собственном опыте скажу, что это вариант очень похож на mission critical. Но есть и отличия. К COPQ здесь можно, без преувеличения, прибавить стоимость упущенной возможности, т.е. потенциальную сумму контракта (если вы потеряли потенциального заказчика именно из-за плохого качества «пилота»).

Кому это надо? Однозначно Исполнителю. По-моему, пилотные проекты «вкусного» класса должны рассматриваться как mission critical, с особым вниманием процедурам из COQ.

Вариант 6. Качество устраивает.

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

Кому это надо? В этом случае больше Заказчику, т.к. он совершенно осознает что делает и отдает себе отчет о результатах.

 
 

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

Просьба не воспринимать буквально следующие цифры, это скорее относительные взаимоотношения доли COQ и COPQ в общей стоимости проекта, деятельности. Приведу по тем вариантам, где есть опытные данные.

  • Вариант 1. COQ + COPQ – 40-50% от общей стоимости
  • Вариант 3. COQ + COPQ – 30-40% от общей стоимости
  • Вариент 4. Опытных данных нет, но осмелюсь предположить что COQ + COPQ – 50-80% от общей стоимости
  • Вариант 5. COQ + COPQ – 40-60% от общей стоимости
  • Вариант 6. COQ + COPQ – 20-30% от общей стоимости, но из COQ + COPQ бОльшая доля принадлежит COPQ

 

В следующей статье «Стоимость качества. Часть 3 – Как это посчитать?» поговорим о практических вопросах сбора и интерпретации данных для подсчета COQ + COPQ.