Архивы для Январь, 2012

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

Так как сбор и интерпретация данных относится к дисциплине метрик, то здесь стоит обратить внимание на классический треугольник успешности и полезности измерений:

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

В этой статье поговорим именно об инструментарии.

Для начала обратимся к такой дисциплине как Scope Management – управление объемом работ по проекту. В первую очередь это правило 100%, т.е. список работ по проекту должен отражать абсолютно ВСЕ работы и им должно быть место в расписании работ, плановые и фактические трудозатраты по ним должны быть оценены и отрапортованы. ВСЕ – в т.ч. инспекции документов, устранение дефектов, совещания, и даже участие в интервью по набору персонала на проект…

Хорошо помогают шаблоны списков работ (WBS – work breakdown structure).

Ключевым моментом является такая декомпозиция списка работ, где были бы выделены отдельные задачи (берем для примера разработчика), и, соответственно временнАя отчетность на:

• Инспекцию спецификаций (COQ)
• Разработку архитектуры
• Юнит тесты (COQ)
• Кодирование
• Инспекцию кода (COQ)
• Устранение дефектов после тестирования (COPQ)
• Разворачивание продукта в тестовом окружении
• Устранение дефектов по гарантийным обязательствам (COPQ)
• Устранение дефектов после инспекции кода (COPQ)
• И т.п.

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

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

Таким образом, если у вас есть такие компоненты:

• Корректная декомпозиция работ
• Таск-тайм трекер, который позволяет отразить и декомпозицию, и отчетность о затраченном времени
• Обучающие меры для сотрудников – как пользоваться таск-тайм трекером

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

Конечно же, возникают некоторые тонкости в организации и процессов работы, и инструментария. Давайте посмотрим на примеры.

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

Интенсивная работа с требованиями. А что если требования обсуждаются настолько интерактивно между заказчиком, аналитиком, разработчиками, тестировщиками, что четкая разница между формализацией требований, их инспекцией (обсуждениями) и устранением дефектов (рекомендации, выданные при обсуждениях) не видна? Или же не имеет смысла это разделять. Тут, наверное, лучший вариант – без фанатизма, просто отнести такой вариант работы в задачу «Разработка требований», т.е. к COQ или COPQ не относить вообще. Если же такого интерактива нет, а есть четкое разделение на формализацию, инспекции, и исправление дефектов, и, внимание!, вам действительно надо выделять COQ и COPQ, то предлагаю такой же подход, как и в предыдущем примере – с использованием системы управления дефектами.

Завершая цикл хочу сказать, что серьезно «заводиться» со стоимостью качества и метриками стоит лишь в том случае, если у вас есть:

• Великая цель – зачем это делать и кому от этого будет лучше
• Подготовка по теме – как это работает
• Здравый смысл – в разумной реализации Великой цели

Надеюсь, что это было вам полезно.

Оригинал статьи здесь.

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

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

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

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

Вариант 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.