«Тотальное управление качеством» (Total Quality Management), «Непрерывное улучшение рабочего процесса» (Continuous Process Improvement) или ISO — в большинстве современных терминов, касающихся качества процесса и продукта, акцент ставится на стремлении к качеству в масштабах всего предприятия и солидные инвестиции с долгосрочной перспективой. Продуманные схемы для оценки и повышения «зрелости процесса», такие как общеизвестная модель развития функциональных возможностей (Capability Maturity Model), разработанная Институтом разработки программного обеспечения (Software Engineering Institute), могут быть весьма полезны. Однако применение подобных моделей может потребовать много ресурсов (Humphrey, Snyder, Willis, 1991 [41]) и привести к непредусмотренным последствиям (Bollinger и McGowan, 1991 [5]). Для получения наибольшей, долговременной отдачи могут понадобиться программы для значительной реструктуризации и обеспечения всестороннего качества. Однако даже небольшие практические шаги будут способствовать быстрому и ощутимому улучшению качества программного обеспечения и эффективности самого проекта.

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

Первые шаги зачастую оказываются самыми важными, а первым шагом в улучшении качества является правильное определение приоритетов. Для улучшения качества продукта и процесса его создания само качество должно стать приоритетом. Если для вас и для организации в целом оно не важно, а стремление к нему не проявляется в действиях руководства, то качество не будет важным критерием и для разработчиков. Все это не означает плакаты с надписями «Качество — наша первая задача!» или напоминания работникам о необходимости стремиться к отсутствию ошибок, Здесь наиболее важно то, что вы делаете, а не то, что говорите.

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

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

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

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

Механизм расходования средств требует обоснования, однако анализировать нужно не только затраты, представляющие только одну часть уравнения, но и прибыль от инвестиций. Например, австралийский консультант Роб Томсет (Rob Thomsett) показал, что одинаковую отдачу можно получить как от инвестирования в CASE-технологии, так и от вложений в формирование команды, однако конечная прибыль от инвестирования в командную работу будет на порядок больше. Тем не менее CASE — это яркая технология, которую можно показать, тогда как эффективная командная работа невидима, поэтому многие компании предпочитают тратить деньги на аппаратные и программные средства, а не на человеческий фактор (peopleware).

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

Проблема не в том, что люди не заботятся о качестве, как жалуются некоторые руководители. Исследование (1991 г.), проведенное компанией Brooks International и охватившее 11000 человек из 6 отраслей, показало, что более 90 % работников чувствовали личную ответственность за качественное выполнение работы. Однако семь человек из десяти заявили, что качество не было важным фактором в оценке их деятельности. И только 25 % опрошенных утверждали, что руководство действительно оценивало повышение качества. Так что же мы поощряем? На самом деле признание и поощрения любого рода намного более редки, чем думают большинство руководителей. Почти 80 % руководителей искренне утверждают, что их подчиненные получают достаточное поощрение, но только один из семи подчиненных соглашается с этим (Lickert, 1989 [48]).

Для улучшения качества необходимо воспользоваться принципом Фербе-ра (Ferber Principle). Психиатра Эндрю Фербера (Andrew Ferber) однажды спросили, что является самым важным для начинающих терапевтов, стремящихся помочь семьям, с которыми они работают. Он ответил:

Почти каждый слышал изречение, утверждающее, что нельзя контролировать то, что нельзя измерить (DeMarco, 1982 [32]). Часто такие слова оказываются прелюдией к активной кампании по запуску проекта, связанного с измерением параметров программного обеспечения или обеспечением статистического контроля качества. У формальных измерений есть множество преимуществ. Однако если на мгновение задуматься, то можно понять, что в жизни есть много важных вещей, которые родители, учителя, руководители контролируют, но не измеряют. Многое вообще нельзя измерить. Когда речь заходит о людях, то важным становится внимание, а не измерение. Значение имеет то, что вы контролируете. Любой хороший родитель знает: чем больше обращать внимание на капризы, тем больше будет капризов, У систем вообще и у человеческих систем в частности есть особенность, согласно которой само наблюдение изменяет предмет наблюдения. На этом основан хорошо известный эффект Хо-ворна (Hawthorne effect): если сделать группу объектом наблюдения и просто уделять больше внимания ее работе, это приведет к повышению производительности.

Безусловно, объект ваших наблюдений имеет значение, потому что именно на него и будет оказываться воздействие. Если оценивать программистов по краткости написанного кода, они будут производить меньшие по размеру системы. Если критерием является дружественность системы по отношению к пользователю, то вы получаете более удобные программы (Weinberg и Schulman, 1974 [66]).

