Ни для кого не секрет, что проблемы качества реализации web-проектов стоит крайне остро. Даже при самом полном описании деталей проекта, при существовании стандартов реализации в компании все равно регулярно вмешивается человеческий фактор. Где-то по незнанию, где-то из-за невнимательности, а где-то из-за банальной лени, но тут и там при реализации вылезают маленькие и большие, критичные и не очень, порой просто нелепые ошибки. Конечно, все мы понимаем, чем это грозит: затянувшийся этап тестирования и отладки, выпуск в свет сырого продукта, ухудшающиеся отношения с заказчиком (особенно, когда именно он обнаруживает недочеты в работе). Все это побудило меня к разработке некоей системы мотивации, которая бы позволила повысить внимательность специалистов на проекте и снизить возникающие ошибки и неточности.
МетодикаВ разработке системы, конечно же, принимали участие программисты и тестеры нашей компании. Именно с их подачи за основной показатель качества была выбрана такая величина, как количество багов на неделю разработки. Хочу оговориться, что общая длительность разработки считается линейно. То есть, сколько будет делаться проект одним специалистом (грубо говоря, длительность проекта в человеко-часах).
Все баги были классифицированы по 2-м показателям (естественно, с описанием признаков того или иного бага): критичность (1 - красный, 2 - желтый, 3 - зеленый) и срочность (1, 2, 3). Но срочность в нашем случае не важна, а вот критичность бага очень влияет на качество.
Вторым показателем, естественно, был выбран срок работ, то есть совпадение календарного и реального графиков работ.
Для расчета премий для группы программистов и группы тестировщиков устанавливается базовая премия, исходя из нормальных показателей работы. Были разработаны следующие схемы.
Программисты:
Для расчета показателей проекта задаются коридоры багов - свой для каждой критичности (дробные значения округляются в меньшую сторону), например:
• Красный - 0.5-0.75 на неделю разработки,
• Желтый - 1-2 на неделю разработки,
• Зеленый - 1.5-2.5 на неделю разработки.
Таким образом, скажем, на проект длительностью 5 недель допустимые коридоры багов (до начала тестирования):
• Красных – 2-3 бага,
• Желтых – 5-10 багов,
• Зеленых – 7- 12 багов.
За каждый выход выше верхнего предела из премии команды вычитается определенный процент премии (в зависимости от критичности, величина процента разная). За выход ниже нижнего предела – начисляется процент к премии.
По срокам процент на уменьшение премии высчитывается за каждый день сверх плана. За уменьшение времени разработки премия не назначалась, так как ускорение проекта не имеет значения (кроме особо оговоренных случаев).
Была определена буферная зона, определенный отрезок, который не вел к уменьшению премии. Он вычисляется из расчета 1 день на 1 неделю разработки, страховочное время. Однако при превышении этого времени уменьшение суммы премии равно всему времени (то есть для 5 недель разработки 5 дней простоя вычитаются из премии). И далее за каждый день просрочки. Естественно, время работ корректируется при каких-либо изменениях в объемах.Тестировщики:
У группы тестировщиков вместо коридора есть показатель качества тестирования. Мы ввели это показатель равным 0.7, то есть на сайте, вводимом в работу, должно быть вычищено 70% ошибок.
Проверяется это таким образом, что за время тестирования сайта заказчиком может быть найдено не более 3 багов на каждые 7, найденных тестировщиками (по каждой группе багов). При обнаружении заказчиком багов сверх нормы премия тестировщиков уменьшается на определенный процент, меньше нормы – увеличивается. Как и в случае с разработчиками, процент зависит от критичности бага.
Кроме того, чтобы стимулировать некоторое соперничество между программистами и тестировщиками, мы ввели премии для тестировщиков за найденные баги сверх коридоров багов, установленных для проектов. То есть если нормальный коридор для проекта, скажем 6-8 багов, а тестировщики нашли 10, то проценты 2 бага зачисляются в премию команде.
Ситуация со временем на тестирование выглядит немного иначе, чем у программистов. У тестировщиков есть определенное количество дней на каждую неделю разработки. Предположим, на неделю разработки 1 день тестирования. То есть, на проект длительностью 5 недель назначается 5 дней на тестирование. Превышение, так же, как у программистов, снимает проценты с премии.Естественно, расчетные цифры в таблицах для всех будут свои. У кого-то принят высокий уровень фиксированной платы и невысокие премии, у кого-то премия составляет существенную часть оплаты труда. Возможно, распределение премии поквартально или помесячно. В таком случае учет ведется сразу по нескольким проектам. Я для статьи брал условные единицы, чтобы вычислить соотношения процентов от ошибок и сроков.
