Статья © 2007 Alex Papadimoulis, Оригинал называется Worse Than Failure.

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

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

Давайте вспомним The Customer-friendly System или Used by the Tool Или еще какую-нибудь уродскую систему из тех, что здесь публиковались. Для создания таких извращений в них нужно знать толк. Они требуют глубоких знаний технологии и соответствующего опыта. Так чего ради человек с такой квалификацией создает ужасную систему? Очень просто. Потому что он не останавливается на провале. Он идет дальше.

Что такое провал?

Как говорят, на ошибках учатся. Это справедливо для всего, от шахмат («ты не становишься лучшим игроком, выигрывая») до бизнеса («провал — это часть успеха»). Правда, при этом забывают упомянуть, что для того, чтобы вынести уроки из поражения, нужно сначала поражение признать. В большинстве случаев («Шах! Мат!» или банкротство) оно очевидно. Но в информационных технологиях — не всегда.

Как говорится в исследовании CHAOS Report от Standish Group по вопросам успешности, «84% всех проектов провальны или сомнительны». Эти выводы совершенно противоречат здравому смыслу, который нам диктует, что большинство проектов либо в целом успешные, или, может, преодолевают некоторые трудности.

Хорошо или плохо (на самом деле, конечно, плохо), но когда проект запустился в коммерческую эксплуатацию и основные проблемы в нем вычищены, празднуется победа! Кропотливая работа в поте лица, жертвенные выходные в офисе — и мы, наконец, видим плоды нашего труда, проект запустился, ура! И еще до того, как пора делать посмертное вскрытие на самом деле неудачного проекта, уже пора двигать следующий! Горькие, как всякая правда, аргументы против изначально плохого дизайна и кривых хаков постепенно забываются, и проект остается в памяти большинства людей как «в целом успешный». Вот именно! Для тех, кто разрабатывал The Customer Friendly System, этот проект был успешным!

Важно это понять. Те, кто проектировал и разрабатывал The Customer Friendly System, продукта, который берет диаграммы Visio как исходник для компиляции в код системы документооборота, они-то ведь считают свой продукт успешным. Это значит, что полученный в этом проекте опыт они будут тиражировать снова и снова. В конце концов, из ниточек более раннего опыта и плетутся системы, подобные этой.

Что такое успех? Что угодно

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

Мы с вами работаем в практически единственной индустрии, где завершение и успех — это синонимы. Если фундамент год назад построенного дома треснул, а крыша протекает, кто-то назовет это успешным проектом? Несмотря на хороший бюджет, разве есть хоть кто-то, кому было бы не стыдно иметь Gigli² в своей фильмографии? Разумеется, нет. Так почему же мы иначе подходим к оценке создаваемых нами сложных информационных систем, срок жизни которых должен составлять не менее пятнадцати лет?

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

Рецепт неудачи

Итак, что же остается? Нам что же, ждать окончания срока эксплуатации системы, чтобы в конце-концов обоснованно назвать ее успешной? Да, именно так. Однако провальный проект мы можем распознать значительно раньше. Но только если мы на самом деле готовы признать свое поражение.

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

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

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

Как пойти по пути страшнее-провалов

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

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

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

Тьма и свет в конце туннеля

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

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

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

28 февраля 2007г., Алекс Пападимулис

---

¹ Игра слов. Сайт раньше назывался «The Daily WTF», где «WTF» — это популярное сокращение от «What's the F*ck?», что переводится примерно как «какого черта?». Новое название «Worse Than Failure» также сокращается в «WTF» — прим. пер.

² Gigli — рекордно провальный голливудский фильм с известными актерами. При бюджете в $54 млн кассовые сборы в мировом прокате составили $7 млн. Фильм был снят с кинотеатров через три недели, а в Англии буквально после первых же сеансов. Подробнее здесь — прим. пер.