«Зачем беспокоиться о том, чего не произойдёт?»

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

За двадцать лет мировые траты на ИТ в расчёте на доллары 2025 года увеличились втрое, с 1,7 триллиона до 5,6 триллиона, и продолжают расти. Несмотря на дополнительные траты, показатели успеха за эти годы повысились незначительно. Из-за этого потери бизнесов и общества становятся всё серьёзнее, ведь ПО проникает во всё большее количество аспектов нашей жизни.

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

Как я говорил двадцать лет назад, причинами краха проектов часто становятся крах человеческого воображения, нереалистичные или несформулированные цели проектов, неспособность справиться со сложностью проекта или неучтённые риски. Всё это регулярно приводит к ИТ-катастрофам и сегодня. Существует и множество других причин, часть которых выявил глава кафедры бизнес-технологий Школы бизнеса Университета Виллановы Стефен Андриоле; его диаграмма, показанная ниже, впервые была опубликована в Forbes в 2021 году. Было бы крайне удивительно обнаружить проект, потерпевший крах каким-то уникальным, незадокументированным ранее образом, потому что подавляющее большинство таких неудач вызваны вполне преодолимыми факторами, за десятки лет изложенными в сотнях отчётов, научных исследований, технических книг и учебников по управлению. Читая литературу о таких катастрофах, часто испытываешь дежавю.

Возникает вопрос: почему же мы не применяем все те знания, которые постоянно вынуждены усваивать?

Феникс, не восставший из пепла

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

Руководители проекта Phoenix считали, что смогут реализовать модернизированную систему оплаты труда, модернизировав стандартную программу расчёта зарплаты PeopleSoft так, чтобы она соблюдала 80 тысяч правил расчёта 105 коллективных договоров с профсоюзами федеральных государственных служб. Также эта система пыталась реализовать в 101 правительственной организации и департаменте 34 интерфейса кадровых систем, необходимых для обмена данными о сотрудниках. Кроме того, привлечённая правительством команда разработчиков считала, что сможет выполнить эту задачу меньше, чем за 60 процентов от бюджета, предложенного поставщиком пакета. Разработчики планировали сэкономить, удалив критичные функции расчёта зарплаты или отложив их реализацию, снизив объём системного и интеграционного тестирования, уменьшив количество участвующих в проекте подрядчиков и государственных служащих и отказавшись от обязательного пилотного тестирования, а также предложив ещё кучу чрезмерно оптимистичных улучшений.

Провал Phoenix был предрешён. В результате него за последние девять лет примерно 70% из 430 тысяч нынешних и бывших сотрудников федерального правительства Канады, получавших зарплату через Phoenix, столкнулись с ошибками расчётов. Даже в 2023–2024 фискальном году с ошибками расчёта зарплаты столкнулось около трети служащих. Степень финансового стресса и тревоги у тысяч сотрудников и их семей невозможно измерить. Повторяющиеся проблемы с начислением зарплаты не только снижают моральный дух сотрудников, но и как минимум в одном задокументированном случае стали причиной суицида сотрудницы вследствие финансовой и эмоциональной нагрузки.

К концу марта 2025 года канадское правительство обещало расчистить бэклог ошибок Phoenix, но на тот момент более 349 тысяч проблем по-прежнему оставались нерешёнными, причём 53% из них тянулись уже больше года. В июне правительство ещё раз пообещало существенно сократить бэклог к июню 2026 года. Учитывая предыдущие обещания, можно испытывать обоснованный скептицизм.

Финансовые затраты канадских налогоплательщиков, связанные с Phoenix, тем временем превысили 5,1 миллиарда канадских долларов (3,6 миллиарда долларов США). Для вычисления окончательной цены этого фиаско понадобятся ещё годы. Прежде чем принять решение о замене Phoenix, правительство потратило не менее 100 миллионов канадских долларов; по его расчётам, замена будет стоить много сотен миллионов долларов, а для её реализации потребуются годы. В отчёте Главного аудитора Канады Майкла Фергюсона, фиаско проекта Phoenix названо «непостижимым провалом руководства проектом и надзора за ним».

Если его и можно назвать катастрофой руководства и надзора, «непостижимым» этот провал Phoenix определённо не был. ИТ-сообщество десятки лет превращало это в обыденность.

Худшая катастрофа в ИТ

