Автор: Джерри Вайнберг (Jerry Weinberg)
Оригинал статьи: Tea-Time With Testers, #03/2021
Перевод: Ольга Алифанова

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

Филипп Б. Кросби.

То, что Кросби говорит про бизнес в целом – безусловная истина для бизнеса по разработке ПО. Сегодня мы поговорим о крупных группах паттернов, или субкультур, ПО, и увяжем их с работой Кросби, резюме которой он приводит в «Матрице зрелости управления качеством».

Применение идей Кросби к ПО

Те, кто читал «Качество бесплатно», заметят, как схожи мои взгляды на качество в целом со взглядами Кросби. В частности, они заметят, что мы согласны в том, что критическим фактором всегда будут «задействованные люди, их мотивация, их реакции». Немногим, однако, удалось успешно приложить подход Кросби к разработке ПО. Это связано с тем, что, как я уже говорил,

1. Не существует двух в точности похожих организаций.
2. Не существует двух абсолютно различных организаций.

Я изменил подход Кросби, чтобы учесть различия, и поэтому нужно пояснить области, в которых мой подход к качеству ПО отличается от подхода Кросби.

Соответствовать требованиям недостаточно

Кросби очень явно определяет качество, как «соответствие требованиям».

«Если Кадиллак удовлетворяет всем требованиям к Кадиллаку, то это качественная машина.

Если Пинто удовлетворяет всем требованиям к Пинто, то это качественная машина».

Отличное определение – если все требования верны. Я не эксперт в производстве, поэтому не могу сказать, часто ли требования на производстве бывают ясными и точными.

Однако я эксперт по разработке ПО, и могу безусловно заявить, что требования к ПО редко бывают близки к правильным. Если покупатель хотел Пинто, а вы создали машину, удовлетворяющую всем требованиям к Кадиллаку – это некачественная машина.

Многие авторы книг про качество ПО упускают из вида, что разработка ПО – это не производственная операция. Она включает производственную операцию – распространение ПО после его разработки. Конечно, некоторые из моих клиентов успешно применяли определения Кросби и его подход, чтобы произвести точные копии готового ПО. Распространение ПО, однако, далеко не самая сложная часть процесса разработки.

Некоторые процессы, задействованные в разработке ПО – это производственные операции, а некоторые схожи с производством по ряду аспектов. Для них, безусловно, можно применять подход Кросби с целью достичь высокого качества.

Следовательно, для разработки ПО определение качества нуждается в генерализации:

Качество – это ценность для некоторого лица (лиц).

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

Отсутствие дефектов в большинстве проектов недостижимо

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

Однако я работаю в разработке ПО и консалтинге 35 лет, и никогда не видел, чтобы работа над требованиями хотя бы приблизилась к «нулю дефектов». Если вы изучите проекты по разработке ПО, утверждающие, что добились этого, то обнаружите, что они всегда начинались с утвержденных задокументированных требований – например:

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

Следовательно, в обозримом будущем большинству из нас придется управлять разработкой ПО в «грязном» окружении, где истинность требований под вопросом. Игнорирование этой реальности – это игра в страуса, а не в менеджера по управлению качеством ПО.

«Экономика качества» существует

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

И снова все основано на допущении, что перед стартом проекта на руках есть правильный набор требований. Если требования верны, то решать, что тут позолота, а что важный элемент – не задача менеджера разработки. Требования раз и навсегда отвечают на этот вопрос. Если существует лишь один правильный способ, нет смысла говорить об «экономике качества». Как совершенно верно говорит Кросби, «Всегда дешевле сделать всё правильно с первого раза».

Однако в ситуации, когда ценности потребителя неизвестны – или, что еще хуже, когда неизвестны сами потребители, - мы не знаем, в чем заключается «всё», которое нам нужно сделать. Мы можем сделать всё правильно, но обнаружить, что сделали неправильное «всё». Поэтому процесс работы с требованиями может создать или уничтожить ценность, и поэтому экономика качества – реальность для любого процесса разработки ПО, где есть процесс работы с требованиями.

Эта «экономика качества требований», безусловно, борется за то, чтобы с первого раза добиться правильных требований. Если вы на это способны – бога ради, пользуйтесь этим подходом. Однако если это невозможно, то политика/эмоции в ходе обсуждения требований (качества) проникнут в ваш проект и сильно его затруднят.

Любой паттерн может быть успешным

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

«Не трогайте программу!»

Или, еще консервативнее:

«Не трогайте процесс (разработки ПО)!»

Над этим поведением часто смеются, но в нем есть экономический смысл. Если способ, которым производится и поддерживается ПО, вас полностью устраивает, не работайте над его изменением; работайте над его поддержкой. Если ваши пользователи счастливы, глупо меняться.

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

Но если ваш паттерн в корне неверен, то попытка улучшить его маленькими порциями схожа с созданием все более и более детальных карт для путешествия не в ту сторону. Если вам нужно попасть из Майами в Кливленд, подробные карты центра Лос-Анжелеса не просто бесполезны – вы зря тратите на них время.

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

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

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

Зрелость – неподходящее слово

