Средства «безнадежных» проектов

Летом 1992 г. Эдварду Йордону довелось обедать с группой менеджеров среднего уровня Microsoft. Во время беседы он спро­сил, является ли для них обычным делом использование таких методологий, как структурный анализ или объектно-ориентиро­ванное проектирование. Ответы были примерно следующими: «иногда», «вроде бы да», «от случая к случаю» и «а что это такое?». Когда же он поинтересовался относительно использования CASE-средств (которые в то время все еще были довольно попу­лярными в индустрии ПО), то из их ответов понял, в чем заклю­чается общее мнение майкрософтовцев: эти средства годятся для «людей с улицы», т.е. «невежественных дикарей, которые только что вылезли из своего первобытного леса и начали обучаться программированию, в отличие от настоящих программистов, не нуждающихся во всяких финтифлюшках».

Будучи слегка уязвленным, он полюбопытствовал, использу­ют ли их проектные команды хоть какие-нибудь средства, и в от­вет услышал, что каждая команда Microsoft может выбрать любые средства, которые сочтет подходящими для своего проекта. Ухва­тившись за такой ответ, Йордон спросил, какое средство считает наиболее важным типичная проектная команда?

«На днях я задал одной из проектных команд такой же воп­рос», - ответил один из менеджеров. «Как вы думаете, что они от­ветили?»

«Какой-нибудь высокопроизводительный компилятор C++? Ассемблер? Или мощное средство отладки для устранения мно­жества ошибок в их коде (хи-хи-хи)?»

«Ничего подобного», — ответил менеджер, игнорируя иро­нию. «Они ответили: электронная почта. Средний разработчик Microsoft получает сотню сообщений в день; он живет в элект­ронной почте. Уберите электронную почту, и проект умрет».

Эти события происходили до начала эры Internet и World Wide Web, когда сотня почтовых сообщений в день могла потрясти во­ображение. Однако можно представить себе, что если бы такой же вопрос о «наиболее важном средстве» был задан в 1996 г., от­ветом могло быть «World Wide Web»; по аналогии, «факс» в 1987 г., «ПК» в 1983 г., «онлайновый терминал» в 1976 г. и «телефон на ра­бочем столе» в 1964 г.

Очевидно, не следует ожидать, что команда «безнадежного» проекта сможет ограничиться только одним средством. Большин­ство команд (даже в нормальных проектах) пользуется в своей повседневной работе самыми разнообразными средствами и тех­нологиями. Правда, подчас количество средств становится чересчур большим, технологии — слишком новыми, а иногда нежела­тельные средства навязываются некомпетентными менеджерами.

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

С другой стороны, предположим, что команда работает в крупной корпорации, имеющей в своем распоряжении сотни различных средств, приобретавшихся в течение ряда лет. Следует ли их все использовать? Конечно, нет! Даже если все они работа­ют, те умственные усилия, которые необходимо затратить, чтобы запомнить, как ими пользоваться, а также дополнительные уси­лия для обеспечения их совместной работы обычно сводят на нет всю выгоду. Можно провести аналогию с командой альпинистов, которые собираются штурмовать вершину и пытаются решить, какое снаряжение им использовать. Существуют необходимые вещи (палатки, питьевая вода и т.д.); и, если маршрут не слишком сложный, можно взять с собой некоторые новомодные приспо­собления, о которых написано в альпинистском журнале. Одна­ко, если они собираются штурмовать Эверест, им не обойтись без помощи ослов или носильщиков из местных жителей, иначе они будут не в состоянии тащить на спине по 300 фунтов снаряжения на человека.

Команда «безнадежного» проекта должна самостоятельно, независимо от принятых в организации стандартов, решить, ка­кие средства являются необходимыми, а без каких можно обой­тись. Очень важно участникам команды прийти к единому мне­нию относительно используемых в проекте средств, иначе насту­пит хаос. Разумеется, это утверждение не следует понимать бук­вально; оно не означает, что все участники команды должны обя­зательно использовать один и тот же текстовый процессор для подготовки своих документов, хотя, скорее всего, важен один и тот же компилятор C++. Одна из проблем, связанных с «безна­дежными» проектами, заключается в том, что разработчики ПО считают допустимой полную анархию на индивидуальном уровне (например, если им хочется использовать никому не известный компилятор C++, который они переписали с университетского Web-сайта, то они считают это своим неотъемлемым правом). Но это не так: неотъемлемым правом обладает команда, и менеджер проекта должен неуклонно проводить его в жизнь во всех ситуа­циях, когда несовместимые средства могут привести к значитель­ным разногласиям.

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