Провал проекта Phoenix тускнеет по сравнению с худшей за всю историю катастрофой ИТ-системы: системой приёма безналичных платежей (EPOS) британской Post Office, разработанной компанией Fujitsu. Выпущенная 1999 году Horizon кишела внутренними программными ошибками, которые намеренно скрывались, из-за чего Post Office ошибочно обвинила 3,5 тысячи руководителей местных почтовых отделений в составлении ложных отчётов, мошенничестве и краже. С 1999 по 2015 год примерно 900 из этих руководителей было осуждено, а 236 помещено в тюрьму. Наконец, общественность и руководители отделений присоединились к репортёрам Computer Weekly (упорно сообщавшим о проблемах Horizon с 2008 года) во мнении о том, что ПО Horizon имело серьёзные недочёты. Чтобы выявить масштабы скандала, потребовался ещё десяток лет судебных дел, независимое публичное юридическое расследование и мини-сериал «Мистер Бейтс против почты».

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

Высшее руководство Post Office многократно утверждало, что ПО Horizon полностью надёжно, враждебно реагировало на сомнения руководителей отделений, нагнетая ситуацию. В конечном итоге, руководство использовало все имеющиеся в его распоряжении юридические рычаги и реализовало первоклассную операцию прикрытия, в том числе активно скрывая свидетельства невиновности, чтобы Post Office могла агрессивно преследовать руководителей отделений и подавлять любые сомнения в качестве Horizon.

Потрясает то, что ошибочно обвинённым по-прежнему приходится бороться за получение справедливой компенсации за разрушенные жизни. Почти 350 из обвинённых людей умерло; считается, что не менее 13 из них покончили жизнь самоубийством, так и не получив финансовую компенсацию за проявленную к ним несправедливость. К сожалению, попытки заменить Horizon в 2016 и 2021 годах закончились неудачей, и Post Office продолжает её использовать. Правительство хочет потратить 410 миллионов фунтов на новую систему, но можно с уверенностью сказать, что её реализация будет стоить гораздо больше. Летом 2025 года Post Office открыла тендер на создание новой программной системы безналичных платежей; ожидается, что решение будет принято 1 июля 2026 года.

Система лицензирования и регистрации Миннесоты

2019 год

В 2016 году штат Миннесота начал реализацию проекта Minnesota Licensing and Registration System (MNLARS) с расчётной стоимостью 41 миллион долларов. Работы были прекращены в 2019 году, когда суммарная стоимость достигла 100 миллионов. Было признано, что систему слишком сложно починить.

Потери от катастроф проектов ПО продолжают накапливаться

В США общий рост стоимости провалов, связанных с разработкой и эксплуатацией ПО ИТ, c 2005 года тоже вырос до многотриллионного уровня, потенциально превысив 10 триллионов долларов. Согласно отчёту Consortium for Information & Software Quality (CISQ), приблизительная ежегодная стоимость эксплуатационных отказов ПО в США в одном лишь 2022 году составила 1,81 триллиона, и ещё 260 миллиардов было потеряно из-за провалов разработки ПО. Это больше, чем общий оборонный бюджет США в том же году (778 миллиардов).

Возникает вопрос: почему же мы не учимся на тех ошибках, которые многократно повторяем?

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

Австралия модернизирует программу ведения торгового реестра

2022 год

Австралия прекратила программу по модернизации своих систем ведения торгового реестра, запланированная стоимость которой составляла 480,5 миллиона австралийских долларов. После того, как было потрачено 530 миллионов, проверка показала, что проецируемые затраты взлетели до 2,8 миллиарда австралийских долларов, а для завершения проекта понадобится ещё пять лет.

Согласно отчёту CISQ, организации США ежегодно тратят более 520 миллиардов долларов на поддержку легаси-систем, и 70-75% организационных ИТ-бюджетов выделено на легаси-обслуживание. Отчёт за 2024 год компании NTT DATA гласит, что 80% организаций допускают, что «неадекватные или устаревшие технологии сдерживают организационный прогресс и инновации». Кроме того, в отчёте говорится, что практически всё руководство высшего уровня считает, что легаси-инфраструктура препятствует способности компаний реагировать на изменения рынка. Но даже при всём при этом, учитывая то, что затраты на замену легаси-систем обычно во много раз превышают затраты на их поддержку, руководство не торопится менять их до тех пор, пока это не перестаёт быть возможно эксплуатационно или с точки зрения стоимости. Ещё одна причина заключается в обоснованных опасениях того, что процесс замены приведёт к провалу наподобие катастрофы Phoenix или других проектов.

Тем не менее, предпринимаются попытки улучшения процессов разработки и поддержки ПО. Например, всё чаще применяются итеративные и инкрементальные стратегии разработки и поддержки программных систем при помощи Agile, методик DevOps и других связанных с ними практик.

