Закон Паркинсона

Руководители знают, что разработка программного обеспечения идет в соответствии с законом Паркинсона: работа заполняет все время, отпущенное на нее, увеличиваясь в объеме. Если вы работаете в сфере разработки ПО, то вам, скорее всего, известно и следствие из этого закона, которое называют «правилом 90/90» (автором этого правила считают Тома Каргилла из Веll Labs): «Первые 90 % кода занимают первые 90 % времени разработки. Остальные 10 % кода занимают вторые 90 % времени разработки». Это уничижительное правило просто-напросто говорит, что даже в тот момент, когда первые 90 % кода написаны, программистам по-прежнему неизвестно, в какой стадии находится проект! Руководство прекрасно знает, что сдать проект в срок не получится, какие бы сроки ни были установлены. А учитывая то, что программисты наиболее продуктивно работают под давлением, руководители применяют дедлайн как один из рычагов воздействия на них.

В 1980-е и 1990-е годы вице-президентом по разработке в небольшой, но достаточно влиятельной компании под названием Т/Maker был Ройял Фаррос. Он говорил так: «Многие из нас устанавливали настолько жесткие дедлайны, что в них было заведомо невозможно уложиться. Такая ситуация лишний раз подтверждала одно из следствий закона Паркинсона: „Этап завершения проекта разработки требует в два раза больше времени, чем планировалось“. Я пребывал в твердом убеждении, что, если установить дедлайн, например, через шесть месяцев, на самом деле это займет год. Таким образом, если нужно было получить продукт через два года, дедлайн надо было устанавливать на один год. Такие сроки просто огорошивали, но метод срабатывал всегда».

Риджли Эверс, предприниматель в сфере разработки программного обеспечения, работая в Intuit над созданием QuickBooks, наблюдал ту же проблему. «Первая версия QuickBooks должна была выйти спустя девять месяцев. Мы правильно решили, что период разработки будет длиться столько же, сколько беременность, правда, кое в чем слегка ошиблись: срок подготовки проекта составил почти два с половиной года – как беременность слона».

Скотт Макгрегор, архитектор программного обеспечения, отмечает, что в такой ситуации применим также закон Грешема, гласящий: «Худшие деньги вытесняют из обращения лучшие». Если на рынке присутствует две валюты, то более сильную люди хранят, а тратят более слабую. В результате это выливается в то, что в обращении преимущественно остается слабая валюта. Аналогичным образом недостоверная оценка сроков реализации проекта вытесняет реалистичные прогнозы. Если все только и занимаются тем, что делают слишком оптимистичные прогнозы, взятые «с потолка», то руководитель, который пытается предлагать более долгие, но вместе с тем приближенные к реальности сроки, выглядит так, будто умышленно саботирует процесс разработки. В конечном счете на него будет оказано давление, и ему придется скорректировать свою оценку ситуации в сторону уменьшения времени работы над проектом.

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

Продукт, который не выйдет никогда

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

Так, в конце 1990-х годов один громко разрекламированный стартап Worlds, Inc., команда которого состояла из множества умных и способных специалистов, работал над созданием виртуального онлайн-мира, где аватары людей могли бы перемещаться по виртуальному пространству и вовлекать других аватаров в общение в реальном времени. У продукта никогда не было полного определения или описания, и после того, как на этот проект были спущены десятки миллионов долларов инвестиций, руководство стартапа благоразумно свернуло эту затею.

В начале 1990-х годов еще один стартап Nomadic Computing потратил почти 15 миллионов долларов на попытку создать новый продукт для бизнесменов, обладающих высокой степенью мобильности. К несчастью, ни один человек в компании не мог точно сказать, что это за продукт. Команда понимала, на какой рыночный сегмент она ориентируется и каким функционалом должен обладать продукт, но не имела ясной картины о целях потенциальных пользователей. Как безумный скульптор откалывает кусок за куском от мраморной глыбы, надеясь обнаружить внутри статую, так и программисты писали внушительные объемы кода, по сути своей бесполезного, который затем просто выкидывали вместе с деньгами, временем, репутацией и своей карьерой. Самой же обескураживающей потерей была упущенная возможность сделать по-настоящему желанный для пользователя продукт.

Не удалось избежать такой напасти даже корпорации Microsoft. Впервые попытавшись создать программное обеспечение для управления базами данных в конце 1980-х годов, компания затратила на это множество человеко-лет, и завершился этот проект тем, что Билл Гейтс просто-напросто милосердно его закрыл. Ударной волной прошла эта преждевременная кончина проекта по сообществу разработчиков. Последовавший за ним программный продукт Access стал совершенно новой попыткой, над которой работала другая команда разработчиков и другие руководители.