Менеджер проекта должен настаивать на достижении кон­сенсуса; в самом деле, это может быть одним из критериев, ис­пользуемых менеджером для выбора потенциальных участников команды. То же самое можно сказать относительно процессов, которые обсуждались ранее.

Вот перечень средств, которые рекомендуются для «безна­дежных» проектов:

Электронная почта, ПО для групповой работы, средства Internet/Web, видеоконференции и т.д. Так же, как и в эпизоде с Microsoft, эти средства находятся в начале списка. Причина зак­лючается в следующем: электронные средства общения и взаимо­действия являются не только более эффективным средством коммуникации, чем записки и факсы, но они также способству­ют координации и сотрудничеству. Безразлично, какие именно средства использовать: Microsoft Outlook или Lotus Notes; важно только, чтобы вся команда работала в сети и хранила там общие проектные данные.

Средства прототипирования/быстрой разработки приложений (RAD). Почти все «безнадежные» проекты используют в той или иной степени прототипирование и пошаговую разработку; следо­вательно, им необходимы соответствующие инструментальные средства. Сегодня не так просто отыскать популярную среду разработки приложений, которая заявляла бы о себе иначе, чем сре­да RAD. Большинство таких средств обладают визуальным поль­зовательским интерфейсом, выполненным в стиле «drag and drop», облегчающим и ускоряющим процесс разработки. Важно, чтобы вся команда использовала один и тот же набор средств от одного и того же поставщика. Если часть команды использует среду разработки Java компании Sun, а другие — Microsoft Visual J++, то это явно глупо, хотя и допустимо с точки зрения техноло­гии.

Средства управления конфигурацией/управления версиями. Не­которые полагают, что они должны быть на первом месте в спис­ке. Очевидно, использование средств управления конфигурацией может принести больше пользы, если они будут интегрированы со средствами разработки приложений. Например, SourceSafe от Microsoft может и не быть самым лучшим средством управления версиями ПО, однако тот факт, что оно тесно интегрировано с Visual Basic, является весомым аргументом в его пользу. Анало­гично, многие другие средства разработки приложений интегри­рованы с PVCS или другими подобными средствами управления конфигурацией.

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

Средства управления проектом (оценка, планирование, PERT/GANTT и т.д.). Обычно их считают средствами менеджера проекта. К этой же категории следует отнести такие средства оценки, как ESTIMACS (Computer Associates), CHECKPOINT (Software Productivity Research) и SLIM (Quantitative Software Management). Они, я считаю, являются важными, поскольку позволяют в ходе выполнения проекта динамически пересматри­вать планы и сроки.

Наборы повторно используемых компонентов. Если проектная команда знакома с концепцией повторного использования ПО и рассматривает ее как стратегическое оружие, позволяющее дос­тичь высокого уровня продуктивности разработки, тЬ набор пов­торно используемых компонентов должен быть в списке тех средств, которые необходимо использовать. Это может быть на­бор компонентов VBX для Visual Basic, компоненты Java компа­нии Sun или библиотека классов 8ТЪдля C++. Разумеется, можно использовать и компоненты, разработанные другими проект­ными командами в организации. Выбор их обычно зависит от ис­пользуемого языка программирования, и это еще одна проблема, нуждающаяся в выработке единого подхода со стороны проект­ной команды.

CASE-средства для анализа и проектирования. Некоторые про­ектные команды рассматривают CASE-средства как «костыли» для новичков, а другие считают их не менее важными, чем текс­товые процессоры. Самая большая проблема, связанная с CASE-средствами, заключается в том, что они поддерживают (а иногда навязывают) определенную методологию, которую проектная команда не понимает и не желает использовать.

Упомянутая проблема CASE-средств, вероятно, представляет собой наиболее очевидный пример трюизма: средства и процес­сы связаны друг с другом сложным образом. Бессмысленно браться за объектно-ориентированное CASE-средство, поддер­живающее анализ, если разработчики никогда не слышали об ие­рархии классов или диаграммах вариантов использования. Ис­пользование такого CASE-средства будет не только бесполез­ным, но и чрезвычайно обременительным, если проектная ко­манда искренне полагает, что диаграммы классов представляют собой лишенные смысла формы бюрократических документов.

Но ситуация не всегда бывает черно-белой. Например, про­ектная команда считает, что диаграммы потоков данных полез­ны, но только как «неформальное» средство моделирования. Та­ким образом, «гибкое» CASE-средство может рассматриваться как нужное и полезное, в то время как «жесткое» CASE-средство может быть отвергнуто.

