Путь камикадзе
Как бы цинично или пессимистично
Как бы цинично или пессимистично ни звучало сказанное в этой главе, это не поможет избавиться от безнадежных проектов. Компании (как крупные, так и небольшие) переполнены политикой, там работают менеджеры и технические специалисты, страдающие безудержным оптимизмом и испытывающие полную гамму эмоций - страха, беззащитности, самонадеянности и жестокости. Сочетание таких факторов, как реинжиниринг, даунсайзинг, аутсорсинг и глобальная конкуренция - в совокупности с возможностями, предоставляемыми новыми технологиями, такими, как объектно-ориентированное программирование, клиент-сервер и Internet - приводит меня к выводу, что в ближайшие годы безнадежные проекты будут, вероятно, всеобщим явлением.
Это главное, что я хотел сказать в данной главе. Вы можете не соглашаться с некоторыми выводами, не принимать причины, порождающие такие проекты или побуждающие участвовать в них, но, тем не менее, это факт. Самое главное - это осознать и понять в самом начале безнадежного проекта свою собственную мотивацию с тем, чтобы вы могли принять взвешенное решение - участвовать в проекте или поискать другую работу. Поскольку многие из таких проектов начинаются в то время, когда корпорации переживают стрессовые ситуации, принимать взвешенные решения не так легко, как может показаться; гораздо легче попасть под влияние эмоций ваших друзей-коллег или менеджера.
Между прочим, все это не означает, что я против любых безнадежных проектов; я согласен с мнением моего коллеги Rick Zahniser, что такие проекты даже в случае неудачи могут дать очень полезный опыт:
Как я уже говорил тебе, я думаю, что каждый должен поучаствовать хотя бы в одном таком проекте. Тем не менее, есть и другие дела, по крайней мере одно из которых ты должен выполнить:
· провести ночь в тюрьме;
· напиться в стельку;
· вырастить сына;
· вырастить дочь;
· начать свой собственный бизнес;
· подняться на гору Фудзи.
(Японцы по этому поводу говорят: «Кому не удалось подняться на гору Фудзи - тот дурак. Тот, кто поднялся на гору Фудзи дважды - еще больший дурак».)
Что касается остальной части книги, я исхожу из предположения, что вы уже приняли обдуманное решение участвовать в проекте, хотя я время от времени буду напоминать вам о возможности выйти из него в процессе работы. Будем предполагать, что в данный момент ваша главная цель - добиться успеха, или, по крайней мере, спасти проект, и в последующих главах мы попробуем разобраться, как это можно сделать.
Литература к главе:
1. John Boddie. Crunch Mode. Englewood Cliffs, NJ: Yourdon Press/Prentice Hall, 1987.
2. Scott Adams. The Dilbert Principle. New York: HarperBusiness, 1996.
Сказанное в данной главе отнюдь не является каким-либо конкретным руководством по управлению, планированию или выполнению безнадежных проектов. Затронутые здесь проблемы достаточно сложным образом пронизывают многие аспекты нашей жизни. Даже если безнадежный проект будет следовать всем правилам, касающимся проектирования, кодирования и тестирования систем ПО, эти проблемы вполне могут похоронить его.
Итак, если мы уже идентифицировали ключевых игроков в проекте, определили категорию проекта и степень возможного участия в проекте каждого члена команды, то теперь самое время перейти к реальной работе над проектом. Она начинается с решения такой большой проблемы, как переговоры, которая будет обсуждаться в следующей главе.
Талантливых исполнителей, сплоченной команды и хороших условий для работы все же недостаточно, чтобы гарантировать успех безнадежного проекта. С другой стороны, их отсутствие почти наверняка гарантирует провал проекта. Как будет ясно из следующих двух глав, хорошо организованные процессы разработки и хорошая технология также являются важными составляющими успеха; однако, все же самая главная составляющая - это люди. Как сказал Рональд Рейган: «Окружите себя самыми лучшими людьми, которых вы только сможете найти, передайте им в руки власть и не мешайте им».
Литература к главе:
Tom DeMarco, Tim Lister. Peopleware. Dorset Publishing, 1987.
Frederick Herzberg. One More Time: How Do You Motivate Employees? Harvard Business Review, September-October 1987.
John Boddie. Crunch Mode. Englewood Cliffs: Prentice-Hall/Yourdon Press, 1987.
Rob Thomsett. Effective Project Teams: A Dilemma, a Model, a Solution. American Programmer, July-August 1990.
Дополнительная литература:
Larry Constantine. Constantine on Peopleware. Englewood Cliffs, NJ: Prentice Hall, 1995
Watts Humphrey. Managing for Innovating: Leading Technical People. New York: McGraw-Hill, 1987.
Gerald M. Weinberg. Understanding the Professional Programmer. New York: Dorset House, 1988.
Ken Whitaker. Managing Software Maniacs. New York: John Wiley & Sons, 1994.
Довольно легко оставить за бортом многие из тех идей, которые обсуждались в этой главе, и оказаться впоследствии в плену пустопорожней бюрократии. Однако, как отмечает Stephen Nesbit (я получил его сообщение как раз тогда, когда добрался до конца этой главы и не знал толком, как ее закончить):
Отсутствие стандартов и методологии само по себе может превратить проект в безнадежный. Например, в моем последнем проекте сжатый и нереальный план был использован в качестве предлога для того, чтобы отказаться от следующего:
1) Использования системы конфигурационного управления для контроля проектного исходного кода, сосредоточенного в трех различных компьютерных системах, расположенных в двух территориально удаленных местах. В результате значительное время было потеряно впустую в попытках:
а) осуществить сборку программного обеспечения;
б) определить, кому какая версия ПО принадлежит;
в) определить, почему ПО работает на одной системе и не работает на другой.
2) Регистрации узких мест и дефектов с помощью системы конфигурационного управления. В результате стало совершенно невозможно оперативно выяснить, какие ошибки устраняются, а какие проигнорированы; какие компоненты закончены и могут тестироваться.
3) Документальной фиксации основных требований, проектных решений и вариантов, узловых точек в процессе разработки и используемых тестов. В результате участникам проектной команды оказалось чрезвычайно трудно добиться взаимопонимания не только относительно текущего состояния проекта, но также и относительно основных решений, принятых в самом начале проекта.
Итак, пожалуйста, не надо воспринимать эту главу как предлог для отказа от каких-либо процессов, методологий или методов вообще; в самом деле, это может погубить безнадежный проект. Фокус заключается в том, чтобы отыскать те процессы, методологии или методы, которые действительно работают, и которым команда будет следовать естественным образом и бессознательно. Последнее особенно важно: команда испытывает такой стресс и давление, что должна делать многие вещи чисто инстинктивно.
Означает ли весь пессимизм данной главы, что вообще не следует использовать никакие средства? Может быть, просто выбросить всю эту технологию и вернуться к добрым старым клавишным перфораторам? Значит ли это, что технология в принципе не способна сослужить нам какую-либо добрую службу?
Риторический характер этих вопросов преследует цель напомнить, что во всех подобных дискуссиях на первом месте должен стоять здравый смысл. Когда звезды и планеты выстроятся в одну линию, может быть, технология действительно станет палочкой-выручалочкой по крайней мере для одного или двух безнадежных проектов. Определенно, следует использовать преимущества самых передовых технологий, поскольку они способны усилить наш интеллект и освободить от решения рутинных задач, связанных с разработкой ПО.
В лучшем из всех миров разработчики ПО будут иметь возможность изучать, экспериментировать и практиковаться в работе с мощными средствами без какого-либо риска; естественно, в лучшем случае эти средства уже развернуты во всей организации и являются частью ее культуры и инфраструктуры. В этом случае нет необходимости затевать какие-либо дискуссии по поводу средств и технологий вообще; остается только взять средства - и вперед в безнадежный проект.
Причина обсуждения в данной главе - и причина того, что все это имеет самое непосредственное отношение к большинству безнадежных проектов - заключается в том, что организация использует заурядные средства, или кто-либо верит, что совершенно новая с виду технология, с восторгом объявленная только на прошлой неделе начинающим поставщиком, может каким-то образом спасти дело. Первый сценарий приводит в уныние, однако он достаточно распространен; второй сценарий тоже достаточно распространен по той простой причине, что технологии в нашей области распространяются быстро и неумолимо.
Если бы внедрение новой технологии не оказывало никакого влияния на наши процессы, и не требовало специального обучения и практики, то мы могли бы принять решение, основываясь всего лишь на сопоставлении затрат и выгод.
Как неоднократно отмечалось на протяжении всей книги, безнадежные проекты становятся неизбежными для сегодняшнего мира бизнеса с его высокой конкуренцией и хаотичностью. Некоторые организации осознали этот факт и стараются в соответствии с этим разумно спланировать свою деятельность. Тем не менее, история развития индустрии ПО за последние 40 лет говорит о том, что большинство организаций извлекают не слишком много уроков из своего опыта, и склонны воспринимать каждый новый безнадежный проект как нечто уникальное. Даже тем организациям, которые поняли, что безнадежные проекты не являются более делом случая, придется испытать серьезные трудности, поскольку бюрократия будет продолжать цепляться за старые стандарты, процедуры, методологии и средства, независимо от их непригодности.
Одним приятным исключением из этого правила являются начинающие организации. Таким организациям, по определению, не нужно изменять культуру ввиду ее отсутствия, и они, скорее всего, воспримут безнадежные проекты как нормальное явление - в конце концов, частью мифологии начинающих компаний является убеждение, что каждый должен работать как заведенный, в то время как компания подвергает себя безумному риску, чтобы преуспеть в конкурентной борьбе с крупными корпорациями. И, если начинающая компания приходит к выводу, что ее успех полностью обусловлен
тактикой ее поведения, то она, вероятно, постарается утвердить такую тактику на будущее.
Разумеется, мои утверждения носят достаточно общий характер, и существует множество причин, по которым такой подход может не дать никаких результатов. Интересным, например, является тот факт, что ветераны разработки ПО, покидая большие бюрократические корпорации и создавая новые софтверные фирмы, приносят с собой почти все свои привычки и традиции. С другой стороны, в настоящее время, так же, как и в начале моей карьеры, молодое поколение разработчиков ПО очертя голову бросается в новые проекты, считая 18-часовой рабочий день «отдыхом». Тем не менее, среди всех происшедших драматических изменений я бы особенно выделил характер и темп работы, который народ в Netscape, Microsoft и множестве других организаций называет просто «время Internet».
