Введение

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

• Как определить, когда продукт достаточно хорош?
• Если продукт еще недостаточно хорош, как сообщить это знание заинтересованным лицам?

Ответ на первый вопрос позволяет выпустить продукт. Ответ на второй вопрос позволяет избежать выпуска плохого продукта.

Разработчик может рассуждать следующим образом: "Я не хочу выпустить не просто хороший продукт - я хочу выпустить превосходный продукт!" Взглянем на эту ситуацию поближе. Что происходит, когда вы говорите своим коллегам, руководителям и инвесторам, что у вас высочайшие стандарты качества и вы планируете выпустить превосходный продукт? Если это происходит в начале проекта, все кивают и улыбаются. Все любят высокое качество. Однако если речь об этом заходит в конце проекта, разработчик находится под давлением различных обстоятельств, обусловливающих сдачу проекта. Для создания превосходного продукта может требоваться обширное тестирование, устранение большого количества неполадок (даже малозначительных), добавление новых функций и даже удаление и повторная разработка отдельных частей кода. Кроме того, нужно будет разрешать разногласия по поводу того, какое качество считается хорошим. Создание превосходного продукта - очень непростая задача. А создание безупречного продукта - задача еще сложнее! Рано или поздно те, кто отвечают за проект, подойдут к вам и скажут: "Безупречность - это прекрасно, но мы должны жить в реальном мире. Мы занимаемся бизнесом. Нам важно качество, но не качество любой ценой. Вы сами знаете, что во всех программах есть ошибки".

Создание превосходного продукта - это благородная цель. Ее достижение - повод гордиться своей работой. Однако сложность в том, что одной только фразы "если высокое качество хорошо, то еще более высокое качество еще лучше" недостаточно для оправдания погони за совершенством. Во-первых, в свете подобных рассуждений вы будете выглядеть как фанатик качества, а не рациональный аналитик. Во-вторых, в подобных рассуждениях не учитывается фактор стоимости. BMW - превосходный автомобиль, но он стоит гораздо дороже Сатурна. Сатурн, может быть, и не самый лучший автомобиль в плане вождения, но это хороший выбор за свои деньги. Без учета стоимости аргумент больше - лучше плох тем, что не принимает во внимание снижение окупаемости инвестиций. Чем лучше ваш продукт, тем сложнее оправдать его дальнейшее улучшение. Пока вы занимаетесь ювелирной отделкой одного из аспектов продукта, вы вынуждены игнорировать другие аспекты этого продукта или даже потенциальные возможности, связанные с другими проектами. Коммерческие организации каждый день должны решать вопрос о том, как наиболее эффективно использовать свои ресурсы. Поэтому помимо качества нужно учитывать и другие факторы.

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

Парадигмы понятия достаточности

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

Ниже приведены примеры апробированных моделей концепции достаточно хорошего. Эффективность этих моделей зависит от конкретной ситуации:

• Не слишком плохо ("мы еще живы") - нам достаточно минимального качества, при котором наша продукция позволяет нам продолжать вести бизнес. Сделаем ее достаточно хорошей для того, чтобы нас не засудили.
  
  
• Положительная непогрешимость ("все что мы делаем - прекрасно") - наша компания лучшая в мире. Поскольку мы настолько хороши, все, что мы делаем, хорошо по определению. Думайте об успехе. Не думайте о неудаче, потому что "негативное" мышление способствует снижению качества.
  
  
• Благородное изнеможение ("или совершенство, или ничего") - никакой продукт недостаточно хорош, важны не результаты, а усилия. Только наше полное изнеможение может служить критерием хорошей работы. Экономическая целесообразность - не наша забота. Мы сделаем все возможное для того, чтобы сделать продукт совершенным. А поскольку мы никогда не закончим усовершенствование, кто-то рано или поздно должен будет прийти и выпытать продукт у нас, если он им так нужен. И тогда они будут отвечать за проблемы с качеством, а не мы.
  
  
• Клиент всегда прав ("это нравится клиентам") - если это нравится клиентам, значит, с качеством все в порядке. Конечно, нельзя сделать счастливыми сразу всех. И если нашему текущему или будущему клиенту не понравится наш продукт, они должны рассказать нам об этом. Мы не умеем читать мысли.
  
  
• Определенный процесс ("у нас правильный процесс") - высокое качество является следствием процесса, которому мы следуем при создании продукта. Мы разработали свой процесс и мы считаем, что он хорош. Поэтому пока мы соблюдаем процесс, мы неизбежно создаем хорошие продукты.
  
  
• Статические требования ("мы выполняем требования") - мы создали определение качества как совокупности объективных, количественных, непротиворечивых целей. Если мы достигнем этих целей, мы получим достаточно хороший продукт, независимо от каких бы то ни было иных субъективных, неколичественных и сомнительных целей.
  
  
• Соблюдение обязательств ("мы выполняем свои обещания") - понятие качества закреплено в контракте. Мы обязуемся сделать определенные вещи и достигнуть определенных целей. Поэтому нам достаточно выполнить условия контракта.
  
  
• Защита ("мы сделали все возможное") - мы за качество. На протяжении всего проекта мы ищем способы препятствовать возникновению новых неполадок, а также находить и устранять те, возникновению которых не удалось воспрепятствовать. Если мы честно будем стремиться к совершенству, этого будет достаточно.
  
  
• Динамический баланс ("мы взвешиваем много факторов") - с учетом нашей задачи и текущей ситуации, мы считаем продукт достаточно хорошим тогда, когда он обладает достаточными преимуществами, в нем отсутствуют существенные неполадки, его преимущества перевешивают его незначительные недоработки, и продолжение его улучшения скорее навредит, чем принесет пользу.
  
  

Обязательно ли достижение высокого качества сопряжено с дополнительными затратами?

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

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

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

Не поможет ли количественная оценка?

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

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

Дополнительная информация

Для помощи в оценке качества продукта большинство рабочих продуктов, входящих в состав RUP, снабжено следующими видами информации:

• Контрольные списки и рекомендации по рабочим продуктам: информация о разработке, оценке и использованию рабочих продуктов.
• Шаблоны: модели или прототипы рабочих продуктов с информацией о структуре материалов и рекомендациями по их применению.

Дополнительные сведения приведены в разделах Технология: Измерение качества и Концепция: Артефакты, рекомендации по артефактам и контрольные точки.