[Перевод] Адаптируем 4 абсолютных принципа качества Кросби в контексте разработки ПО
У Филиппа Кросби заслуженная репутация лидера в вопросах качества в обрабатывающей промышленности, он написал множество книг о качестве в период с 1968 по 1999 год. Среди его известных и цитируемых работ — «Качество бесплатно», «Ноль дефектов с помощью предотвращения» и »4 абсолютных принципа качества». Хотя Кросби говорил об этих темах в контексте компаний с производственными линиями, его уроки часто без изменений можно перенести на разработку ПО.
После участия в Твиттере во многих обсуждениях работ Кросби и прочтения некоторых его книг, я написал эту статью, чтобы передать на более глубоком уровне мои мысли о »4 абсолютных принципах качества» Кросби из его книги «Качество бесплатно». По моему мнению, эти четыре принципа поддерживают дискуссии о концепции отсутствия дефектов и качестве без затрат.
Примечание: у Кросби много хороших работ! Эта заметка не критикует его творчество. Она подчёркивает, как я использовал идеи Кросби и применил их в контексте моей работы с программным обеспечением. Вы можете согласиться со мной, а можете не согласиться. И это нормально. Я лишь делюсь своими знаниями и взглядом на мир качества в моём представлении.
Четыре абсолютных принципа качества
Качество определяется как соответствие требованиям.
Способ обеспечения качества — предотвращение, а не оценка.
Стандартом работы должно быть Отсутствие Дефектов.
Мера качества — цена несоответствия, а не индексы.
Я прошу пока не думать об этих принципах с точки зрения разработки ПО. Подумайте о них в первую очередь с точки зрения производства оборудования, поскольку они формулировались в этом контексте.
Во время работы в сфере производства оборудования, при тестировании оборудования, прошивок, и ПО для производителя принтеров, мне довелось побывать в заводском цехе, увидев производственные линии своими глазами. Это позволило мне понять, что означают «обеспечение качества» и «контроль качества» в этом контексте. Эти термины также были перенесены в сферу разработки ПО, но, по моему мнению, они не очень хорошо подходят к контексту создания программных продуктов. Аналогично, в моём текущем контексте, в компании Photobox также есть значительная доля конвейерного производства: люди используют Photobox для заказа печатных подарков, например, фотоальбомов, фотографий, распечаток на холсте, календарей, кружек, открыток, чехлов для телефонов, пазлов и множества других товаров. Наши производственные линии впечатляют: в высоком темпе на продуктах печатаются тысячи изображений, их заботливо упаковывают в грамотно спроектированную упаковку, и после этого они готовы к отправке нашим покупателям, которые скоро увидят свои самые счастливые моменты на выбранных ими предметах.
Если рассматривать 4 абсолютных принципа с точки зрения производственной линии, то они покажутся разумными. Но я говорю не о проектировании оборудования или концепции аппаратного продукта, а о производственной линии. Речь идёт о создании физических продуктов по набору спецификаций, которые соответствуют строго заданному шаблону и перед упаковкой собираются заданным способом. Физические товары каждый раз выходят с линии одинаковыми, снова и снова, произведенные по очень строгой спецификации, и каждый созданный продукт должен ей соответствовать. Тогда качество производства можно рассматривать как соответствие каждого выпущенного товара требуемому эталону. Любое отклонение от эталона будет считаться дефектом. И контроль качества — проверка части партии с целью поиска «дефектов» (т.е. «несоответствия» заданной спецификации) — это способ выявления отклонений и получения обратной связи, касающейся производственной линии, будь то сбои в работе оборудования, ошибки работников, слишком быстрое движение конвейера и т.д.
Общая идея подразумевает, что качество — это «точность» в контексте оборудования. На производственных линиях, цель которых — создавать одни и те же продукты снова и снова одним и тем же способом, «точность» — это один из основных рассматриваемых параметров. Из четырёх абсолютных принципов пункты 1, 3 и 4 имеют смысл в этом контексте.
Пункт 2 имеет смысл с точки зрения проектирования процессов работы производственной линии.
Исправлять ошибки производства очень дорого. Обнаружение дефектов до отправки заказчику может показаться успехом, но нужно учитывать стоимость материалов и времени, требуемых для перезапуска производственной линии ради исправления дефекта и перевыпуска продукции с решёнными проблемами. Поэтому максимально возможные меры по недопущению дефектов кажутся хорошей стратегией на производстве.
Но что насчёт разработки ПО? Просто перенести эти 4 абсолютных принципа не получится. Разработка — это не описание продукта для запуска линии по производству одинаковых товаров и отправки их покупателям. Разработка гораздо динамичнее. Разработка — это задача на «подумать», а не на «сделать». Это набор загадок.
Мы можем попробовать описать нужды и пожелания заказчика, но при создании программного продукта у разработчика есть сотни способов написать код с применением множества различных инструментов. К тому же сложность создания программных продуктов распространяется и на пользователей, и на заказчиков. Их пожелания и нужды субъективны и относительны. Они различны для каждого пользователя.
В том, как они используют ПО, есть сотни различий. Какие у них данные, когда и где они запускают ПО и как с ним работают — всё это в конечном итоге означает возникновение для продукта сотен видов рисков, затрагивающих уровень удовлетворённости пользователя при работе с ПО.
В случае «железа» у продуктов обычно задана понятная цель. Скажем, наушники разрабатываются так, чтобы быть на ушах или в ушах для приватной передачи звуковой информации. Кружка создана для того, чтобы наливать в неё горячие или холодные напитки, и имеет ручку, подходящую под левую и правую руку, чтобы можно было её держать. Мониторы созданы для отображения информации, переданной с компьютера или другого устройства, они превращают эту информацию в пиксели, которые формируют изображение.
Все эти предметы созданы с конкретной целью, и люди используют их для достижения этой цели. Да, с ними может поставляться программное обеспечение и прошивки. Но это ПО и прошивки не создаются таким же образом, как производится оборудование.
Рассмотрим 4 абсолютных принципа с точки зрения ПО:
Качество определяется как соответствие требованиям.
Способ обеспечения качества — предотвращение, а не оценка.
Стандартом работы должно быть Отсутствие Дефектов.
Мера качества — цена несоответствия, а не индексы.
Абсолютный принцип №1: Качество определяется как соответствие требованиям
Принцип не работает в контексте разработки ПО. Да, требования важны, ведь у заказчика есть нужды и пожелания. Всегда ожидается, что разработка будет вестись с их учётом. Но из-за сложности ПО и множества вариантов создания и использования возникают неопределённости, включая те, о которых мы ещё даже не подозреваем. Неожиданности, которые выходят за рамки описанных требований… Так что утверждать, будто качество — это соответствие требованиям, означает упустить общую картину работы с ПО, включающую как требования, так и фактическое его применение, основанное на наличии или отсутствии навыков работы с ПО у пользователя.
Мне просто кажется это неправильным. ПО — это не про «точность». Ваша программа может работать в полном соответствии требованиям, но при этом быть абсолютно ужасной в использовании из-за неучтённых факторов, влияющих на впечатление пользователей. Качество ПО должно рассматриваться в более широкой перспективе, связанной с «добротностью». Нужно обращать внимание не только на описанные требования, но и на риски продукта и исследование неизвестных; определять, испытывает ли пользователь восторг или отчаяние. То есть оценивать, насколько хорошо (или плохо) работается с программой.
Абсолютный принцип №2: Способ обеспечения качества — предотвращение, а не оценка
На мой взгляд, предотвращение — значительная часть мер по обеспечению качества ПО. Можно тестировать саму идею программного решения, а также артефактов и набросков UX/UI-дизайна, архитектуры и кода. Выявленная информация покажет множество видов рисков, переменных, перспектив, неясностей, свойств, целей, неизвестных и т.д.
Эта информация определённо приведёт к улучшению решений, в частности, поможет написать код лучше и предотвратить многие из рисков до того, как они проявятся в виде проблем с ПО. Принятие во внимание рисков и неизвестных величин делает предотвращение дефектов возможным, и исследовательское тестирование — лучший способ найти и подсветить эти потенциальные проблемы на ранних этапах жизненного цикла ПО, ещё до написания кода.
Однако нужно понимать, что нельзя учесть каждый риск и каждую переменную. Все мы люди. Незнание по-прежнему играет роль: существуют факторы, о которых мы так и не узнаем, а значит нельзя предусмотреть и предупредить все проблемы с помощью более качественного проектирования. Предотвращение дефектов — одна из способов повышения качества ПО. И значит исследовательское тестирование необходимо для проверки написанного кода и работающего ПО. Результаты тестирования на этих этапах больше связаны с обнаружением проблем. Да, на этом этапе жизненного цикла ПО мы также обнаруживаем и риски, но в таком случае мы можем дополнительно исследовать их и определить, являются ли они настоящими проблемами.
Абсолютный принцип №3: Стандартом работы должно быть Отсутствие Дефектов
Если поразмышлять о психологии неизвестного и учесть, что существуют факторы, о которых мы вообще не знаем (а значит, и не можем их протестировать или спроектировать решение для них), то станет ясно, что это утверждение спорное.
На мой взгляд, «отсутствие дефектов» в контексте разработки ПО должно принимать другое значение — «отсутствие известных дефектов». То есть, если дефект (или проблема) обнаружены, значит, его следует устранить. Если знаешь о проблеме, то стремись её исправить. Но такая формулировка также учитывает, что невозможно предусмотреть всё на свете, всегда будут неизвестные факторы, которых мы не замечаем. Кроме того, если принято решение не исправлять баг, его следует просто закрыть.
Лично я предпочитаю рассматривать стандарты качества ПО с точки зрения рисков: обнаруженные риски, риски предотвращённые с помощью проектирования, исследованные риски, и риски, проявившиеся в проблемах. Оценка может быть качественной или количественной, но в итоге она даст картину нашей уверенности в воспринимаемом качестве.
Абсолютный принцип №4: Мера качества — цена несоответствия, а не индексы
У меня возникает ощущение, что это описывает проблемы, связанные с «точностью» (или, скорее, несовпадением между работой ПО и требованиями). Но, как я уже упоминал, помимо требований есть много других факторов. Тем более, что требования могут быть ошибочными или неправильно интерпретированными, если требование неоднозначное. Например, как в предложении: «На улице я столкнулся со служанкой графини, много лет жившей в доме неподалёку» — кто жил неподалёку? служанка? графиня? Предложение можно прочесть по-разному.
Повторюсь, для меня пункт №4 — лишь часть общей картины. Следует смотреть на степень соответствия/несоответствия требованиям, поскольку они задают набор ожиданий. Но в то же время нужно оценивать качество по шкале добротность/непригодность, смотреть на ПО и идеи программных решений со всех сторон, а не только с точки зрения требований.
Но определять качество ПО сложно. Как уже говорилось, программное обеспечение субъективно и относительно. А это означает, что и качество тоже субъективно и относительно. Как и баги/дефекты/проблемы. Так что любой способ измерения качества будет представлять точку зрения команды или человека, который исследует качество программы.
Ещё можно использовать данные, полученные пользователями ПО в контексте их собственной работы. Так мы получим представление о том, какое на самом деле у них впечатление от нашего ПО, и это замечательно! Однако, нужно учитывать, что такой подход создаёт риски для бизнеса в случае поставки ПО, о качестве которого нет предварительных данных, полученных до релиза. Программа может быть неприятна в использовании на самом базовом уровне, что приведёт к неудовольствию пользователей при работе с ней, и это может повлиять на вашу репутацию и прибыльность, если из-за этого пользователи предпочтут выбрать продукт конкурентов.
Я рекомендую использовать смешанный подход: нужно иметь данные о работе пользователя с ПО, но при этом получить собственное представление о качестве продукта.
По этим причинам я считаю, что 4 абсолютных принципа Филиппа Кросби не полностью подходят в контексте разработки ПО. Попытка применить их в этой области без адаптации и осмысления приведёт к неприятным последствиям, вызванным заблуждениями в сфере разработки ПО.
Моя версия абсолютных принципов качества для использования в контексте разработки ПО
Качество определяется как «точность» и «добротность» по отношению к ценности для заинтересованных сторон.
Способ обеспечения качества — предотвращение и обнаружение недостатков с последующим решением.
Один из стандартов работы — «отсутствие известных дефектов», и к нему добавляются «обнаружение рисков» и «снижение рисков».
Мера качества субъективна, относительна и индивидуальна, а значит связана с уверенностью в воспринимаемом о качестве
Завершая на позитивной ноте
Будучи поборником качества, Кросби многое сделал для обрабатывающей промышленности, поэтому я вставил его цитату, которая, на мой взгляд, важна и при разработке ПО, и в других отраслях.
«Качество — это результат тщательно созданной культурной среды. Она должна быть основой организации, а не её частью»
Эта цитата подчёркивает моё убеждение, что компании должны думать о качестве на уровне культуры организации, а не как о дополнении, о котором можно вспомнить уже после того, как что-то создано.
Какие у вас впечатления о «четырёх абсолютных принципах качества» Кросби? Что вы думаете об их применении в контексте разработки ПО?
Присоединяйтесь к дискуссии и комментируйте, но, пожалуйста, будьте уважительны друг к другу. Спасибо!