В Австралии новый руководитель группы по разработке программ технического обслуживания захотел улучшить не только эффективность своей команды, но и ее статус и значение в компании. Для этого среди прочего он стал посылать основным программистам отчеты об ошибках, которые были обнаружены и исправлены в системах после их передачи «в производство». Программист мог получить записку, в которой просто сообщалось, что в минувшие выходные в системе произошел сбой и некорректное закрытие файла вывода, однако программист Куинфорп из отдела технического обслуживания обнаружил ошибку в цикле модуля Z091, который был исправлен, перекомпилирован и протестирован за 1,6 часа.

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

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

Обратная связь — это важный ингредиент. Когда работники получают информацию о собственной производительности и ее связи с организационными целями, качество повышается. Это основа открытой модели руководства, в которой работники получают не только отчеты о производстве и ошибках, но и финансовую информацию о затратах, статьях расходов и прибылей (Саве, 1990 [6]; Finegan, 1990 [36]). Обладая такой информацией, работники проще оптимизируют распределение времени и улучшают собственные рабочие процессы. Ключом здесь является обратная связь, которая объединяет индивидуальную и командную производительность с общей финансовой картиной. Работникам известны не только выявленные ошибки и время, затраченное на программирование, но и общая стоимость работ, и получаемая в результате выгода (или убыток) с точки зре-

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

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

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

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

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

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

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

Ведение детального протокола всех трудностей — изъянов, упущений, жалоб потребителей, изменений дизайна, ошибок в анализе, «улучшений» при бета-тестировании — является важным шагом. Другой шаг заключается в регулярном и методичном изучении всех неполадок. Это означает, что в каждом проекте необходимо предусматривать время для методичных размышлений. Если мы не изучаем свои ошибки и не учимся на них, то как мы сможем избежать их в будущем?

Для улучшения качества особенно важно никогда не путать оппозицию и критику с нелояльностью.

Зачастую именно противоположный взгляд или критическое рассмотрение дает самую ценную информацию о возможностях улучшения процесса. На самом деле качество решения задач в чрезвычайной степени зависит от наличия критики. Группы, в которых есть «свой критик» или «спорщик», а также группы, практикующие диалектические процессы столкновения идей и активной критики, работают с большей производительностью (Constantine, 1989 [11]; Priem и Price, 1991 [59]).

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

В названии одной известной песни 60-х годов можно найти действенный принцип улучшения качества:

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

Опыт показывает, что качество программного обеспечения можно значительно улучшить, если просто увеличить объем работы, выполняемой лицом к лицу (глава 26). Когда двое или более людей вместе работают над одной задачей, качество повышается. Как правило, повышение видимости рабочего процесса повышает его качество. Почему? В принципе, для того чтобы два программиста, вместе создающие программу, внесли ошибку или отступили от стандартов и правил, они должны сговориться об этом. Однако заметить ошибку или отступление от правил может и один человек. Забудьте о том, что вы слышали про «групповое мышление» или коллективную посредственность. Все эти эффекты существуют, но они зависят от определенных условий. Групповые лидеры могут легко способствовать улучшению качества решения задач и избежанию недостатков группового мышления. Для этого лидерам любых групп достаточно просто воздерживаться от выражения своего собственного мнения или откладывать его на какое-то время (Anderson и Balzer, 1991 [2]).

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

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

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

Этот принцип является важнейшим компонентом метода «чистого» (clean room) программирования. С помощью этого подхода были созданы некоторые средние и крупные системы, которые практически не содержали ошибок (Cobb и Mills, 1990 [8]). В этой модели один человек или группа пишет код, стараясь «все сделать правильно». Еще кто-нибудь выполняет компиляцию и тестирование, стараясь обнаружить ошибки и погрешности. В этой модели есть и другие приемы, но даже простое разделение обязанностей само по себе может повысить качество. Знание того, что кто-то другой в команде не только просматривает код, но и занимается компиляцией и тестированием, повышает ответственность и побуждает принимать правильные решения с первого раза.

Десятилетия исследований и практический опыт показали нам, что по продуктивности лучшие программисты зачастую на порядок отличаются от худших и в два раза от средних программистов (DeMarco и Lister, 1987 [33]).

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

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

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

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

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

Разработчики должны непосредственно участвовать в определении сроков поставки продукта и стадий исполнения проекта. Определение сроков следует рассматривать как переговоры, в ходе которых могут быть найдены компромиссы. «Да, проект можно сдать к концу года, если вас устраивает 15 ошибок на каждую тысячу строк. Либо мы можем пообещать более низкую частоту ошибок, если вы согласны вдвое сократить количество экранов».

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

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

По материалам журнала American Programmer, февраль 1992 г.