Авторы книги «Образцы не для подражания: кризис программного обеспечения, архитектур, проектов» (AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis) убеждены в том, что «очень крупные проекты — бесполезная трата сил»

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

Выход программы из строя — неприятность, которая может случиться с каждым, и этим она страшна. Специализированные и не очень издания постоянно пичкают нас историями об успешных проектах, сводками о победном шествии новой экономики, отчетами, в которых доказывается, что распространение Internet по своим последствиям сопоставимо с изобретением Гутенбергом печатного станка. Нам редко приходится слышать об обратной стороне медали. А ведь сотни тысяч программных проектов ежегодно заканчиваются провалом!

Производителей программного обеспечения и ИТ-специалистов не обвинишь в страстном желании поведать миру о своих неудачах, и отчасти поэтому мы так мало знаем об их бесплодно потраченных усилиях. Однако частота неудач не может не внушать тревогу. Действительно, по оценкам The Wall Street Journal, более 50% от общего числа корпоративных программных проектов не оправдывают возложенных надежд, причем работы над 42% прекращаются задолго до их логического завершения.

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

Но стоит ли сравнивать падение большого, дорогого космического корабля и маленького, скромного Web-сайта, ведь в последнем случае на кон поставлены лишь наши рабочие места и репутация?

С учетом финансовых и временных ресурсов, выделяемых на программные проекты, кажется странным, что «дырки» в программах столь нередки. Этот феномен можно объяснить постоянно повторяющимся возникновением ошибок, типичных для разработчиков и менеджеров.

Не усложняй задачу

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

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

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

Сохраняй разумный консерватизм

Филипп Райлз из компании Gemstone Associates обращает внимание на следующее обстоятельство: программисты, недавно окончившие колледж, еще не успели привыкнуть «к реальному миру бюджетов и сроков», и это может повлечь за собой вполне определенные проблемы.

В отличие от строителей и автомехаников, во главу угла ставящих практичность, программисты — люди веселые и находчивые. Их любопытство и радикализм зачастую влекут за собой использование новейшего, самого модного решения, даже если старая версия работает более надежно. Стивен Флауэр, автор книги «Ошибка в программе: ошибка управления» (Software Failure: Management Failure) называет это «соблазном лидерства».

Для сравнения: новейшей технологией в строительстве считается дрель без шнура питания. Рабочие, пользующиеся таким инструментом, могут лучше сконцентрироваться на своей работе.

Не впадай в беспочвенный оптимизм

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

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

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

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

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

Не меняй своих намерений

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

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

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

По правде говоря, программисты любят, когда меняются требования. Вам когда-нибудь приходилось, приехав в автосервис, чтобы заменить зажим за 8 долл., услышать от автомеханика, что без новой трансмиссии за 1700 долл. автомобиль не тронется с места? Вот-вот! Даже если трансмиссия совсем никуда не годится, зажим вы поменяете гораздо охотнее.

Чтобы приспособиться к изменениям конъюнктуры рынка, вам приходится использовать гибкое программное обеспечение. Постарайтесь, однако, управлять изменениями с умом. И обязательно объясните клиентам, к чему может привести изменение требований в ходе реализации проекта.

Ничего не упускай из виду

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

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

Чтобы избежать «потери элементов», менеджеры должны заказывать проверенные разработки у надежных поставщиков, а также следить за тем, чтобы члены коллектива хотя бы частично дублировали друг друга.

Не перегибай палку

Опыт подсказывает, что успешность проекта находится в обратно пропорциональной зависимости от его размера. Исследование Standish Group показало, что проекты стоимостью менее 750 тыс. долл. оказываются успешны в 55% случаев, стоимостью от 1 до 2 млн. долл. — в 18%, а от 5 до 10 млн. — всего в 7% случаев.

Авторы книги «Образцы не для подражания: кризис ПО, архитектур, проектов» (AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis) убеждены в том, что «очень крупные проекты — бесполезная трата сил».

Провалившаяся программа американского налогового управления по модернизации налоговой системы стоимостью 4 млрд. долл. в 90-х годах — яркий пример, подтверждающий эту тенденцию. Модернизация налоговой системы потерпела фиаско потому, что был избран путь «больших потрясений», в рамках которого предполагалось создать новую гигантскую информационную систему, интегрирующую множество разрозненных и устаревших систем.

Не отрицай недостатки

В книге «Смертельный марш» (Death March) Эд Йордон анализирует несколько конкретных неудачных проектов по созданию программного обеспечения, которые он и называет «маршами смерти». Проект превращается в «марш смерти», если каких-либо ресурсов изначально не хватает на 50% или больше. Либо сроки в два раза урезаны, либо народу в два раза меньше, чем нужно, либо бюджет выделен в размере 50% от необходимого, либо объем работ вдвое больше.

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

Практика, получившая распространение в строительстве и машиностроении, несколько иная: каждая авария должна стать предметом расследования, результаты которого предаются гласности. И слава богу! Если бы мосты рушились, а лифты выходили из строя так же часто, как программы, нам бы вряд ли удалось по этому поводу дискутировать.