Все это означает, что команда «безнадежного» проекта долж­на в первую очередь нормально воспринимать те процессы и ме­тоды, которым она собирается следовать. Кроме того, она долж­на решить, каким из них надо подчиняться беспрекословно, а ка­ким — следовать духу, но не букве закона. После принятия такого решения можно соответственно выбрать (или отвергнуть) сред­ства и технологию. Таким же образом менеджер проекта может решить использовать какое-либо средство для усиления процес­са, необходимость которого все понимают, но на практике следу­ют ему достаточно небрежно; примеры таких процессов — конт­роль версий и управление конфигурацией.

Один из величайших мифов, касающихся использования инструментальных средств в любых проектах (и особенно опас­ных в безнадежных проектах) заключается в отношении к сред­ству как к «серебряной пуле», которая позволит творить чудеса. Разумеется, поиском чудес занимается в основном высшее руко­водство. Однако даже менеджера проекта могут соблазнить рек­ламные заявления поставщика, уверяющего, что с помощью его гениальных средств можно в десять раз повысить производитель­ность программирования, тестирования или какой-нибудь дру­гой деятельности.

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

Ирония заключается в том, что большинство организаций в своих провалах винит технологию. Они приобретут дорогостоя­щую библиотеку классов или поменяют свою старую технологию разработки ПО на объектно-ориентированную, исходя из пред­положения, что объекты и повторное использование — это одно и то же. Обнаружив, что не добились сколько-нибудь ощутимых результатов, они будут винить во всем объектную технологию, библиотеку классов, поставщика и др. Между тем все процессы остались в точности такими же, какими были до внедрения новой технологии. Культура такой организации может быть выражена следующей фразой: «Только бездари пользуются чужим кодом; настоящие программисты, черт возьми, пишут свой!»

С точки зрения работы над «безнадежным» проектом мораль проста: если внедрение новых средств потребует серьезного из­менения стандартных процессов команды, то это значительно увеличит риск и, возможно, будет способствовать провалу проек­та. Необходимость обучения и освоения практического исполь­зования новых средств создает дополнительные проблемы. Одна­ко наиболее серьезной из них является изменение режима рабо­ты, который целиком определяется процессом. Это трудно сделать и в нормальных условиях, когда у нас достаточно времени, чтобы относительно безболезненно перейти к новому процессу. Для «безнадежного» проекта такой переход будет просто катаст­рофическим.

При работе над «безнадежными» проектами некоторые часто хватаются за новые средства и технологии для достижения более высокой продуктивности. При этом возникают два наиболее ве­роятных риска — технология и обучение. Во многих случаях но­вое средство даже не является законченным коммерческим про­дуктом; обычно кто-нибудь из проектной команды переписывает из Интернета бета-версию. Или же данное средство невозможно интегрировать с любыми другими средствами, используемыми проектной командой; поставщик давал на этот счет неопределен­ные обещания, однако в результате оказалось, что возможности экспорта-импорта изобилуют ошибками. Или, средство никем не поддерживается — оно разработано студентом из Ирака или (что еще хуже) создано в домашних условиях одним из разработчиков ПО, который не видит ничего странного в том, что банк разраба­тывает свое собственное CASE-средство, а страховая компания — свою СУБД.

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

Как много времени на это потребуется? Очевидно, это зави­сит от характера и сложности средства, а также от его пользова­тельского интерфейса, возможностей онлайновой подсказки и др. В лучшем случае разработчики могут самостоятельно разоб­раться в использовании средства. В такую возможность очень хочется верить менеджеру проекта и разным другим руководите­лям, поскольку они считают любое обучение потерей времени и отвлечением от работы над проектом. Более реалистичная оцен­ка заключается в том, что на освоение средства потребуется час, день или неделя. Независимо от формы обучения (занятия в классе, чтение книги или просто «игры» со средством), на это все равно потребуется какое-то время.

Однако в результате недельного обучения не получится опыт­ного пользователя, в совершенстве владеющего средством. Это должно быть очевидным, однако нарушает планы высшего руко­водства, которое склонно возмущаться: «Мы потратили кучу де­нег на этих высокооплачиваемых преподавателей и напрасно по­теряли столько времени в классах, чтобы эти ленивые бездельни­ки-программисты могли научиться кодировать. Теперь мы хотим увидеть реальную отдачу от этого «замечательного» средства, за которое вы так агитировали!» Наверное, в такой наивности выс­шего руководства нет ничего удивительного, поскольку они сами практически не сталкивались с инструментальными средствами. Однако, к сожалению, приходится наблюдать похожую реакцию со стороны многих менеджеров «безнадежных» проектов, гораздо лучше разбирающихся в технических вопросах.

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

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

! Следует запомнить

1. Во многих проектах наиболее серьезные проблемы носят не столько технический характер, сколько политический, социальный, культурный и человеческий.

2. Проекты, выполняющиеся в экстремальных условиях, предъявляют особые требования к используемым методам, средствам и технологиям.