OpenQuality.ru

Gerald Marvin (Jerry) Weinberg делится полувековым опытом в области психологии разработки ПО: стопроцентный сценарий возникновения проблем и надежный способ их избежать.

Во что обходятся провалы?

Часть перфекционистов в индустрии разработки ПО чрезмерно озабочена провалами, а большинство других не подвергают вдумчивому анализу ценность бесперебойной деятельности. Тем не менее, обычно при тщательной оценке стоимости провала мы видим, что повышение надежности программного обеспечения может принести огромную пользу. В книге “Responding to Significant Software Events” я представляю пять примеров, которые вас убедят.

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

Коммунальное предприятие изменяло алгоритм выставления счетов в соответствии с изменением ставки оплаты труда (эфвемизм коммунальщиков для “повышения тарифов”). Процедура сводилась к корректировке нескольких численных констант в существующей программе биллинга. Незначительная ошибка в одной константе приумножилась миллионами потребителей и вылилась в X долларов, безвозвратно потерянных предприятием. Я говорю “X долларов”, поскольку слышал эту историю от четырех разных клиентов с различными значениями X. Оценка потерь варьировалась от 42 миллионов до 1,1 миллиарда долларов. Учитывая, что такая история произошла с четырьмя моими клиентами, и лишь малая часть коммунальных компаний пользуется моими услугами, я уверен, что на самом деле такие случаи бывали намного чаще.

О следующем случае я узнал из общедоступной прессы, поэтому могу сказать, что речь идет о New York State Lottery. Законодательный орган штата Нью-Йорк разрешил проведение особой лотерии в целях сбора дополнительных средств на одно достойное дело. Поскольку эта лотерея отличалась от обычной лотереи, в программу для печати лотерейных билетов нужно было внести изменения. К счастью, модификация заключалась в изменении одной цифры в существующей программе. Крошечная ошибка привела к печати билетов-дубликатов, а общественное доверие к лотерее было подорвано и сопровождалось убытками, оцениваемыми в пределах между 44 и 55 миллионами долларов.

Другую историю я знаю со стороны, как клиент одной большой брокерской фирмы. Однажды фиктивная строка с 100.000$ была напечатана в сводках 1500000 аккаунтов, и никто не знал причин ее появления. Суммарная стоимость этого провала составила по меньшей мере 2000000 долларов, а причина заключалась в простейших ошибках при программировании на языке COBOL: не очищалась строка в зоне печати.

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

Сценарий Больших Провалов

В каждом из исследованных случаев события развивались согласно универсальному сценарию:

1.   Есть работающая система, которая считается надежной и архиважной

2.   Запрос на быстрое изменение в системе обычно исходит от высокопоставленного лица в организации.

3.   Изменение признается “тривиальным”.

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

5.   Изменение проводится без каких-либо мер предосторожности, типичных для разработки ПО и внедренных в организации (пусть в минимальном объеме).

6.   Изменение проводится непосредственно в системе, выполняющей повседневные операции.

7.   Точечный эффект от изменения невелик, поэтому никто не замечает его сразу.

8.   Этот скромный эффект приумножается многократными операциями и приводит к большим последствиям.

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

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

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

11.   Руководитель группы понижается в должности до программиста – наверное, вследствие продемонстрированного (не)понимания технических аспектов работы.

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

13.   Вышестоящие менеджеры остаются нетронутыми. В конце концов, что они могли сделать?

Первое Правило Предотвращения Провала

Осознав Универсальный Сценарий Гигантских Потерь, вы знаете как поступать в ответ на высказывания такого рода:

Когда вы слышите, как кто-нибудь считает нечто слишком маленьким и недостойным внимания, будьте начеку. Вот Первое Правило Предотвращения Провала:

Нет ничего слишком маленького, чтобы оно было недостойно внимания.

Все может быть иначе

Истории катастроф всегда служат хорошим предметом новостей, но наблюдение за ними может исказить реальность. Если мы рассматриваем только катастрофы в разработке ПО, мы упускаем все организации с эффективным управлением. Но хорошее управление так скучно! Не происходит ничего достойного публикации в прессе. Или почти ничего. К счастью, мы изредка встречаем согревающие душу истории, как, например, публикация в Financial World, рассказывающая о Чарлзе T. Фишере III из NBD Corporation, одном из титулованных CEO восьмидесятых:

“Когда компьютеры Comerica начали извергать ошибочные отчеты своим клиентам, Фишер ввел Контроль Гарантированной Производительности, обещая 10$ за каждую ошибку в месячном отчете клиента NBD. В течение двух месяцев корпорация NBD заявила о 15000 новых клиентов и более чем 32 миллионах долларов в новых аккаунтах.”

История умалчивает о том, что происходило в недрах департамента Информационных Систем, когда его сотрудники осознали, что их CEO Чарлз Т. Фишер III установил стоимость их работы. Я не присутствовал при этом, но могу предположить эффект от осознания того, что каждая непредотвращенная ошибка стоила бы 10$ наличными.

Второе Правило Предотвращения Провала

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

Потеря X долларов всегда является ответственностью управленца, чья финансовая ответственность превышает X долларов.

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

Конечно, я не думаю, что Чарлз Т. Фишер III или любой другой CEO приложит руку даже к одной цифре в программе на COBOL. Но я действительно надеюсь, что когда исполнительные директоры осознают ценнность бесперебойной деятельности, они совершат правильные управленческие поступки. И тогда это послание просочится на уровни, в которых можно что-то предпринять по его поводу – наряду с ресурсами для таких действий.

Учиться у других

Другой урок из этих историй: к моменту обнаружения провалов все будет слишком поздно. Будем надеяться, что ваш CEO прочитает о незащищенности в этих учебных примерах, а не в отчете о катастрофе в вашем офисе. Лучше найти способы предотвратить провалы до того как они выйдут из стен офиса.

Вот вопрос на проверку ваших познаний в разработке ПО:

Каков самый ранний, дешевый, легкий и наиболее практичный способ обнаружить провалы?

И вот ответ, который вы, возможно, не ожидали:

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

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

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

(По материалам книги Responding to Significant Software Events)
Оригинальная публикация: http://secretsofconsulting.blogspot.com/2011/01/universal-pattern-of-huge-software.html