Стоимость качества. Часть 2.1 – Зачем это надо?

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

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

Но, возникают вопросы:

  • Как доказать и убедиться, что улучшение полезно, для кого или чего именно?
  • Как понять, чьим интересам улучшение соответствует, или не соответствует?

 

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

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

Еще одно необходимое отступление – по поводу производительности. Это некоторое количество работы в единицу времени. Количество работы «по научному» — размер (size). Наиболее понятный пример – Velocity (Story Points per Sprint), где Story Point – одна единица размера. Это конечно не идеальный способ, но все же существенно лучше чем человеко-часы. Или же, за единицу размера могут приниматься какие-то дискретные виды работ (например, разработка стандартного баннера). Тема размера – это отдельная довольно серьезная дисциплина, по этому поводу есть небольшая ознакомительная статья, а более полный комплект доступен здесь (за подписку).

Для плавного перехода к практическому применению давайте сначала для наглядности посмотрим на следующие диаграммы, иллюстрирующие потенциальное влияние изменений. Предположим, что у нас работает стабильная по составу команда, и за последнее время в среднем соотношение затрат между видами работ такое (из спринта в спринт, из месяца в месяц и т.п.). Где «Создание продукта» — это все что не «Total Quality Costs – TQC» (см. Часть 1), т.е. кодирование, требования и т.п.

Соотношение №1

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

Cost of Quality

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

Решили что следующие улучшения могут быть наиболее полезными:

  • ввести инспекцию спецификаций,
  • или же добавить нагрузочное тестирование,
  • или же ввести инструментарий прослеживаемости (traceability) требований

 

Пусть это будут Соотношения №№2-4 соответственно. И пусть они для простоты будут внедряться независимо, по-одному. Рассмотрим потенциальные варианты.

Соотношение №2

Инспекция спецификаций помогла, она, как часть COQ (+5%), помогла существенно сократить COPQ (-10%), высвободив ресурсы. Причем, высвобождение может пойти либо на увеличение производительности (Соотношение №2), либо на экономию средств (Соотношение №2.1).

Cost of Quality

Cost of Quality

Соотношение №3

Введение нагрузочного тестирования, очевидно, не помогло — производительность команды понизилась (-5%), т.к. время на него тратится, а COQ повысился (+5%). Заметим, что проверка достижения запланированной нагрузки на приложение тоже входит в TQC, а дефекты, вызванные, якобы, нагрузочными проблемами, таковыми не оказались. Значит, «копали не туда».

Cost ofQuality

Соотношение №4

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

Cost of Quality

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

Подводя итог можно сказать, что:

  • Во-первых, если что-то кого-то в проекте не устраивает, то проблемы есть, и надо что-то улучшать
  • Во-вторых, если проблемы есть, но непонятно что конкретно может помочь, то можно предположить несколько наиболее полезных улучшений
  • НО, в-третьих, нужно понимать, чьим интересам какое улучшение соответствует, или не соответствует. Т.к. даже от самого очевидного улучшения не все участники проекта могут быть счастливы :). Об этом в следующей Части 2.2
  • В-четвертых, нужно определить, каким образом будет оцениваться успешность улучшений, так чтобы было поменьше субъективных ощущений и побольше цифр и фактов. Об этом в еще одной — Части 3.

 

Спасибо за внимание, продолжение следует.

Tags: , , , ,

Comments are closed.