Когда рассуждаешь о культурах, так и тянет нарядиться в судейскую мантию. Скажем, иногда людям трудно поверить, что любая субкультура ПО может быть успешной. Как свиньи в «Скотном дворе» Оруэлла, они принимают на веру, что «Все животные созданы равными», а затем добавляют «…, но некоторые равнее других». «Любая культура ПО может быть успешной», - соглашаются они, - «но некоторые успешнее других».

Чаще всего личные оценки прокрадываются незаметно. Кросби, к примеру, описывает пять различных паттернов управления качеством в своей «Матрице зрелости управления качеством». Матрица – потрясающе полезный инструмент, но лучше было бы просто назвать ее «Матрицей управления качеством». Слово «Зрелость» - это оценка, не факт, а интерпретация фактов. Как минимум, она не подходит к фактам. Зрелость, как правило, движется в одном направлении, но Кросби дает ряд примеров компаний, «откатывающихся назад», как в этой цитате:

«Мы были Просветлены (одна из стадий «зрелости») несколько лет, а затем получили нового генерального директора, считающего, что качество – это слишком дорого. Нам нужно вернуться на стадию-другую назад, пока он не достигнет просветления».

В обычном языке «зрелый» - значит «достигший нормального пика естественного роста и развития». В движении по стадиям Кросби нет ничего особенно «естественного». И Кросби тратит много сил, делая акцент на огромной работе, необходимой для перехода от одной стадии к другой.

Более того, мне знакомо множество организаций, занимающихся разработкой ПО, которые достигли «нормального пика» - то есть они собираются оставаться там, где они находятся, если не случится ничего экстраординарного. Они достаточно хороши, и инвестиции в переход на другой паттерн не соответствуют ни одной организационной цели. Как мы уже видели, культурные паттерны не различаются по большей или меньшей зрелости – они просто больше или меньше подходят к конкретной ситуации. Конечно, ряд людей испытывает эмоциональную нужду в «совершенстве», и они будут навязывать эту нужду всем, с кем столкнутся. Однако это не имеет отношения к проблемам организации – это связано лишь с их собственными проблемами:

Стремление к ненужному совершенству – это не зрелость, а инфантильность.

Гитлер довольно четко объяснял, что такое «высшая раса». Его «арийская» раса должна была представлять собой зрелый конечный продукт всей истории человечества, что позволило Гитлеру обосновать любые зверства в отношении «менее зрелых культур» - цыган, католиков, евреев, поляков, чехов и всех, кто встал у него на пути. Многие псевдо-реформаторы разработки ПО начинают работу с требования, чтобы «цель» признала свою прошлую неполноценность. Эти «крошки-Гитлеры» не добились особенных успехов.

Крайне небольшое количество здоровых людей добровольно признается в чем-то подобном, и даже концентрационные лагеря не смогли изменить точку зрения людей. Это не «просто слова». Слова важны для любых перемен, потому что они дают нам модель мира – такого, каким он был, и такого, каким мы хотим его видеть. Если ваша цель – изменить организацию, начните с отказа от сравнений – даже неявных, скрытых в сложном слове «зрелость».

Шесть паттернов субкультуры ПО

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

Наблюдения Кросби – это то, чем мы, консультанты организаций, постоянно пользуемся – это применение «Обратного базиса Боулдинга», который гласит:

Все таково, каково оно есть, потому что таким оно было сделано.

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

1. Неуверенность.
2. Пробуждение.
3. Просветление.
4. Мудрость.
5. Уверенность.

В основном они основаны на отношении менеджмента, характерном для каждого из них.

Рэдис и другие авторы в статье «Изучение процесса программирования» адаптировали «стратификацию по качеству» Кросби, приложив ее к разработке ПО. Уоттс Хамфри в книге «Управление процессом разработки» подхватил их знамя, выявив пять уровней «процессной зрелости», через которые проходит организация, разрабатывающая ПО, в ходе своего роста.

Эти паттерны называются так:

1. Начальная.
2. Повторяющаяся.
3. Определенная.
4. Управляемая.
5. Оптимизированная.

Эти имена связаны с типами процессов в каждом паттерне, а не с отношением менеджмента.

Другие наблюдатели быстро отметили полезность уровней зрелости Хамфри. Билл Кёртис, к примеру, заметил, что можно провести параллельную классификацию просто на основании обращения с людьми внутри компании. Он предложил «модель зрелости управления человеческими ресурсами в разработке ПО», в которой пять уровней:

1. Выпас стада.
2. Управление.
3. Адаптация.
4. Институционализация.
5. Оптимизация.

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

1. Неведение. «Мы даже не знаем, что выполняем некий процесс».
2. Вариативность. «Мы делаем то, что нам хочется делать в этот момент».
3. Рутина. «Мы следуем нашим рутинам (кроме случаев, когда паникуем)».
4. Управление. «Мы выбираем одну из рутин по результатам, которые она даст».
5. Предвкушение. «Мы устанавливаем рутины на основании прошлого опыта работы с ними».
6. Конгруэнтность. «Все непрерывно включены в процесс улучшения всего».

Эту классификацию мы далее будем применять для описания организаций.

Продолжение следует.

Обсудить в форуме