Департамент транспортных средств Луизианы

2025 год

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

Заявленная цель — предоставить конечным пользователям в максимально короткий срок работоспособное, надёжное и доступное по стоимости ПО. DevOps стремится к реализации этой цели на протяжении всего срока жизни ПО. Хоть Agile и DevOps продемонстрировали свой успех во многих организациях, с ними связана и своя доля разногласий и недоверия. Провокативные отчёты утверждают, что частота провалов Agile-проектов составляет до 65%, а в других говорится, что до 90% инициатив DevOps не оправдывают ожиданий организаций.

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

Упорствование в глупых заблуждениях

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

ИТ-сообщество упрямо отказывается учиться на прошлых ошибках. Менеджеры ИТ-проектов постоянно заявляют, что их проект чем-то отличается или даже уникален, поэтому выводы из предыдущих провалов к нему неприменимы. Это оправдание обычно вызвано не невежеством. Например, Phoenix был второй попыткой замены правительственной системы расчёта зарплат; первая закончилась провалом в 1995 году. Менеджеры проекта Phoenix проигнорировали тщательно задокументированные причины первого провала, заявив, что уроки первого проекта к ним не относятся, поэтому ничто не помешало их повторить. Как уже было сказано, мы больше учимся на неудачах, чем на успехах, но многократные неудачи обходятся чертовски дорого.

Jaguar Land Rover

2025 год

Из-за кибератаки крупнейшая автомобильная компания Британии Jaguar Land Rover была вынуждена более чем на месяц прекратить свои международные операции. По первоначальной оценке модели затрат на кибербезопасность FAIR-MAM, потери Jaguar Land Rover составили приблизительно от 1,2 до 1,9 миллиарда долларов (от 911 миллионов до 1,4 миллиарда фунтов), при этом инцидент затронул 33 тысячи сотрудников компании и примерно 200 тысяч сотрудников её поставщиков.

Не все провалы в разработке ПО плохи, некоторые даже полезны. В процессе исследования новых типов программных продуктов, технологий или практик, как это происходит сейчас в ИИ-проектах, потенциальный провал — вполне приемлемый риск. С каждой неудачей нарабатывается опыт, появляются новые идеи, вносятся исправления, лучше осознаются ограничения, а технологические инновации и прогресс движутся дальше. Однако большинство провалов в сфере ИТ сегодня связано не с инновационными фронтирами, а с пограничными случаями повседневных задач. Они представляют собой не «бури созидательного разрушения», в формулировке австрийского экономиста Йозефа Шумпетера, а больше похожи на бури финансового разрушения. Сколько ещё нужно провалов проектов систем ERP, чтобы успех стал чем-то обыденным? Подобные провалы следует называть просчётами, потому что из них вряд ли можно извлечь какие-то новые уроки.

Чем был Phoenix: неудачей или просчётом? Я считаю, что вторым, но, как минимум, Phoenix можно считать мастер-классом плохого управления ИТ-проекто��. Вопрос в том, научилось ли канадское правительство на этом опыте чему-то большему, чем на опыте фиаско реализации проекта 1995 года? Правительство утверждает, что выводы будут сделаны, и, возможно, это так, учитывая большой политический вес Phoenix. Но будут ли уроки Phoenix применены в случае тысяч устаревших канадских правительственных ИТ-систем, нуждающихся в замене или модернизации? Будем надеяться. Но надежда — это не методология, для этого потребуются осознанные целенаправленные действия.

Многократное повторение одних и тех же ошибок в надежде на другой результат — это не обучение, а фарс и абсурдность. Перефразируя цитату Генри Петроски из книги «To Engineer Is Human: The Role of Failure in Successful Design» (Vintage, 1992 год), можно сказать, что мы научились рассчитывать провалы ПО по причине риска, но пока не научились устранять сбои, связанные с сознанием. Существует множество примеров проектов наподобие Phoenix, провалы которых были отчасти связаны с неумелым руководством, однако крайне сложно найти программные проекты с профессиональным управлением, которые тем не менее потерпели провал.

