Психбольница в руках пациентов - [29]
Закон Паркинсона
Руководителям известно, что разработка программного обеспечения подчиняется закону Паркинсона: работа увеличивается в объеме, занимая любое отведенное под нее время. Если вы заняты в бизнесе программного обеспечения, то, вероятно, знакомы со следствием закона Паркинсона, известным в качестве правила Девяносто-Девяносто (авторство приписывается Тому Каргилу из Веll Labs):
«Первые 90% кода отнимают первые 90% времени разработки. Оставшиеся 10% кода отнимают вторые 90% времени разработки».
Иными словами, это самоуничижительное правило гласит, что когда программисты написали 90% кода, они все еще не знают, где находятся! Руководство отлично понимает, что успеть сдать работу вовремя нельзя, какие сроки сдачи ни устанавливай. Разработчики же лучше всего работают под давлением, поэтому руководство использует дату сдачи, как одно из средств давления.
В восьмидесятые и девяностые годы Ройял Фаррос был вице-президентом небольшой, но влиятельной компании Т/Maker, где руководил разработкой. Вот его слова:
«Многие из нас устанавливали сроки сдачи заведомо невозможные, причем настолько, что делали верным одно из следствий закона Паркинсона: «Для завершения проекта требуется в два раза больше времени, чем было отведено». Я твердо верил, что если выделить под проект шесть месяцев, он займет год. Так что если необходимо было получить что-то через два года, следовало требовать сдачи через год. Тупое принуждение, конечно, но оно всегда срабатывало».
Когда предприниматель от программного обеспечения Риджели Эверс работал в Intuit над созданием QuickBooks, он столкнулся с той же проблемой.
«Выпуск первой версии QuickBooks должен был занять девять месяцев. Мы правильно оценили, что начальное развитие будет длиться столько же, сколько длится беременность, но все-таки ошиблись: у нас ушло почти два с половиной года – срок беременности слона».
Архитектор программного обеспечения Скотт Мак-Грегор указывает, что закон Грешема – плохая валюта вытесняет хорошую – также имеет силу в этом контексте. Когда на рынке сосуществует пара валют, люди создают запасы сильной валюты и стараются тратить слабую. В конечном итоге это приводит к преобладанию слабой валюты. Так и некачественные оценки завершения проекта вытесняют реальные прогнозы. Когда все делают радужные, но взятые с потолка прогнозы, руководитель, выдающий реалистические и более долгие сроки, производит впечатление, будто специально занимается саботажем. Такой руководитель подвергнется давлению, будет вынужден занизить свои оценки.
Сроки сдачи в некоторых проектах неразумны по причине произвольности. Рациональные руководители в большинстве своем по-прежнему склонны устанавливать сроки хотя и физически возможные, но возможные лишь ценой больших жертв. Пилот самолета, по аналогии, может заявить: «Успеем в Чикаго вовремя, но багаж придется выбросить!» Мне приходилось видеть, как руководители разработки приносят в жертву не только проектирование, но и тестирование, применимость, функции, интеграцию, документацию и даже реальность. Большинство руководителей разработки продуктов, с которыми мне приходилось работать, предпочтут выбросить на рынок неработоспособный продукт, но не опоздать со сдачей этого продукта.
Продукт, вечно не готовый к выпуску
Часто причиной этому служит глубочайший страх каждого, кто руководит разработкой программного обеспечения: если продукт опаздывает, он вообще никогда не будет выпущен. Нет сомнения в правдивости историй о продуктах, которым так и не суждено было увидеть свет. Проект опаздывает сначала на год, потом на два, а потом, на третьем году жизни, его мстительно подвергают эвтаназии руководители высшего звена или члены директората. Это объясняет неистовую приверженность к фиксированным срокам сдачи, пусть даже ценой жизнеспособности продукта.
Для примера – в конце девяностых годов в широко разрекламированной начинающей компании Worlds, Inc. масса умных и способных людей работали над созданием сетевого виртуального мира, где люди, посредством своих аватар, могли бы путешествовать и общаться с другими людьми в реальном времени. Продукт никогда не имел четкого определения или описания, и после растраты десятков миллионов инвестированных долларов члены правления компании милосердно прекратили эту агонию.
В начале девяностых другая начинающая компания, Nomadic Computing, потратила около 15 миллионов долларов, пытаясь создать новый продукт для мобильных деловых людей. К сожалению, никто в этой компании не знал точно, что это за продукт. Все было ясно с рыночной нишей продукта, и были известны возможности программы, однако не было четкого понимания целей потенциальных пользователей. Словно безумные скульпторы, обтесывающие гигантский мраморный камень в надежде обнаружить внутри статую, разработчики писали невероятные объемы бесполезного кода, который в конечном итоге просто выбросили, вместе с деньгами, временем, репутацией и карьерами. Самая же печальная потеря в этой истории – потеря возможности создать востребованную программу.
