Ларри Константин - Человеческий фактор в программировании

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

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

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

Запомни, это все — данные

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

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

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

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

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

Поощряйте критику

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

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

Исправляйте процесс, а не только программу

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

Пусть светит солнце

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