Последствия отказа от учёбы на ошибках будут становиться ещё более масштабными и коварными, когда обществу придётся бороться с нарастающим влиянием искусственного интеллекта, а точнее «интеллектуальных» алгоритмов, встроенных в программные системы. Намёки на то, что может происходить, если уроки прошлого останутся без внимания, можно найти во впечатляющем провале одной из первых систем автоматизированного принятия решений Мичиганской системы обработки заявок на пособие по безработице MiDAS и систем получения выплат австралийской компании Centrelink. В обеих использовались сомнительные алгоритмы выявления мошеннических заявок без человеческого контроля. Из-за MiDAS служащие штата обвинили десятки тысяч жителей Мичигана в мошенничестве с пособиями, а представители Centrelink ложно обвинили сотни тысяч австралийцев в том, что они обманом получили социальные выплаты. Нельзя даже определить, судьбу скольких людей изменили такие обвинения. Правительственные служащие Мичигана и Австралии слишком доверились этим алгоритмам. Их пришлось долго вынуждать признаться в совершённых ошибках, даже когда было чётко доказано, что ПО ненадёжно. Но и после этого официальные представители пытались преуменьшить влияние ошибок на людей; они упорно старались избежать выплаты компенсаций пострадавшим.

ERP сети супермаркетов Lidl

2017 год

Международная сеть супермаркетов Lidl решила вернуться к своей легаси-системе управления товарами после трёхлетних попыток реализации работы ERP-системы SAP стоимостью 500 миллионов евро.

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

Что потребуется для того, чтобы снизить количество просчётов в ИТ? За последние двадцать лет особых подвижек в этой сфере не произошло. Финансовые мотивы выпуска дефектного ПО, зависимость ИТ-отрасли от failure porn и отсутствие ответственности за глупые решения руководства глубоко укоренились в сообществе ИТ. Кто-то говорит, что пора писать законы об ответственности за ПО, другие же возражают, что ИТ-специалисты должны лицензироваться, как и все остальные специалисты. Но ни того, ни другого в ближайшее время не случится.

Boeing 737 Max

2018 год

Boeing внедрила в новую модель самолёта 737 Max некачественно спроектированную и задокументированную систему Maneuvering Characteristics Augmentation System (MCAS), что привело к двум авиакатастрофам с 346 жертвами среди пассажиров и экипажа и запрету на полёты в течение примерно двадцати месяцев. По оценкам, общий урон для Boeing составил 14 миллиардов долларов прямых затрат и 60 миллиардов косвенных.

Мы, как специалисты и члены общества, обязаны сделать упор на очевидном: перед тем, как браться за создание ИТ-системы, нужно понять, что мы знаем, что мы должны знать, и насколько велик разрыв между этими категориями. Если никто никогда не создавал вашу систему успешно в рамках заданного графика, бюджета и функциональности, то требуется объяснение, почему, по мнению организации, она справится с этим в данном случае. Программное обеспечение невероятно хрупкое; создание комплексных, безопасных и надёжных программных систем — это сложный, детализированный и длительный процесс. Крошечные ошибки способны иметь огромное влияние, которое может проявляться почти бесконечным количеством способов, от незначительной функциональной ошибки до аварии системы или проникновения в систему угрозы кибербезопасности. Чем сложнее и взаимосвязаннее система, тем больше вероятностей ошибок и их использования в злоумышленных целях. Высшему руководству, имеющему контроль над финансами, наконец-то стоит начать воспринимать разработку, эксплуатацию и поддержку ПО и систем с тем вниманием, которого они заслуживают. Для этого нужно не только предоставить все человеческие и финансовые ресурсы, а также поддержку руководства, но и требуемую ответственность специалистов и персонала.

F-35 Joint Strike Fighter

2025 год

Не прекращаются программные и аппаратные проблемы обновления F-35 Block 4. Начавшаяся в 2018 году программа обновления Block 4, целью которой стало повышение эффективности самолёта JSF, передвинула свои сроки завершения с 2026 года до как минимум 2031 года, а её цена возросла с 10,5 миллиарда долларов до минимум 16,5 миллиарда. Для реализации всех возможностей флота F-35 потребуются ещё годы.

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

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

Наконец, при оценке соотношения затрат и выгод проектов по разработке ПО редко учитывается финансовая и эмоциональная нагрузка, которой подвергаются конечные пользователи ИТ-систем в случае возникновения ошибок, в том числе и долговременных последствий неудач. Если бы подобные затраты принимались в расчёт в случае Phoenix, MiDAS и Centrelink, то, вероятно, оценки финансовых, технологических и эмпирических затрат по созданию успешной программной системы были более реалистичными. Возможно, этот призыв будет бесплодным, но ИТ-сообщество определённо должно перестать многократно повторять одни и те же смехотворные ошибки, которые оно совершает как минимум с 1968 года, когда появилось понятие «кризис ПО». Пора бы начать совершать новые ошибки, чёрт побери. Как сказал древнеримский оратор Цицерон в двенадцатой филиппике, «Заблуждаться может каждый, упорствовать в заблуждении — только безумец».