Мы постоянно говорим о важности удовлетворенности пользователей. Есть две составные части в удовлетворенности пользователей. О первой мы уже говорил, это соответствие результатов проекта требованиям пользователей. Если вы потратили время на то, чтобы четко определить требования, ваш проект должен в результат дать именно то, что вы согласовали с пользователями. Вторая часть заключается в том, что требования должны быть корректными, это означает, что конечные результаты должны удовлетворять реальным нуждам пользователей (а не выдуманным).
Есть существенная разница между «должны иметь» и «хорошо бы иметь» в мире пользователей. Если вашему проекту не удается выдать результаты, удовлетворяющие требованиям, которые «должны иметься», проект будет восприниматься пользователем, как неуспешный (или полностью проваленный). Качество (ошибки, дефекты) и класс (функциональность) также очень тесно взаимосвязано в представлении пользователей. Класс через качество и требования пользователей определяет, как хорошо проект выполняет все требования.
Старая пословица гласит «сто грамм предотвращения стоит килограмма исправлений», это особенно справедливо, когда дело касается качества. Всегда проще и выгодней учитывать качество в проекте с самого его начала. Возвращаться назад после того, как проект уже в разгаре или, что еще хуже, определять качество с помощью тестовой процедуры в конце проекта, это самый неподходящий путь контроля качества. Гораздо меньше денег требует и меньше времени отнимает встраивание качества в проект с начала, чем возвращение и исправление сделанного после начала проекта (или даже перед его завершением). Система управления качество фокусируется на предотвращении проблем с качеством, а не на исправлении их. Мы обсудим стоимость качества более детально через минуту.