Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте

Death March Second edition

Edward Yourdon

Prentice Hall Professional Technical Reference Upper Saddle River, New Jersey 07458

Путь камикадзе Второе издание

Эдвард Йордон

Издательство “ЛОРИ” Москва

2008

Death March Second edition

Edward Yourdon © 2004 Pearson Education, Inc. Publishing as Prentice Hall Professional Technical Upper Saddle River, New Jersey 07458

Reference

Эдвард Йордон Путь камикадзе (Второе издание) Переводчик А. Веидров Корректор J1.H. Белая Верстка Ю. Куиашовой © Издательство “Лори”, 2008 Изд. № : OAI (03) ЛР № : 07612 30.09.97 г. ISBN 5-85582-227-3 Подписано в печать 29.02.2008 Формат 84x108/32 Гарнитура Литературная. Печать офсетная Печ. л. 9,5. Тираж 1500. Заказ № 20. Цена договорная Издательство “Лори" Москва, 123100, Шмитовский пр., д. 13/6, стр. 1 (пом. ТАРП ЦАО) Телефон для оптовых покупателей: (495) 256-02-83 Размещение рекламы: (495) 259-01-62 www.lory-press.ru Отпечатано в типографии ООО “Тиль-2004" 107023 Москва, ул. Электрозаводская, д. 21

Содержание

пред и сло ви е

ix

Глава 1 ВВЕДЕНИЕ В ПРОБЛЕМУ 1.1 Определение безнадежного проекта 1.2 Категории безнадежных проектов 1.3 Почему существуют безнадежные проекты? 1.4 Почему люди участвуют в безнадежных проектах? 1.5 Заключение

1 2 5 8

Библиография

26 47 49

Глава 2 ПОЛИТИКА 2.1 Идентификация “игроков”, вовлеченных в проект 2.2 Определение сущности проекта 2.3 Отношение участников к проекту 2.4 Анализ основных проблем, порождающих политические разногласия 2.5 Заключение

50

Глава 3 ПЕРЕГОВОРЫ 3.1 Нормальные переговоры 3.2 Допустимые компромиссы 3.3 Переговорные игры 3.4 Стратегии переговоров

78 79 83 86

51 64 70 73 76

94

3.5 Что делать в случае провала переговоров Библиография

ЧЕЛОВЕЧЕСКИЙ ФАКТОР В БЕЗНАДЁЖНЫХ ПРОЕКТАХ 4.1 Кадровые вопросы 4.2 Лояльность, обязательства, мотивация и вознаграждения 4.3 Значение коммуникации 4.4 Проблемы формирования проектной команды 4.5 Условия работы в безнадежном проекте 4.6 Заключение

99 107

Глава 4

Библиография

115 129 130 138 143 143

Глава 5 5.1 5.2 5.3 5.4 5.5 5.6 5.7

ПРОЦЕССЫ В БЕЗНАДЕЖНЫХ ПРОЕКТАХ Концепция “triage” Важность управления требованиями SE1, 1SO-9000. Формальные процессы против неформальных “Достаточно хорошее” программное обеспечение Наилучшая практика и наихудшая практика Безнадежные проекты и экстремальное программирование Заключение

109 111

Библиография

Глава 6 ДИНАМИКА ПРОЦЕССОВ 6.1 Модели процессов разработки программного обеспечения 6.2 Визуальные модели 6.3 Пример: модель Тарика Абдель-Хамида 6.4 Заключение Библиограф ия

147 148 156 165 168 174 183 187 188

190 191 201 203 211 213

Глава 7

МЕТОД КРИТИЧЕСКИХ ПОСЛЕДОВАТЕЛЬНОСТЕЙ И ТЕОРИЯ ОГРАНИЧЕНИЙ 7.1 Введение 7.2 Что означает дисфункциональное поведение организации? 7.3 Как можно изменить дисфункциональное поведение организации? 7.4 Жизнь в разумном мире 7.5 Метод критических последовательностей 7.6 Заключение Библиография

Глава 8 УПРАВЛЕНИЕ РАБОЧИМ ВРЕМЕНЕМ 8.1 Влияние корпоративной культуры на управление рабочим временем 8.2 Отставание от графика из-за разногласий между заинтересованными лицами 8.3 Как повысить эффективность использования рабочего времени проектной команды Библиография

215 215

217 222 226 229 232 233

235 236 238 241 243

Глава 9

УПРАВЛЕНИЕ И КОНТРОЛЬ ЗА ПРОДВИЖЕНИЕМ ПРОЕКТА 244 9.1 Принцип “ежедневной сборки" 245 9.2 Управление рисками 249 9.3 Дополнительные способы мониторинга продвижения проекта: периодические оценки 256 Библиография 260 Глава 10

ТЕХНОЛОГИЯ И ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА БЕЗНАДЕЖНЫХ ПРОЕКТОВ 10.1 Минимально необходимый набор инструментальных средств

261

263

10.2 Средства и процессы 10.3 Риск выбора новых средств 10.4 Заключение ' Библиография

ИМИТАТОРЫ И “ ВОЕННЫЕ ИГРЫ” 11.1 Введение 11.2 Концепция военных игр 11.3 Заключение

270 274 278 279

Глава 11

Библиография

280 280 282 287 289

ПРЕДИСЛОВИЕ

Думаю, что вас заинтриговало название этой книги и вы решили заглянуть в нее. Но, к сожалению, вы, как обычно, ужасно заняты и не уверены, найдется ли у вас время на чтение еще одной книги об управлении софтверными про­ ектами. Особенно если в ней речь идет о некоем идеальном мире, в котором здравомыслящие мужчины и женщины хладнокровно принимают благоразумные решения относи­ тельно бюджета, графика и ресурсов вашего проекта. Тем не менее мы живем в отнюдь не идеальном мире, и существует вероятность того, что в вашем проекте вам придется взаимодействовать с людьми не слишком рацио­ нального склада мышления, решения которых трудно на­ звать хладнокровными или благоразумными. Другими словами, вы участвуете в безнадежном проекте. Замеча­ тельно, что название этой книги не требует никаких пояс­ нений. Каждый раз, когда я упоминаю его в присутствии моих друзей и коллег, они говорят мне со смехом: “Послу­ шай, ты ведь говоришь именно о моем проекте!" Такой проект может быть моим, вашим, чьим-либо еще — мы все так или иначе участвуем в безнадежных проектах. Я думаю, первый вопрос, который вы должны за­ дать самому себе (хотя он может и не возникнуть): “Как я позволил вовлечь себя в такую авантюру?” Это мы обсу­ дим в первой главе, поскольку мой опыт в качестве кон­ сультанта, наблюдающего множество подобных проектов со стороны, говорит о том, что наш мир мог быть разумнее, если бы большинство из нас имело смелость остановиться

и сказать: “Дудки! Я не желаю участвовать в этом безна­ дежном проекте!” Допустим, вы не можете хлопнуть дверью и уйти: трудно найти другую работу или к вашему работодателю вас при­ ковывает своего рода “золотая цепь” , отбивающая охоту выйти их проекта. В этом случае следует спросить себя: “Как я могу выжить в этом проекте без ущерба для здоро­ вья, психики и достоинства?” Оптимисту может показаться интересным процесс преодоления препятствий по пути по­ пыток завершения безнадежного проекта в срок и в рамках бюджета. Но если вы уже неоднократно сталкивались с по­ добными проектами, вы, скорее всего, знаете, что обстоя­ тельства обычно против вас и выживание — это лучшее, на что можно надеяться. Проработав в индустрии ПО более 30 лет, я обнаружил, что в нашей профессии безнадежные проекты воспринима­ ются весьма неоднозначно. Скажем, в Силиконовой Долине они окружены ореолом славы, являясь чем-то вроде испы­ тания силы духа и стойкости, наподобие покорения Эвере­ ста босиком. Я и сам переболел этой болезнью во время моих первых проектов в середине 60-х годов, затем наблю­ дал развитие этих идей у следующего поколения, что навело меня на мысль о постоянстве этого феномена, поскольку технология продолжает развиваться такими же быстрыми темпами, как и в мое время. Наша индустрия тоже продол­ жает развиваться. Каждый год появляются и новый Эве­ рест, и толпа отчаянных программистов, уверенных в том, что смогут пробежать босиком весь путь до вершины. В другой области нашей индустрии такие проекты рас­ сматриваются как серьезные неудачи. Мы бываем завалены статистикой, свидетельствующей о срыве планов, перерас­ ходе бюджета, ошибках в ПО, раздраженных пользователях и полных провалах проектов. Эксперты, консультанты и ме­ тодологи постоянно твердят нам, что причиной неудач явля­ ется использование неверных методов (или отказ от исполь­ зования каких-либо методов), или неправильных средств, или неправильных способов управления проектом. Иными

словами, безнадежные проекты существуют из-за нашей бестолковости или некомпетентности. Общаясь с покрытыми шрамами, закаленными в боях ветеранами-разработчиками, которые прошли через пару безнадежных проектов и поняли, что на самом деле ни к чему покорять Эверест босиком, вы наверняка услышите: “Постойте! Я вовсе не бестолковый! Безусловно, мне хоте­ лось бы использовать правильные методы, средства и спо­ собы управления проектом. Но нам их уже продиктовали сверху, в самый первый день, когда мы еще не успели по­ лучить хотя бы представление о проекте! Вряд ли мое выс­ шее руководство и мои пользователи позволят мне про­ явить инициативу!" Вывод: в существовании безнадежных проектов виновато высшее руководство, а также наивность и безрассудство пользователей. Без сомнения, в этом есть некоторая доля правды. Управляя нашими проектами, мы совершаем множество глупых ошибок, наше высшее руководство увлекается сме­ хотворными политическими играми, а наши пользователи предъявляют к нам непомерно высокие требования. Я убе­ жден, что это в основном объясняется быстрым научнотехническим прогрессом, а также обычным неуважением каждого нового поколения к советам и опыту предыдущего поколения. Зачем сегодняшним Java-ориентированным фанатам прислушиваться к советам представителей моего поколения, имеющих 30-летней давности опыт программи­ рования на ассемблере? И как нынешнее поколение поль­ зователей может узнать, какое Web-приложение для них наиболее приемлемо, если их предшественники применяли онлайновые системы на мэйнфреймах с символьными, мо­ нохромными и немыми терминальными интерфейсами? Каким бы ни было объяснение этого феномена, я уже пришел к следующему выводу: безнадежные проекты — норма, а не исключение. Полагаю, что сегодняшние раз­ работчики ПО и менеджеры проектов достаточно изобре­ тательны и горят желанием управлять проектами разумно. Сегодня пользователи и высшее руководство обладают го­

раздо большей компьютерной грамотностью, чем предыду­ щее поколение, и менее наивны относительно результатов, которые можно ожидать от разработчиков ПО в условиях ограниченных ресурсов. Это не мешает ни тем, ни другим участвовать в очередном безнадежном проекте, продикто­ ванном необходимостью выживания в конкурентной борь­ бе, а также заманчивыми возможностями, предлагаемыми новыми технологиями. Бизнес-менеджеры могут вполне осознавать, что при разумном планировании разработка новой системы займет 12 календарных месяцев, однако в то же время они будут настойчиво утверждать, что отсутст­ вие готовой системы через 6 месяцев позволит конкурен­ там захватить весь рынок и вытеснить их новый продукт или услугу. Аналогично технические специалисты, отдавая себе отчет в высоком риске использования новых техноло­ гий, подобных Интернету, продолжают утверждать, что в случае успеха новая технология обеспечит им стратегиче­ ское преимущество в конкурентной борьбе, и это оправды­ вает любой риск. С другой стороны, отчеты таких организаций, как Standish Group, а также статистические данные авторитет­ ных экспертов, подобных Кэперсу Джонсу, Говарду Рубину, Полу Штрассману и Лари Путнэму, говорят о том, что в среднем продолжительность проекта больше плановой на 6— 12 месяцев, а стоимость превышает бюджет на 50— 100%. Конкретная ситуация зависит от размера проек­ та и ряда других факторов, но в любом случае суровая ре­ альность заставляет предполагать, что условия вашего про­ екта повлекут за собой некоторую степень обреченности на неудачу и это отразится на поведении менеджера проекта и его технических специалистов.. Проект, характеризующийся с самого начала высокой степенью риска, наверняка повле­ чет за собой сверхурочную работу, потерянные выходные, и, скорее всего, массу эмоциональных и физических стрессов до самого завершения. Даже если проект начинается в ра­ зумной и спокойной обстановке, все равно не исключена ве­ роятность, что по мере своего продвижения он переродится

в безнадежный. То ли первоначальные план и бюджет ока­ жутся крайне нереалистичными, то ли у пользователей поя­ вится много новых требований, которые не были учтены при составлении первоначального плана и бюджета. Итак, спрашивается: если невозможно избежать безна­ дежных проектов, как их выдержать? Что следует предпри­ нять для повышения шансов на успех? Когда следует быть готовым к компромиссу — и когда следует уйти в отстав­ ку, если дальнейшее продолжение работы невозможно? Именно об этом идет речь в данной книге. Эти вопросы одинаково актуальны как для менеджера, отвечающего за проект, так и для технических специалистов, мозолистыми руками которых система проектируется, программируется, тестируется и документируется; все главы книги адресуются в равной степени обеим группам. Несколько слов относительно менеджеров и технических специалистов: некоторые из комментариев, обнаруженных вами в следующих главах, предполагают, что менеджеры — “злые”, а участники проектной команды — невинные, угне­ тенные жертвы. Очевидно, такая ситуация не является обя­ зательной для всех проектов и всех компаний, хотя само су­ ществование безнадежных проектов является, как правило, результатом сознательных решений руководства. Если вы не в состоянии читать всю книгу, скажу только одно слово, которое может оправдать время, потраченное на чтение предисловия: приоритетность (triage). Если вы участвуете в безнадежном проекте, почти наверняка окажется недостаточно ресурсов, чтобы реализовать всю функциональность и возможности ПО, которые требуются конечному пользователю, в рамках утвержденного плана и бюджета. Так или иначе придется решать, какие возмож­ ности следует реализовать в первую очередь, а какими — пожертвовать. Действительно, некоторые из незначитель­ ных возможностей не будут реализованы никогда, поэто­ му — лучше дать им спокойно умереть собственной смер­ тью. Другие возможности являются достаточно важными, но также относительно легко реализуемыми, например с

помощью поставляемой библиотеки классов или исполь­ зуемых вами CASE-средств. Говоря языком медиков, эти возможности и сами выживут. Успех или неудача без­ надежного проекта зачастую зависит от способности про­ ектной команды выделить критические функции и возмож­ ности, которые нельзя реализовать, не вкладывая значи­ тельные ресурсы и энергию. Разумеется, чтобы спасти безнадежный проект, недоста­ точно одной только правильной расстановки приоритетов в реализации функций (см. главу 3). Необходимо рассматри­ вать и такие вопросы, как кадровое обеспечение, процессы и методологии, методы и средства. Я старался быть как можно более немногословным, чтобы вам хватило пары ча­ сов на прочтение всей книги; она могла бы помочь более реалистично оценить очередной безнадежный проект. Но не воспринимайте эту книгу как “библию” и не ду­ майте, что она преподнесет вам решение всех проблем. Стопроцентно правильных решений не существует; то, что срабатывает в одних компаниях и ситуациях, может не сра­ ботать в других. Также важно, что компромиссы, на кото­ рые готовы пойти некоторые менеджеры и технические специалисты, будут совершенно неприемлемы для других. Я предлагаю те решения, которые считаю разумными, но в конечном счете вы сами должны определить, какие из них годятся для вас, а какие — нет. Я намереваюсь постоянно собирать на своем Web-сайте ( www.yourdon.com) информацию и практические реко­ мендации от различных проектных команд по поводу наи­ лучшей практики, наихудшей практики и разнообразных проблем. Даже если в вашем проектном бюджете недоста­ точно денег на покупку этой книги (такой крохотный бюд­ жет уже говорит о рискованности проекта!), бесплатно об­ ратитесь к Web-странице. Как бы вы ни решили поступить, желаю самой большой удачи вашему очередному безнадежному проекту.

ГЛАВА 1

ВВЕДЕНИЕ В ПРОБЛЕМУ

Что такое безнадежные проекты? Почему они суще­ ствуют? По какой причине здравомыслящие люди согла­ шаются участвовать в них? Для многих закаленных ветеранов эти вопросы — чистая риторика. С точки зрения их опыта, каждый про­ ект — это безнадежный проект. Почему так происхо­ дит? Поведение больших корпораций зачастую выглядит неразумным. Как отмечает эксперт Ричард Саржент, “ неразумное поведение корпораций заключается в том, что они делают одно и то же снова и снова, каждый раз ожидая различных результатов”. Почему мы участвуем в таких проектах? Как отмечает эксперт Дейв Кляйст: Вряд ли можно где-нибудь увидеть объявле­ ние о найме для участия в безнадежном проек­ те. Какой смысл спрашивать: “Хотите ли вы работать сверхурочно без какой-либо прибав­ ки к зарплате? Привлекает ли вас бесконечная работа по устаревшей технологии и тщет­ ное ожидание участия в каком-нибудь замеча­ тельном проекте GUI/DSS/DWH/HTML? Каково будет узнать, что трехзвенная архитектура ”клиент-сервер" позволит остальным участ­ никам проекта обойтись без вашей помощи?" На самом деле безнадежные проекты редко объявляются таковыми во всеуслышание, и вам придется долго проработать в нанявшей вас компании, прежде чем удастся обнару­

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

Если ответы на эти вопросы кажутся вам очевидны­ ми, можете смело переходить к следующей главе. Я и сам начинаю думать, что они очевидны, поскольку меня редко спрашивают, что же я понимаю под “ безнадеж­ ным проектом” . Однако, если вы не из тех, кто сообра­ жает, о чем я говорю, или полагаете, что это книга о боевых походах времен Второй Мировой Войны1, стоит сделать паузу, чтобы разобраться в предмете книги.

1.1 Определение безнадежного проекта Под безнадежным проектом (death march project) я понимаю такой проект; параметры которого отклоняют1 Определение «Death March» (смертельный марш) дей­ ствительно взято из американской истории Второй Ми­ ровой Войны. Такое название получили трагические пе­ реходы американских солдат, взятых в плен японцами, по тропическим джунглям. Во время этих переходов большая часть военнопленных заболевала или погиба­ ла. — Прим. пер.

ся от нормальных значений по крайней мере на 50%. По отношению к софтверным проектам это обычно означа­ е т одно или более из следующих ограничений: • План проекта сжат более чем наполовину по сравнению с нормальным расчетным планом; таким образом, проект, для выполнения которо­ го в нормальных условиях требуется 12 кален­ дарных месяцев, приходится осуществлять за 6 или менее месяцев. Жесткая конкуренция на мировом рынке и наступление “эры Интернета” делают такую ситуацию наиболее распростра­ ненной. • Число разработчиков уменьшено более чем на­ половину по сравнению с действительно необ­ ходимым для выполнения проекта данного раз­ мера и масштаба; таким образом, менеджеры проекта убеждают, что вместо проектной ко­ манды из десяти человек достаточно и пяти. Та­ кое представление может быть результатом на­ ивной веры в магические возможности новых CASE-средств или языков программирования удваивать производительность труда разработ­ чиков, несмотря на то, что разработчики не изу­ чали новую технологию или не имеют практиче­ ского опыта работы с ней и, скорее всего, с ними никто не советовался по поводу решения использовать новую технологию. К сожалению, такое случается все чаще и чаще, например, весной 2003 года (когда писалась эта книга) ос­ новной причиной был экономический спад и, как следствие, урезание 1Т-бюджетов. • Бюджет и связанные с ним ресурсы урезаны на­ половину. Зачастую это результат сокращения компании или конкурентной борьбы за выгод­ ный контракт. В этой ситуации менеджер проек­ та в консалтинговой фирме получает из отдела

маркетинга следующую информацию: “У нас хорошая новость — мы выиграли тендер, но есть и плохая новость — мы были вынуждены наполовину урезать бюджет, чтобы победить конкурентов”. Такое ограничение часто непо­ средственно влияет на число нанимаемых раз­ работчиков, однако последствия могут быть и менее явными — например, если принято ре­ шение привлечь относительно недорогих и не­ опытных молодых разработчиков вместо опыт­ ных дорогостоящих специалистов. Наконец, может сложиться такая ситуация экономии, ко­ гда менеджер проекта будет не в состоянии за­ казать пиццу для своей команды, проработав­ шей все выходные в офисе. • Требования к функциям, возможностям, произ­ водительности и другим техническим характери­ стикам вдвое превышают значения, которые они могли бы иметь в нормальных условиях. Например, проектной команде могут заявить, что они должны по сравнению с конкурентом получить в два раза больше возможностей из фиксированного объема RAM или дискового пространства. Или от них могут потребовать, чтобы система поддерживала вдвое большее ко­ личество транзакций по сравнению с любой со­ поставимой системой. Требования, связанные с производительностью, могут и не повлечь за со­ бой неудачу проекта. В конце концов, всегда можно использовать преимущества более деше­ вого и производительного оборудования, а так­ же разработать более совершенный алгоритм или подход к проектированию для повышения производительности (хотя при сжатых сроках могут не помочь и безграничные возможности человеческого мозга). С другой стороны, удвое­ ние функциональных возможностей обычно оз-

начает удвоение необходимого объема работы, что обязательно приведет к неудаче проекта. Во многих организациях это приводит к тому, что от проектной команды требуют работать вдвое интен­ сивней и/или тратить в два раза больше часов в неде­ лю, чем в “нормальном” проекте. При том, что нор­ мальная рабочая неделя составляет 40 часов, команде безнадежного проекта зачастую приходится работать по 13— 14 часов в день и б дней в неделю. В такой обстановке, естественно, возрастает напряженность и увеличивается число стрессов. Другой способ охарактеризовать безнадежный про­ ект заключается в следующем: беспристрастная, объек­ тивная оценка риска такого проекта (включая риск, свя­ занный с техническими проблемами, человеческим фактором, законами, политикой и т.д.) определяет веро­ ятность провала свыше 50%. Безусловно, даже если перечисленные ограничения отсутствуют, риск неудачи проекта все равно может быть высоким, например из-за конфликтов между ITподразделением и пользователями. Однако в общем слу­ чае причиной высокого риска является сочетание ука­ занных выше факторов.

1.2 Категории безнадежных проектов Далеко не все безнадежные проекты одинаковы; по­ мимо ограничений в планах, штатах, бюджете и функ­ циональности, они могут иметь различные масштабы, формы и другие особенности. Исходя из своего опыта, могу сказать, что наиболее важной отличительной характеристикой безнадежного проекта является его масштаб. В зависимости от мас­ штаба можно выделить четыре категории проектов: • небольшие проекты — проектная команда включает менее 10 человек, работает в исклю­

чительно неблагоприятных условиях и должна завершить проект в срок от 3 до 6 месяцев; • средние проекты — проектная команда вклю­ чает от 20 до 30 человек, протяженность проек­ та составляет 1 — 2 года; • крупномасштабные проекты — проектная команда включает от 100 до 300 человек, протя­ женность проекта составляет 3 — 5 лет; • гигантские проекты — в проекте участвует армия разработчиков от 1000 до 2000 человек и более (включающая, как правило, консультан­ тов и соисполнителей), протяженность проекта составляет от 7 до 10 лет. По различным причинам небольшие проекты явля­ ются наиболее распространенной категорией в тех орга­ низациях, где мне удалось побывать, и, к счастью, их шансы на успешное завершение наиболее высоки. Ком­ пактная и сплоченная команда не более чем из 10 чело­ век, скорее всего, не распадется, несмотря на все пре­ пятствия, в течение короткого шестимесячного периода. При высокой степени заинтересованности ее участники, вероятно, будут готовы пожертвовать своей личной жиз­ нью (но не здоровьем!) в течение 3 — 6 месяцев, по­ скольку они знают, что бессонные ночи, потерянные вы­ ходные и отсроченные отпуска через считанное время закончатся. Шансы на успешное завершение средних проектов заметно ниже, а дня крупномасштабных проектов почти равны нулю. В больших проектных командах трудно под­ держивать дух сплоченности. Причем решающее значе­ ние имеет не только число участников проекта, но и вре­ менная протяженность: 80-часовую рабочую неделю в течение 6 месяцев еще можно вытерпеть, но если рабо­ тать так в течение двух лет, могут возникнуть проблемы. Даже если менеджер способен убедить небольшую груп­

пу технарей в том, что так работать необходимо, это практически невозможно сделать для больших проект­ ных команд. По статистике вероятно, что некоторые из них женятся или выйдут замуж или найдут себе еще какое-нибудь занятие. Что касается гигантских проектов, то их существова­ ние часто просто непонятно. Возможно, разработка сис­ темы, связанной с проектом NASA высадки человека на Луну в 1969 г., может считаться примером успешного за­ вершения безнадежного проекта; однако подавляющее большинство их с самого начала обречено на провал. Большинство руководителей высшего звена это понима­ ют, и многие крупные организации (а только они могут себе позволить подобные проекты!) стараются их избе­ гать. К сожалению, государственные учреждения все еще пускаются в такие рискованные мероприятия, мотивируя это соображениями “национальной безопасности” (осо­ бенно после 11 сентября 2001 г.) или какими-либо други­ ми эмоциональными призывами, которые эффективно действуют на недальновидное высшее руководство, не от­ дающее себе отчет в том, что успеха достичь невозможно. Для того чтобы охарактеризовать “степень безнадеж­ ности” проекта, может оказаться полезным, помимо масштаба проекта, использовать такой критерий, как количество организаций-пользователей, вовлеченных в проект. Довольно трудно бывает удовлетворить запросы и одного-единственного пользователя или однородной группы пользователей из одного подразделения. Трудно­ сти, с которыми приходится сталкиваться в проектах масштаба предприятия, на порядок серьезнее хотя бы из-за политических и коммуникационных проблем, свя­ занных с коллективной деятельностью любого рода. В результате системные проекты, связанные с проекта­ ми реинжиниринга бизнес-процессов, часто вырожда­ ются в безнадежные — даже если на разработку затра­ чиваются достаточно скромные ресурсы (технические средства и ПО), политические баталии способны па­

рализовать всю организацию и причиняют проектной команде бесконечную головную боль. Наконец, нужно различать очень сложные и принци­ пиально невыполнимые проекты. Как отмечает Джон Бодаи [ 1]: Сочетания высококвалифицированных тех­ нических специалистов, замечательного руко­ водства, выдающихся проектировщиков и ин­ теллигентных пользователей недостаточно, чтобы гарантировать успех сомнительного проекта. На самом деле реально существуют невыполнимые проекты, и все новые и новые начинаются каждый день. Наиболее нереаль­ ные проекты могут быть квалифицированы как таковые на самой ранней стадии. По-види­ мому, существуют два основных типа таких проектов: “системы с нечеткими целями” и "очень сложные системы”.

До сих пор остались без ответа вопросы, почему вполне разумные организации предпринимают подобные проекты и почему разумные менеджеры и технические специалисты соглашаются участвовать в таких проек­ тах. Эти вопросы будут рассмотрены ниже.

1.3 Почему существуют безнадежные проекты? Если вы задумываетесь о том, что происходит в ва­ шей организации, нетрудно понять, почему существуют безнадежные проекты. Как отмечает Скотт Адамс, автор всемирно известного “принципа Дилберта” [2]: Когда я впервые услышал эти истории [о не­ разумном корпоративном поведении], я пришел в недоумение, однако после тщательного ана­

лиза я разработал сложную теорию, объясняю­ щую такое странное поведение. Она заключа­ ется в следующем: люди — это идиоты.

Себя я тоже включаю сюда. Идиоты все, не только люди с низкими интеллектуальными показателями. Единственная разница между нами заключается в том, что мы — идиоты по отношению к различным вещам в различное время. Неважно, насколько вы остроумны и находчивы, все равно большую часть дня вы проводите как идиот. Наверно, слишком тягостно представить себе, что вы идиот, окружены идиотами и руководят вами идиоты. Наверно, вы рассматриваете как оскорбление даже саму возможность такого предположения. На этот случай в таблице 1.1 приведен более детальный список причин, порождающих безнадежные проекты. Таблица 1.1 Причины безнадежных проектов Политика, политика, политика Наивные представления маркетинговых служб, высшего руковод­ ства, менеджеров проекта и др. Наивный оптимизм юности: “Мы сможем сделать это за выходные!" Менталитет первопроходцев у неопытных предпринимателей Менталитет "Морского Корпуса”: Настоящие программисты не нуж­ даются в сне! Высокая конкуренция, порожденная глобализацией рынков Высокая конкуренция, вызванная появлением новых технологий Сильное воздействие неожиданных правительственных решений Неожиданный и/или незапланированный кризис — например, ваш поставщик оборудования/ПО только что обанкротился или три ва­ ших лучших программиста только что умерли от бубонной чумы

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

1.3.1 Политика, политика, политика Многие разработчики ПО клянутся, что не дадут втя­ нуть себя в политические игры, поскольку они считают это не своим делом. Кроме того, они полагают, что все связанное с политикой, — отвратительно. Увы, уйти от политики невозможно; как только в какое-либо совместное предприятие войдут двое или более человек, тут же начнется политика. Однако когда в большом, сложном проекте поли­ тика начинает доминировать, он скорее всего выро­ дится в безнадежный проект. Вспомните мое опреде­ ление безнадежного проекта: сроки, штат, бюджет или ресурсы на 5 0 — 100% меньше, чем следует. О т­ куда берутся эти ограничения? Как будет видно из дальнейшего обсуждения, существует много возмож­ ных объяснений, тем не менее, в большинстве случа­ ев ответ весьма прост: “ Политика” . Это может быть война между двумя менеджерами в вашей организа­ ции, либо проект намеренно провален в качестве мес­ ти менеджеру, который наступил не на ту мозоль, да еще в неподходящее время. Перечислять такие ситуа­ ции можно бесконечно. Вряд ли найдутся такие политики, которые прояс­ нили бы вам реальное положение вещей; тем не м е­ нее, если вы технический специалист, не будет лиш-

ним спросить вашего менеджера, не является ли весь проект политической спекуляцией. Даже если полити­ ка вам не нравится или вы в ней новичок, вниматель­ но выслушайте ответ менеджера. Вы не глупы и не совсем наивны. Если ваше шестое чувство подсказы­ вает, что в проекте доминируют малоприятные поли­ тические игры, вероятно, так оно и есть; и если ваш непосредственный начальник отделывается однослож­ ным или неопределенным ответом, вы должны сами сделать для себя выводы. Другими словами, если ваш проект смахивает на карикатуры “Дилберта” , лучше держаться от него подальше. А если ваш менеджер открыто соглашается с вами? Что если он отвечает: “Да, на самом деле весь этот про­ ект не более чем ожесточенная схватка между вице-пре­ зидентом Смитом и вице-президентом Джонсом”? Если это так, почему же тогда сам менеджер участвует в про­ екте? Для этого, как сказано ниже в подразделе 1.4, мо­ жет быть множество причин; но то, что заставляет менеджера участвовать в проекте, вовсе не распростра­ няется и на вас. Неизбежное зло политики не означает, что вы должны немедленно бросить проект или совсем уволиться с работы. Но что бы ни происходило в проек­ те, следует отстаивать свои собственные приоритеты, цели и моральные ценности— 'особенно потому, что скорее всего многие принимаемые решения (начиная с решений по плану/бюджету/ресурсам, превративших проект в безнадежный с самого начала) не соответству­ ют интересам пользователей и организации в целом. Если проект все же увенчается успехом, то это скорее всего либо счастливая случайность, либо руководитель оказался более хитрым политиком, чем считали его про­ тивники.

1.3.2 Наивные представления маркетинговых служб, высшего руководства, менеджеров проекта и др. Наивность часто связана с неопытностью, поэтому не удивительно, когда люди, не имеющие представления о трудоемкости и длительности создания нужной им систе­ мы, принимают нереалистичные решения. В самом худшем варианте это может привести к тому, что мой кол­ лега Том ДеМарко называет “ истерическим оптимиз­ мом” . Это ситуация, когда все в организации бездумно ве­ рят в то, что сложный проект, который трудно выполнить и за три года, будет осуществлен за девять месяцев. Наивность и оптимизм, как мы видим, присущи и тех­ ническим специалистам. Однако вообразим на минуту, что именно ваши менеджер, отдел маркетинга или ко­ нечный пользователь несут ответственность за чересчур оптимистичный план или бюджет. Как они отреагируют, когда поймут чрезмерную оптимистичность первона­ чальных оценок? Захотят ли они продлить срок разра­ ботки, увеличить бюджет и спокойно согласиться с тем, что все не так просто, как они себе представляли? Ска­ жут ли они вам и вашим коллегам спасибо за героиче­ ские усилия? Если это так, то самым важным для вас может оказаться отказ от классической каскадной моде­ ли жизненного цикла ПО, чтобы сразу после реализа­ ции первой версии прототипа системы можно было получить реалистичную оценку плана, бюджета и ре­ сурсов. Тем не менее в большинстве безнадежных проектов нельзя скорректировать выполнение проекта в середине работы над ним. Это может произойти в том случае, если главный менеджер наивно пообещал что-либо за­ казчику и считает, что дело чести — выполнять свое обязательство, несмотря ни на что. Самое худшее — ко-

гда человек, принимающий на себя обязательства, впол­ не осознает происходящее (обычно тайное становится явным, когда после празднования по поводу заключения нового контракта с очередным доверчивым пользовате­ лем менеджер по маркетингу признается менеджеру проекта за кружкой пива: “Послушай, мы никогда бы не заключили этот контракт, если бы сказали клиенту, сколько времени потребуется для выполнения проекта на самом деле; в конце концов, мы знали, что наши кон­ куренты тоже придут с заманчивыми предложениями. И, кроме всего прочего, твои ребята всегда раздувают планы и бюджеты, не так ли?” ). На последнее замечание особенно трудно возразить, если оно исходит от вашего босса или менеджера, кото­ рый выше вас на два или три уровня. Предполагается, что вся оценка планов и бюджета является предметом переговоров (см. главу 3). В то же время ваш менеджер ведет себя в некоторой степени наивно, если он, будучи недовольным “раздуванием” плана и бюджета, полагает, что вы сможете завершить проект в смехотворно корот­ кий срок, принятый без вашего ведома. Такой срок мо­ жет быть установлен и под влиянием менталитета “Морского Корпуса” (см. подраздел 1.3.5). Наконец, принятие отделом маркетинга смехотворного плана и бюджета может быть результатом политических игр, о которых говорилось ранее; менеджера по маркетингу вряд ли волнует реалистичность предлагаемого им плана и бюджета, поскольку его основная цель — получить комиссионное вознаграждение или доставить удовольст­ вие своему боссу. Представим себе, что наш безнадежный проект — это результат “наивности в чистом виде”, свободной от политики или каких-либо других злонамеренных воздей­ ствий. Главный вопрос заключается в следующем: что делать? Как было отмечено выше, определяющим фак­ тором является вероятность того, что лица, принимаю­ щие решения, пересмотрят свои бюджеты и планы, ко­

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

1.3.3 Наивный юношеский оптимизм: “ Мы сможем сделать это за выходные!” Руководство компании чаще всего критикуют за при­ нятие нелепых решений, связанных с безнадежными проектами, хотя технические специалисты тоже не такие уж невинные агнцы. Во многих случаях высшее руковод­ ство, к счастью, осознает свою неопытность в вопросах оценки и планирования сложных проектов. Оно обяза­ тельно будет консультироваться относительно продол­ жительности проекта с каким-нибудь технократом-со­ рвиголовой, которого, может быть, только неделю как назначили на высокую руководящую должность. Если этот технократ честолюбив и полон молодого оптимизма (что напоминает юношеские фантазии о бес­ смертии, всемогуществе и всеведении), он ответит: “Нет проблем! Мы можем покончить с этой ерундой за выходные!” Высококвалифицированный программист (правда, здесь больше подходит определение “хакер” )

твердо уверен, что может разработать любую систему за выходные. Такие незначительные мелочи, как докумен­ тирование, отладка, тестирование и проработка пользо­ вательского интерфейса, настолько скучны, что нечего о них и говорить. Если вы оптимистичный программист и при этом от­ ветственны за оценку параметров проекта, то, скорее всего, не представляете себе, что вы делаете. Вероятно, вы прочли последний абзац, немедленно оскорбились и подумали: “Черт возьми! Я в самом деле могу разрабо­ тать любую систему за выходные!” Господи благослови вас; может статься, вы и преуспеете. В любом случае, что бы вы ни услышали от старого ворчуна вроде меня, вряд ли это изменит ваше мнение. Однако, если вы — закаленный в битвах ветеран, за­ мечаете, что вас почти втянули в безнадежный проект, поскольку какой-то молодой и наивный технический ме­ неджер взял на себя смехотворные обязательства отно­ сительно плана, бюджета и ресурсов, то вам, по-моему, лучше всего спасаться бегством. Когда до таких менед­ жеров дойдет, что они пытаются прыгнуть выше головы, они впадают в состояние коллапса, что выражается в непредсказуемом поведении или полной беспомощно­ сти. В большинстве случаев им никогда не приходилось прежде иметь дело с такими большими и сложными про­ блемами, которые невозможно решить ни гениальным умом, ни грубой силой (например, кодируя без переку­ ров 48 часов в выходные). В любом случае, когда проект не уложится в срок, для них будет весьма неприятно услышать от вас: “А я ведь тебя предупреждал!”.

1.3.4 Менталитет первопроходцев у неопытных предпринимателей Я не просто наблюдал такие проекты со стороны, а сам участвовал в них, причем иногда отвечал за развер­ тывание работ. Когда я писал эту книгу, случилось так,

что любая начинающая компания со словом .с о т в сво­ ем названии или названии ее продукта могла получить такой начальный капитал, что не знала, как им распоря­ жаться. Но чаще начинающие компании недоукомплектованы специалистами и менеджерами, не имеют доста­ точного финансирования и слепо верят в свои шансы на успех. Так и должно быть, поскольку предусмотритель­ ный и консервативный менеджер никогда не подумает о создании новой компании без тщательного планирова­ ния и крупной суммы на банковском счете на случай не­ предвиденных расходов. Возникшие сравнительно недавно Интернет-компа­ нии, быть может, представляют собой наиболее экст­ равагантный пример этого явления, но далеко не единственный. Индустрия ПО порождает множество начинающих компаний с 1960-х годов, если не рань­ ше, и этот процесс будет продолжаться до тех пор, пока у интеллектуалов не перестанут возникать новые технологические идеи. По определению, высокий процент проектов, связан­ ных с начинающими компаниями, — это безнадежные проекты. Большая их часть заканчивается крахом как самих проектов, так и компаний вместе с ними. Се ля ви — такова судьба почти всех начинаний в области вы­ соких технологий (особенно в США). Воспитанный в та­ ких условиях, я думаю, что это вполне нормально (моя позиция подкрепляется также тем, что я достаточно удачно завершил несколько таких начинаний). Несо­ мненно, такой сценарий развития событий часто являет­ ся одним из положительных мотивов для начинания без­ надежного проекта, что будет детально обсуждаться в подразделе 1.4. Далеко не каждый знаком с культурой и средой на­ чинающих компаний. Если последние 20 лет вы рабо­ тали в каком-нибудь дряхлеющем государственном уч­ реждении, окруженный пишущими на КОБОЛе зомби (то же самое можно сказать и про большинство бан-

ков, страховых и телефонных компаний), и буквально только что вследствие даунсайзинга, аутсорсинга1 или реинжиниринга оказались на работе в начинающей фирме, вряд ли у вас имеются какие-либо перспекти­ вы. Безнадежные проекты имеют место и в больших корпорациях, но там в штат проекта, как правило, включаются разные лишние люди из “Ночи Живых Мертвецов " . В безнадежных проектах начинающих компаний обстановка совершенно другая, она подобна избытку адреналина. В то же время начинающие компании часто страдают разновидностью наивного оптимизма, многие из которых основываются технарями-сверхэнтузиастами, убежден­ ными, что их новая технология сделает их богаче Билла Гейтса; другие создаются гениями маркетинга, считаю­ щими, что смогут продавать доверчивым эскимосам холодильники с возможностями Интернета!. Оптими­ стичный настрой важен для любого начинающего пред­ приятия, его успех может зависеть от деятельности, которой ранее никто не занимался. Но даже самая аг­ рессивная и оптимистичная компания вынуждена подчи­ няться основным законам физики и математики. Если вы вовлечены в безнадежный проект начинающей ком­ пании, проверьте, существует ли какой-нибудь план достижения успеха или все это предприятие — воздуш­ ный замок.

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

1.3.5 Менталитет “ Морского Корпуса” : Настоящие программисты могут работать без сна! Начинающие компании временами оказываются под­ верженными синдрому “Морского Корпуса” , однако мне чаще приходилось наблюдать его в консалтинговых ор­ ганизациях вроде EDS и аудиторских фирм из Big-X (я написал “X” , потому что раньше это была Большая Шестерка, а нынешние корпоративные скандалы могут превратить ее в Большую Единицу). Этот синдром мо­ жет быть отражением особенностей характера основа­ телей фирмы или внутрикорпоративной культуры в це­ лом. Так, например, обстоит дело с корпоративной культурой Microsoft. По существу, ваш ближайший ме­ неджер просто скажет: “Этот проект ничем не отличает­ ся от других, потому что мы всегда так работаем. Это приносит нам успех, и мы этим гордимся, черт возьми. Если вас это не устраивает, то вам здесь нечего делать” . Является ли такая позиция цивилизованной, гуман­ ной или верной, — это тема для отдельного разговора. Другой вопрос, разумеется, насколько она приносит ус­ пех. Важно понять, что она не случайная, а обдуман­ ная. Если вы — революционер или мученик, то можете повоевать с корпоративной культурой, но вряд ли у вас при этом хоть что-нибудь получится. Вероятно, в целом культура, порождаемая безнадежными проектами, бу­ дет иметь долговременные негативные последствия, в частности, будут потихоньку увольняться лучшие спе­ циалисты, и сама компания может в конце концов раз­ валиться. Однако когда имеешь дело с конкретным без­ надежным проектом, бессмысленно спрашивать, почему у него такие нереальные сроки и бюджет. Как отвечает типичный менеджер такой компании: “ Если вас это не устраивает, то вам здесь нечего делать” . Иногда такая позиция компании имеет официальное обоснование — например, “ мы работаем в условиях

жесткой конкуренции, и все наши конкуренты не глупее нас. Единственный путь к успеху — работать вдвое ин­ тенсивнее”. Бывает также, что целью безнадежного проекта является естественный отбор среди самых мо­ лодых (слабых) сотрудников, чтобы только выжившие в проекте достигли высокого статуса “Партнера" или “Вице-президента”. Независимо от обоснования, такая позиция обычно выдерживается весьма последователь­ но, и нет смысла затевать бучу из-за одного-единственного проекта. Это не означает, что вам следует согласиться участ­ вовать в таком проекте; из того, что все проекты данной организации — безнадежные, вовсе не следует, что вы сумеете преуспеть или вообще выжить в нем. Ясно только то, что причины, порождающие безнадежные проекты, вполне понятны.

1.3.6 Высокая конкуренция, порожденная глобализацией рынков Некоторые организации, не допускавшие в прошлом никаких безнадежных проектов, в 21-м столетии вынуж­ дены сделать это просто по причине возросшего уров­ ня конкуренции, связанного с глобализацией рынков. Вторичными факторами в данном случае являются гло­ бальные телекоммуникации (включая Интернет) и пра­ вительственные решения, открывающие ранее закры­ тые секторы рынка и ликвидирующие специальные тарифы и квоты. Для некоторых организаций все это не так уж и ново. Например, автомобильная и электронная про­ мышленность имеют дело с высокой конкуренцией с начала 70-х годов. Для других организаций появление европейских и азиатских конкурентов на североамери­ канском рынке оказалось для них настоящим шоком.

Когда высшее руководство осознает реальность серьез­ ной конкуренции, оно может пойти на различные ради­ кальные меры от даунсайзинга до аутсорсинга, но мо­ жет также решить встретить конкурентов во всеоружии с новым продуктом или услугой, которые, в свою оче­ редь, потребуют для своей поддержки создания новой, претенциозной системы. Вот вам, пожалуйста, и безна­ дежный проект. Относительно недавний вариант этого феномена гло­ бализации — аутсорсинг, связанный с оффшорными компаниями Индии, Китая, России и других стран. По­ сетив ряд таких компаний, могу засвидетельствовать, что они, как правило, не являются “ потовыжималками” , которые заставляют своих программистов работать по 16 часов в день и семь дней в неделю. Однако низкая стоимость оффшорного программирования заставляет американские компании более серьезно нагружать сво­ их высокооплачиваемых программистов. Безнадежные проекты становятся для многих компаний обычным де­ лом, поскольку единственный способ выдержать конку­ ренцию — выбросить продукт на рынок раньше других и по низким ценам, и эта ситуация не меняется даже с экономическим ростом.

1.3.7 Высокая конкуренция, вызванная появлением новых технологий Конкуренция на расширяющемся рынке зачастую вызывает необходимость принятия защитных мер, но может также привести к активной и агрессивной поли­ тике. “ Если мы создадим эту новую систему с двухбайто­ выми символами, тогда мы сможем продавать наши продукты в Японии” . Точно такж е появление принципи­ ально новой технологии может вызвать у компании (ко­ торую вполне устраивают продукты, созданные с помо-

щью прежней технологии) защитную реакцию; лиос может привести к смелому решению использовать но­ вую технологию для получения преимущества в конку­ рентной борьбе. Во время написания этой книги техно­ логии, подобные беспроводным вычислениям или Web, представляли собой очевидный пример такого феноме­ на. Самое замечательное в нашей индустрии то, что та­ кие технологии появляются через несколько лет. Если реакция корпорации на новую технологию явля­ ется в основном защитной по своей природе, то безна­ дежный проект может быть результатом попытки вы­ жать из старой технологии гораздо больше, чем она может дать. Поэтому, если организация вложила в ста­ рую технологию и соответствующую инфраструктуру слишком много средств, чтобы совсем от нее отказаться, она может попытаться перепрограммировать свои ста­ рые системы, потребовав при этом, чтобы программи­ сты нашли способы сделать их в десять раз производи­ тельней и привлекательней. Многие безнадежные проекты данной категории связаны с применением в первый раз новых техноло­ гий. Вспомните первые проекты в вашей организации, связанные с объектно-ориентированной технологией, технологией “клиент-сервер”, реляционными базами данных или Internet/Java. Некоторые из них носили экспериментальный характер и имели целью извлече­ ние потенциальных выгод из новой технологии, однако другие, вероятно, были ответом конкурентам, вне­ дрившим такую же технологию. В последнем случае такие проекты могут быть непомерно большими, а также отягощенными чрезвычайно агрессивными пла­ нами и бюджетами. В то же время самым серьезным фактором безнадеж­ ности проекта, помимо его масштаба, плана и бюджета, является попытка использовать неопробованную техно­ логию в критически важных приложениях. Даже если технология в принципе применима, она может не го­

диться для крупномасштабного применения; никто не знает, как использовать ее преимущества и избежать ее недостатков; у поставщика нет опыта ее поддержки и т.д., и т.п. Все это может восприниматься участниками старой проектной команды (теми, кто помнит “старое доброе время” языков FORTRAN II и Ассемблера) как неприят­ ный опыт, важно помнить, что молодые технари и ме­ неджеры предпочитают эти новые технологии именно потому, что они новые. И это те же самые люди, кото­ рых я ранее характеризовал как наивных оптимистов по отношению к условиям ограниченных планов и бюдже­ тов, в которых они работают. Что же удивительного в том, что все трудятся до позднего вечера и в выходные, пытаясь придать экспериментальной новой технологии некоторое подобие работоспособной, а проекты при этом вырождаются в безнадежные?

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

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

1.3.9 Неожиданный и/или незапланированный кризис Вообразите, что два самых лучших программиста только что пришли к вам в офис, чтобы сказать, (а) что они вступают в брак, (б) что они вступают в группу мис­ сионеров, которая будет строить больницы в джунглях

Африки и (в) сегодня последний день их работы. Или ваш сетевой администратор звонит и сообщает, что ваш поставщик только что обанкротился, а чтобы использо­ вать сетевой протокол другого поставщика, необходимо за следующие 30 дней все перепрограммировать. Или ваш юридический отдел звонит и сообщает, что компа­ нии предъявлен судебный иск на невообразимую сумму , потому что она нарушила подпункт 13(6) Указа Q о ка­ ком-то скрытом налоге, о котором даже никто и не знал. Или... Конечно, можно возразить, что в компании с хоро­ шим руководством такие вещи, как возможный уход двух лучших программистов, стараются предвидеть заранее и быть к ним готовыми. И вы не так глупы, чтобы полно­ стью зависеть от единственного поставщика телекомму­ никационного оборудования. И руководство должно быть предусмотрительным, чтобы детально изучить Указ Q. В представлении идеалиста такие кризисы — резуль­ тат плохого планирования и плохого руководства; “ неза­ планированный кризис” — это нонсенс. Может быть, так оно и есть, но на практике стано­ вится все труднее предвидеть и планировать возможные казусы, которые случаются в мире бизнеса. Хорошо это или плохо, но мы живем в мире хаоса, и безнадежные проекты — это естественное следствие такого хаоса. В самом деле, даже если мы хорошо представляем себе, что в будущем может произойти в подобном хаотическом мире, мы в состоянии отреагировать на это только без­ надежными проектами. Например, каждый, кто живет поблизости от разлома Сан Андреас в Калифорнии, зна­ ет, что там рано или поздно произойдет крупное земле­ трясение. Однако это не остановило начало работы над массой всяких проектов буквально на следующий день после того, как западная половина штата оказалась не­ множко ближе к Тихому Океану. В самом деле, даже если нам точно известно, когда произойдет кризис, все равно начинаются безнадежные

проекты, поскольку руководство склонно до самого последнего момента не думать о проблемах. Как еще можно объяснить панику, охватившую многие IS/IT-ор­ ганизации, когда на горизонте замаячила проблема 2000 года? Мы давно знали о наступлении 1 января 2000 г. и что эту дату никак нельзя отодвинуть. Мы точ­ но знали, в чем заключается суть проблемы и что для ее решения не требуются никакие новомодные технологии вроде Java. Почему же тогда так много безнадежных проектов, связанных с решением проблемы 2000 г., было начато в 1998 и 1999 гг? В любом случае непредвиденный кризис может по­ влечь за собой самые разнообразные безнадежные проекты. В худшем варианте конечный срок таких проектов — “ вчера, если не раньше”, поскольку кри­ зис уже наступил, и ситуация будет ухудшаться до тех пор, пока внедрение новой системы не позволит ре­ шить проблемы. В других случаях, например при не­ ожиданном увольнении ключевых разработчиков, “нормальный” в обычных условиях проект превраща­ ется в безнадежный. Такая ситуация приводит к возникновению наихуд­ ших разновидностей безнадежных проектов, поскольку заранее предвосхитить ее невозможно. Если к тому же еще имеет место синдром “Морского Корпуса”, о ко­ тором говорилось выше, такое положение вообще не должно никого удивлять. С самого первого дня работы над проектом все знают, что для его выполнения потре­ буется приложить много усилий. А представители моло­ дых компаний, начинающих безнадежный проект, испы­ тывают особенное волнение и возбуждение, ведь его успех сделает всех сказочно богатыми.

1.4 Почему люди участвуют в безнадежных проектах? В предыдущем разделе шла речь о том, что организа­ ции начинают и/или допускают существование безна­ дежных проектов по вполне определенным причинам. Мы можем с ними соглашаться или нет, можем сочувст­ вовать тем, кто оказался в кризисной ситуации, но, в конце концов, должны принять эти проекты безогово­ рочно. Однако это вовсе не означает, что мы как индивидуу­ мы обязаны лично участвовать в безнадежных проектах. В своей книге я в основном исхожу из предположения, что вы будете участвовать в безнадежном проекте, хотя в дальнейшем я советую в определенных обстоятельст­ вах отказаться от участия. И в большинстве случаев это лучше сделать в самом начале проекта. Когда вам гово­ рят, что вас решили включить в такой проект в качестве менеджера или технического специалиста, следовало бы ответить: “ Благодарю покорно! Я лучше постою в сторо­ не”. Если же для вашей внутрикорпоративной культуры такой ответ неприемлем, вы почти всегда оставляете за собой право сказать: “ Благодарю! Я лучше уволюсь” . Некоторые разработчики и, вероятно, еще в большей степени менеджеры возразят, что такой вариант им практически не подходит. Далее мы остановимся на этой теме, а сейчас важно отметить, что это одна из несколь­ ких возможных “негативных” причин участия в безна­ дежном проекте; в этом нет ничего хорошего, но, воз­ можно, альтернативы еще хуже. С другой стороны, некоторые разработчики (и менеджеры) с радостью со­ глашаются участвовать в таких проектах; спрашивается, почему же (не считая наивных оптимистов) нормальный здравомыслящий человек добровольно соглашается уча­ ствовать в проекте, где ему, скорее всего, придется ра­ ботать 14 часов вдень, 7 дней в неделю и год или два без отпуска?

Наиболее распространенные причины приведены в таблице 1.2, ниже они будут подробно обсуждаться. Таблица 1.2 Причины участия в безнадежных проектах

Риск высок, но вознаграждение тоже Синдром покорителей Эвереста Удовольствие “вкалывать" среди других таких же энтузиастов Наивность и оптимизм молодости Альтернатива — безработица Возможность будущей карьеры Альтернатива — банкротство или прочие разные бедствия Возможность победить бюрократию Месть

Этот список далеко не полон. Кевин Хьюгенс на од­ ном из недавних совещаний предложил своей проектной команде устроить небольшой мозговой штурм, в ходе ко­ торого был выработан следующий список: 1. Почему трезвомыслящие люди соглашаются участ­ вовать в безнадежном проекте? 2. Если ваш коллега собирается стать менеджером безнадежного проекта, что бы вы посоветовали ему сде­ лать? 3. Наоборот, что бы вы посоветовали ему не делать ни при каких обстоятельствах?

Таблица 1.3 Еще несколько причин участия в безнадежных проектах

Каждый хочет быть нужным

Ожидаемые возможности

Ожидаемые доходы

Не могу позволить себе потерять работу

Приглашение со стороны возгла­ вить проект

Желание преодолеть неуверен­ ность в себе

Возможность поработать с новой технологией, невзирая на воз­ можный провал проекта

Обучение новой технологии в процессе работы

Вечный оптимизм

Вызов

Явная глупость

Шанс самоутвердиться

Работу надо выполнять

Это всего лишь проект

Проектом руководит мой друг

Проектом руководит мой брат (это еще важнее, чем друг)

Мой босс сказал, что так надо

Я не мыслю себе другой жизни

Лучшего дела не существует

Получение дивидендов по акциям

Ожидание повышения зарплаты по сравнению с имеющейся

Любовь слепа

Формирование послужного списка

Безразличие

Чувство товарищества

Ожидание, что проект продлится недолго

I

Естественно, все сказанное предполагает, что вы з а ­ ранее знаете о безнадежности проекта. Как отмечает эксперт Дейв Кляйст, это не так просто, когда вас ин­ тервьюируют по поводу новой работы:

Вряд ли можно где-нибудь увидеть объяв­ ление о найме для участия в безнадежном проекте. Какой смысл спрашивать: “Хотите ли вы работать сверхурочно без какой-либо прибавки к зарплате?”...- На самом деле, без­ надежные проекты редко объявляются тако­ выми во всеуслышание, и вам придется дос­ таточно долго проработать в нанявшей вас компании, прежде чем удастся обнаружить, что она обладает склонностью плодить без­ надежные проекты.

Как отмечает Стив Бентинг, иногда приходится стал­ киваться с неприятными сюрпризами: Первое время проект кажется довольно хо­ рошо продуманным. У проекта есть лидер, есть реально заинтересованное лицо в руко­ водстве, план выглядит достаточно солид­ ным, а участники проекта — квалифицирован­ ными. Над таким проектом действительно хочется работать. Но в один прекрасный мо­ мент все летит кувырком, потому что руко­ водство увлеклось политическими играми, план основывался, как оказалось, на неверных предпосылках, и один или два ключевых разра­ ботчика вдруг закапризничали. Как ни старай­ ся, невозможно полностью застраховаться от ошибок. Не хочется верить, что такое может повториться сначала. (Лично я участвовал в одном крупном проекте, но он закончился весь­ ма неудачно. Срок завершения был перенесен с октября 1994 г. на март 1995 г. Я работал над планом действий в непредвиденных ситуациях до самого конца и ушел вслед за большинст­ вом участников проекта в январе 1995 г. Но­ вая система так до сих пор и не разработана.

В настоящий момент компания пытается приобрести другую систему, которая не обла­ дает и половиной требуемой первоначально функциональности.)

1.4.1 Риск высок, но и вознаграждение тоже Наилучший пример данной ситуации — это работа в начинающей компании, которая обсуждалась в подраз­ деле 1.3.4. Если вы заверите участников проекта, что его успех принесет компании всеобщую известность, а им поможет стать миллионерами, то они с радостью бу­ дут работать до изнеможения. Конечно, они могут отда­ вать себе отчет в рискованности этой затеи, но, по­ скольку многие верят, что они всемогущи и бессмертны, они не обратят особого внимания на риск. В самом деле, если принимать во внимание влияние западной культуры (особенно в США), то вовсе не уди­ вительно наблюдать, как молодые программисты готовы добровольно участвовать в безнадежных проектах. Мы не устаем повторять, что успех кинозвезд, рок-певцов, выдающихся спортсменов и олимпийских чемпионов, а также лидеров в софтверном бизнесе объясняется их колоссальной энергией, огромной работоспособностью и готовностью пожертвовать личной жизнью для дости­ жения успеха. Мы никогда не слышали о том, чтобы ус­ пех могли принести хитрость и двуличность, сомнитель­ ные сделки и противозаконная деятельность. И нам редко приходится слышать, что удачу приносит умение оказаться в нужном месте в нужное время. Например, Билл Гейтс — книжный образ удачливого бизнесмена; однако, если бы группа руководителей IBM не появи­ лась в Сиэтле, чтобы взглянуть на операционную систе­ му для ПК, и если бы Гейтс не оказался под рукой в то время, как IBM не смогла дождаться результата от сво-

его первоначального подрядчика, кто знает, где была бы Microsoft сегодня? И еще один момент: мы не слишком много знаем о реальных последствиях тех “жертв”, которые обычно требует безнадежный проект — жертв, связанных с фи­ зическим и психическим здоровьем, человеческими взаимоотношениями. Все это кажется неважным для 22-летнего специалиста и для необщительных интравер­ тов, которые полностью поглощены работой на компью­ терах. С другой стороны, несколько удивляет, что среди 40- и 50-летних тоже оказываются добровольные участ­ ники безнадежных проектов; ведь они не только знают, что большинство таких проектов обречено на провал, но и убедились (на своем же горьком опыте!), что бессмыс­ ленно жертвовать своей семейной жизнью и хорошими отношениями с детьми. В конце концов, это личный выбор каждого, и он зависит от системы ценностей. Не будем больше го­ ворить на тему о том, что хорошо и что плохо. Хоте­ лось бы только подчеркнуть, что я совсем не негатив­ но отношусь к участию в безнадежных проектах, как можно подумать из сказанного выше. Думаю, что я не так наивен, как в начале своей компьтерной карьеры в середине 1960-х годов, но-меня все еще привлекает предпринимательство. Предложите мне более высо­ кое вознаграждение, и я брошусь в еще один безна­ дежный проект. Вознаграждение бывает не только денежным. Иногда просто приятно получить похвалу от руководителя про­ екта или доказать самому себе, что вы можете не расте­ ряться в сложившейся ситуации. Как отмечает Шэрон Марш Робертс: Вполне понятно, когда неопытные разра­ ботчики ПО попадают под влияние руководи­ телей, утверждающих, что их сверхчеловече­ ские усилия помогут победить коммунизм, вылечить рак и т.д. Однако, когда вы слыши­

те подобные басни во второй или в третий раз, это звучит, как заигранная пластинка. Почему же мы снова и снова попадаемся на один и тот же крючок? Потому что "герои” необходимы, нужны и желанны. Только они займут свое место в ис­ тории, поскольку могут встать на защиту проекта от провала. Такие люди буквально горят желанием ту­ шить пожары. Если тебе удает ся выиграть в одном случае из десяти, в то время как ос­ тальные всегда проигрывают, почему бы тебе тоже не быть героем ?

1.4.2 Синдром покорителей Эвереста Почему люди штурмуют такие опасные горы, как Эверест, несмотря на риск и мучения? Почему они уча­ ствуют в марафонских забегах и многоборье, несмотря на физическую усталость? Потому что этим они бросают вызов окружающим, пытаясь совершить то, что никому не удавалось сделать. И это еще больше возбуждает. Например, из шести миллиардов людей на планете толь­ ко один может сказать: “Я был первым человеком, сту­ пившим на Луну” . Кто-то может подумать, что даже сама попытка совершить нечто подобное — это безумие и эгоизм. А другие, наоборот, хотели бы преодолеть все преграды для того, чтобы прославиться и завоевать об­ щественное признание. Как заметил в письме ко мне консультант Эл Кристианс: Существует много занятий, вызывающих подобное удивление. Работа шахтера, ковбоя, лесоруба, летчика-истребителя, подводника и даже мойщика окон высотных зданий имеет много отрицательных моментов, более опас­ ных, чем в проектировании ПО, и, тем не ме-

нее, в каждой из этих профессий есть люди, которые не мыслят себя вне ее.

То же самое можно сказать и про безнадежные софт­ верные проекты. В 1983 г. я посетил разработчиков проекта Macintosh за несколько месяцев до официаль­ ного выхода продукта на рынок. Я был просто поражен их энергией. Одна из причин, побуждающих их долго и интенсивно работать, состояла в следующем: имея дело с маниакальной личностью Стива Джобса, участники команды были абсолютно уверены (отчасти благодаря харизме Джобса), что Macintosh должен произвести революцию в персональных вычислениях. Они были счастливы. С точки зрения такой перспективы даже провален­ ные безнадежные проекты могут выглядеть довольно значительными. В эту категорию попадает бесчислен­ ное множество проектов в Силиконовой Долине. Не­ смотря на то, что их провал влечет за собой банкротство целых компаний, разводы, язвенные болезни, нервные расстройства и многое другое, люди, участвовавшие в таких проектах, все еще с гордостью говорят о своем опыте. “Я работал над созданием системы Toys.com, это была настоящая революция в программном обеспе­ чении!” — скажет закаленный ветеран охваченному благоговением стажеру. Хотя такие проекты могут никогда не попасть на пер­ вые страницы Computenvorld, тем не менее в больших корпорациях выполняется множество амбициозных про­ ектов, и разработчики приложений с радостью соглаша­ ются участвовать в них. “Корпоративный Эверест” вы­ глядит в их глазах весьма достойным вызовом. Иногда такие проекты заканчиваются провалом, потому что пользователи на рынке и в самой корпорации не нужда­ ются в такой чудесной и революционной системе; ино­ гда — потому, что проектная команда хватает больше, чем может съесть, и обещает больше, чем может сде­ лать.

Если вас все же одолевает массовый психоз в ра­ боте над безнадежным проектом типа “ покорения Эвереста” , не забывайте про две важные вещи. Вопервых, остерегайтесь проектов, которые заранее об­ речены на неудачу. Предположим, кто-то сказал вам, что есть возможность принять участие в первой экс­ педиции на Марс и, даже более того, вам может вы­ пасть честь оказаться первым человеком, ступившим на поверхность Марса. “ Разумеется, — продолжал бы ваш менеджер проекта, — у вас не будет никаких кислородных баллонов, потому что в космическом ко­ рабле не хватает места для дополнительного груза. Это означает, что вы наверняка погибнете — однако подумайте о чести и славе, которая вас ждет!” Более детально такие проекты (под названием “ камикадзе” ) будут обсуждаться в главе 3, а описанный выше сце­ нарий говорит сам за себя. Во-вторых, следует остерегаться таких ситуаций, ко­ гда грандиозная задача, поставленная руководством кор­ порации (или владельцем вашей софтверной компании), может впоследствии оказаться совсем не такой важной. Особенно опасно, когда проблема по своей природе яв­ ляется чисто технической, например, “Мы будем первы­ ми людьми на Земле, сумевшими уместить операцион­ ную систему с функциональностью Windows ХР в 128К ROM !”. Да, это было бы замечательное техническое достижение, ну и что с того? Хорошая мысль — регулярно задавать такой вопрос на каждое очередное сообщение руководства корпора­ ции. Например, вам говорят: “Такая Windows ХР смо­ жет уместиться в ваших наручных часах!” , а вы в ответ снова спрашиваете: “ Ну и что?” В конце концов, ответы могут оказаться настолько глупыми, что это само собой вернет вас на грешную землю. Вообразите, что ваш босс отвечает на второй вопрос “ ну и что?” следующее: “ Если мы сможем сжать до такого же размера систему распо­ знавания речи, то можно будет писать программы на

Visual C + + , прогуливаясь по улице и разговаривая со своими часами!” Без сомнения, найдется несколько десятков програм­ мистов, которые воскликнут: “Здорово/” и добровольно согласятся посвятить следующие три года своей жизни такому проекту. Для них не имеет значения, что ни один разумный человек не будет пользоваться такой систе­ мой; достаточным оправданием служит сама техниче­ ская проблема. Размещение Windows ХР, системы рас­ познавания речи и Visual C + + в 128К ROM даст вам право на высшую степень бахвальства перед любым со­ бранием хакеров и программистов; если это именно то, ради чего вы живете, то — вперед. Еще одна хорошая мысль — простым нетехническим языком изложить суть проекта своей супруге, родителям или детям. Они спросят: “Ну и что? Ты собираешься угробить свои вечера, выходные и отпуска на два года вперед только для того, чтобы впихнуть Windows ХР в наручные часы? Зачем вообще это нужно делать}" Если вы в состоянии ответить на эти вопросы, не чувст­ вуя себя полным идиотом, то можете с чистой совестью участвовать в этом проекте. Наихудшей разновидностью проекта “покорения Эвереста” является тот, где решаемая проблема имеет чрезвычайно важное значение для руководства корпо­ рации, но ровным счетом никакого значения для любого, кто остановится и задумается о ней хотя бы на секунду. “ Почему мы должны участвовать в этом безнадежном проекте, босс?”, — невинно спросит молодой програм­ мист. “Потому, — ответит босс с праведным негодова­ нием, — что это увеличит доход нашей корпорации на одну акцию на целых 3,14159 цента!” Это означает, что если программиста вполне удовлетворяет обладание сотней акций своей компании, и если каждый цент из возросших доходов будет выплачен в виде дивидендов, то он получит огромные деньги — целых 3,14 доллара; и, если реакция Уолл-стрит на успех проекта будет на­

столько замечательной, что акции подорожают на один доллар, то чистый доход программиста увеличится еще на какую-нибудь сотню долларов. “ И это все, что я буду иметь за тысячи часов сверхурочной работы, босс?” , — спросит программист. Но босс будет хранить молчание, потому что честный ответ (и он прекрасно это знает) — ничего. Такой проект лишен какой-либо привлекатель­ ности, не использует новых технологий и вероятность его провала — не меньше 75% . Но, по-моему, еще хуже тот случай, когда босс умышленно вводит в заблуждение проектную команду, заставляя ее поверить, что проект сродни покорению Эвереста, в то время как он прекрасно знает, что это не так. Представьте себе, что участник проектной команды спрашивает: “ Почему мы должны так стараться, чтобы разработать на COBOL эту пакетную систему резерви­ рования авиабилетов для мэйнфрейма всего за шесть месяцев, босс?” Тот скорее всего ответит: “ Потому что раньше во всей авиационной индустрии никто даже не пытался сделать это быстрее, чем за три года!” Может быть, это на самом деле серьезная техническая задача, заслуживающая внимания, но это совсем не та техноло­ гия, с которой я бы хотел иметь дело в XXI веке. В лю­ бом случае, этот проект выглядит безнадежным не из-за решаемой технической проблемы, а из-за смехотворных сроков. Почему же менеджер проекта поступает таким образом? Причины могут быть самыми разными. Одна­ ко вряд ли всем этим можно будет гордиться год спустя.

1.4.3 Наивность и оптимизм молодости Наша индустрия молода. Многие вызывающие про­ екты выполняют и возглавляют люди, которым нет еще и 30 лет. Для безнадежного проекта нет ничего необыч­ ного, если все технические специалисты в проектной команде моложе 25 лет. Они напоминают мне пилотов-

истребителей, призванных в Военно-Воздушные Силы во время Второй Мировой и вьетнамской войн: такие же молодые идеалисты, абсолютно убежденные, что они могут все. Как отметил Дэвид Максвелл: Проекты подобны вступлению в брак. Пона­ чалу мы наивны и полны надежд, однако со вре­ менем реальность вынуждает нас умерить свои надежды. Существует много причин, не имеющих отношения к логике, побуждающих людей вступать в брак. То же самое можно сказать о проектах. Молодые менеджеры и разработчики изо всех сил стремятся про­ явить себя и проверить свои силы, поэтому безнадежные проекты будут создаваться сно­ ва и снова. Мой личный опыт показывает, что одни и те же ошибки могут повторяться мно­ го раз.

Разумеется, самоуверенность участников проекта выручает в ситуациях, когда обычные проектные коман­ ды терпят поражение. Тот факт, что наиболее успешные продукты — от Lotus 1-2-3 до Netscape Navigator — были разработаны небольшими командами в условиях, неприемлемых для нормальных людей, уже стал фольк­ лором в нашей индустрии. Такие проекты, заканчиваясь успешно, приносят проектной команде известность и славу; даже когда они проваливаются, то зачастую по­ зволяют всем участникам извлечь для себя важные уро­ ки (хотя для организации в целом последствия могут быть катастрофическими!). Важно отметить, что наивность и оптимизм молодо­ сти обычно сочетаются с огромной энергией, целеуст­ ремленностью и отсутствием таких помех, как семейные отношения. Гораздо чаще можно встретить 22-летнего программиста, который готов и жаждет участвовать в безнадежном проекте со 100-часовой рабочей неделей в 'течение года или двух, чем 35-летнего женатого про­

граммиста с двумя детьми и весьма умеренной склонно­ стью к покорению горных вершин. Молодой програм­ мист, желающий участвовать в безнадежном проекте, а также относительно молодой менеджер проекта, даю­ щий оптимистические обещания начальству, как бы утверждают: “ Разумеется, мы обеспечим успех этого проекта и сокрушим все препятствия на своем пути!” Бессмысленно высказывать какое-либо серьезное суждение по этому поводу, Как уже было отмечено выше, наша индустрия привлекает молодых. Я не думаю, что ситуация изменится в ближайшие несколько лет, что молодежь утратит оптимизм, энергию и способности со­ средоточиваться на решении проблем. Что касается их наивности, ничего не поделаешь, эта болезнь проходит только с возрастом.

1.4.4 Альтернатива — безработица Поскольку мы работаем в индустрии молодых опти­ мистов и последние 30— 40 лет наша индустрия непре­ рывно (и временами довольно быстро) развивается, я удивлялся, когда участники безнадежных проектов при­ водили мне этот довод. Но даже наша индустрия не свободна от кризисов. Как раз весной 2003 года, во время написания этой кни­ ги, продолжался спад в области высоких технологий. Тем, кто еще слишком молод, могу напомнить, что по­ добные спады имели место в начале 1990-х, 1980-х и в середине 1970-х годов. Нужно учитывать, что в таких условиях профессио­ нальные знания довольно быстро обесцениваются. За последнее десятилетие произошли огромные изменения, которые помогли людям нашей профессии накопить значительный опыт даунсайзинга, реинжиниринга и аут­ сорсинга. В целом уровень занятости в индустрии ПО возрастает. Однако не забывайте, что спрос на програм­ мистов C + + растет быстрее, чем падает спрос на про-

граммистов COBOL. Кроме того, большие IT-организации, превратившись в огромных бюрократических монстров с тысячами сотрудников, оказались частично подверженными реинжинирингу и даунсайзингу; их выс­ шее руководство часто сокращает менеджеров среднего звена, администраторов и обслуживающий персонал. Все это приобретает особое значение в безнадеж­ ных проектах. Вполне возможно, что нехватка людей в проектной команде является следствием общего со­ кращения штата разработчиков ПО, предпринятого руководством. Аналогично, уменьшение срока разра­ ботки вдвое может быть следствием реинжиниринга, проводимого под лозунгом: организация должна рабо­ тать вдвое продуктивнее, чем прежде (что в переводе на командный язык означает “Работать усерднее! Ра­ ботать быстрее!” ). Поскольку реинжиниринг не является предметом данной книги, мне не хотелось бы давать какие-либо комментарии по поводу его стратегий, предпочитаемых менеджментом. В данном случае важно то, что многие технические специалисты и менеджеры чувствуют скры­ тую угрозу, когда проекты выполняются в такой обста­ новке. Довольно часто бывает так, что несогласие с ка­ кими-либо условиями проекта означает для них увольнение с работы. Для 22-летнего неженатого про­ граммиста это не страшно. Для 35-летнего менеджера проекта, имеющего семью и долги, увольнение может стать серьезной проблемой. Что же касается 45-летнего программиста, специализирующегося лишь на таких языках программирования, как COBOL и CICS, то для него потеря работы может стать катастрофой. В нашей индустрии можно найти даже 55- и 60-летних програм­ мистов, которые вынуждены изо всех сил держаться за свою работу до наступления пенсионного возраста. Для людей среднего и старшего возраста характерна привязанность к своему месту жительства. Причины различны: их супруги работают в том же городе, дети

могут учиться только в местных школах, совесть не по­ зволяет покинуть своих старых родителей и других членов семьи. Это не является проблемой, если рынок труда достаточно велик, однако каждый, кто жил в Пукипси, Нью-Йорк в начале 1990-х, хорошо знает, о чем я говорю. Люди, живущие-в Редмонде, Вашингтон, ве­ роятно, могли сталкиваться с такими же неприятными проблемами 5, 10 или 20 лет назад. Я очень сочувствую профессионалам-разработчикам среднего и более старшего возраста, которые оказались сегодня в сложном положении. Но удивительно, что тех­ нические специалисты усиленно игнорировали тот факт, будто это может случиться именно с ними, несмотря на то, что разнообразные мероприятия по реинжинирингу/даунсайзингу проводятся уже давно. Но это отдель­ ный предмет; я уже обсуждал эти проблемы в своих кни­ гах “Decline and Fall of the American Program m er” и “Rise and Resurrection of the American Program m er”.

Здесь я веду разговор лишь о том, что непосредственно касается безнадежных проектов. Если вам намекают или говорят открытым текстом, что, не согласившись участвовать в проекте со смехо­ творными графиком, бюджетом и ресурсами, вы остане­ тесь без работы, то что вам остается делать? Очевидно, это зависит от вашего финансового, физического, эмо­ ционального и психологического состояния; но, кроме этого, вы должны точно знать положение дел в вашей компании. В некоторых случаях реальная опасность за ­ ключается в следующем: ваше продвижение по службе, премии или рост зарплаты будут остановлены, если вы откажетесь участвовать в проекте (ниже я отдельно ос­ тановлюсь на этой проблеме). Однако, даже если вы те­ ряете работу, помните, что в больших компаниях обычно невозможно претворить эту угрозу в жизнь немедленно. До увольнения у вас может быть два или три месяца в запасе. За это время вы, вероятно, найдете новую работу.

Но если угроза гораздо ближе и ощутимее? Напри­ мер, ваш босс заявляет: “Немедленно соглашайся уча­ ствовать в проекте или собирай свои вещи и выметайся отсюда!” Разумный человек вряд ли сможет работать в такой ситуации, ведь до сих пор обстановка была вполне дружелюбной, пока последняя реинжиниринговая мания не сделала вашего босса неуправляемым лунатиком. Итак, вам предстоит выбор: подписаться, уйти или быть уволенным. Что вы предпочтете? Я советую уйти сразу, потому что потом будет еще хуже. Возможно, придется несколько месяцев посидеть на мели, пока не приобретете опыт в какой-либо новой технологии. Однако впоследствии вы, скорее всего, уви­ дите, что это гораздо лучше, чем, подчинившись обстоя­ тельствам, продолжать работу без какой-либо надежды на улучшение ситуации. Можно согласиться доброволь­ но участвовать в проекте и одновременно, обновив свое резюме, искать новую работу, хотя при этом может воз­ никнуть проблема этического характера, если ваш уход в середине проекта поставит остальных участников команды в трудное положение. Если же вам некуда деваться (близится уход на пен­ сию, ваша специальность не пользуется спросом на рынке или во всем городе один-единственный работода­ тель, а семейные обстоятельства не позволяют никуда уехать), следует убедить себя выработать более пози­ тивное отношение к безнадежному проекту. “Черт возь­ ми, я докажу им, что этот старый пес еще способен ла­ ять”, — скажет среднего возраста ветеран. “Я покажу начальству, что мы ничуть не хуже этих сопливых маль­ чишек, и мы сделаем проект в срок!” Конечно, смелость и позитивный взгляд на вещи просто замечательны, но не забывайте при этом одно обстоятельство: если безна­ дежный проект закончится успешно, за ним последует еще один. Вспомните, что было сказано в начале книги: безнадежные проекты являются нормой, а не ис­ ключением.

1.4.5 Возможность будущей карьеры Иногда “ приглашение” участвовать в безнадежном проекте сопряжено с опасностью поставить будущее продвижение по службе в зависимость от успеха проек­ та и того признания, которое он получит. Зачастую это связано с реинжинирингом. “Только те люди, которые возглавят невероятно сложный проект реинжиниринга Total System 2000, возглавят и сам Мега-Банк в XXI столетии!” Если вы оказались в подобной ситуации, помните, что ключевым фактором здесь является поли­ тика. Люди, делающие ставку на успех безнадежного проекта, могут сами в нем и не участвовать. И менед­ жер, который инициирует безнадежный проект реинжи­ ниринга, вероятно, рассматривает его просто как воз­ можность сделать карьеру. При этом ему совершенно безразлична судьба участников проектной команды. Если вы помните каждое слово из “ Принца '” Маккиавелли, и если политические игры доставляют вам удо­ вольствие, то такие безнадежные проекты как раз для вас. Однако большинство профессиональных разработ­ чиков ПО вряд ли знает иПринца”, они просто испыты­ вают отвращение к политике и абсолютно не уважают тех людей, которые ею увлекается. Если это так, почему же тогда находятся люди, готовые участвовать в проекте Total System 2000 Мега-Банка? Единственный подходя­ щий ответ: они искренне верят, что других таких проек­ тов больше не будет и что этот проект надолго обеспе­ чит им успешное продвижение по службе в Мега-Банке. Если вы верите в это, вы, должно быть, верите и в то, что свиньи умеют летать. В большинстве ситуаций, которые мне приходилось наблюдать, угроза для карьеры является неотъемлемым свойством обсуждаемой ранее принадлежности к “Мор­ скому Корпусу” , и это непреложный факт. Если такая угроза имеет место в вашем первом безнадежном проек­ те, вероятно, то же самое будет во втором, третьем и

четвертом. Начиная работать в какой-либо компании, вы еще слишком простодушны, чтобы всерьез задумать­ ся над долгосрочными последствиями такой политики, но рано или поздно вам придется с ними столкнуться. И тогда у вас только две возможности: принять все как есть или уйти.

1.4.6 Альтернатива — банкротство или прочие разные бедствия Как я уже объяснял, причиной некоторых безнадеж­ ных проектов являются решения относительно реинжи­ ниринга, даунсайзинга и аутсорсинга, принимаемые высшим руководством, которые, в свою очередь, зачас­ тую продиктованы глобальной конкуренцией, неожидан­ ными решениями правительства и т.п. Независимо от причины результат всегда один и тот же: сотрудники компании соглашаются участвовать в проекте, посколь­ ку верят, что альтернативой является банкротство или какие-нибудь другие ужасные бедствия. Нередко ситуа­ ция усугубляется провокационными заявлениями руко­ водства, которое предлагает всем, не желающим участ­ вовать в проекте, немедленно освободить свое место, дабы не мешать тем, кто остается. Мы не обсуждаем здесь, правильно или неправильно действует руководство в подобной ситуации, пытаясь упредить надвигающийся кризис. Кризис наступил, и ру­ ководство затевает безнадежный проект, теперь вам предстоит решить — участвовать в нем или нет. Учитывая ранее сказанное, вы можете предвидеть, каким будет мой совет: отступите на шаг и спросите себя, является этот безнадежный проект исключением или все еще только начинается. Даже если вы выиграете свое сражение, компания может проиграть войну; в самом деле, ваш успех в проекте может оказать компа­ нии медвежью услугу, оттянув ее крах на срок, достаточ­

ный для того, чтобы затеять следующий безнадежный проект. Еще раз повторюсь: ваше решение является сугу­ бо личным. Мотивы, движущие вами, могут быть сле­ дующими: преданность компании, сочувствие или жела­ ние показать всему миру, что вы и ваша компания не собираетесь сдаваться без борьбы. И кто знает, может быть, значительный успех безнадежного проекта сумеет в корне изменить ситуацию. Именно так произошло с фирмой Borland, выпустившей на рынок свой продукт Delphi. Никто не может предсказать будущее безнадеж­ ного проекта; последствия успеха или неудачи проекта. Некоторые компании умирают быстро, другие терпят долгий затяжной кризис, а некоторые успевает кто-ни­ будь купить, пока они окончательно не вступили на путь неудач. Поговорите на эту тему с людьми, которые не имеют своей доли в доходах компании. Может быть, вам удаст­ ся побеседовать с честными и беспристрастными руко­ водителями, которые искренне готовы обсуждать по­ следствия неудачи или успеха безнадежного проекта; но вам следует также помнить, что те же руководители де­ лают карьеру и заботятся о своей зарплате; эгоизм и по­ литическое чутье могут не позволить им сообщить вам какую-либо информацию, жизненно важную для приня­ тия правильного решения.

1.4.7 Возможность победить бюрократию Технические специалисты и менеджеры проектов часто жалуются, что их корпоративные бюрократы ме­ шают продуктивно работать и задерживают разработки ПО. Чем крупнее организация, тем сильнее бюрокра­ тия, и особенно в тех организациях, где служба стандар­ тов требует строгого соблюдения требований SEI-CM M или ISO-9000. Аналогично департамент по управлению

персоналом может использовать процедуры скрупулез­ ной проверки каждого вновь принимаемого на работу сотрудника или стороннего разработчика, привлекаемо­ го к участию в проекте. Безнадежные проекты нередко предоставляют воз­ можность обойти некоторые, если не все, бюрократиче­ ские рогатки — и этого достаточно, чтобы раздражен­ ные бюрократией разработчики ПО принимали участие в таких проектах. В крайнем случае проектная команда перебирается в отдельное здание, где ничто не мешает им выполнять свою работу. Даже в менее экстремаль­ ной ситуации безнадежный проект зачастую дает воз­ можность использовать собственные средства и языки программирования, осваивать новые технологии напо­ добие объектно-ориентированного программирования, а также сокращать большинство громоздких процедур и количество документации, которые в обычных условиях требуются в полном объеме. Не менее важно и то, что менеджер проекта получает большую свободу действий в подборе участников проектной команды, чем в обыч­ ных условиях. В лучшем случае все эти перемены могут превра­ тить безнадежный проект в своего рода цивилизован­ ный эксперимент, поскольку не учитывается целый ряд ограничений на процедуры, технологии или люд­ ские ресурсы, которые обычно угрожают превратить проект в безнадежный. И, если безнадежный проект будет иметь шумный успех, он может послужить ката­ лизатором процесса внедрения используемых техноло­ гических и управленческих новшеств во все другие проекты, выполняемые в организации. И наоборот, провал проекта может послужить подтверждением того, что “стандартные” бюрократические процедуры, в конце концов, не так уж и плохи. В любом случае, подобная ситуация является хоро­ шим предлогом для участия в проекте. В некоторых ор­ ганизациях ряд разработчиков считает своим долгом

всегда участвовать в подобных проектах, поскольку это хороший способ избежать бюрократических ограни­ чений.

1.4.8 Месть Стремление отомстить может показаться не слиш­ ком разумным объяснением участия в безнадежном проекте, но, тем не менее, это может быть именно так. В случае успешного завершения работы над без­ надежным проектом вы можете отстранить от власти некомпетентного вице-президента компании или уте­ реть нос критиканам, которые все время уверяли вас, что в рамках ограниченных сроков и бюджета такой проект выполнить немыслимо. Месть — это весьма сильное чувство, особенно развитое в среде высших руководителей крупных организаций, где обиды запо­ минаются на всю жизнь и хитрые политики могут ме­ сяцами и годами дожидаться возможности отомстить своим противникам. Месть может быть очень мощным личным мотивом, но обычно не так просто внушить это чувство всей про­ ектной команде. Если это случается, то проектная ко­ манда перестает видеть “официальную” цель разработ­ ки, которая была запланирована в проекте, — их первым и высшим приоритетом становится месть. Если вашим личным мотивом является месть, то я могу сказать только одно — это ваши личные пробле­ мы. Но если вы собираетесь участвовать в проекте, в котором менеджер или вся команда из чувства мести готовы согласиться с совершенно неразумными для “нормального” проекта планом и бюджетом, то следует быть особенно осмотрительным. “ Вице-президент — кретин, — может сказать вам менеджер проекта, — и если мы завершим этот проект за шесть месяцев, то он будет выглядеть таким дураком перед Советом Директо­ ров, что ему придется подать в отставку” . Может быть,

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

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

наются в то время, когда корпорации переживают стрессовые ситуации, принимать обдуманные решения сложно; гораздо легче попасть под влияние эмоций ва­ ших друзей-коллег или менеджера. Следует отметить, что некоторые аналитики смотрят на проблему более оптимистично; они полагают, что ко­ личество безнадежных проектов в последующие годы будет уменьшаться. Так, например, Эрик Петерсен в дискуссии весной 2003 г. назвал мне две, по его мнению, причины такого уменьшения: а) рост корпоративной культуры ГТ-компаний; б) обучение разработчиков раз­ личным методам обеспечения качества в сочетании с “быстрой” разработкой ПО. Кроме того, я вовсе не против любых безнадежных проектов; я согласен с мнением моего коллеги Рика Занисера, что такие проекты даже в случае неудачи могут обогатить нас полезным опытом: Как я уже говорил тебе, я думаю, что каж­ дый должен поучаствовать хотя бы в одном таком проекте. Тем не менее, есть и другие дела, по крайней мере одно из которых ты должен выполнить: • провести ночь в тюрьме; • напит ься в стельку; • вырастить сына; • вырастить дочь; • начать свой собственный бизнес; • подняться на гору Фудзи.

Японцы по этому поводу говорят: “ Кому не удалось подняться на гору Фудзи — тот дурак. Тот, кто поднялся на гору Фудзи дважды — еще больший дурак” . Что касается остальной части книги, я исхожу из предположения, что вы уже приняли обдуманное реше­ ние участвовать в проекте, хотя я время от времени буду напоминать вам о возможности выйти из него в процес­ се работы. Будем думать, что в данный момент ваша

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

Библиография 1. John Boddie. Crunch Mode. Yourdon Press/Prentice Hall, 1987. 2. Scott Adams. The Dilbert Principle. HarperBusiness, 1996.

ГЛАВА 2

ПОЛИТИКА

Политика играет вполне определенную роль в любом софтверном проекте, хотим мы этого или нет. Отличи­ тельной чертой безнадежных проектов является на­ столько сильное влияние политики, что она может све­ сти на нет все усилия выполнить хотя бы какую-нибудь работу. Поскольку процессы, связанные с политикой, в особенности ведение переговоров, будут обсуждаться в отдельной главе, здесь важно просто обозначить нали­ чие политики и предложить некоторые общие рекомен­ дации. Некоторые разработчики ПО считают, что по­ скольку политики не избежать, они предпочли бы держаться подальше от всей этой грязи. Это вполне понятное желание — многие из нас, кто всерьез по­ глощен разработкой ПО, социально инертны и поли­ тически наивны: мы не только считаем политические игры тошнотворными, но и уверены, что попытки иг­ рать в политические “ игры” ничем хорошим для нас кончиться не могут. Все это нормально до тех пор, пока кт о-нибудь (обычно менеджер проекта) в со­ стоянии держать политиков в руках. Однако, если все участники безнадежного проекта полагают, что “ по­ скольку данный проект так важен, они оставят нас в покое и избавят от грязных политических игр” , такой проект имеет весьма мало шансов на успех. В данной главе будут обсуждаться четыре аспекта по­ литики:

• идентификация политических “игроков”, вовле­ ченных в проект; • определение сущности проекта; • отношение участников к проекту; • анализ основных проблем, порождающих поли­ тические разногласия.

2.1 Идентификация “ игроков” , вовлеченных в проект Я хочу здесь отметить, что ваши шансы на успех в безнадежном проекте будут равны нулю до тех пор, пока участники проектной команды не узнают ключевых “иг­ роков” . Некоторые из них создают много шума, другие станут друзьями и сторонниками; будут крикливые оппо­ ненты проекта, а также те, кто будет ждать удобного мо­ мента, чтобы нанести менеджеру удар в спину. Обо всем этом легко забыть среди тысячи других административ­ ных и технических проблем, но это очень важно. Я убежден, что каждый участник проекта обязан знать ключевых “игроков”, несмотря на то, что постоян­ но с ними взаимодействует только менеджер проекта. В редких “особо важных” случаях команде удается отго­ родиться от всего остального мира на время выполнения проекта, но это нетипично. В современном мире такие проекты не могут быть полностью изолированы, по­ скольку все взаимодействуют друг с другом посредством электронной почты и Интернета. В нормальной рабочей обстановке каждый участник проекта сотрудничает со своими коллегами — техническими специалистами, а также с вышестоящим руководством и различными представителями сообщества пользователей. Это неиз­ бежно: мы встречаемся с ними в коридоре, кафетерии или в комнате отдыха.

Поэтому, когда участник проекта сталкивается с со­ вершенно невинным, на первый взгляд, телефонным звонком, почтовым сообщением или как бы случайным вопросом типа “ Как движется проект?", который задает дружелюбным тоном один из менеджеров среднего зве­ на, для участника проекта важно знать, кто к нему обра­ щается — друг или враг, и не содержит ли в связи с этим вопрос политический подтекст. Ваш ответ скорее всего станет достоянием всей организации, и ничего удивительного, если содержащаяся в нем информация будет утрирована, искажена или скрыта. Типичными “игроками” в безнадежном проекте явля­ ются следующие: • владелец; • заказчик; • акционер; • заинтересованное лицо; • защитник. Каждая из этих ролей будет обсуждаться ниже.

2.1.1 Владелец Традиционно владелец — это человек, который при­ нимает, санкционирует или финансирует систему и/или результаты проекта. Чрезвычайно важно идентифици­ ровать этого человека и сделать все возможное, чтобы он был удовлетворен ходом проекта. Множество проектов выполняется без малейшего представления их участников о том, кто является владель­ цем. Такая ситуация типична для организаций, где проек­ ты порождаются честолюбивыми и сверхэнергичными ITпрофессионалами, которые стремятся перещеголять друг друга. При этом они говорят: “Держу пари, что отдел мар­ кетинга придет в экстаз, когда увидит эту новую систему,

которую мы разрабатываем для иих”. Очевидно, в органи­ зациях с грамотным руководством такие проекты никогда ие C M O i y r начаться, но главное — можно с трудом найти такие безнадежные проекты, которые начались бы без четкого распоряжения со стороны владельца. Причина очевидна: такие проекты чрезвычайно дороги и/или рис­ кованны и/или ограничены по срокам. Невероятно, чтобы IS/lT-подразделение выдумало такой проект по собствен­ ной инициативе, и бюрократы в организации не позволят включить его в план и финансировать до тех пор, пока не получат четкое и недвусмысленное указание от того, кто имеет на это право. Отсюда следует одно интересное соображение: вла­ делец безнадежного проекта зачастую является руково­ дителем более высокого уровня, чем в случае “нормаль­ ного” проекта. Владельцем может быть президент или исполнительный директор, поскольку проект затрагива­ ет жизненно важные интересы организации. Даже если это всего лишь вице-президент, заметим, что владелец безнадежного проекта обычно имеет гораздо больше полномочий в вопросах дополнительных расходов или исключения бюрократических ограничений, чем в “нор­ мальном” проекте. С другой стороны, одна из проблем, возникающих во многих безнадежных проектах, заключается в том, что менеджер мало или совсем не контактирует с владель­ цем проекта. Различные распоряжения и требования от­ четов о состоянии проекта передаются по цепочке от владельца к менеджеру среднего уровня, который явля­ ется как раз непосредственным начальником менеджера проекта. И все эти посредники между реальным вла­ дельцем и менеджером проекта могут быть, говоря вы­ шеуказанными терминами, пользователями, акционера­ ми, заинтересованными лицами или политическими противниками проекта. Важно помнить, что изначальные требования вла­ дельца проекта могут быть переданы менеджеру проекта

уже в искаженном виде. Часто соглашения трудно дос­ тичь в вопросе окончания работы над проектом: новая супер-система однозначно и безусловно должна быть закончена к 1 января, иначе наступит конец света! Но пока это указание дойдет до менеджера, оно с помощью бюрократии обрастет целым слоем дополнительных тре­ бований, например: в качестве языков программирова­ ния использовать только Ada и RPG; в проектную команду нужно обязательно включить Джорджа, Харри­ ет и Мелвина (потому что они настолько некомпетент­ ны, что их не берут ни в один проект); в проекте должна присутствовать вновь созданная (но никогда не исполь­ зовавшаяся ранее) объектно-ориентированная методо­ логия; еженедельно надо проверять, правильную ли ме­ тодологию использует проектная команда; каждый участник проектной команды должен в конце каждого рабочего дня заполнять 17-страничную форму XJ13 в трех экземплярах... и так можно продолжать до беско­ нечности. В подобных ситуациях встреча с владельцем проекта может способствовать отмене всех этих идиотских тре­ бований, за исключением конечного срока. Однако, если менеджер — официальное лицо, отвечающее за выпол­ нение проекта, он не будет следовать смехотворным правилам (которые сами по себе могут быть серьезной причиной нарушения сроков выполнения проекта). И тогда, возможно, удастся завершить безнадежный проект в соответствии с плановым сроком. И, если вла­ дельца проекта можно убедить в том, что необходимо выделить некоторые дополнительные средства на при­ обретение оборудования, инструментальных средств или на еженедельную пиццу для проектной команды, то ме­ неджеру проекта обычно удается их получить, даже если все скупердяи в организации будут стараться не допус­ тить этого. Очевидно, не все владельцы проектов в такой степе­ ни расположены к сотрудничеству и не все обладают

достаточно высоким положением в организации. Но главное заключается в следующем: идентифицировать владельца важно для любого проекта, а для безна­ дежного — вдвойне. Мой опыт говорит о том, что в большинстве случаев владелец проекта — это друг, а не враг. В интересах владельца разрезать красную ленточ­ ку и избавиться от бюрократических рогаток, что почти всегда является благом для менеджера проекта. Но не надо забывать, что владелец проекта может быть совсем не тем человеком, который будет реально использовать разработанную систему, и вовсе не он один может оказывать влияние на ход выполнения про­ екта. Следует учитывать мнение и других “игроков”, ко­ торые рассматриваются ниже.

2.1.2 Заказчики Заказчик — это тот человек или группа людей, ко­ торые будут использовать разработанную систему по­ сле завершения проекта. Во всем мире их обычно на­ зывают “пользователями”. Заказчики могут быть владельцами безнадежных проектов, однако в боль­ шинстве случаев они — административные или канце­ лярские работники, которые будут эксплуатировать разработанную систему. Политические аспекты, связанные с ролью заказчи­ ков, рассматриваются в книгах по управлению проекта­ ми, и я не собираюсь детально останавливаться на этом вопросе. Достаточно сказать, что в безнадежных проек­ тах политика имеет гораздо большее значение. Мы знаем, что именно заказчик предъявляет детальные тре­ бования к системе, поскольку владелец (и другие раз­ личные руководители высокого уровня) имеет неболь­ шой опыт практической работы с бизнес-приложениями(или не имеет его совсем) и склонен окидывать взглядом эти проблемы с высоты 30000 футов. Участники проекта должны взаимодействовать с заказчиком/пользователя­

ми для выявления детальных требований к системе. Од­ нако мы знаем, что во многих проектах владелец (или другие менеджеры) не рекомендуют участникам проекта общаться с пользователями, поскольку “они слишком заняты” или “ я сам могу сообщить вам все необходимое относительно их требований” , или в ход идут еще какиенибудь отговорки. В “ нормальных” проектах пользова­ тели могут полностью саботировать конечные результа­ ты, отказываясь их использовать или утверждая, что они не отвечают их требованиям. Все это в равной степени справедливо и для безна­ дежных проектов, но с одной дополнительной оговоркой: пользователи могут ничего не знать об экстраординар­ ной политике, ограничениях и давлении, которыми со­ провождается работа над безнадежным проектом. Про­ изойдет настоящая катастрофа, если кто-нибудь из проектной команды подойдет к пользователю и скажет: “ Я буду очень признателен, если ты прервешь сейчас работу и расскажешь о своих требованиях, потому что, если проект не будет выполнен в срок, вся компания обанкротится. Но разумеется, даже если проект за ко н ­ чится успешно, ты все равно останешься без работы, поскольку основная задача нашей новой системы — способствовать проведению обширного даунсайзинга, который сократит весь твой канцелярский департамент из 700 человек” . Особенно важным примером заказчика/пользователя является тот, которого я называю “ пользователь-не­ удачник” (loser user); тот, чьи интересы могут постра­ дать в случае успеха проекта. Отрицательный результат может заключаться для него в потере власти, престижа, вознаграждения, комфорта и т.д. Типичные примеры та­ ких пользователей: • Поставщик, чья система заменяется на новую • Конечные пользователи, которые лишаются своей работы с установкой новой системы

• Конечные пользователи, довольные существую­ щей системой и считающие, что новая система будет менее функциональной или удобной • Конечные пользователи, беспокоящиеся, что их квалификация недостаточна для работы с новой системой • Менеджер, бюджет которого будет сокращен с целью финансирования разработки новой сис­ темы • Менеджер, считающий, что проект провалится из-за своей амбициозности (и он постарается сделать так, чтобы его предсказания оправда­ лись) • Менеджер, чьи влияние, власть, престиж и во­ обще “ владычество” уменьшатся в случае успе­ ха проекта

2.1.3 Акционеры Акционеры являются, по существу, “совладельцами”

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

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

У поставщика, вовлеченного в проект, могут быть различные категории акционеров. Например, торговый

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

2.1.4 Заинтересованные лица Разница между акционерами и заинтересованными лицами может показаться чисто теоретической, но на самом деле она важна. Заинтересованные лица — это те, кто имеет свою “долю” в конечных результатах проекта, даже если они не участвуют в принятии реше­ ний. В этом смысле заказчики, владелец проекта и дру­ гие акционеры также являются заинтересованными ли­ цами. Заинтересованными лицами могут быть также члены руководящей иерархии, которым придется отказаться от использования своей старой информационной системы, если новая система будет сдана в срок. Они могут также быть членами различных объединений, поставщиками, заказчиками или конкурентами. Они могут быть другими сотрудниками IT-подразделения, поскольку успешное завершение безнадежного проекта повлияет на выбор методов и средств для работы над “нормальными" про­ ектами. Пол Нойхард отмечает еще одну общую катего­ рию заинтересованных лиц: Не стоит забывать про “узкий круг” людей, которые вроде бы напрямую не заинтересова­ ны в проекте, однако имеют влияние на его участников. Они рассказывают, что следует делать, и стремятся навязать свое мнение всем окружающим. Это “кабинетные советчи­

ки”, которые наш епт ы ваю т руководителям, как надо пост упит ь в определенной ситуации. Они довольно бы ст ро м огут сделат ь из друга врага, причем так, что вы об эт ом и не узнае­ те. Такое бывает в лю бой политической орга­ низации от Б ел ого Д ом а до конгресса и в лю­ бой компании, где работ ает больш е 3 человек. Лучше, если такие лю ди — среди твоих сто­ ронников. Эт о могут быт ь ст ары е одноклас­ сники, вице-президент по продажам, имеющий свое мнение по любому вопросу и нахально ве­ рящий в то, что он всегда прав, или предан­ ный секретарь, проработ авш ий на своем мес­ те 20 лет, который “все эт о уже видел" и знает, “что на самом деле нам нужно”.

Другими словами, если вы хотите иметь дело с г-ном Клинтоном, вам не стоит ссориться с г-жой Клинтон. Эрик Петерсен выделяет другую важную группу за­ интересованных лиц: это люди, которые тестируют вновь разработанную систему: Команда тестировщиков может оказаться самым “крепким орешком” из заинтересован­ ных лиц, особенно, если менеджер проекта откладывает тестирование на последний мо­ мент. В процессе тестирования из-за нехват­ ки времени и неудовлетворительного качест ­ ва нормальный проект может превратиться в безнадежный.

Это звучит так, будто заинтересованные лица явля­ ются “ врагами” безнадежного проекта, но на самом деле 1 вовсе так не думаю; они могут быть союзниками и 1аже оказывать существенную поддержку. Они в со­ стоянии образумить всякого рода непрошеных советчн;ов, которые неизбежно будут шушукаться за спиной

участников проекта; они в состоянии оказать разнооб­ разную помощь проектной команде (как материальную, так и моральную), если сочтут, что она этого заслужива­ ет. Само собой, если безнадежный проект выглядит как жертва в схватке Давида с Голиафом, то ему смело предложат помощь даже те сотрудники организации, ко­ торым вообще безразличны результаты проекта. Несмотря на возможность такого рода поддержки, все же более вероятно, что заинтересованные лица ока­ жутся критиками или противниками проекта. Причина этого проста: безнадежный проект с большей вероятно­ стью, чем “нормальный” проект, предполагает внесение серьезных перемен в организации; в то же время один из основных принципов политики гласит, что люди и кор­ поративная культура автоматически сопротивляются любым изменениям статус-кво, даже если они прекрас­ но понимают, что эти изменения важны и необходимы. Таким образом, проектная команда, с радостью привет­ ствуя тех, кто настроен дружелюбно по отношению к проекту, должна также остерегаться тех, кто, возможно, будет вставлять палки в колеса. Необходимо также помнить следующее: обнаружить и распознать всех заинтересованных лиц непросто, по­ скольку формально они могут и не быть членами орга­ низации. Если система оказывает непосредственное воздействие на каких-либо сотрудников организации, например на клерков в отделе приема заявок, нетрудно понять, что они и будут заинтересованными лицами. С другой стороны, вдруг найдется такой старый ворчли­ вый менеджер проекта, который, играя в гольф с вицепрезидентом по информационным системам, будет не­ довольно бормотать себе под нос: “Если этот чертов проект закончится успешно, нам всем придется учить Smalltalk, а я до сих пор уверен, что Smalltalk — это происки коммунистов”. Значит, перед вами еще одно заинтересованное лицо, которое может оказывать не­ заметное, но существенное влияние на проект.

2.1.5 Защитники Поскольку существуют потенциальные противники безнадежного проекта, есть и его сторонники. Защит­ никами называют тех, кто имеет большую власть и го­ тов оказать помощь. Защитник, который одновременно является и владельцем проекта, — самый лучший чело­ век во всей вселенной. Защитниками могут быть заказ­ чики, акционеры и заинтересованные лица. Тем не ме­ нее, защитники обычно оказываются вне традиционного круга политических игроков проекта. Защитник, вероят­ но, заинтересован в успехе молодого менеджера проек­ та — своего протеже, тогда его интерес также связан с успехом всего проекта в целом, поскольку в этом случае возрастет доверие к IS /IT -подразделению или всей ор­ ганизации. Гораздо чаще защитник бывает заинтересо­ ван в новой технологии типа “серебряной пули” , с помо­ щью которой менеджер безнадежного проекта надеется сотворить чудеса — либо это Java, либо объектно-ори­ ентированная технология, либо новое средство разра­ ботки приложений “ клиент-сервер” — защитник мог ранее посещать презентации этой технологии или даже быть одним из тех, кто предложил использовать ее в безнадежном проекте. У каждого проекта могут быть один или два защитни­ ка, но только безнадежным проектам они действи­ тельно необходимы. Это следует, очевидно, из преды­ дущего обсуждения: у подобных проектов и без того хватает критиков и противников, не считая тех, кто бу­ дет пытаться предвосхитить каждое решение менеджера проекта. Во время работы над проектом не раз будут возникать ситуации, когда кто-нибудь на совещании у руководства вздумает пожаловаться: “эти чокнутые из Проекта Титаник уже заказали семь копий Visual Basic Enterprise Edition в обход принятого порядка заказов. Но мало этого, менеджер проекта еще истратил в по-

следнюю пятницу целых $32,98 на гамбургеры и жаре­ ный картофель для своей команды. С какой стати я в своем офисе должен был нюхать, как пахнет этот карто­ фель?! Мы не можем позволить им с таким вопиющим пренебрежением относиться к принятым в компании правилам!” Защитник в такой ситуации способен пре­ рвать эту чепуху и сказать: “Поверьте мне, может быть, эти ребята и чересчур смелые, однако они сделают свою работу. Оставим их в покое.” Разумеется, если защитник не пользуется большим авторитетом в политических кругах организации, то ни­ чего хорошего из этого не получится — не имея авто­ ритета, он вообще не может быть защитником. Защит­ ник, как правило, много лет проработал в организации, он старше и мудрее, чем нетерпеливые менеджер про­ екта и его добровольные участники, пока еще достаточ­ но выносливые, чтобы месяцами работать по 18 часов в день. Подведем итог: защитник более важен для проекта, чем любая, самая новейшая методология или супермод­ ный язык программирования. В отсутствие защитника, способного отстоять право проектной команды игнори­ ровать бюрократические правила и поддержать решение использовать достаточно рискованные методы и средст­ ва, безнадежный проект будет всего лишь единичным жалким экспериментом. Я бы не стал выполнять такой проект. Если же ваш защитник является владельцем проекта и не существует каких-либо других заслужи­ вающих внимания акционеров, а ваш владелец/защит­ ник — авторитетная фигура для всех заинтересованных лиц, вы можете игнорировать всякую политику. В то время как обычно проблемы, связанные с политикой, ложатся на плечи менеджера проекта, остальные участ­ ники проектной команды должны иметь хотя бы мини­ мальное представление о составе действующих лиц на политической арене.

2.2 Определение сущности проекта В предыдущей главе я назвал некоторые характери­ стики безнадежных проектов: они могут быть большими или нет; иметь однородную группу заказчиков или груп­ пы с противоположными интересами; кроме того, имеют различные ограничения на сроки, бюджет и ресурсы. Существует другой способ, помогающий охаракте­ ризовать безнадежные проекты. Он имеет наиболь­ шее значение с точки зрения политики. Он представ­ ляется (см. рис. 2.1) в двухмерной системе координат, где горизонтальная ось показывает вероятность ус­ пешного завершения проекта, а вертикальная — сте­ пень удовлетворенности участников проектной коман­ ды в ходе выполнения проекта. Один из способов определить, как ощущают себя участники проектной команды, — это спросить: “ Когда этот проект закон­ чится, захотите ли вы участвовать еще в одном безна­ дежном проекте?” Или, еще проще: “ Вы чувствуете себя нормально или нет?” На данной диаграмме нет какого-либо точного мас­ штаба, и границы между четырьмя квадрантами весьма условны; для некоторых известных мне проектов я даже не могу точно определить, к какому квадранту они при-

Рис. 2. Г Квадрант безнадежных проектов

надлежат. Весьма сомнительно, чтобы кто-либо начинал безнадежный проект с явным намерением отнести его к той или иной конкретной категории, да и по ходу дела совокупность всех возможных ограничений (на сроки, бюджет и т.д.) может переместить проект в любом на­ правлении. Определение данных четырех квадрантов также весь­ ма условно, и вы можете изменять его как угодно, чтобы приспособить к условиям своей организации. В данном случае я определяю основные характеристики четырех квадрантов следующим образом: • Проекты “Невыполнимая миссия" — этот вид проектов воспет старыми телесериалами и но­ вым (1996 г.) фильмом с участием Тома Круза. Кажется, что все темные силы на свете объеди­ нились против проекта, все злодеи и изменники жаждут его провала. Но менеджер проекта — великолепный голливудский супермен, его ха­ керы — интеллектуальные гении, и на стороне команды сам Бог. Участники команды фанати­ чески преданы друг другу (несмотря на все пре­ пятствия и капризы судьбы), они крепнут с каж­ дым ударом, их возбуждает “ходьба по лезвию ножа”. В реальных проектах такого рода их команды обычно мечтают о славе, почестях и богатстве в случае успеха проекта. В конце кон­ цов, их миссия должна закончиться успешно; они убеждены, что сочетание интенсивной рабо­ ты с профессиональной виртуозностью сделает это возможным. • “ Отвратительные” проекты — такие, где участники команды — это жертвенные агнцы, которые будут зарезаны хладнокровным менед­ жером ради успеха проекта. Проекты такого рода обычно обладают менталитетом “Морско­ го Корпуса”, который обсуждался в главе 1 —

т.е. менеджер проекта будет постоянно произ­ носить перед своей командой речи на тему “ настоящие программисты не нуждаются во сне!". При этом также подразумевается, что “ настоящим" программистам нет необходимо­ сти бывать дома со своими семьями, навещать престарелых родителей в больнице и вообще заниматься чем-либо, что хоть на минуту отвле­ чет их от проекта. Для таких проектов нередки случаи, когда один или двое участников команды падают от изнеможения, страдают от язвы или нервных припадков или разводятся. А менеджер проекта только посмеивается и заявляет ос­ тальным участникам команды, что такие лю­ ди — неудачники и слабаки, заслуживающие своей судьбы. Ключевыми характеристиками таких проектов являются следующие: (а) менеджер проекта на­ целен на успех, (б) менеджер проекта нацелен на выживание и, вследствие этого, извлечение выгоды из успеха проекта, (в) менеджер проек­ та ради достижения успеха готов на то, чтобы пожертвовать здоровьем и благополучием уча­ стников проектной команды. “ Самоубийственные ” проекты — в таких про­ ектах все выглядят несчастными и обреченны­ ми. Участники команды и менеджер проекта обычно бывают вынуждены согласиться рабо­ тать над таким проектом только потому, что альтернатива — увольнение; они с самого нача­ ла знают, что нет никаких шансов на успех, но не могут позволить себе выйти из проекта, у ко­ торого нет защитника, все складывается против них... Проекты “ камикадзе" — также обречены на неудачу, но все согласны с тем, что это будет

почетный провал и они впоследствии будут гор­ диться своей причастностью к работе. Техниче­ ские специалисты проектной команды могут получить удовлетворение от возможности пора­ ботать с передовой технологией, которую они никогда ранее не использовали и которую, как они полагают, им больше никогда не увидеть после того, как проект будет свернут. Менед­ жер проекта надеется, что проект послужит хо­ рошим уроком будущим менеджерам. Иногда эти проекты затеваются обреченными компа­ ниями, чье славное прошлое объясняет такую неистовую преданность некоторых участников команды, что они почитают за честь и привиле­ гию пожертвовать собой в обреченном проекте, провал которого станет последним “ура” компа­ нии. Разумеется, еще существует небольшая вероятность того, что проект закончится успеш­ но и компания сможет выжить; даже если при этом участники проектной команды останутся без сил, пытаясь совершить чудо, они все равно будут счастливы. Исходя из этих определений, вы могли бы сказать, что я с одобрением отношусь к проектам “Невы­ полнимая миссия” , восхищаюсь проектами “камикадзе”, сочувствую тем, кто добрался до конца “самоубийствен­ ных” проектов, и испытываю неприязнь к “отвратитель­ ным” проектам. Однако хочу заметить, что это моя соб­ ственная система ценностей, она может и не совпадать с вашей. Она может и не совпадать с системой ценностей вашего менеджера проекта. Кроме того, если вы являе­ тесь менеджером проекта, то можете обнаружить, что системы ценностей у вас и участников вашей команды не совпадают. По вполне очевидным причинам, самое лучшее, когда все вписываются в один квадрант. Трудно рассчитывать на успех проекта “Невыполнимая мис­ сия” , если один или два ключевых участника команды

полагают, что они участвуют в "самоубийственном” про­ екте. Следует также помнить, что публичные заверения различных акционеров, заинтересованных лиц и разно­ образных менеджеров по поводу безнадежного проекта могут и не быть объективным отражением реальной си­ туации. Хотелось бы надеяться, что у владельца проекта хватит ума не затевать “самоубийственный” безнадеж­ ный проект. В большинстве случаев высшее руковод­ ство располагает достаточной информацией, чтобы оце­ нить реальные шансы проекта на успех. Например, ваш вице-президент может совершенно точно знать о пред­ стоящем слиянии (или приобретении) компаний, о кото­ ром будет публично объявлено за неделю до планируе­ мого завершения вашего безнадежного проекта. При этом проект будет прекращен независимо от того, на­ сколько успешно он выполняется. Се ля ви. Опасно оказаться вовлеченным в “отвратительный” безнадежный проект, когда менеджер проекта отказы­ вается признать, что он собирается принести участников команды в жертву. К счастью, такую ситуацию обычно легко распознать, даже если менеджер скрывает это. Позицию такого менеджера выдают чересчур “ мужест­ венное” поведение и уничтожающие характеристики, да­ ваемые самым слабым участникам команды, которые не способны демонстрировать такую же производитель­ ность, как “ настоящие программисты” . Разумеется, если вы обладаете менталитетом “Морского Корпуса” , а также готовы решать любые физические, эмоциональ­ ные, политические и психологические проблемы, то та­ кой проект не представляет для вас ничего страшного. Менеджеры “отвратительных” проектов обычно при­ глашаются со стороны либо в самом начале проекта, либо после того, как первый менеджер уйдет или будет уволен. Новый менеджер обычно никак не связан с пре­ дысторией компании и не имеет личных взаимоотноше­ ний с кем-либо из ее сотрудников. Поэтому он меньше

колеблется, когда приходится заставлять участников проектной команды работать интенсивнее и дольше. Я наблюдал несколько ситуаций, когда менеджер проек­ та был “наемным стрелком” , кочующим из одной компа­ нии в другую. Он обычно добивается успешных резуль­ татов в проекте и благодаря этому получает репутацию, а также довольно высокое вознаграждение. Однако уча­ стники проектной команды испытывают отвращение к своей работе и по завершении проекта (если не раньше) дружно уходят всей командой, а менеджер проекта на­ живает так много врагов, что у него не остается другого выбора, как упаковать свои чемоданы и перебраться в другой безнадежный проект. Такая роль идеально подхо­ дит для Клинта Иствуда, и лучше поостеречься, если кто-либо, похожий на его героев, въезжает в ваш горо­ док, чтобы захватить власть в проекте, в котором вы только что согласились участвовать. Один такой менеджер, которого я знал, работая в сфере финансовых услуг на Уолл-Стрит, имел любопыт­ ный подход для испытания физической выносливости и силы духа своей команды. В самом начале проекта он создавал “искусственный” кризис и немедленно бросал всю команду на его ликвидацию, заставляя при этом ра­ ботать с удвоенной энергией. За происходящим он смот­ рел из-за кулис; один или двое из участников команды могли уволиться, один или двое могли заработать нерв­ ный срыв, и один или двое “скромных героев” могли проявить себя и ликвидировать кризис за счет сверхинтенсивной работы или удачного технического решения. Испытав таким образом свою команду, этот хладнокров­ ный менеджер приступал к реальной работе над проек­ том. Но теперь он знал, как поведут себя участники про­ ектной команды в случае возникновения настоящего кризиса (который рано или поздно наступит в безнадеж­ ном проекте). О подобной перспективе лучше всего иметь пред­ ставление до начала проекта. В процессе формирова­

ния проектной команды менеджеру следует оценить, с какого рода проектом он будет работать, и затем спро­ сить у предполагаемых участников команды, (а) как они оценивают проект, и (б) что они думают относительно принадлежности проекта к одному из четырех квадран­ тов на рис. 2.1. Я твердо уверен, что менеджер безна­ дежного проекта должен самостоятельно выбирать. участников своей команды, учитывая не только профес­ сиональную квалификацию сотрудников. Важно подби­ рать людей таким образом, чтобы они мели сходное представление относительно “категории” проекта. Совсем другое дело, если вы сами являетесь предпо­ лагаемым участником команды безнадежного проекта и вас интервьюирует менеджер проекта. Как уже было сказано в главе 1, у вас может просто не быть никакого выбора. А менеджер не сможет самостоятельно принять решение относительно вашего участия в проекте; в та­ кой ситуации по крайней мере полезно выяснить, как оценивает проект ваш менеджер. Но если вы можете от­ казаться от участия в проекте, тогда гораздо важнее убедиться, что ваша оценка проекта сходна с оценкой вашего менеджера. Как было сказано выше, это вдвойне важно, если намечается “отвратительный” проект; вы должны спросить себя, не может ли так случиться, что вы станете одной из жертв этого проекта. Не забывайте также, что в ходе работы над проектом ситуация может резко измениться в зависимости от про­ гресса (или его отсутствия), достигнутого командой, от политического климата вокруг самой команды, от физи­ ческого или эмоционального истощения некоторых уча­ стников проекта и т.д.

2.3 Отношение участников к проекту Теперь следует обсудить еще одну тему: уровень са­ моотдачи, на который готовы и способны участники про­ ектной команды.

Отношение участников команды к проекту зависит от того, к какой категории из ранее обсуждавшихся при­ надлежит проект. Если всем членам команды становится ясно, что они участвуют в “самоубийственном” проекте, вряд ли они будут затрачивать больше физических и эмоциональных сил, чем это необходимо. Даже если ру­ ководство настаивает на необходимости длительной сверхурочной работы, можно будет обнаружить, что уча­ стники команды в вечерние часы и в выходные (в то са­ мое время, когда высшее руководство, навязавшее сверхурочную работу, само отсутствует), звонят прияте­ лям по телефону, строчат письма своим близким или об­ мениваются последними сплетнями. В “отвратительном” проекте отношение его участни­ ков диктуется менеджером проекта или сильно зависит от его требований. Мой опыт подсказывает, что менед­ жер такого проекта сам должен относиться к работе так, как требует от остальных. Если проектная команда все субботы и воскресенья проводит в офисе, он должен быть вместе с ними. Что же касается проектов “камикадзе” и “невыпол­ нимая миссия” , а также безнадежных проектов, которые вообще невозможно отнести к какой-либо определенной категории, то для них очень важно, чтобы у менеджера проекта было реалистичное представление о тех преде­ лах, в которые укладывается отношение участников команды к проекту. Кроме того, важно, чтобы любой участник проекта, которому в перспективе придется по­ жертвовать своей личной жизнью на ближайшие не­ сколько месяцев, знал, может ли он рассчитывать на та­ кое же отношение к работе со стороны своих коллег. Самое лучшее, если каждый участник проекта честно и объективно оценит свои возможности. Может слу­ читься так, что кто-то скажет: “Я готов работать на все 100%, но моя сестра собирается выйти замуж в июне, как раз перед завершением проекта, и мне придется взять отпуск на три недели. Мне очень жалко вас остав­

лять, но ее свадьба — важное событие в моей жизни.” Поскольку остальные участники проекта даже не знако­ мы с его сестрой, они могут счесть такое исчезновение в критический заключительный период разработки черес­ чур легкомысленным, но по крайней мере тот честно заявил о своих намерениях. Однако менеджер “ отврати­ тельного” проекта может негативно отнестись к подоб­ ному заявлению и сказать, что такой вариант неприем­ лем. Это в порядке вещей, если происходит в самом начале проекта. Участнику проектной команды при этом необходимо выбрать одно из двух: если свадьба сестры для него важнее, то лучше сразу и без особого ущерба выйти из проекта, ^ем позже оказаться в критическом положении. К сожалению, далеко не каждый способен заплани­ ровать все, что может повлиять на его участие в проек­ те. Рядовой представитель команды пообещает 100%ное участие в проекте, однако, если его ребенок заболе­ ет и попадет в больницу, все обещания будут нарушены. Кроме того, разумеется, у каждого участника есть шанс выиграть главный приз в лотерею и получить раз в жизни уникальный шанс отправиться всей семьей на Таити... и, кто знает, какие еще непредвиденные собы­ тия заставят нарушить данные обещания? Кстати, это хорошая причина для формирования небольших проект­ ных команд и краткосрочных планов. Команда из 5 чело­ век, работающая над 6-месячным проектом, гораздо меньше подвержена воздействию всяких непредвиден­ ных событий, чем команда из 30 человек, действующая 3 года. Многие люди вступают в брак, у них есть дети и домашние заботы; если решение личных проблем и можно отложить, то только на несколько недель или ме­ сяцев, а уж никак не на три года. Бессмысленно требо­ вать от кого-либо предвосхищения всех возможных си­ туаций, но для менеджера проекта вполне по силам составить себе реалистичное представление относитель­ но ожидаемой степени участия в проекте для каждого

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

2.4 Анализ основных проблем, порождающих политические разногласия Ни один IT-проект не может обойтись без политики; она стоит за каждым взаимоотношением между двумя или более индивидуумами. В лучшем случае она может играть незначительную роль, если участники проекта до­ говорятся между собой и достигнут компромисса, или один участник (или группа) одержит верх над всеми остальными, и будет диктовать свои условия. В безнадежном проекте наиболее очевидным источ­ ником политических споров и дискуссий являются вре­ менные, бюджетные и ресурсные ограничения, которые обсуждались в главе 1. Если бы с ресурсами было все в порядке, то не было бы и предмета для обсуждения. Однако существуют и другие источники политических разногласий. Некоторые из них очевидны для любых разработчиков — например споры по поводу специфи­ кации требований: она действительно отражает реаль­ ные требования пользователей или же является неадек­ ватной и неполной. Это особенно актуально для безнадежных проектов, поскольку не хватает времени на интервьюирование конечных пользователей, фор­ мальное документирование, согласование и утвержде­ ние их требований. Большинство IT-профессионалов

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

новных заинтересованных лиц. Разумеется, простого решения этой проблемы не существует, но, по крайней мере, лучше знать о ней заранее. Кроме этих проблем, существует еще один источник политических дебатов: разногласия по поводу статуса проекта, вероятности его успешного завершения и дей­ ствий, которые необходимо предпринять, если проект выбьется из графика и/или бюджета. Некоторые из этих проблем мы обсудим в следующих главах книги, а сейчас посмотрим на эти вопросы с точ­ ки зрения политики, чтобы быть готовыми к ответам на них и представлять себе возможные точки зрения раз­ личных заинтересованных лиц.

В какой момент можно реально оценить шансы на успех проекта? • В самом начале проекта • В конце различных стадий жизненного цикла: анализа, проектирования, написания кода, мо­ дульного тестирования и т.д. • В середине времени, определенного первона­ чальным графиком • За месяц (неделю или день) до завершения про­ екта Когда можно сделать вывод, что проект терпит не­ удачу? Кто в первую очередь должен знать о реальных шансах на успех проекта или о серьезных проблемах? • Менеджер проекта • Пользователь/заказчик • Высшее руководство • Другие участники проекта

Что должен делать менеджер проекта, если стано­ вится очевидным, что проект терпит неудачу? • Работать 24 часа в день для “спасения” проекта • Переложить решение проблемы на высшее ру­ ководство • Собрать вместе основных заинтересованных лиц, чтобы найти приемлемое решение В любом случае политические разногласия могут привести к существенным задержкам в проекте, что само по себе является серьезной проблемой для безна­ дежного проекта. Одним из возможных решений, осо­ бенно в случае разногласий относительно функцио­ нальности и других требований к системе, является проведение JAD-сессий (JAD — Joint Application Development), в которых участвуют все заинтересован­ ные лица, пытаясь выработать общее решение в серии коротких, но интенсивных совещаний. Если это невозможно, менеджеру проекта следует до­ биться согласия основных заинтересованных лиц на то, что все решения, требующие их согласования или утвер­ ждения, будут рассматриваться в течение 24 часов. Хорошим примером такой стратегии является об­ суждение “экстремальной разработки ПО” в 100-дневных проектах, выполненных компанией Shoulders Corp. ( www.shoulderscorp.com).

2.5 Заключение Сказанное в данной главе отнюдь не является какимлибо конкретным руководством по управлению, пла­ нированию или выполнению безнадежных проектов. За­ тронутые здесь проблемы пронизывают многие аспекты нашей жизни. Даже если безнадежный проект будет следовать всем правилам, касающимся проектирования,

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

ГЛАВА 3

ПЕРЕГОВОРЫ

Если вы являетесь менеджером безнадежного проек­ та, то очень легко предсказать результат переговоров относительно бюджета, срока и ресурсов: вы проиграе­ те. Это практически неизбежно, поскольку такие пере­ говоры происходят в самом начале проекта (или даже до его официального начала), когда владелец проекта/за­ казчик ни интеллектуально, ни эмоционально, ни поли­ тически не расположен воспринимать те неприятные для него контрпредложения, с которыми выступает ме­ неджер. Более разумные переговоры могут иметь место за месяц или два до срока завершения проекта, когда новый менеджер проекта может в качестве обязательно­ го условия своего назначения потребовать, чтобы все трезво оценили невозможность выполнения первона­ чальных планов и бюджета и реализации требуемой фун кционал ьности. Никто из нас, видимо, не хотел бы оказаться в таком незавидном положении. Поэтому, несмотря на сосредо­ точенность данной главы на разумных переговорных стратегиях, я, тем не менее, стараюсь не уходить от ре­ шения проблемы, с которой сталкивается большинство из нас: каким образом в самом начале проекта добиться нормальных условий его выполнения? Увы, но в этой главе вы не найдете никаких волшебных секретов; мрач­ ная реальность такова, что в результате переговоров вы скорее всего окажетесь в проигрыше. Однако все же по­ лезно знать некоторые тонкости политических игр и

уметь извлекать из них выгоду. Также вы должны уметь действовать и в том случае, если столкнулись с совер­ шенно нереальными сроками, бюджетом и/или ограни­ чениями на формирование проектной команды. В данной главе я исхожу из предположения, что вы так или иначе участвуете в переговорах по поводу безна­ дежных проектов, планов и т.д. Если вы — технический специалист, то можете и не принимать непосредствен­ ное участие в переговорах, а, консультируя менеджера проекта, готовить для него необходимую информацию с тем, чтобы он мог проводить переговорные баталии на более высоком уровне. Однако, как напомнил мне не­ давно Даг Скотт, даже менеджер проекта может ока­ заться на вторых ролях, поскольку все переговоры про­ водятся от его имени менеджером более высокого уровня. Единственной и самой большой помехой для меня в безнадежных проектах было мое собственное руковод­ ство. Необходимо знать его позицию в переговорном процессе и, если руководство чересчур увлекается поли­ тическими играми, лучше держать его подальше от про­ екта.

3.1 Нормальные переговоры Заявление о том, что мы в самом деле знаем., как точно оценить сроки выполнения бюджета и ресурсы какого-либо нетривиального проекта, наверняка вызовет бурные дебаты между различными группами софтвер­ ных профессионалов и менеджеров. Итоги, полученные в течение ряда лет, вряд ли будут слишком убедительны­ ми; с другой стороны, многие могут заметить, что про­ блемы, возникающие при оценке, являются результатом политических игр, связанных именно с безнадежными проектами/которые мы обсуждаем в данной книге. Однако в большинстве крупных организаций могут припомнить ряд проектов, которые были разработаны

самой проектной командой, ини самостоятельно плани­ ровали, составляли бюджет и твердо обещали создать в этих условиях функционально полную систему; потом все эти обещания лопались как мыльный пузырь. В ре­ зультате ничего не получалось. Поэтому не удивительно, что во многих таких организациях пользователи и выс­ шее руководство, не отвлекаясь на переговорные про­ цессы, просто навязывают жесткие сроки и бюджеты типа “сделай или умри". Таково происхождение многих безнадежных проектов. Сказанное вовсе не означает, что мы не должны при­ лагать никаких усилий для получения “ разумных” оце­ нок, которые можно потом использовать во время пред­ варительных переговоров по проекту. Важно, чтобы менеджер проекта не пошел по пути наименьшего со­ противления и не принял любые начальные условия без­ надежного проекта как указ свыше. Одним из общих признаков того, что команда решила следовать страте­ гии “самоубийственного” проекта (см. главу 2), являет­ ся позиция, выражаемая менеджером проекта (и разде­ ляемая участниками команды). Она заключается в следующем: “Мы не знаем, сколько времени реально потребуется на выполнение этого проекта, да это и не имеет значения, поскольку нам уже сообщили конечный срок. Таким образом, придется работать семь дней в не­ делю и 24 часа в день, пока мы не свалимся от изнемо­ жения. Пускай нас ругают и колотят, но мы не в состоя­ нии прыгнуть выше головы...” Я не собираюсь долго обсуждать различные методы оценки; если у менеджера проекта нет никакой квали­ фикации или опыта в оценке, то безнадежный проект совсем не подходит для обучения таким методам. Позво­ лю себе все же отметить некоторые полезные и доступ­ ные ресурсы, имеющиеся в данной области: • Средства оценки, являющиеся коммерчески­ ми продуктами — такие, как SLIM от Quan­ titative Systems Management и CHECKPOINT от

Software Productivity Research (SPR). Глава SPR Кэперс Джонс, “гуру” в области метрик ПО, считает, что на рынке средств оценки проектов имеется примерно 50 продуктов. Их нельзя на­ звать совершенными, и все они требуют от поль­ зователя высокого уровня квалификации (здесь, как и в других областях деятельности, работает принцип “что посеешь, то и пожнешь” ). В луч­ шем случае с помощью таких продуктов можно получить оценку с точностью +10%. Даже если точность будет ±50% , это лучше, чем иметь дело только с продиктованными политикой требова­ ниями, с которыми приходится справляться ме­ неджеру проекта и которые на 1000% выходят за пределы возможностей проектной команды. • Динамические модели систем — разработано множество имитационных моделей, которые по­ зволяют исследовать нелинейные зависимости между различными факторами, влияющими на динамику проектных процессов. Например, если частью стратегии безнадежного проек­ та является требование менеджера работать сверхурочно, то каков будет эффект через не­ сколько недель или месяцев? Сначала произво­ дительность будет выше по сравнению с нор­ мальным восьмичасовым рабочим днем. Однако опытный менеджер проекта также отметит, что постепенно она будет снижаться. Люди уста­ нут, возрастет количество ошибок, что, очевид­ но, повлияет на трудоемкость тестирования и отладки. И, если сверхурочная работа будет продолжаться достаточно долго, то проектная команда просто окажется на грани истощения. Из всех имитационных моделей, которые я ви­ дел, наилучшей представляется описанная в [ 1], которая реализована на языках DYNAMO и iThink.

написано множество книг. Лучше всего начать с книги Барри Боэма [2]; отметим также, что его модель СОСОМО, разработанная в начале 80-х годов, была позд­ нее модифицирована в модель СОСОМО-2 [3]. Другой классической работой является книга Фреда Брукса [4], недавно переизданная с уче­ том современной технологии и практики разра­ ботки ПО. Еще одна новая книга, которую можно рекомендовать, — это работа Джима Маккарти [5]. Об оценке проектов

Сам процесс оценки достаточно изучен и доку­ ментирован, и организации, подобные Software Engineering Institute (SEI), уже опубликовали различные руководства и отчеты [6, 7], кото­ рые могут помочь при выполнении оценки про­ ектов. Такие распространенные методы, как прототи­ пирование, также могут использоваться для оценки критичности тех или иных проектных ограничений для всей разрабатываемой систе­ мы в целом. Этот подход не может служить “за­ щитой от дурака”, но он позволяет привнести немного здравого смысла в проектную команду и окружающих ее менеджеров и заказчиков. Если руководство хочет, чтобы команда из трех разработчиков написала миллион строк кода за 12 месяцев, то следовало бы в течение первого месяца разработать небольшой прототип буду­ щей системы, который, по крайней мере, позво­ лит грубо оценить производительность проект­ ной команды, а также реализуемость проекта в целом.

3.2 Допустимые компромиссы Предположим, что проектная команда подготовила “разумную” оценку плана, бюджета и персонала, тре­ буемых для безнадежного проекта, и руководство го­ тово пойти на переговоры перед тем, как принять окончательное решение. Наиболее вероятно, что ру­ ководство объявит первоначальную оценку “неприем­ лемой” и выдвинет свои требования, которые окажут­ ся более жесткими. Как в этом случае поступить менеджеру проекта? Как отметил автор и консультант Джон Бодаи, очень важно, чтобы все согласились с наличием более чем од­ ного возможного “сценария” для проекта. При проведе­ нии переговоров нелишними будут такие вопросы, как “Обанкротится ли организация, если система будет го­ това не к 1 сентября, а к 5-му?” или “Все хотят, чтобы работа была сделана хорошо, быстро и дешево. Все зна­ ют, что реально можно выполнить только два требова­ ния из трех. Выберите два требования, которые важны для вас.” Если контрпредложение со стороны высшего руково­ дства или заказчика содержит только одну “перемен­ ную” , менеджер проекта может оценить влияние осталь­ ных переменных. Например, если первоначальная оценка менеджера проекта заключается в том, что про­ ект потребует 12 месяцев на реализацию, трех разра­ ботчиков и бюджет $200 ООО, вполне вероятно, что пер­ вой реакцией руководства будет: “Вздор! Нам нужно, чтобы система была готова и работала через шесть ме­ сяцев!” На первый взгляд, очевидный способ сделать это заключается в увеличении штата и/или бюджета (например, увеличить зарплату, чтобы привлечь более продуктивных программистов). С другой стороны, Фред Брукс уже более 30 лет на­ зад отмечал, что зависимость между количеством разра­ ботчиков и временем разработки носит нелинейный

характер; поэтому термин “человеко-месяц” был объяв­ лен мифом. Разумеется, практически все зависимости межлу ключевыми переменными проекта являются не­ линейными и зависящими от времени. Вследствие эф­ фекта “обратной связи” , возникающего в результате многих решений руководства, изменение одной пере­ менной (например, увеличение штата) повлияет со вре­ менем не только на другие переменные (продуктив­ ность), но и на собственное первоначальное значение. Например, увеличение штата может отрицательно ска­ заться на моральном состоянии команды, что повлечет за собой текучесть кадров. В результате уменьшится численность персонала. Упомянутые динамические модели систем как раз от­ ражают сущность этих нелинейных и нестационарных зависимостей; их характер является еще и причиной ис­ пользования различных коммерческих средств оценки, описанных выше. Следует отметить, что математической основой этих динамических моделей являются нелиней­ ные дифференциальные уравнения, в которых большин­ ство из нас не слишком хорошо разбирается. Подобным образом коммерческие средства оценки выполняют сложные расчеты с учетом множества параметров; по­ пытка сделать такую работу на интуитивном уровне, ос­ новываясь только на своем замечательном чутье, приве­ дет, скорее всего, к грубым ошибкам. К сожалению, именно в таком положении оказыва­ ется большинство менеджеров безнадежных проектов. Отчасти это объясняется самой природой переговор­ ного процесса (напоминающего игру под названием “Испанская инквизиция” , которая будет обсуждаться ниже); однако причиной может быть отсутствие адек­ ватных средств оценки и соответствующего опыта во многих организациях. Если решением данной пробле­ мы раньше не занимались, то тем более бесполезно делать это во время работы над безнадежным проек­ том. Если в организации привыкли к торопливости и

небрежности в количественной оценке проектов, то менеджеру безнадежного проекта вряд ли удастся вы­ бить $10 000 на приобретение достаточно сложного средства оценки. Итак, менеджеру в крайнем случае остается осознать тщетность усилий и отреагировать соответствующим об­ разом; такая ситуация будет детально обсуждаться в подразделе 3.5. Однако в менее сложной ситуации суще­ ствуют два возможных варианта действий: • Если требования пользователей или высшего руководства включают изменение одной из пе­ ременных проекта в пределах 10%, его можно компенсировать пропорциональным изменени­ ем одной из остальйых переменных. Например, если руководство хочет сократить срок разра­ ботки на 10%, следует увеличить на 10% со­ став проектной команды. Вряд ли это будет точ­ ной компенсацией, но это все, что вам удастся добиться в процессе переговоров. • Если изменение одной переменной выходит за пределы 10%, следует исходить из предполо­ жения, что обратное воздействие на какую-ли­ бо одну из оставшихся переменных будет квад­ ратичным. Предположим, что руководство хочет наполовину уменьшить срок разработки с 12 месяцев до 6. Вместо того чтобы удваивать состав проектной команды, менеджеру следует увеличить его в 4 раза — или увеличить в 4 раза бюджет, чтобы нанять суперпрограмми­ стов, которые умеют кодировать одновременно обеими руками. В отсутствие формальной мо­ дели оценки невозможно определить, насколь­ ко эта грубая эвристика будет соответствовать конкретной ситуации. Однако это лучше, чем оказаться в ловушке или придерживаться ли­ нейной зависимости между временем и людь­

ми. К сожалению, “ квадратичный” вариант достаточно трудно отстоять, и, скорее всего, “ наглые” требования менеджера проекта будут отвергнуты, однако в случае хотя бы мини­ мальной удачи менеджер все равно может ока­ заться в лучшем положении, чем при “линей­ ном” варианте.

3.3 Переговорные игры Переговоры — это игра, она имеет место во всех софтверных проектах. Переговоры в безнадежных про­ ектах характеризуются тем, что ставки гораздо выше, эмоции захлестывают через край, а запросы противопо­ ложной стороны (в терминах плана, бюджета и т.д.) обычно доходят до такой крайности, что могут превысить любой “запас прочности” . В обычном проекте самый очевидный запас прочности — это сверхурочное время. Даже если менеджер проекта оказался вынужден при­ нять под давлением жесткий график и урезанный бюд­ жет, успеха все равно можно будет добиться. Для этого надо уговорить проектную команду работать сверхуроч­ но от 10 до 20 ч в неделю в течение нескольких заключи­ тельных месяцев проекта. Эти дополнительные усилия никак не отражаются в официальной статистике, по­ скольку программисты ничего не получают за сверх­ урочную работу, поэтому в конце проекта менеджер вы­ глядит героем. Однако в безнадежном проекте небольшого количе­ ства сверхурочного времени обычно недостаточно, что­ бы достичь тех впечатляющих результатов, которые тре­ бует руководство. Кроме того, пользователи и высшее руководство не столь наивны — они зн аю т , что может потребоваться сверхурочная работа и учитывают ее в своих собственных оценках графика выполнения проек­ та. Таким образом, они лишают менеджера возможности использовать этот свободный ресурс. Правда, менедже­

ры-ветераны подобных переговоров должны иметь за­ пасные доводы, которые могут пригодиться уже в начале переговоров. В самом плохом положении находится неопытный менеджер. Он даже не представляет, что его последний успех мог быть достигнут только благодаря проектной команде, которая добровольно согласилась работать сверхурочно, чтобы уложиться в сжатые до минимума сроки. В свою очередь, такой смехотворный план мог быть навязан проектной команде именно из-за неопыт­ ности менеджера в области проектных оценок и пере­ говоров. Консультант в области менеджмента Роб Томсет в своей замечательной статье [8] определил общие вари­ анты переговорных игр; наиболее распространенные из них приведены ниже: • Удвой и добавь еще — эта уловка использует­ ся в проектах, начиная с египетских пирамид, если не раньше. Используйте любые методы оценки, оказавшиеся под рукой, затем получен­ ную “разумную” оценку удвойте и для большей надежности добавьте еще три месяца (или три недели, или три года, в зависимости от масшта­ ба проекта). Главная проблема такой стратегии заключается в том, что она ведет к самому же­ сткому ограничению, связанному с безнадежны­ ми проектами: сжатым срокам. • Обратное удвоение — руководство может быть осведомлено о попытках менеджеров про­ ектов “ раздуть” свои оценки, используя преды­ дущую стратегию. Одна из причин такой прони­ цательности заключается в том, что высшее руководство во многих организациях — это бывшие менеджеры проектов в области инфор­ мационных технологий, поэтому они хорошо разбираются в таких играх. В результате они

берут те начальные оценки, которые им дают менеджеры проектов, и автоматически урезают их наполовину. В незавидном положении оказы­ вается неопытный менеджер, который даже не знает, что его подозревают в удвоении своих на­ чальных оценок! “Угадай число, кот орое я задум ал" — такую игру я освоил в одном из моих первых проек­ тов, когда был еще молодым программистом. У пользователя или руководителя высокого уровня есть своя “приемлемая" оценка для сроков, бюджета и/или других аспектов перего­ воров, но они от казы ваю т ся чет ко ее сфор­ мулировать. Когда менеджер проекта предла­ гает свою оценку сроков и бюджета, пользователь или руководитель попросту качает головой и говорит: “ Нет” . Такой ответ подразу­ мевает: “Это слишком много — попробуй уга­ дать еще раз”. Незадачливый менеджер в конце концов (иногда после полудюжины попыток!) приходит с нужной оценкой, но поскольку те­ перь это его оценка, ему впоследствии и придет­ ся отвечать за нее. Двойной плевок пуст ышкой — “ пустышкой”

(dummy) называется детская соска, а “выплю­ нуть пустышку” означает, что ребенок настоль­ ко расстроен и рассержен, что выплевывает свою соску. Томсет использует это как метафо­ ру, чтобы описать такую ситуацию в процессе переговоров: руководитель высокого уровня впадает в буйное неистовство, когда менеджер проекта в первый раз докладывает свои предло­ жения по плану и бюджету. Дисциплинирован­ ный менеджер поспешно удаляется, затем снова возвращается с пересмотренной оценкой, а руководитель снова закатывает истерику. Полу­

чается “двойной плевок пустышкой”. Идея за­ ключается в следующем: запугать и затеррори­ зировать менеджера до такой степени, чтобы он согласился с чем угодно, лишь бы избежать еще одной вспышки гнева. Испанская инквизиция — такое случается, ко­

гда менеджер проекта приходит на совещание руководителей высшего уровня, не зная, что от него потребуют дать “немедленную оценку” безнадежному проекту. Представьте себе ком­ нату, полную ворчливых вице-президентов, ко­ торые пристально смотрят на вас, в то время как директор грозным тоном спрашивает: “Итак, Смит, когда же, по вашему мнению, мы получим эту систему? Я уже доложил всему ру­ ководству, что она будет готова к середине мар­ та , вы же не собираетесь подвести меня, не так ли?” Если у вас хватит смелости возразить, что более реальный срок — середина ноября, тогда инквизиторы обрушатся на вас с вопросами от­ носительно вашего интеллекта, полномочий, лояльности и, возможно, даже религиозных убеждений. Игра на пониж ение — по мере роста тенден­

ции к использованию аутсорсинга во многих организациях такая игра становится все более распространенной. Она часто имеет место в ситуации, когда организация-разработчик ПО проигрывает своим конкурентам борьбу за право разработки системы для организацииклиента. Эта игра очевидна: заказчик (или в некоторых случаях представитель службы мар­ кетинга организации-разработчика) говорит менеджеру проекта, что один из претендентов внес свои предложения о коротком сроке раз­ работки и/или более скромном бюджете. Это

вынуждает менеджера проекта не только отве­ тить на вызов конкурента (который может быть вполне реальным, а может, и нет), но и пре­ взойти его, чтобы повысить свои шансы на за­ ключение контракта. Один из вариантов такой игры — клиент дает понять, что он не исклю­ чает возможность, что проект вообще не со­ стоится; при этом организация-разработчик, которая во что бы то ни стало стремится запо­ лучить этот проект (возможно, потому, что он служит карьерным целям вице-президента по информационным технологиям), постарается выдвинуть такие заманчивые для клиента пред­ ложения, от которых он не сможет отказаться. Это означает, что один или более членов IT-ие­ рархии знают, что эти предложения чрезмер­ но оптимистичны или просто лживы. Такие действия ведут к описанным ниже играм “Месть” и “Китайская пытка водой” . Месть — эту игру иногда затевает менеджер

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

TOpbI C Н в в О З М О Ж Н и и и и п i n .

iv_ivi u v

не помешает заказчику найти способ отомстить за ту игру, которую с ним сыграли. Очевидной формой такой мести будет увольнение менедже­ ра проекта. Точно так же его может подставить собственное руководство (которое в первую очередь виновато в нереальных условиях безна­ дежного проекта), чтобы списать на него свою вину. Все могут подумать, что виной всему является некомпетентность менеджера проекта; наймут другого менеджера, примут (или нет) бо­ лее реалистичные сроки и бюджет, и проект продолжится. Тем временем, разумеется, никто и не подумает ослабить пресс сверхурочной ра­ боты, который давит на участников проектной команды. • Кит айская пыт ка водой — в отличие от предыдущей игры ва-банк, связанной с высо­ ким риском, данная игра заключается в том, что плохие новости преподносятся заказчику и/или высшему руководству небольшими пор­ циями. Вообразите такую ситуацию, когда ра­ зумная оценка срока выполнения проекта, сделанная менеджером, составляет 12 меся­ цев. По его мнению, при помощи сверхуроч­ ной работы и разного рода чудес проект можно выполнить за 6 месяцев, однако руко­ водство настаивает на 4 месяцах. Менеджер нехотя уступает и устанавливает для проекта последовательность “ контрольных точек” — например, новая версия прототипа системы должна предъявляться заказчику каждую не­ делю. Первое предъявление окажется опо­ здавшим на один день, однако менеджер дока­ жет, что для данной работы задержка может составлять от 14 до 20% (в зависимости от того, сколько дней в неделю работает коман­

да — 5 или 7); отсюда, по его мнению, следу­ ет, что срок разработки заключительной версии системы также может быть отодвинут на 14— 20%. На такой ранней стадии проекта руководство отказывается пойти на уступки, но когда вторая контрольная точка также ока­ жется сдвинутой на день (что означает общую задержку в два дня в течение двух недель), ме­ неджер вновь повторит свои аргументы. Кап, кап, кап; это похоже на китайскую пытку во­ дой — одной плохой новости недостаточно, чтобы сразить вас, но все вместе могут ока­ заться роковыми. Туманы и миражи — горе тому несчастному менеджеру проекта, вице-президент которого нанял консультанта по метрикам с моделью оценки, ничего в ней не понимающего. Метри­ ки ПО в конечном счете представляют собой статистику, а модели оценки основываются, как правило, на сложных математических зави­ симостях. Когда они попадают в руки человека неопытного, наивного или преследующего оп­ ределенные политические цели, эти средства могут быть использованы для “доказательства” корректности любой произвольной оценки. Все это вдвойне опасно, если источником метрик является поставщик, пытающийся до­ казать, что безнадежный проект преуспеет благодаря фантастической производительности его CASE-средств, средств визуального про­ граммирования или новейшей методологии разработки ПО. Спрятанное качество — это одна из наибо­ лее хитрых игр. В ней могут участвовать (в кон­ структивной или деструктивной манере) хоро­ шо информированные менеджеры проектов,

менеджеры высокого уровня по информацион­ ным технологиям и/или заказчики. Все очень просто: как менеджер проекта, я могу предос­ тавить пользователю бесконечно большое чис­ ло программ за нулевое время, пока их не нуж но реально эксплуатировать. Разумеет­ ся, было бы глупо предлагать такой экстре­ мальный сценарий. Однако суть заключается в том, что качество ПО (выражаемое в количест­ ве ошибок, переносимости, сопровождаемости и т.д.) — это одно из “измерений” проекта, ко­ торое нужно учитывать во время переговоров по срокам, затратам, персоналу и другим ресурсам. Некоторые заказчики слишком не­ опытны, чтобы понимать это, а другие не соби­ раются принимать в расчет длительную пер­ спективу: “Мне все равно, будет ли система работоспособна через два года, поскольку за это время возможности для бизнеса могут кар­ динально измениться, да и я сам буду другим. Что меня действительно беспокоит — это что­ бы система была готова через три месяца и ра­ ботала после этого 12 месяцев”. Если полити­ ка оказывает достаточно сильное давление на принимаемые решения, то нетрудно обнару­ жить IT-менеджеров и менеджера проекта, го­ товых принять эту позицию. Менее вероятно, что с ней согласятся технические специалисты. В самом лучшем варианте такая “игра” отра­ жает стратегию “достаточно хорошего” (goodenough) ПО. Ее я описал в [9]. В худшем виде она носит такой же жульнический характер, как и некоторые другие упомянутые выше по­ литические игры.

3.4 Стратегии переговоров Что следует предпринять, если вы втянуты в одну из описанных выше политических игр? Это решение важ­ но, даже если вы не являетесь их непосредственным участником, а наблюдаете со стороны (например, в ка­ честве технического специалиста-участника проектной команды) все происходящие вокруг вас игры по поводу сроков, функциональности и бюджета. Томсет высказы­ вает интересную мысль, что все мы обучаемся политиче­ ским играм от наших наставников, менеджеров и “ста­ рейшин” политической культуры своей организации. И если мы сами не можем избежать этих игр, возможно, нам удастся уберечь от них своих подчиненных. Будем надеяться, что все эти политические игры сами по себе отомрут через поколение или два. Это было бы просто замечательно, но, к сожалению, я не столь оптимистичен. Иногда мне кажется, что поли­ тика заложена в нас на генетическом уровне, в коде ДНК. Даже если положение и не такое удручающее, реалии таковы, что политические игры, подобные опи­ санным в этой главе, всегда вокруг нас; софтверные проекты вовсе не являются в этом смысле чем-то уни­ кальным, и каждый из нас в течение своей жизни оказы­ вался втянутым в те или иные игры. Даже если предпо­ ложить, что такие игры нетипичны для софтверных проектов, все равно наша профессия достаточно мо­ бильна для того, чтобы любая организация почти наверняка в какой-либо период времени оказалась “ин­ фицирована” чересчур политизированными менеджера­ ми, поставщиками и специалистами по маркетингу. По­ литические игры следует принять, как неизбежное зло, и мы должны уметь наилучшим образом справляться с ними. Одно мы действительно можем сделать (как сове­ тует Томсет в своей замечательной статье [8]) — это не попасть в ловушку “скоропалительных” оценок

проекта. Наихудшую разновидность такой ловушки представляет собой игра “испанская инквизиция”. Однако существуют и не такие заметные ловушки, ко­ торые поджидают нас в безнадежном проекте во вре­ мя планирования и переговоров. Преднамеренно или нет, но менеджера проекта часто ставят в положение, когда от него требуется быстро дать “грубую оценку” времени и количеству персонала, требуемым для реа­ лизации каких-либо частей проекта; и достаточно один раз сболтнуть об этом окружающим, как эти оценки могут превратиться в жесткие, не подлежащие изменению требования. Таким образом, в любой по­ добной ситуации менеджеру необходимо ответить: “Мне нужен один день (или неделя, или месяц — или даже час!), чтобы сделать необходимые расчеты, тогда я смогу дать оценку. Я отправлю ее по электронной почте” . Разумеется, если все расчеты будут выполне­ ны заранее и вы уже окажетесь готовы к таким во­ просам, то это даст вам очевидное преимущество, но, к сожалению, не всегда можно это сделать. Не всегда возможно избежать требования дать не­ медленную оценку. Представьте, что во время презен­ тации ваш клиент поворачивается к вам и спрашива­ ет: “О’кей, Гарри, допустим, мы исключим из системы интерактивный Web-браузер и добавим десять наших людей в твою команду. Сколько времени тебе потре­ буется на всю работу?” Все поворачиваются и смот­ рят на вас, и вы видите, что менеджер по маркетингу чувствует себя явно не в своей тарелке; из всех пре­ дыдущих дискуссий по этому вопросу вы, вероятно, знаете, что политически приемлемый ответ — “Три месяца — и никаких проблем!” Хватит ли у вас духу ответить: “Джо, я в самом деле не знаю; нам следует вернуться в офис и проиграть то, что ты сказал, на нашей оценочной модели. Кроме того, мне необходи­ мо поговорить с твоими людьми и выяснить их квали­ фикацию...”

В подобной — и во многих других ситуациях, когда у вас действительно имеется некоторое время на выпол­ нение формальной оценки, — очень важно выразить ваши оценки в терминах “уровней достоверности” или в некотором диапазоне “плюс-минус” . Если у вас абсо­ лютно отсутствуют данные для детальной оценки и если в безнадежном проекте используется совершенно новая технология и участвует персонал неизвестной квалифи­ кации, то будет благоразумным сказать: “ Проект, веро­ ятно, потребует от трех до шести месяцев” или “Я ду­ маю, что мы закончим проект через шесть месяцев плюс-минус 50% ”. Конечно, большинство менеджеров проектов знают о таком подходе, и они уже могут его использовать (либо нет). Определение размера диапазона “ плюс-минус” является составной частью науки проектных оце­ нок, и я адресую интересующихся к тем источникам, которые перечислены в конце главы. В безнадежных проектах важно не забывать о вмешательстве полити­ ки в те оценки, которые даются во время переговоров. Наиболее распространенной, например, является та­ кая ситуация, когда все, что вы говорите по поводу диа­ пазона “плюс-минус” , напрочь игнорируется вашими партнерами по переговорам. Так, если вы, находясь на совещании по вопросам планирования, говорите заказчику и другим руководите­ лям: “Мы могли бы завершить этот проект за шесть ме­ сяцев + 25% ” , каждый запишет в свой блокнот “шесть месяцев” . (Конечно, те, кто поднаторел в политике, возьмут наихудшую оценку, данную вами, и добавят к ней еще для “надежности” перед тем, как докладывать своему высокому начальству. К сожалению, политиче­ ски неопытные или амбициозные поступят как раз на­ оборот. В результате директор может сделать оконча­ тельный вывод, что проект будет закончен через четыре месяца или раньше.) Неважно, сколько раз вы это по­ вторили, все равно никто не обратит внимания, и когда

информация вернется обратно от вашего босса, вы об­ наружите, что срок разработки составляет шесть меся­ цев. Все, что вы в состоянии сделать, — это никогда не отказываться от знака “ ± " в любых устных или пись­ менных утверждениях, обещаниях, соглашениях или оценках, которые вы даете. Это не устранит проблему, но, по крайней мере, послужит для вас оправданием, если срок разработки окажется максимальным по срав­ нению с вашей оценкой. Один из читателей чернового варианта данного изда­ ния книги прислал интересный комментарий по этому поводу: Проблема, связанная с оценкой, заключает­ ся в том, что я понимаю это слово следующим образом: “наилучшая оценка, известная в на­ стоящий момент и могущая служить в каче­ стве прогноза на будущее”. Однако опыт пока­ зывает, что как только оценка опубликована, она превращается в твердое обязательство, на основании которого определяется макси­ мум ресурсов, выделяемых на проектную фазу или на весь проект. Аналитики, программисты и другие техна­ ри понимают, что такое оценка. Может быть, менеджер проекта тоже это понима­ ет. Однако высшее руководство обычно по­ нимает только слово "обязательство”. Прав­ да, иногда до начала проекта руководители тоже понимают слово “оценка”. Но как только потрачен первый доллар, оценка обычно ста­ новится фразой “вы рискуете своей работой, если не будете выполнять своих обяза­ тельств”.

К сожалению, есть один довольно неприятный мо­ мент, связанный с использованием приближенной оцен­ ки: вас могут обвинить в неуверенности, слабости или

даже в некомпетентности. Это особенно характерно для безнадежных проектов с синдромом “Морского Корпу­ са”, который обсуждался ранее. Высшее руководство хочет от вас : твердого обещания и обязательств, что проект будет закончен точно к определенной дате, его бюджет будет составлять определенное количество дол­ ларов и персонал будет состоять из определенного числа людей. Им доставляет огромное удовольствие (а) не за­ ботиться больше о проблемах, связанных с продолжи­ тельностью проекта, и (б) иметь козла отпущения, на котором можно отыграться, если обещания будут нару­ шены. Оценки, имеющие вид “X месяцев ± 50% ”, “$500 ООО ± 100%” и “ 10 человек + 25% ” , никак не могут их удовлетворить. Джим Маккарти в своей интересной книге [5] утвер­ ждает, что менеджер проекта обязан открыто идти на­ встречу этим проблемам, убеждая заказчиков и руковод­ ство, что они должны войти в положение проектной команды и разделить с ней то бремя неопределенности, под тяжестью которого она будет находиться ежедневно. Таким образом, менеджеру следует сказать заказчику или высшему руководству: “ Послушайте, я не скажу с абсолютной точностью, когда закончится проект — но, будучи менеджером проекта, я гораздо скорее, чем кто-либо еще в этой организации, смогу оценить срок настолько точно, насколько это вообще возможно. Обе­ щаю немедленно докладывать вам обо всем, что мне станет известно” . Только у самоуверенного и способного уклоняться от различных заданий менеджера хватит наглости ска­ зать такое в политизированной атмосфере безнадеж­ ного проекта. Однако самое удобное время для того, чтобы высказаться таким образом, — это начало про­ екта. Даже, если заказчик и высшее руководство не воспринимают вас всерьез как менеджера проекта, то у вас хороший шанс показать, что вы в самом деле знаете о проекте больше других; зачем же тогда на

вас возложили ответственность за этот проект? Неу­ жели вам хочется быть козлом отпущения и высту­ пать в качестве “ марионеточного менеджера” , когда все решения будут приниматься за вас разными поли­ тическими манипуляторами? Если это так, — самое время хлопнуть дверью! Если же вы — младший программист в проектной команде и имеете удовольствие наблюдать подобные политические игры, это почти наверняка означает, что ваш менеджер проекта (а) не уверен ни в одной из своих оценок, (б) у него не хватает твердости , чтобы постоять за себя и за свою команду, и (в) он оказался в ситуации, когда почти все ключевые решения при­ нимаются людьми, не имеющими непосредственного отношения к проекту. Это говорит о том, что проект скорее всего провалится, и, пока вы еще не слишком в него втянулись, может быть, лучше поискать себе пастбище позеленее. Я хорошо знаю, насколько трудно бывает менеджеру убедить различных “игроков” , чтобы они в полной мере прониклись неопределенностью, связанной со сроками, бюджетом и персоналом. Сообразительный заказчик, разумеется, в состоянии сделать это. Организация-раз­ работчик ПО, обладающая достаточным опытом, учиты­ вает такую неопределенность как один из обязательных элементов управления рисками. Наконец, люди, кото­ рые относятся друг к другу с уважением и заботой, со­ гласятся, что было бы непорядочно подвергать одного из членов группы высокому риску и перспективе зарабо­ тать язву.

3.5 Что делать в случае провала переговоров Выше я отметил, что если менеджер проекта ока­ зался не в состоянии добиться от заказчика или выс­ шего руководства понимания неопределенности, свя-

занной с планом или бюджетом безнадежного проекта, он должен всерьез задуматься об отставке; то же самое касается и технических специалистов проектной команды. Но это только один аспект не­ удачных переговоров; как следует поступить менедже­ ру, если он на 100% уверен, что продиктованный по­ литическими соображениями срок в шесть месяцев явно недостаточен? Как следует ему поступить, если он абсолютно уверен, что проектная команда должна состоять как минимум из трех человек, а руководство дает только двух? В этой книге я упоминал о возможности отставки, но понимаю, что это не слишком подходящий вариант для некоторых профессионалов. Разумеется, для ме­ неджеров отставка является более серьезной пробле­ мой, чем для технических специалистов, по той про­ стой причине, что они, как правило, на 5 — 10 лет старше и поэтому обременены долгами, семьями и т.д. Они больше сомневаются в том, что смогут быстро найти другую работу. Молодые и холостые участники проектной команды практически уверены, что смогут устроиться за 24 часа. Важно понимать, что я вовсе не рекомендую исполь­ зовать отставку в качестве наказания или мести. Она яв­ ляется просто разумным действием, которое стоит пред­ принять, столкнувшись с неразрешимой ситуацией и непримиримыми противоречиями на переговорах. Жизнь на этом не кончается, впереди будут другие про­ екты и другие работы. Как отметила недавно Сью Пе­ терсен: Я научилась кое-чему от своих детей и ду­ маю, что это применимо к работе в такой же степени, как и к обыденной жизни... Я должна беречь себя, свою энергию, эмоциональное и физическое здоровье, свое свободное и рабо­ чее время. Если же я не поберегу себя, у меня не останется ничего для детей.

Еще одно обстоятельство, связанное с уходом, каса­ ется лояльности и трудового соглашения между работо­ дателем и работником. Вплоть до 80-х годов многие про­ фессиональные программисты работали в крупных организациях, элементом корпоративной культуры кото­ рых являлась “пожизненная занятость”. Для них это никогда не было столь серьезно, как в японских компа­ ниях. Однако большинство программистов и проекти­ ровщиков в крупных банках, страховых компаниях, правительственных учреждениях и компьютерных ком­ паниях (таких, как IBM и DEC) полагали, что в отсутст­ вие войны, голода или чумы они будут продолжать расти вместе с организацией, пока не уйдут в 65 лет на пенсию с золотыми часами. В небольших компаниях никогда не было такого рода культуры. Многие профессионалы-разработчики работали именно в небольших компаниях, особенно в тот период, когда компьютерные технологии стали на­ столько дешевыми, что даже небольшая семейная ла­ вочка могла приобрести ПК и Web-cepeep. Те из нас, кто трудились в консалтинговых фирмах, бюро обслу­ живания и различных начинающих компаниях, всегда знали, что там не было и речи о пожизненной заня­ тости. Профессионалы в больших компаниях также нача­ ли сталкиваться с этой проблемой, поскольку на­ ступление эры даунсайзинга, аутсорсинга и реижиниринга повлекло за собой распад многих софтверных компаний и безработицу в нашей области. Эти про­ блемы обострились, когда произошло слияние и при­ обретение компьютерных компаний. Кроме того, они стали заметны в отраслях экономики с высокой степе­ нью конкуренции, где обработка информации играет ключевую роль. Например, когда в середине 1990-х объединились Chemical Bank и Chase Manhattan Bank, высшее руководство столкнулось с проблемой объединения двух различных системно-технических

платформ и иерархий IT-менеджмента. Как я отмечал в главе 1, именно такая ситуация порождала много­ численные безнадежные проекты, которые имели ме­ сто в 1990-х годах. Проблема многих таких крупных организаций за­ ключается в следующем: в то время как работодатель определенно менял свой подход к трудовому соглаше­ нию, работник не был готов отреагировать на это со­ ответствующим образом. Многие программисты и проектировщики, честно трудившиеся на благо компа­ нии 10— 20 лет, искренне полагают, что (а) компания будет и дальше заботиться о них и (б) они должны оставаться с компанией при любых неприятностях. “Неприятность” — это подходящее понятие для боль­ шинства безнадежных проектов. Вряд ли можно получать какое-то удовольствие, жертвуя своим сво­ бодным временем, работая до изнеможения и сталки­ ваясь со стрессами и политическим давлением. Так почему же мы делаем это? Потому что мы взяли на себя определенные обязательства и считаем делом чести их выполнять. Тем не менее, эти обязательства лишаются всякого смысла, если работодатель аннулирует трудовое со­ глашение; в этом случае необходимо пересмотреть свое отношение к работе и решить, стоит ли ее про­ должать. Я вовсе не советую поступать неэтично или аморально, но не вижу ничего плохого в том, чтобы ограничить свои обязательства по отношению к рабо­ тодателю одним-двумя годами или временем одного проекта. Работодатель, который заявляет проектной команде: “ Если вы не сдадите систему к 31 декабря, я вас уволю” , тем самым показывает свое отношение к трудовому соглашению. Помимо угрозы быть уволенным, которая опреде­ ленно присутствует при обсуждении безнадежного проекта, существует также опасность, что вас обойдут с повышением в должности или продвижением по

службе. Однако, если трудовое соглашение нарушает­ ся и с вами поступают достаточно жестко, вы имеете полное право ответить тем же. Один из самых силь­ ных козырей в переговорной игре — это имеющееся у вашего противника понимание того, что вы готовы все бросить и уйти, если результаты переговоров не будут взаимно приемлемыми. (Некоторые читатели, вероятно, возразят против использования понятия “противник” по отношению к заказчику или одному из руководителей. Однако сущность безнадежного про­ екта такова, что владелец проекта, заказчик, различ­ ные акционеры и заинтересованные лица вполне со­ знательно и умышленно подталкивают менеджера к принятию решений, которые по своей воле он никогда бы не принял.) Если высшее руководство угрожает уволить вас в случае провала безнадежного проекта или вы (что практически одно и то же) категорически не согласны с нереальными планами, которые вас заставляют при­ нять, вам следует в ответ проявить такое же хладно­ кровие и настойчивость в своих требованиях. Может быть, и не стоит сильно настаивать на изменении пла­ на, однако следует проявить гораздо большую требо­ вательность, когда речь пойдет о формировании про­ ектной команды (этот вопрос будет более детально обсуждаться в следующей главе). И, определенно, нужно быть настойчивым в том, что касается игнори­ рования или отмены административных и бюрократи­ ческих правил и процедур, которые могут гарантиро­ вать провал безнадежного проекта. По этому поводу есть старая поговорка: “Сначала сделай, потом извиняйся”. Может быть, не стоит терять время на переговоры, чтобы добиться для себя времен­ ной передышки от всяких бюрократических ограниче­ ний, которые могут погубить проект. Определенно, не­ зачем пытаться это сделать, поскольку само ваше назначение со стороны высшего руководства обычно

дает достаточно прав, чтобы обойти или проигнориро­ вать деятельность различных начальников, комитетов и блюстителей стандартов, вьющихся вокруг проекта. Од­ нако, если вы получите уклончивый ответ вроде: “Мы вовсе не уверены, что это такая уж хорошая идея — дать вашим программистам два ПК и разрешить им ра­ ботать вне офиса; нам надо посоветоваться с хозяйст­ венной службой и узнать, что они об этом думают”, не теряйте больше времени даром. Просто идите и делайте то, что считаете нужным! Любой умный человек найдет способ обойти многие из бюрократических рогаток таким образом, что бюро­ кратам потребуется шесть месяцев, чтобы обнаружить это и предпринять ответное наступление; к тому време­ ни ваш проект может уже закончиться (или успеет про­ валиться). Если же бюрократия пойдет в наступление, будьте готовы ответить тем же. В конце концов, работа находится в самом разгаре, и руководство, вероятно, не захочет сталкиваться с риском вашего ухода (и ухода всей команды) и необходимостью начинать все сначала. Если вы выбрали такой вариант действий, нужно пом­ нить о двух вещах: • Вы должны быть готовы к тому, что вас будут провоцировать. Если блюстители методологии из службы стандартов обратят внимание на ваш проект и придут в негодование от того, что вы не используете официально утвержденную методо­ логию компании, то вас наверняка ждет гнев­ ный звонок от босса вашего босса. Вы должны ответить: “Мистер Большая Шишка, мы реши­ ли не использовать эту методологию, потому что она гарантирует провал. Если вы считаете необ­ ходимым настаивать на ней, моя команда и я го­ товы уйти хоть сегодня, с другой стороны, я был бы чрезвычайно признателен, если бы вы оста­ вили нас в покое и велели блюстителям стан­ дартов сделать то же самое. Мы делаем все, что

необходимо”. Эт от прием не сработает до тех пор, пока большой начальник в самом деле не убедится, что вы и ваша команда уйдете немедленно, как только вас к этому вынудят.

• Вы должны быть готовы иметь дело с врагами, которые даже в случае успеха проекта будут иметь на вас зуб. Например, в описанном выше случае вы бросили вызов Большой Шишке, и он этого не забудет. Вы спутали карты блюстите­ лям методологии и тем самым облегчили жизнь их жертвам; они никогда не простят вам этого. В самом деле, вы могли сжечь так много мостов и нажить столько врагов, что вам (и, возможно, вашей команде тоже) придется уйти к концу проекта. Если отставка или жесткая линия поведения на пере­ говорах для вас неприемлемы, что же тогда остается де­ лать, если переговоры приносят неудовлетворительные результаты? Все очень просто: надо переопределить сущность проекта (см. рис. 2.1, глава 2). В самом начале переговоров вам может казаться, что начинается проект “невыполнимая миссия” . Действительно, имея достаточ­ ные ресурсы и талантливых исполнителей, вы готовы творить чудеса. Однако, если ресурсов окажется недо­ статочно, а программисты будут тупыми, то с чудесами ничего не выйдет. Таким образом, вероятно, что вас толкают в проект “камикадзе” или “самоубийство” . В лучшем случае при достаточно жесткой позиции на переговорах может по­ лучиться “отвратительный” проект. Все же менеджер проекта должен верить в возможность достижения по­ ставленных целей (в частности, планов, требуемой функциональности и т.д.) и найти способ убедить участ­ ников проектной команды в их достижимости. Как отме­ тил Джон Бодци в [ 10]:

Лидер проекта, который заботится о своих сотрудниках, не должен обещать им золотые горы и скрывать истинное положение вещей. Он честно скажет о том, какие усилия от них потребуются и каковы шансы на успех. Про­ граммисты вовсе не так уж глупы. Самые опытные из них прекрасно чувствуют, когда им “вешают лапшу на уши". Большинство из них не желают участвовать в разных играх вокруг проекта, зная, что в случае кризиса вся его тяжесть ляжет именно на них.

Если же менеджер проекта убедился, что цели без­ надежного проекта недостижимы, но проект в любом случае должен продолжаться, то для него очень важно донести до остальных участников команды, что они оказались в проекте “ камикадзе” или “самоубийство". Некоторые могут согласиться с любым вариантом, и менеджеру важно понимать причины, толкнувшие их на это; а другие могут отказаться от участия в проек­ те. Например, вполне возможно, что ущемленные в чем-либо участники проекта рассматривают его как отличный способ отомстить обидевшей их организа­ ции, поэтому они могут присоединиться к проектной команде с единственной целью — обеспечить провал проекта. В этом есть любопытный этический аспект. Как было отмечено выше, я вовсе не советую поступать неэтично или аморально, однако я также считаю, что те переговоры, которые имеют место в безнадежном проекте, вынуждают менеджера проекта относиться к владельцу, заказчику и/или высшему руководству как к противникам. С другой стороны, участники проект­ ной команды подобны одной семье. Помимо чисто деловых и профессиональных взаимоотношений с уча­ стниками команды, менеджер должен ощущать ответ­ ственность за них и заботиться о том, чтобы они не

стали жертвами политических баталий. Я признателен Джону Бодди [10] за цитирование высказывания На­ полеона, которое выражает эту мысль более убеди­ тельно, чем я смог бы это сделать: Каждый командующий армией, обязанный выполнять план, который он считает пороч­ ным, должен отстаивать свои доводы и тре­ бовать изменения плана и, в конце концов, дол­ жен скорее подать в отставку, чем стать причиной поражения своей армии.

Библиография 1. Tarek Abdel-Hamid, Stuart Madnick. Software Project Dynamics. Prentice-Hall, 1993. 2. Barry Boehm. Software Engineering Economics. Prentice-Hall, 1981. 3. Barry Boehm, Bradford Clark, Ellis Horowitz, Chris Westland, Ray Madachy, Richard Selby. The COCOMO 2.0 Software Cost Estimation Model. American Programmer, July 1996. 4. Frederick Brooks. The Mythical Man-Month. 20th anniversary edition, Reading, MA: Addison-Wesley, 1995. 5. Jim McCarthy. Dynamics of Software Develop­ ment. Redmond, WA: Microsoft Press, 1995. 6. Robert E. Park, Wolfhart B. Goethert, J. Todd Webb. Software Cost and Shedule Estimating: A Process Improvement Initiative. Technical Report CMU/SEI-94-

SR-03. Pittsburgh, PA: Software Engineering Institute, May 1994. 7. Robert E. Park. Checklist and Criteria for Evaluating the Cost and Schedule Estimating Capabilities of Software Organizations. Technical Report CMU/SEI-95-

SR-005. Pittsburgh, PA: Software Engineering Institute, January 1995.

8. Rob Thomsett. Double Dummy Spit and Other Estimating Games. American Programmer, June 1996. 9. Edward Yourdon. Rise and Resurrection of the American Programmer. Upper Saddle River, NJ: Prentice-Hall, 1996. 10. John Boddie. Crunch Mode. Englewood Cliffs: Prentice-Hall/Yourdon Press, 1987.

ГЛАВА 4

ЧЕЛОВЕЧЕСКИЙ ФАКТОР В БЕЗНАДЕЖНЫХ ПРОЕКТАХ

Джеральд Вейнберг, автор книги по психологии про­ граммирования, любит говорить, что у каждого проекта есть три проблемы: люди, люди и люди. Это как нельзя лучше характеризует безнадежные проекты: если у вас имеются ограниченные средства, то большинство ме­ неджеров проекта скажет, что для повышения шансов на успех в безнадежном проекте их надо потратить на “человеческие ресурсы” . Это не означает, что сплочен­ ная команда суперталантливых людей всегда сумеет справиться с несовершенными процессами, устаревши­ ми инструментами, не расположенными к сотрудничест­ ву пользователями, враждебно настроенными заинтере­ сованными лицами, недостаточным бюджетом и крайне сжатыми сроками, но я скорее сделаю ставку на такую команду, чем понадеюсь на то, что средненькая команда, вооруженная мощными средствами программирования и передовой методологией, сможет справиться со всеми этими проблемами. Итак, если человеческий фактор играет самую важ­ ную роль, что же нам следует делать? Собственно, в этом нет ничего нового. Будьте настойчивы в отстаива­ нии права формировать собственную команду. Можно ожидать, что команда будет работать сверхурочно. Од­ нако при этом надо помнить, что они участвуют в мара­ фоне и могут пробежать в спринтерском темпе только последние 100 ярдов. Если работа над проектом закон­

чится успешно, добейтесь для них щедрого вознагражде­ ния. Но не дразните их обещаниями будущих экстраор­ динарных наград, потому что это только собьет их с толку. Приложите максимум усилий для создания спаян­ ной и дружной команды, готовой к сотрудничеству. Важ­ но, чтобы все члены команды имели необходимую ква­ лификацию, а также умели общаться друг с другом. В основном, это все, что касается человеческого факто­ ра в безнадежном проекте. К сожалению, этого явно недостаточно для большин­ ства менеджеров безнадежных проектов, поскольку они работают в организациях, пренебрегающих человече­ ским фактором даже в “нормальных” проектах. Может показаться, что в таких условиях безнадежные проекты обречены на провал, но иногда получается как раз на­ оборот. Как отмечалось в главе 3, менеджер может быть вынужден согласиться с нереальными сроками или бюд­ жетом, но в качестве компенсации — настаивать на принятии предложенных им решений по вопросам пер­ сонала (на праве нанимать нужных исполнителей, соот­ ветствующим образом вознаграждать их и обеспечивать им нормальные условия работы). Безнадежный проект может восприниматься как уг­ роза теми, кто желает сохранить бюрократическое ста­ тус-кво. Менеджер проекта, обходя бюрократические ограничения с помощью непосредственных распоряже­ ний высшего руководства, должен быть готов к тому, что приобретет себе вечных врагов в лице кадровых работ­ ников и других администраторов. Тем не менее, если безнадежный проект будет иметь громкий успех, он мо­ жет послужить катализатором к изменению кадровой политики в последующих “ нормальных” проектах. В любом случае, в этой главе я вовсе не ставлю зада­ чу менять сложившуюся в организации культуру управ­ ления людскими ресурсами. На эту тему уже написано достаточно много, особенно в такой замечательной кни­ ге, как “ Peopleware" Тома ДеМарко и Тима Листера [1]

(ряд ссылок содержится в конце главы). Главный вопрос данной главы заключается в следующем: если вы уже знакомы с “основами” управления персоналом, что но­ вого привносят безнадежные проекты?

4.1 Кадровые вопросы Первая отличительная особенность безнадежного проекта — умение правильно сформировать проектную команду. Сотрудничая с софтверными организациями в разных странах, я сталкивался с четырьмя наиболее распространенными стратегиями формирования коман­ ды безнадежного проекта: • нанять суперпрограммистов и предоставить им свободу действий; • настаивать на привлечении команды, которая готова к “невыполнимой миссии” и имеет опыт совместной работы; • набрать команду из простых смертных, но при условии, что они будут знать, на что идут; • взять любых сотрудников, которых вам дают, и сделать из них команду “невыполнимой миссии”. Первая стратегия выглядит весьма заманчиво. Пред­ полагается, что суперпрограммисты будут невероятно изобретательны, чтобы предложить для безнадежного проекта новые решения. С другой стороны, это риск, по­ скольку суперпрограммисты обычно являются супер­ эгоистами и могут не ужиться друг с другом. Кроме того, для многих организаций такая стратегия проблематична, поскольку руководство не желает платить суперпро­ граммистам такую высокую зарплату, какую они требу­ ют. И даже если это вам по карману, мало шансов на то, что они согласятся работать над безнадежным проек­

том — ведь они все работают в Netscape или Microsoft или еще где-нибудь, где, по их мнению, — действитель­ но впечатляющие проекты. Вторая стратегия почти наверняка будет идеальной для большинства организаций, поскольку она не требует привлечения суперпрограммистов. Кроме того, такой тип проектной команды воспет телесериалом "Невы­ полнимая миссия ” . Однако, если ваша организация предпринимает свой первый безнадежный проект, такой команды просто не существует. Если же такие проекты ранее имели место и носили характер “самоубийствен­ ных” , “камикадзе” или “отвратительных” проектов, то их команды в дальнейшем, скорее всего, распались и прекратили свое существование. Таким образом, стра­ тегия сохранения в целости проектной команды успеш­ ного безнадежного проекта должна, как правило, пла­ нироваться заранее как корпоративная стратегия, исходя из предположения, что безнадежные проекты мо­ гут появиться в будущем. Третья стратегия, по вполне очевидным причинам, является наиболее распространенной. В большинстве организаций нет суперпрограммистов и нет тех, кто уцелел в предыдущих безнадежных проектах. Следова­ тельно, команда каждого нового безнадежного проекта комплектуется заново. Участники команды вполне ком­ петентны и, возможно, выше среднего уровня разработ­ чиков в данной организации, однако от них нельзя ожи­ дать сотворения чудес. Для данной стратегии жизненно важно, чтобы участники команды понимали, на что они идут; знали, что им придется совершать необычайные подвиги в разработке ПО. Последней стратегии следует избегать при любых за­ тратах. Если проект превращается в “свалку" для со­ трудников, которых не хотят брать ни в какие другие проекты, он почти наверняка будет “самоубийствен­ ным”. Такой тип команды также воспет Голливудом, особенно в фильмах, например “Чертовой Дюжине".

Их смысл заключается в том, что отверженных и неудач­ ников может сплотить сильный, харизматический лидер и заставить их совершать чудеса. Все это хорошо, одна­ ко Голливуд ничего не рассказывает нам о проектах, осуществляемых командами неудачников. Я думаю, что если вы согласитесь руководить таким проектом (или участвовать в нем), то вы — самоубийца. Мы подошли к центральному вопросу формирования команды безнадежного проекта: до какой степени ме­ неджеру проекта следует настаивать на своем праве принимать кадровые решения? Как было отмечено выше, большинство менеджеров вынуждены прими­ риться с фактом, что они не получат карт-бланш, что­ бы нанимать самых талантливых суперпрограммистов в мире. Кроме того, существующая в организации полити­ ка может не позволить менеджеру по собственной воле, не спрашивая разрешения, привлечь в проект лучших сотрудников организации, поскольку они либо уже уча­ ствуют в других важных проектах, либо их свирепо от­ стаивают другие менеджеры. Но есть один аспект, кото­ рый, по моему убеждению, менеджер должен отстаивать как свое абсолютное право: это право наложить вето на попытку других руководителей навязать проектной команде неугодного им сотрудника. В противном случае и уровень риска в проекте может повыситься до недо­ пустимых пределов. Естественно, такая ситуация порождает разнообраз­ ные и неприятные политические баталии. Менеджеру проекта придется, вероятно, выслушивать всякие успо­ каивающие заверения вроде: “Не надо беспокоиться. У Чарли были некоторые проблемы в предыдущих про­ ектах, но с твоим будет все в порядке” . Или “Ты такой грандиозный менеджер, и я уверен, что ты способен раз­ вернуть Чарли на 180° и получить от него реальную от­ дачу”. Мой совет — держаться до последнего и быть не­ преклонным в своем праве отвергнуть любого, кто, по вашему мнению, не подходит для проектной команды.

Один из критериев таких решений — это вероят­ ность того, что предполагаемый участник команды покннет проект, не дожидаясь его окончания. Разумеется, большинство разработчиков не расскажут вам ничего о своих планах уйти в середине проекта. Однако некото­ рые из них все же поделятся своими личными намере­ ниями (женитьбе, разводе, планируемой экспедиции в Гималаи и т.д.), которые могут вывести их из работы над проектом. Крайне нежелательно в самом разгаре проек­ та лишиться некоторых сотрудников и оказаться вынуж­ денным принимать новых людей. В главе 3 я рассматривал варианты действий, кото­ рые имеются у менеджера проекта в случае неудачи пе­ реговоров: уйти в отставку, обратиться за помощью к высокому руководству, игнорировать бюрократические правила и принимать свои собственные решения или определить для себя проект как самоубийственную мис­ сию. Игнорирование правил обычно является сложным делом, поскольку включение дополнительных участни­ ков в проектную команду может быть связано с огра­ ничениями штатного расписания, которое менеджеру проекта неподконтрольно. С другой стороны, иногда имеется возможность “одолжить” людей из другого про­ екта или даже нанять по контракту временных исполни­ телей. Можно также попытаться изолировать нежелатель­ ного участника команды, которого включили в проект против воли менеджера; его можно загрузить какой-ни­ будь безобидной работой или отправить изучать поведе­ ние африканских мух цеце до самого конца проекта. Даг Скотт описал еще более хитрый вариант такой стра­ тегии: Безнадежные проекты к концу зачастую оказываются в таком отчаянном положении, что высшее руководство готово выбросить любые средства, например, чтобы нанять еще 20 человек. В таких случаях я всегда со­

глашаюсь. Я поручаю этим субъектам менять перегоревшие предохранители у кофейного автомата и другие важнейшие задания, в то время как я занимаюсь своими лучшими со­ трудниками. (Среди этих людей, если вдруг по­ везет, тоже могут оказаться хорошие испол­ нители.) Затем вы можете способствовать уходу из проекта лишних людей и продолжать настаивать на их замене все новыми и новы­ ми. Например, в одном случае я сократил пер­ воначальный персонал на 20% и, несмотря на это, получил нужный результат высшего ка­ чества. В этом нет ничего удивительного.

4.2 Лояльность, обязательства, мотивация и вознаграждения В главе 2 мы рассматривали вопросы отношения к безнадежному проекту. Оно является важным эле­ ментом политики в проектах такого рода, а также од­ ной из ключевых характеристик команды, которой менеджер проекта должен уделять максимальное вни­ мание. В идеальном случае (с точки зрения менедже­ ра проекта) участники команды должны дать клятву верности и преданности безнадежному проекту; для молодых и неженатых технарей это звучит не так уж дико, как может показаться. С другой стороны, отно­ шение существенно зависит от длительности проекта. Можно работать над 3- или 6-месячным проектом, но не над трехлетним. Отношение к проекту также зависит от способности менеджера проекта заинтересовать участников команды этой работой. До какой-то степени это определяется его харизмой. Некоторым менеджерам удается привлечь участников команды к работе и сделать так, что они бу­ дут преданы ей до конца и последуют за своим руководи­ телем хоть на край света. Другие настолько бездарны в

этом отношении, что их команды и палец о палец бы не ударили, даже если целью проекта было бы спасение че­ ловечества от вторжения пришельцев. Конечно, можно возразить, что менеджер должен брать в свою команду только тех, кто проявляет высо­ кую заинтересованность. Можно также утверждать, что данное обсуждение вообще бессмысленно, поскольку большинство разработчиков ПО и так обладает доста­ точной мотивацией, как отмечают в [ 1] Том ДеМарко и Тим Листер: Для любого работника нет ничего более обескураживающего, чем чувствовать, что его собственной мотивации явно недостаточ­ но, и она должна “подкрепляться" его боссом. Достаточно редко приходится прибегать к драконовским мерам, чтобы заставить ваших людей работать; большинство из них любит свою работу.

Существуют уровни или степени мотивации. Мы мо­ жем рассчитывать на то, что разработчик ПО проявит определенную степень мотивации в “нормальном’’ про­ екте, но безнадежные проекты требуют более высокой степени, поскольку участникам команды месяцами при­ дется выдерживать изнурительную работу, политиче­ ское давление и технические трудности. Кроме того, в начале проекта менеджер сталкивается с такой пробле­ мой, как отсутствие точного знания мотивации каждого из участников команды. Как отмечает Даг Скотт: Вы предполагаете, менеджер знает, что за людей он получает в свою команду. У меня обычно получалось так, что их включали в команду до того, как я успевал узнать о них что-либо хорошее или плохое.

Во многих случаях основные факторы, влияющие на мотивацию (или демотивацию), сосредоточены вокруг

техпроцессов, которые происходят в команде (ниже бу­ дем обсуяедать эти вопросы более детально). Существу­ ет, однако, два конкретных фактора, которые оказывают значительное воздействие на мотивацию и находятся под непосредственным контролем менеджера: вознагражде­ ния за работу и сверхурочное время.

4.2.1 Стимулирование участников проекта Было бы здорово решить проблему мотивации, посу­ лив большие суммы денег каждому участнику проектной команды (и менеджеру, конечно!). Фредерик Херцберг [2], тем не менее, полагает, что не всегда можно обой­ тись одними деньгами: Деньги, выгода, комфорт и тому подобное являются факторами “гигиены ” — их отсут­ ствие вызывает неудовлетворенность, одна­ ко они не могут заставить людей полюбить свою работу и дать им необходимые внутрен­ ние стимулы. Что действительно может стать стимулами, так это ощущение значи­ тельности достигнутых результатов, гор­ дость за хорошо выполненную работу, более высокая ответственность, продвижение по службе и профессиональный рост — все то, что обогащает труд.

Эта оценка достаточно точно характеризует “ нор­ мальные” проекты. А в большинстве безнадежных проектов деньги все же играют важную роль. На са­ мом деле они могут являться главной целью всего проекта. Многие начинающие компании Силиконовой Долины предпринимают безумные и бесперспектив­ ные проекты в надежде на то, что им удастся разрабо­ тать какое-нибудь совершенно “убойное” приложение

для нового технического устройства и продать милли­ он его копий на сгорающем от нетерпения рынке. Если участники проектной команды являются акцио­ нерами и собираются участвовать в распределении прибыли, то денежное вознаграждение, очевидно, со­ ставляет весьма существенную часть мотивации их участия в проекте. Действительно, многие компании Силиконовой Долины намеренно придерживают зар­ плату на 2 0 — 30% ниже преобладающего на рынке уровня, заинтересовывая своих специалистов возмож­ ностью серьезного участия в акционировании и других формах распределения будущей прибыли. Эта страте­ гия направлена не только на повышение мотивации, но также и на снижение расхода наличности, посколь­ ку зарплаты сотрудников зачастую составляют единст­ венные самые крупные затраты начинающей софтвер­ ной компании. Разумеется, существуют из ряда вон выходящие безнадежные проекты, в которых деньги не играют никакой роли. Разработчик ПО, получивший единст­ венный в жизни шанс в проекте, подобном открытию средства против СПИДа, не нуждается в деньгах. Он, безусловно, согласен с комментарием Стива Джобса по поводу проекта Macintosh: “ Само путешествие это награда” С другой стороны, мне доводилось встречаться с угнетающе скучными безнадежными проектами в дряхлеющих правительственных учреждениях, в кото­ рых никто не питает ни малейшей надежды на какоелибо дополнительное вознаграждение. Размеры зар­ платы определяются уровнем, установленным для го­ сударственных служащих, и ее структура закреплена законодательством (она не допускает никаких премий, акционирования или участия в распределении прибы­ ли). В таких ситуациях, очевидно, глупо даже обсуж­ дать денежное вознаграждение в качестве стимула — это может только расстроить участников команды.

Ну а как насчет гибкой организации? Если безна­ дежный проект достаточно важен для предприятия, оно найдет способы зарезервировать значительный премиальный фонд для поощрения проектной команды при условии удачного завершения проекта в срок. Возможность премирования существует и для “нор­ мальных" проектов, однако премии там обычно более умеренные. Приятно получить в конце проекта чек на $1000, но третью часть этой суммы составят налоги, а того, что останется, явно недостаточно, чтобы повы­ сить жизненный уровень типичного разработчика ПО со средним уровнем доходов. В безнадежных проектах дело обстоит иначе: премиального чека на $10 ООО может оказаться достаточно для покупки новой маши­ ны (пускай даже самой скромной по современным меркам!) или отдыха за границей. Чека на $100 000 хватит, чтобы заплатить за обучение ребенка в пре­ стижном колледже или купить дом (по крайней мере, заплатить за него первый взнос). Наконец, чека на $1 000 000 достаточно, чтобы обеспечить себе дос­ тойную пенсию. Допуская возможность такого вознаграждения, сде­ лаем некоторые замечания: • Не забывайте о том, что 20%-ное повышение зарплаты имеет гораздо большее значение для молодого программиста, зарабатывающего $25 000 в год, чем для опытного и квалифици­ рованного программиста с годовым доходом $75 000. При более высокой зарплате пре­ дельная налоговая ставка обычно существенно выше и может достигать 50% , поэтому опыт­ ный программист приносит домой не намного больше молодого, и, следовательно, зарплата при этом рассматривается, скорее, как фактор гигиены. Что же касается молодого програм­ миста, налоговая ставка при его зарплате до­ статочно низка, и этих 20% может вполне хва-

тить для выплаты ежемесячных взносов за его первый автомобиль или переезда от родителей в арендованную квартиру. Помните, что возможность заработать боль­ шие деньги может по-разному подействовать на мотивацию людей. Руководство может пола­ гать, что она просто побудит всех работать бо­ лее интенсивно, однако, она может также за­ ставить участников команды критически и подозрительно относиться друг к другу. Напри­ мер, какой-либо из участников команды может выразить свое недовольство следующим обра­ зом: “Джордж имел наглость отсутствовать в сочельник на работе, чтобы побыть со своей глупой семейкой, как раз тогда, когда у нас был важный этап тестирования. Похоже, он соби­ рается оставить нас без премии!” Помните, что размер премии напрямую не свя­ зан с количеством времени, затрачиваемым проектной командой на выполнение проекта. Мне приходилось наблюдать, как в некоторых организациях высшее руководство пытается соблазнить проектную команду двойной преми­ ей (при отставании проекта от графика), по­ скольку руководство, очевидно, верит, что это заставит людей работать вдвое больше. Одна­ ко, если участники команды уже работают по 18 часов в день, законы физики не позволят работать вдвое больше даже самым рьяным из них. Для того чтобы премия была стимулом, проект­ ная команда должна верить, что она существует и высшее руководство не будет искать удобный предлог, чтобы отменить ее. Разумеется, если вознаграждение зависит от успеха на рынке, то никаких гарантий быть не может — например,

даже если проект закончится успешно, то воз­ можный обвал на финансовом рынке может на­ рушить все планы компании по продвижению ее продукта. Однако, если премиальное вознагра­ ждение полностью зависит от высшего руково­ дства, и проектная команда знает, что в преды­ дущих безнадежных проектах их участники его не получили, то “обещание” премии сыгра­ ет, скорее всего, роль отрицательного стимула. Аналогично, если проектная команда приходит к выводу, что она практически не влияет на успех выполнения проекта (например, зависит от своевременной поставки нового оборудования, которое разрабатывается внешним поставщи­ ком), то обещанное руководством вознагражде­ ние будет восприниматься как “ игра в лоте­ рею”, а не как стимул. • Проектная команда должна верить, что распре­ деление премии будет справедливым. Если ко­ манда знает, что львиная доля вознаграждения достанется менеджеру проекта, а другим участ­ никам останутся крошки со стола, то результат предсказуем. Подобные вопросы необходимо обсуждать в самом начале работы над проектом. Вряд ли участников проекта могут успокоить та­ кие заявления менеджера, как “Доверьтесь мне и ни о чем не беспокойтесь, я приложу все усилия, чтобы каждому досталось по справедли­ вости”. Что касается проектов, за выполнение которых не­ возможно получить большие премии, менеджеру проек­ та важно не забывать о том, что существуют разнооб­ разные виды нематериального вознаграждения. И с их помощью можно стимулировать участников проекта. Это также справедливо и для “ нормальных" проектов, но для безнадежных особенно важно. Помните, что

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

Букет цветов — это красивый жест, но для членов семьи иногда важнее более “ практичные” вознагражде­ ния — особенно для супруги, которая вынуждена водиночку управляться с хозяйством и ухаживать за детьми, в то время как ее “сильная половина” пропадает круг­ лые сутки в безнадежном проекте. Внимательный ме­ неджер проекта может выяснить, нужно ли такси, чтобы отвезти ребенка домой из школы, или оказать помощь супруге, которая сидит дома с больными детьми. Если дети серьезно больны и нуждаются в медицинской помо­ щи, менеджер проекта должен перевернуть землю, сло­ мать бюрократические преграды и сделать все, чтобы успокоить участника проекта, волнующегося о своей семье. Конечно, чтобы оказать подобную услугу, нужны деньги, но не такие уж большие. В бюджете есть статья под названием-“ прочие затраты” . Конечно, если бюро­ краты обнаружат это, они поднимут вой, что такие расходы официально не предусмотрены. Менеджер, ко­ торый уступит такому нажиму, будет просто бесхарак­ терной тряпкой; при необходимости менеджер должен оплачивать такие расходы из своего собственного кар­ мана, поскольку он обычно получает гораздо большую

зарплату, чем технические специалисты в его команде. В любом случае, воевать с бюрократами — это забота менеджера; самое последнее дело вынуждать техниче­ ских специалистов попусту тратить свое время и эмо­ циональную энергию на борьбу с бухгалтерией, чтобы доказать им целесообразность покупки дополнительной пиццы на ужин для команды, задержавшейся на работе до позднего вечера. Скромные вознаграждения в течение всего проекта обязательно сыграют свою роль, однако существуют и более действенные нематериальные поощрения, кото­ рые могут быть сделаны по окончании проекта. Я не имею в виду продвижение по службе, в конечном счете попадающее в ту же категорию, что и прямые денежные вознаграждения. Ниже приведены примеры поощрений, которые могут оказать благотворное действие в безна­ дежном проекте: • Дополнительный отпуск — если проект закон­ чится успешно, предоставьте его участникам отпуск такой же продолжительности, как и весь проект. Большинство из нас не знает тол­ ком, что делать с двухнедельным отпуском , од­ нако, если бы нам предоставили шестимесяч­ ный оплачиваемый отпуск, мы могли бы отправиться в кругосветное морское путешест­ вие, о котором всегда мечтали. Любопытный тест: выскажите эту идею своему менеджеру и посмотрите на его реакцию. Если вы услышите что-нибудь наподобие: “ Что?!? Ты, наверное, спятил? Шестимесячный отпуск за шестиме­ сячный проект?!? Мы дадим тебе пару дней и не вздумай больше искушать судьбу!” , то это означает только одно: менеджер полагает, что разработчики ПО — это не более чем бессло­ весные рабы. Такая позиция объясняет, какое отношение к трудовым соглашениям принято в данной организации.

Оплаченная свобода действий — когда безна­ дежный проект завершится, привлеките участ­ ников команды к шестимесячной работе над “ Проектом X". Вопрос: что такое “X”? Ответ: все, что они пожелают. Вместо того чтобы сра­ зу же оказаться втянутыми в еще один безна­ дежный проект (или в скучный до безобразия “ нормальный” проект, что ничуть не лучше), участники команды получат хорошую возмож­ ность в течение шести месяцев осваивать Java, изучать новейшие объектно-ориентированные методологии или даже вернуться в колледж, чтобы получить свою степень магистра. Надо проявить некоторую изобретательность, при­ думывая “официальное” название для Проекта X, чтобы поставить в тупик бюрократов; чтонибудь вроде “эвристической объектно-ориен­ тированной клиент-серверной системы страте­ гического прогнозирования с возможностями Интернета” может произвести необходимый эффект. Создание полностью оснащенной домашней компьютерной системы — хотя ПК сегодня ста­ ли намного дешевле, и у каждого из нас есть дома компьютер, он может быть необязательно суперсовременным. У многих из нас стоят ПК, купленные пять лет назад, в то время как ос­ тальной мир мчится вперед на ПК с удвоенной производительностью и вчетверо большей па­ мятью. Интересный момент, связанный с безна­ дежными проектами, заключается в том, что они зачастую оснащаются самым совершенным компьютерным оборудованием, поскольку руко­ водство готово раздуть бюджет до невообрази­ мых размеров, свято веря, что передовая техно-, логия может спасти проект. Если к концу проекта какое-либо оборудование становится

ненужным, отдайте его участникам команды в качестве премии; если же такой открытый пода­ рок нарушает слишком много бюрократических правил, передайте его хотя бы во временное пользование.

4.2.2 Сверхурочная работа В то время как премии и дополнительные отпуска являются положительным стимулом, необходимость сверхурочной работы на протяжении проекта считается отрицательным. Тем не менее, в безнадежных проектах она почти всегда неизбежна; это единственный способ, дающий менеджеру проекта хоть какой-то шанс уло­ житься в жесткий график. И, как отмечалось ранее, для нее зачастую не требуется никаких специальных просьб менеджера: молодые, холостые и фанатичные участники команды, которых возбуждает брошенный вызов и воз­ можность использования в проекте самой передовой технологии, рады работать по 60, 80 или 100 часов в не­ делю. Сверхурочным временем необходимо правильно рас­ поряжаться, чтобы избежать отрицательного воздейст­ вия на команду и не поставить под угрозу успех проекта. Один из способов это сделать — убедиться, что высшее руководство знает реальную стоимость сверхурочной ра­ боты; как отмечает консультант Дейв Кляйст: До тех пор, пока участники проектной команды не будут иметь такие же хорошие возможности участия в акционерном капитале компании, как высшее руководство, любые дру­ гие формы компенсации за участие в безна­ дежном проекте нельзя всерьез считать вознаграждением (в положительном смысле). В то время как менеджер проекта редко распо­ ряжается такого рода компенсацией, то, что

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

Независимо от того, получают участники команды компенсацию за сверхурочную работу или нет, самой большой ошибкой будет отсутствие учета этого времени. Даже если с точки зрения бухгалтерии именно так оно н есть, менеджер не должен рассматривать сверхурочное время как свободное. Предположим, что участники команды способны всю жизнь без устали работать по 18 часов в день, для менеджера критически важно фик­ сировать, сколько таких “ невидимых” сверхурочных ча­ сов затрачивается в течение работы над проектом. Для менеджера это единственный способ точно измерить производительность команды и вероятность своевре­ менного достижения каждой промежуточной контроль­ ной точки в графике проекта. Каждому известно, что люди не в состоянии рабо­ тать всю жизнь по 18 часов в день; даже если они будут очень стараться, все равно скоро устанут. А ко­ гда они устают, то становятся раздражительными и вспыльчивыми, работают менее продуктивно и дела­ ют гораздо больше ошибок. Это может отрицательно повлиять на работу над проектом. Поэтому менеджер должен четко понимать, когда следует попросить команду поработать сверхурочно, а когда не следует этого делать. Все это может показаться не столь важным для 3 — 6-месячного проекта, когда молодая и энергичная проектная команда способна “ безвылазно" сидеть на работе от начала до конца проекта. Однако для более длительных проектов тщательный контроль за сверх­

урочной работой крайне необходим. Как отметил Даг Скотт: При грамотном планировании следует знать, что потребность в сверхурочной рабо­ те может возникнуть довольно неожиданно, как вспышка, и затем так же сойти на нет. Невозможно держать людей на работе 90% времени и в течение длительного срока.

И, как отмечено в [3], важно, чтобы менеджер пони­ мал, что каждый участник команды может совершенно по-разному относиться к сверхурочной работе: У каждого индивидуума свой собственный метаболизм. Некоторые люди — “совы”, а дру­ гие — “жаворонки" (хорошо работают рано ут­ ром). Независимо от этого не будет никакого вреда здоровью от десятичасового рабочего дня. Когда проект набирает обороты, можно ожидать, что его участники будут работать как минимум по 60 ч в неделю. Если этого не происходит, проверьте в первую очередь, нет ли чего-нибудь такого в организации проекта, что мешает работать.

Лидер проекта должен рассчитывать на максимально возможное время работы. При этом, во-первых, он сам должен показывать пример. Нельзя ожидать от людей готовности к сверхурочной работе, если вы сами этого не делаете. Такую работу надо лично возглавлять. Вовторых, надо быть вместе с ними, чтобы отвечать на не­ отложные вопросы, помогать в борьбе с бюрократиче­ ской волокитой и фиксировать возникающие в эти часы проблемы. Одна из опасностей, которые менеджер проекта дол­ жен предвидеть — это чрезмерная добровольная сверх­ урочная работа той части молодых энтузиастов, которые не представляют пределов своих собственных возмож­

ностей и не задумываются о побочных эффектах работы до изнеможения. Как показано на рис. 4.1, производи­ тельность труда действительно может расти в первые 20 ч сверхурочной работы (благодаря повышенному со­ держанию адреналина в крови, концентрации внимания и т.д.). Но рано или поздно каждый достигнет критиче­ ской точки, после чего начнется спад, поскольку возрас­ тет количество ошибок и ослабнет концентрация внима­ ния. Таким образом, наступит момент, когда участник команды будет демонстрировать “отрицательную” про­ дуктивность, поскольку усилия, затрачиваемые на ис­ правление ошибок и дефектов в программах и их пере­ писывание, будут сводить к нулю всю выполненную работу. Предполагая, что масштаб на рис. 4.1 достаточ­ но точен (хотя это зависит от возможностей конкретного разработчика ПО), менеджер может относительно без­ болезненно настаивать на 60-часовой рабочей неделе. При работе от 60 до 80 ч следует четко установить пре­ делы индивидуальных возможностей каждого разработ­ чика; при 80— 90-часовой рабочей неделе менеджер должен отправлять разработчиков домой и заставлять их отдыхать.

Рис. 4.1 Зависимость производительности от количества рабочих часов

4.3 Значение коммуникации В безнадежных проектах очень важны вопросы, свя­ занные с человеческими ресурсами, — природа и сте­ пень взаимодействия между менеджером проекта и ос­ тальной командой. Идеальная ситуация — когда у менеджера проекта нет секретов от команды и каждый участник команды знает о проекте все. Это означает, что каждый участник команды располагает актуальной ин­ формацией относительно состояния проекта, первооче­ редных приоритетов, рисков, ограничений, политики и т.д. При таких условиях в команде может быть создана атмосфера взаимного доверия и доброжелательности. Если участники команды прилагают экстраординарные усилия к работе над проектом и приносят в жертву лич­ ную жизнь, для них было бы крайним разочарованием обнаружить, что менеджер проекта скрывает от них важную информацию или играет за их спиной в полити­ ческие игры. Поскольку в безнадежном проекте все процессы протекают интенсивнее и быстрее, чем в “нормальном” , выше вероятность, что участники коман­ ды обнаружат утаивание информации или непристойные политические игры вокруг них. Очевидный контраргумент против такой философии заключатся в том, что менеджер должен оберегать команду от посторонних помех, особенно от каждоднев­ ных мелочных политических игр, которые происходят вокруг проекта. В большинстве случаев участники ко­ манды по достоинству оценивают возможность освобо­ диться от политики; однако они также нуждаются в уве­ ренности, что в ответ на прямой вопрос менеджер не станет темнить или лгать им. В большинстве проектов, нормальных или безнадежных, регулярно проводятся совещания, на которых говорится о состоянии проекта и поднимаются острые вопросы; если участники команды всегда могут узнать о том, что происходит в проекте, то­

гда они спокойно смогут на 99% сконцентрироваться на своей непосредственной работе. Уровень коммуникации между отдельными участ­ никами команды весьма важен, особенно если они ранее не работали вместе. Нужно, чтобы не было по­ стороннего вмешательства во внутрикомандное взаи­ модействие. В этом случае можно будет поддерживать честный и откровенный обмен информацией. Для большинства сегодняшних проектов это обязательно подразумевает наличие электронной почты и различ­ ных средств групповой работы наподобие Lotus Notes. Помимо этого, менеджеру проекта следует планиро­ вать еженедельные совместные завтраки или обеды, чтобы участники команды могли пообщаться друг с другом вне стен офиса.

4.4 Проблемы формирования проектной команды Открытые и честные взаимоотношения являются важной составляющей процесса формирования эффек­ тивной команды. Подбор психологически совместимых исполнителей — другая ключевая составляющая. Край­ не важно, чтобы менеджер проекта имел свободу дейст­ вий при выборе участников команды,. При подборе команды полезно использовать тесты оценки личности Бриггса-Мейерса, чтобы попытаться заранее оценить способность участников команды к взаимодействию друг с другом. Еще одна составляющая заключается в концепции командных ролей. Многие менеджеры проекта сосредо­ точиваются на чисто “технических” ролях, таких как проектировщики баз данных, специалисты по сетям, эксперты по пользовательскому интерфейсу и т.д. Все они важны, но нужно подумать и о ролях “психологиче­ ского” плана, которые могут играть один или более уча­ стников команды. Эти роли присутствуют и в "нормаль­

ных” проектах, однако в безнадежных они приобретают особую важность. Роб Томсет в [4] определил восемь ключевых ролей в проекте следующим образом:

• Председатель (chairperson) — выбирает путь, по которому команда движется вперед к общим целям, обеспечивая наилучшее использование ее ресурсов; умеет обнаружить сильные и сла­ бые стороны команды и обеспечить наибольшее применение потенциала каждого участника команды. Можно думать, что таким человеком является, как правило, официальный руководи­ тель проекта; однако в самоуправляемых коман­ дах им может быть любой человек. • Оформитель (shaper) — придает законченную форму действиям команды, направляет внима­ ние и пытается придать определенные рамки групповым обсуждениям и результатам сов­ местной деятельности. Такой человек может иметь официальную должность “архитектора” или “ведущего проектировщика” , но главное то, что эта роль “воображаемая”. В безнадежном проекте особенно важно иметь единое и четкое представление о проблеме и ее возможном ре­ шении. • Генератор идей (plant) — выдвигает новые идеи и стратегии, уделяя особое внимание глав­ ным вопросам, занимается поиском новых под­ ходов к решению проблем, с которыми сталки­ вается группа. Мне кажется, для такой роли больше подходит название “провокатор" — че­ ловек, который пытается внедрять в команде радикальные технологии, искать новые решения технических задач.

• Критик {monitor-evaluator) — анализирует проблемы с прагматической точки зрения, оце-

нивает идеи и предложения таким образом, что­ бы команда могла принять сбалансированные решения. В большинстве случаев такой человек поступает как “скептик” , уравновешивая опти­ мистические предложения оформителя и гене­ ратора идей. Критик хорошо знает, что новые технологии отнюдь не всегда работают, обеща­ ния поставщиков о возможностях новых средств и языков программирования иногда не сбыва­ ются и все может пойти не так, как было заду­ мано. Рабочая пчелка (company worker) — превра­

щает планы и концепции в практические рабо­ чие процедуры, систематически и эффективно выполняет принятые обязательства. Другими словами, в то время как оформитель придает законченную форму крупным технологическим решениям, генератор идей предлагает ради­ кальные новые решения, а критик занимается поиском изъянов и недостатков в этих предло­ жениях, рабочая пчелка — это тот человек, который работает, не привлекая внимания, и выдает “ на гора” тонны кода. Очевидно, любой безнадежный проект нуждается по крайней мере в паре таких пчелок, но сами по себе они не способны принести успех проекту, по­ скольку не обладают необходимой широтой кругозора. Опора команды ( team worker) — поддержи­

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

жет быть и менеджер проекта, так же как и любой из участников команды, относящийся более внимательно к своим коллегам. Эта роль особенно важна в безнадежных проек­ тах, поскольку команда зачастую испытывает сильный стресс, и по меньшей мере один или два ее участника начинают вести себя как рав­ нодушные ко всему “супермены” . • Добытчик (resource investigator) — обнару­ живает и сообщает о новых идеях, разработ­ ках и ресурсах, имеющихся за пределами проектной группы, налаживает внешние кон­ такты, которые могут оказаться полезными для команды, и проводит все последующие пе­ реговоры. Я предпочитаю называть такого че­ ловека “уборщиком мусора” , поскольку он всегда знает, где отыскать бесхозный ПК, сво­ бодный конференц-зал, дополнительный ра­ бочий стол или почти что любой другой ре­ сурс, в котором нуждается команда. Такие ресурсы могут быть добыты по официальным каналам или нет; но даже если их можно дос­ тать “нормальным” способом, это нередко требует заполнения 17 форм в трех экземпля­ рах, после чего приходится шесть месяцев ждать выполнения всех бюрократических про­ цедур. Безнадежный проект не может ждать так долго и не может позволить, чтобы вся ра­ бота застопорилась из-за того, что какой-то помощник вице-президента из зависти не раз­ решает воспользоваться единственным в ор­ ганизации свободным конференц-залом. Ко­ мандный добытчик имеет много друзей и связей в своей организации, с помощью кото­ рых можно выпросить или одолжить необхо­ димые ресурсы. Главное, что добытчик об о­ жает свою деятельность.

• Завершающий ( completer ) — поддерживает в команде настойчивость в достижении цели, активно стремится отыскать работу, которая требует повышенного внимания, и старается, насколько возможно, избавить команду от оши­ бок, связанных как с деятельностью, так и с бездеятельностью. Такой человек играет доми­ нирующую роль во время тестирования системы на завершающей фазе жизненного цикла проек­ та, однако его роль на более ранних стадиях тоже важна. Команде необходимо время от вре­ мени (а еще лучше каждый день!) напоминать, что они не делают себе карьеру на всю жизнь, а всего лишь участвуют в проекте с жесткими сроками и промежуточными контрольными точ­ ками, которые необходимо достигать вовремя, чтобы не провалить проект. К сожалению, даже наличие исполнителей на каждую роль и психологическая совместимость не гарантируют, что команда будет представлять собой единое целое. Как отмечено в [ 1]: Вряд ли вам удастся заставить команду стать сплоченной. Вы можете на это наде­ яться, можете скрещивать пальцы, можете предпринимать все возможное, но превратить команду в единое целое не в вашей власти. Этот процесс слишком хрупкий, чтобы им можно было управлять.

Если процесс формирования такой команды проте­ кает успешно, обычно это бывает заметно по некото­ рым внешним признакам. Как замечают ДеМарко и Листер, в преуспевающих командах обычно бывает сильное ощущение общности интересов и гордости за свою команду, а также (по крайней мере, в безнадеж­ ных проектах типа “ невыполнимая миссия” ) чувство, что они в состоянии хорошо выполнять свою работу и

получать от этого удовольствие. С другой стороны, если организация не в состоянии обеспечить создание такой сплоченной команды, это может привести к тому, что ДеМарко и Листер называют “командным самоубийством” (teamicide), т.е. принимается созна­ тельное или бессознательное решение плыть по тече­ нию и не совершать никаких действий для создания сплоченной и целостной команды. Такую ситуацию обычно порождают следующие причины: • Оборонительное руководство — не доверяю­ щее проектной команде. Отметим, что при этом для команды становится очень важным наличие “защитника” (см. главу 2). • Бюрократия — изобилие бумажной работы. Если команда обладает хоть каким-то здравым смыслом, она просто откажется заниматься бу­ мажной работой или невнятно пообещает вер­ нуться к ней после окончания проекта. • Физическое разобщение участников коман­ ды — (например, по различным зданиям, горо­ дам или странам) — конечно, электронная поч­ та и средства групповой работы могут частично решить эту проблему, однако этого явно недо­ статочно для поддержки командного духа, кото­ рый столь необходим для успеха безнадежного проекта. • Фрагментация рабочего времени участников проекта — особенно в ситуациях, когда участ­ ники команды часть своего времени официаль­ но заняты в безнадежном проекте, а в осталь­ ное время решают свои личные проблемы. Трудно вообразить себе, что в безнадежных проектах может происходить такое, однако это случается в больших бюрократических органи­ зациях.

Снижение качества продукта — хотя команда может быть готова к тому, чтобы допустить не­ которое снижение уровня качества с целью своевременной разработки “достаточно хоро­ шего” ПО, обычно существует нижняя грань, которую они откажутся перейти. Понятие каче­ ства может подразумевать наличие дефектов (ошибок), отсутствующие функции, примитив­ ный пользовательский интерфейс или некачест­ венную документацию. Нереальные сроки — настолько жесткие сроки, что команда абсолютно не верит в возможность их выполнения. Такая разновидность “команд­ ного самоубийства” обычно превращает проект “невыполнимая миссия” в “самоубийственный" проект. Произвол руководства — роспуск проектной команды после завершения проекта. Как было отмечено выше, некоторые команды по завер­ шении проекта приходят к выводу, что он невы­ разимо скучен, а пользователи, для которых они разрабатывали свои программы, — неблаго­ дарные деревенщины; таким образом, единст­ венное удовлетворение, полученное от проекта, заключается в удовольствии от совместной ра­ боты в одной команде с конкретными людьми. Это удовлетворение может быть настолько большим, что участники команды выражают на­ дежду на перспективу продолжения совместной работы в будущих проектах. Но на их беду, ко­ мандный дух, который помог им добиться успе­ ха, зачастую воспринимается руководством как угроза для своего благополучия, поэтому рос­ пуск такой команды после завершения проекта является обычным делом. Такая перспектива, в свою очередь, является настолько деморали-

зующей, что команда может распасться еще до окончания проекта. Последнее, что следует сказать относительно форми­ рования сплоченной команды: даже если удается это сделать, то никак не в самый первый день проекта. Ти­ пичная команда в процессе своей эволюции проходит четыре стадии, которые также относятся к процессу до­ стижения понимания и поиску общего решения при­ кладной проблемы: • Формирование: участники команды определя­ ют цели, роли и направление работы. • Утряска: команда устанавливает правила и процедуры принятия решений и, как правило, пересматривает роли и ответственность. • Нормирование: вырабатываются процедуры, стандарты и критерии. • Выполнение: команда начинает функциониро­ вать как целое. В идеальном случае команда оказывается уже про­ шедшей первые две стадии еще до начала проекта, по­ скольку участники команды работали вместе в предыду­ щих проектах. Тем не менее, все проекты разные, и в ка>вдой проектной команде обычно имеются один или два новых человека, присутствие которых повлечет за собой некоторое “формирование” и “утряску”. Но неза­ висимо от того, сколько времени потребуется на весь процесс — день, неделя или месяц, — он все равно произойдет; если это окажется возможным, менеджеру проекта следует постараться как можно больше ввести команду в курс дела еще до “официального” начала про­ екта, чтобы к этому моменту уже оказаться в стадии “выполнения” . Важно также не забывать, что даже сплоченная команда может развалиться под воздействием стрессов.

которые они испытывают в безнадежном проекте. В своем письме ко мне Дейл Эмери рекомендует, чтобы менеджер проекта внимательно следил за процессами, происходящими в команде: Уделяйте внимание взаимоотношениям, складывающимся в команде, и не жалейте уси­ лий на поддержку готовности людей к совме­ стной сверхурочной работе. Давление, кото­ рое испытывают участники безнадежного проекта, может превратить небольшие недо­ разумения в серьезные конфликты. Периодиче­ ское “измерение температуры” в группе мо­ жет помочь вам и команде справляться с проблемами во взаимоотношениях, когда они еще в самом зародыше.

В худшем случае команда так и не пройдет первые две стадии, или, иначе говоря, встанет на путь “командного самоубийства” , не сумев справиться с перечисленными выше проблемами. Если через какое-то время менеджер проекта (или кто-нибудь из более высокого руковод­ ства) обнаружит, что так оно и произошло, может оказаться слишком поздно формировать новую команду. Се ля ви.

4.5 Условия работы в безнадежном проекте Проблемы создания нормальных условий для работы (в противоположность офисным кабинкам Дилберта) так много лет обсуждаются среди разработчиков ПО, что кажется бессмысленным снова их поднимать. Том ДеМарко и Тим Листер, чья книга [1] уже не раз цити­ ровалась, уделяют большое внимание тем преимущест­ вам, которые дает создание нормальных условий для ра­

боты. Если разработчики ПО работают в достаточно тихом помещении, вероятность появления у них ошибок уменьшается на одну треть по сравнению с теми, кто ра­ ботает в шумном офисе и постоянно отвлекается на по­ сторонние дела. Проанализировав работу 600 разработчиков ПО, ДеМарко и Листер смогли получить результаты, убеди­ тельно говорящие о том, что продуктивность работы тех, кто находится в хорошем офисе и может закрыть дверь, не отвечать на телефонные звонки и не отвлекаться на посторонние дела, почти в 2,6 раза выше, чем у находя­ щихся в обычном офисе. ДеМарко и Листер опубликовали свою работу в 1987 г., но с тех пор в условиях работы большинства разработчиков ПО мало что изменилось — за исклю­ чением фирм-разработчиков ПО. Условия работы в Microsoft и в большинстве других софтверных компа­ ний Силиконовой Долины достаточно цивилизован­ ные — отдельные помещения с закрытыми дверями, наличие содовой, сока и других напитков, и “ постоян­ ный” телефонный номер, который остается за про­ граммистом даже в том случае, если он перебирается в другое помещение. Разработчики ПО, работающие в банках, страхо­ вых компаниях, правительственных учреждениях, про­ мышленных предприятиях и сотнях других компаний, до сих пор смотрят на программное обеспечение как на “накладные” расходы. Поэтому им приходится ра­ ботать не в нормальных офисах, а в отгороженных клетушках, где практически нет возможности скон­ центрировать свои умственные усилия на решении ка­ кой-либо проблемы. Звучит набившая оскомину му­ зыка, не прекращаются телефонные звонки, лают собаки, кричат люди и нет никакого спасения от кого угодно (от курьера до директора), кто может засунуть голову в твою комнату и отвлечь от работы. Как от­ мечают ДеМарко и Листер:

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

Пока сотрудники будут тесниться в шумных и непри­ способленных помещениях, нельзя говорить о сколь-ни­ будь продуктивной работе. К сожалению, мои рассуждения относительно сло­ жившейся ситуации вряд ли смогут оказать на нашу индустрию большее воздействие, чем гораздо более детальные и убедительные выкладки ДеМарко и Лис­ тера. Однако не следует забывать, что мы здесь гово­ рим о безнадежных проектах, к которым применимы другие правила, и я думаю, что менеджеру проекта следует принять такую философскую позицию, кото­ рая подразумевает отсутствие вообще каких бы то ни было правил. Если вы являетесь менеджером безнадежного проек­ та с практически нереальными сроками, то сведений о том, что хорошие условия работы могут улучшить про­ дуктивность в 2,6 раза, может оказаться достаточно, чтобы заставить вас сломать множество преград. То, чего вам удастся в этом деле достичь, может оказаться всего лишь временным; как только проект закончится, налетит хозяйственная служба, все отберет и вернет вас обратно в крохотные клетушки. Однако, если безнадеж­ ный проект продолжается хотя бы полгода и вы доста­ точно изобретательны, стоит попытаться обеспечить подходящие условия для работы таким образом, чтобы хозяйственная служба вообще не знала о том, что про­ исходит. Для этого есть несколько возможностей:

Лобовая ат ака — если у вашего проекта есть

защитник и/или владелец, которые крайне заинтересованы в его успехе, объясните им, насколько важно, чтобы проектная команда работала в хороших условиях. Если защитник проекта является руководителем высокого уровня, то организовать временный переезд команды в более подходящее помещение будет несложно. Самовольный захват — не спрашивая ни у

кого разрешения, займите какое-нибудь пустое помещение. Такой захват обеспечит 90% успеха в борьбе за условия работы; пока бюрократы будут ругаться, спорить и отправлять в разные стороны гневные послания, вам, может быть, уже удастся закончить проект и незаметно уда­ литься на прежнее место. Дистанционный доступ — разрешите всем

работать дома и организуйте еженедельные ра­ бочие совещания в ближайшем “Макдональд­ се” (в 9 ч утра, когда почти нет посетителей). Пока кто-нибудь обнаружит исчезновение команды, может пройти не одна неделя. Для до­ полнительного отвлечения внимания можно посадить чучела за столы, которые обычно за ­ нимала проектная команда; руководству понадо­ бится достаточно много времени, чтобы отли­ чить их от других зомби, сидящих в офисе. Переход на работ у в ночную смену — это

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

полуночи! Они будут слать сердитые записки и послания по электронной почте, при этом сле­ дует игнорировать их и делать вид, что никогда их не получали. Если это не удается, просто от­ кажитесь менять свой график работы; пока они не додумаются отключать свет или поменять замки на двери офиса, вряд ли им удастся по­ мешать вам в рамках обычного безнадежного проекта. • Преграды и заслоны — если ваша команда работает в обычном “открытом” офисе и упо­ мянутые выше стратегии неприменимы, тогда постарайтесь сделать все возможное, чтобы собрать команду в смежных помещениях. По­ сле этого сделайте все необходимое, чтобы за­ баррикадироваться от остальной толпы в офи­ се. Отключите селекторную связь и вопящий громкоговоритель (и будьте готовы проделы­ вать это еженедельно, поскольку обслуживаю­ щий персонал может снова включить их). Вы­ ключите телефоны из сети, или, как советуют ДеМарко и Листер, набейте вату в звонок. Если вы сможете проделать такое на целом этаже или вообще во всем здании, то будет еще лучше. Поднимите над зданием пиратский флаг, как это сделал Стив Джобс со своей командой в Apple во время проекта Macintosh. Установите охрану, чтобы гнать прочь непро­ шеных визитеров. Некоторые из этих акций могут спровоцировать бо­ лее резкую ответную реакцию корпоративной бюрокра­ тии, чем другие; команда и ее менеджер должны решить, какая стратегия будет наиболее эффективной. Но я хо­ тел бы подчеркнуть, что вполне серьезно рассматриваю все эти стратегии, невзирая на очевидный факт, что они нарушают “ правила игры", принятые почти в каждой

крупной компании. Борьба с бюрократией таким спосо­ бом — не для робкого десятка; но ведь и сами безна­ дежные проекты тоже не для робкого десятка. Если ме­ неджер безнадежного проекта не проявляет желания бороться и отстаивать право на нормальные условия ра­ боты, то с какой стати проектная команда должна идти на экстраординарные жертвы ради организации и менед­ жера проекта?

4.6 Заключение Талантливых исполнителей, сплоченной команды и хороших условий для работы все же недостаточно, что­ бы гарантировать успех безнадежного проекта. С другой стороны, их отсутствие приведет к провалу проекта. Как будет ясно из следующих двух глав, хорошо организо­ ванные процессы разработки и хорошая технология так­ же являются важными составляющими успеха; однако самая главная составляющая — это люди. Как сказал Рональд Рейган: “Окружите себя самыми лучшими людьми, которых вы только сможете найти, передайте в их руки власть и не мешайте им".

Библиография 1. Tom DeMarco, Tim Lister. Peopleware. Dorset House Publishing, second edition, 1997. 2. Frederick Herzberg. One More Time: How Do You Motivate Employees? Harvard Business Review , Sept.Oct. 1987. 3. John Boddie. Crunch Mode. Prentice Hall/Yourdon Press, 1987. 4. Rob Thomsett. Effective Project Teams: A Dilemma, a Model, a Solution. American Programmer, July-August 1990.

5. Peter R. Scholtes, Brian L. Joiner, Barbara Streibel. The Team Handbook. Oriel Inc., 1996. 6. Rich Cohen, Warren Keuffel. Pull Together. Software M a g a z in e , Aug. 1991. 7. Larry Constantine. Constantine on Peopleware. Englewood Cliffs, NJ: Prentice Hall, 1995. ISBN: 0-13-331976-8. 8. Larry Constantine. The Peopleware Papers. Engle­ wood Cliffs, NJ: Prentice Hall, 2001. ISBN: 0-13-060123-3 9. J. Daniel Couger, Robert A. Zawacki. Motivating and M a n a g in g Computer Personnel. New York: John Wiley & Sons, 1980. ISBN: 0-471084-85-9. 10. B. Curtis, W.E. Hefley, S. Miller. People Capability Maturity Model, Draft version 0.3. Pittsburgh, PA: Software Engineering Institute, April 1995. 11. Torn DeMarco, Timothy Lister. Programmer Productivity and the Effects of the Workplace. Proce­ edings o f the 8th fC S E , Washington, DC: IEEE Press, 1985. 12. Tom DeMarco. Slack: Getting Past Burnout, Busywork, and the M yth of Total Efficiency. Broadway Books, 2001. ISBN: 0-76-790768-X. 13. J. Richard Hackman (ed.). Groups That Work (and Those That D o n ’t): Creating Conditions for Effective Teamwork. San Francisco, CA: Jossey-Bass, 1990. ISBN:

1-555421-87-3. 14. Watts Humphrey. M a n a g in g for Innovation: Leading Technical People. New York: McGraw-Hill, 1987. ISBN: 0-135503-02-07. 15. Magid Igbaria, Jeffrey H. Greenhaus. Determinant of MIS Employees’ Turnover Intentions. Communications of the ACM , February 1992. 16. J.R. Katzenbach, O.K. Smith. The Wisdom of Teams. Boston, MA: Harvard University Press, 1993. ISBN: 0-8754843067-0.

17. Guy Kawasaki. The Macintosh Way: The Art of Guerrilla Management. Glenview, IL: Scott Foresman and Company, 1989. ISBN 0-06-097338-2. 18. J.R Klubnik. Rewarding and Recognizing Employees. Chicago, IL: Irwin Publishers, 1995. 19. Otto Kroeger and Janet M. Thuesen. Type Talk: The 16 Personalities That Determine How We Live, Love, and Work. New York: Bantam Doubleday, 1988.

ISBN: 0-440-50704-9. 20. Susan A. Mohrman, Susan G. Cohen, Allan M. Mohrman, Jr. Designing Team-Based Organizations. San Francisco, CA: Jossey-Bass, 1995. 21. Peter Senge. The Fifth Discipline: The Art and Practice of the Learning Organization. New York: Doubleday, 1990. ISBN: 0-385260-94-6. 22. S.B. Sheppard, B. Curtis, P. Milliman, T. Love. Modern Coding Practices and Programmer Performance. IEEE Computer, December 1979. 23. Paul Strassmann. Internet: A Way for Outsourcing Infomercenaries? American Programmer, August 1995. 24. Auren Uris. 88 Mistakes Interviewers Make and How to Avoid Them. New York: American Management Association, 1988. 25. Rob Thomsett. Radical Project Management. Englewood Cliffs, NJ: Prentice Hall/Yourdon Press, 2002. ISBN: 0-13-009486-2. 26. J.D. Valett, F.E. McGarry. A Summary of Software Measurement Experiences in the Software Engineering Laboratory. Journal of Systems and Software, Vol. 9, No. 2, 1989, pp. 137-148. 27. Susan Webber. Performance Management: A New Approach to Software Engineering Management. American Programmer, July-August 1990. 28. Gerald Weinberg. The Psychology of Computer Programming. New York: Van Nostrand Reinhold, 1971. ISBN: 0-442-29264-3.

29. Gerald M. Weinberg. Understanding the Profes­ sional Programmer. New York: Dorset House, 1988. ISBN : 0-932633-09-9. 30. Mike West. Empowerment: Five Meditations on the Soul of Software Development. American Programmer, July-August 1990. 31. Ken Whitaker. M a n a g in g Software Maniacs. New York: John Wiley & Sons, 1994. ISBN: 0-471-00997-0.

ГЛАВА 5

ПРОЦЕССЫ В БЕЗНАДЕЖНЫХ ПРОЕКТАХ

Если вы запомните хотя бы что-то из данной главы (или из книги), то это должно быть слово приори­ тетность (triage). Исходя из названия главы, вы можете подумать, что речь в основном пойдет о таких знакомых методологиях, как структурный анализ, или о формальных дисциплинах наподобие SEI Capability Maturity Model (СММ), или различных подходах к разработке ПО под общим названием RAD (Rapid Application Development) и ХР (extreme Program­ ming). Это важные и нужные вещи, но самое главное заключается в том, что в безнадежном проекте вам не хватит времени на то, чтобы удовлетво­ рить все потребности пользователя. Если вы бу­

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

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

5.1 Концепция “ triage” Слово “triage” происходит от старого французского “ trier”, что означает “сортировать, классифицировать”. American Heritage Dictionary (3-е издание) определяет его следующим образом: triage — существительное 1. Процесс распределения раненых по группам в за­ висимости от их потребности в оказании немедленной медицинской помощи. Применяется на поле боя, в мес­ тах катастроф и госпиталях в условиях ограниченных медицинских ресурсов. 2. Система, используемая при распределении дефи­ цитных товаров (например, продовольствия) среди тех, кто способен получить от этого наибольшую выгоду. Многие из нас знакомы с медицинской трактовкой этого термина, однако для безнадежных проектов под­ ходит второе определение: распределение дефицит­ ных ресурсов (самым дефицитным из которых обычно является время) таким образом, чтобы извлечь из этого наибольшую выгоду. Или, как отметил Стивен Кови в [ 1], “ главное — это быть уверенным в том, что главное — это главное” .

Большинство подходов, связанных с прототипирова­ нием и RAD/ХР, вполне сочетаются сданной концепци­ ей, а другие на нее ссылаются. Однако многие подходы RAD делают акцент только на быстром получении неко­ торого — какого угодно! — результата (работающего приложения), который можно показать пользователю с целью (а) продемонстрировать, насколько ошутим до­ стигнутый прогресс, и (б) получить замечания, касаю­ щиеся функциональности системы и (преимущественно) пользовательского интерфейса. Все это весьма полезно. Однако, если проектная команда будет расходовать свои ресурсы на проектирование начальных прототипов с внешне привлекательными, но несущественными во­ зможностями, то как команда, так и пользователь будут зря терять время. Большинство методологий разработки ПО, незави­ симо от того, базируются они на классической “кас­ кадной” модели жизненного цикла или на современ­ ной “спиральной” модели и прототипировании, имеют незаметное на первый взгляд, но довольно коварное свойство. Оно выражается следующей фразой: “Не­ важно как, но ко времени завершения проекта мы сделаем все". Возможно, причина этого заключается в том, что в детстве родители запрещали нам выхо­ дить из-за обеденного стола, пока мы не оставим пус­ тые тарелки. В любом случае невысказанный девиз многих проектных команд — “мы не оставим невы­ полненным ни одного требования” . Разумеется, это честный девиз, но в безнадежных проектах он почти всегда невыполним. Как я уже отме­ чал в главе 1, в большинстве безнадежных проектов “официально утвержденные” требования превышают ресурсы проектной команды (в особенности, человече­ ские и временные ресурсы — на 50— 100%). В этой си­ туации неопытная команда надеется, что, работая сверх­ урочно вдвое больше, она сможет как-нибудь покрыть этот дефицит; а циничная команда “самоубийственного"

проекта предполагает, что их работа над проектом все равно затянется на 50— 100% по сравнению с первона­ чальным планом. Но даже если циничная команда оши­ бается в этом, она все равно предполагает, что рано или поздно она в конце концов реализует все функции, кото­ рые требовались пользователю. Один из ключевых моментов в безнадежных проектах состоит в том, что некоторые требования не просто ос­ танутся невыполненными до официального срока завер­ шения проекта, но и не будут выполнены никогда. Если предположить, что известное правило “80—20" справедливо, то проектная команда сможет добиться 80% “эффекта” от разработанной системы, реализовав 20% требований к ней — при условии правильного вы­ бора этих 20%. И, поскольку пользователю не терпится получить работающую систему задолго до того срока, который проектная команда считает разумным, он мо­ жет взять эти готовые 20% , приступить к их использо­ ванию и навсегда позабыть об оставшихся 80% функций системы. Это, конечно, упрощенный подход. Однако почти во всех безнадежных проектах, в которых я принимал уча­ стие, приходилось устанавливать приоритеты, разделяя все требования к системе на три категории: “необходимо выполнить", “следует выполнить" и “можно выпол­ нить". Смысл этих категорий очевиден, а тот факт, что их всего три, предупреждает любые бесполезные дис­ куссии на тему о приоритетах, например, какой приори­ тет присвоить конкретному требованию — шестой или седьмой. При такой расстановке приоритетов в проекте очевидная стратегия будет заключаться в следующем: в первую очередь сосредоточиться на требованиях, кото­ рые необходимо выполнить; затем, если останется вре­ мя, на тех, которые следует выполнить; и наконец, если произойдет чудо, заняться требованиями, которые мож­ но выполнить.

Если подобной стратегии не следовать с самого на­ чала работы над проектом , то к концу он окажется в кризисной ситуации. Чтобы понять, почему это происхо­ дит, рассмотрим типичное начало безнадежного проек­ та, когда никто (в особенности пользователи и высшее руководство) не желает осознать, что сроки для его вы­ полнения нереальны. У менеджера проекта и участников команды может возникнуть неприятное ощущение, что им предстоит выполнять “самоубийственную” миссию. Однако, если они — оптимисты, то могут поверить, что проект будет иметь характер “невыполнимой миссии”, и впоследствии какое-нибудь чудо придет им на помощь. В этот момент самым важным является то, что до окон­ чания работы еще далеко (шесть месяцев или год) и ни­ кто не хочет всерьез задумываться о невыполнимости поставленных задач. Политическое давление и неопытность проектной команды могут привести к тому, что даже в середине проекта он не будет подвергнут переоценке. Проблема может оказаться сложнее, если проектная команда ис­ пользует какую-либо разновидность RAD-подхода, по­ скольку они, вероятно, уже продемонстрировали поль­ зователю один или более прототипов системы и тем самым поддержали у него иллюзию, что все будет сдела­ но вовремя. Однако к этому моменту проектная команда скорее всего начнет понимать, что они пытаются прыг­ нуть выше головы, и если для менеджера этот безнадеж­ ный проект — первый, он будет наивно верить, что выс­ шее руководство и пользователи тоже в конце концов их поймут. Увы, но обычно понимания не происходит — склады­ вается кризисная ситуация. Теперь пользователи и/или высшее руководство вынуждены посмотреть в лицо ре­ альности: невзирая на их требования и искренние заве­ рения менеджера проекта, система не будет готова в срок. Обычно подобная ситуация возникает за месяц до

окончания проекта, иногда за неделю, а иногда и через день после официального окончания! Последствия могут быть различными: это зависит от степени напряженно­ сти политических баталий к этому моменту, а также от степени изнуренности и разочарованности менеджера проекта. Тем не менее происходит следующее: высшее руководство приходит к выводу, что во всем виноват ме­ неджер проекта, и в итоге несчастного увольняют (если только он сам уже не уволился!) и ставят нового с тре­ бованием “ликвидировать весь этот бардак и сдать сис­ тему вовремя". Новый менеджер может быть как закаленным ветераном из самой организации, так и сторонним консультантом. Иногда случается, что он в самом деле обнаруживает ряд грубых ошибок, допущенных его предшественником (например, отсутствие планирова­ ния или рабочих графиков); иногда новый менеджер приходит к выводу, что его предшественник в основ­ ном делал все правильно, но не смог избежать участи козла отпущения, когда высшее руководство наконец убедилось, что их первоначальные требования невы­ полнимы. Однако новый менеджер должен быть готов к сле­ дующему: все проектные требования в полном объеме не удастся реализовать в соответствии с первоначально установленным сроком — если бы это было не так, то предыдущего менеджера вряд ли бы уволили. Что же предпринять новому менеджеру? Две наиболее очевид­ ные возможности заключаются в следующем: • пересмотреть срок окончания проекта; • пересмотреть требования к системе. Первая возможность вполне допустима, однако в безнадежном проекте практически нереальна. В самом деле, ведь основной причиной, побудившей пользовате­ лей настаивать на таких нереальных планах, является

неотложная потребность в системе, которая позволила бы им справиться со своими проблемами в бизнесе. По­ скольку новый менеджер начинает работать над проек­ том в тот момент, когда близок первоначально установ­ ленный срок завершения, высока вероятность того, что пользователи уже строят планы эксплуатации новой системы. Им не хотелось бы слышать, что проект про­ длится еще 6— 12 месяцев. Поэтому успешно применяемый метод заключается в определении приоритетов для первоначальных тре­ бований. Отметим, что новый менеджер разговарива­ ет с позиции силы — это не его вина, что проект ока­ зался в таком плачевном состоянии; при этом не высказывается вслух, но подразумевается, что руко­ водство и пользователи в первую очередь были на­ столько глупы, что позволили загнать себя в такой ту­ пик. Новый менеджер соглашается участвовать в работе над проектом в том случае, если переговоры пройдут успешно. Он заявляет примерно следующее: “Если вы хотите, чтобы я вытащил вас из этой ямы, то должны принять как факт, что мы сможем реали­ зовать в срок только небольшой процент первона­ чально заданных функций. Таково реальное положе­ ние вещей, согласны вы с ним или нет". Такое заявление будет прямым и честным, хотя и обескураживающим. Однако уместно задать вопрос: что же делать со всем тем, что было сделано до на­ ступления кризиса и прихода нового менеджера? Ведь команда, вероятно, уже успела много напрограммировать и оттестировать, и может быть, разработала не­ которую документацию и проектные модели. Что же делать со всей этой частично выполненной работой? Наиболее вероятный ответ: большую часть придется выбросить. Подобное утверждение может показаться чересчур пессимистичным. В самом деле, почему бы просто не отложить всю частично выполненную работу в сторо­

ну и вернуться к ней позднее? В лучшем из миров так оно и происходит; однако это возможно при наличии хороших средств и процессов управления версиями, конфигурацией, исходным кодом и т.д. — всего того, что отвергается в пылу сражения, когда все усилия команды сосредоточены на получении максимальных результатов. Реальная причина, по которой вся частично выпол­ ненная работа превращается в напрасный труд, за­ ключается в следующем: ни у кого не найдется вре­ мени, чтобы снова к ней вернуться. Предположим, что участники проектной команды (теперь уже под ру­ ководством нового менеджера, к которому они могут относиться с уважением или нет) способны реализо­ вать только самый минимум необходимых функций, причем работа над проектом обычно доводит их до та­ кого истощения, что половина из них уходит. Кроме того, проект уже так осточертел пользователям, что они не будут приставать с вопросами относительно функций, оставшихся нереализованными; или же, на­ оборот, они будут настолько довольны минимальным набором функций, что также никогда не потребуют довести систему до конца. Даже если они это сделают и проектная команда еще будет существовать в пер­ воначальном составе, высока вероятность, что в по­ пытках реализовать “скелет” системы в нее будет внесено так много архитектурных изменений, что на­ половину законченные ее компоненты (соответствую­ щие второстепенным функциям) никогда больше не будут использоваться. Заметьте, что мы в данном обсуждении еще ни разу не коснулись таких тем, как структурный анализ, SEI-CMM или любые другие “ книжные” методологии и процессы создания ПО. Все, что говорилось по по­ воду приоритетности, продиктовано исключительно здравым смыслом. А это для безнадежных проектов является критически важным. Чтобы концепция ра­

ботала, все акционеры и заинтересованные лица должны принять согласованное решение относительно того, какие требования следует отнести к категории "необходимо выполнить” , какие к “следует выпол­ нить” и какие к “ можно выполнить” . Разумеется, если владелец проекта категорически настаивает на том, чтобы все требования были обязательно выполнены, дальнейшее обсуждение будет пустой тратой времени. (Я бы порекомендовал менеджеру проекта и его команде использовать такое обсуждение в самом на­ чале проекта как лакмусовую бумажку. Если поль­ зователи, владелец проекта, высшее руководство, акционеры и заинтересованные лица не желают при­ нимать такой подход к расстановке приоритетов тре­ бований, то наиболее разумно будет выйти из проек­ та, пока не поздно. В качестве дополнительной лакмусовой бумажки следует предложить пользовате­ лям разделить все требования на три равные группы в соответствии с вышеуказанными категориями. Это может уберечь от того, чтобы 90% требований были объявлены критическими). Если акционеры и заинте­ ресованные лица не могут достичь консенсуса по по­ воду отнесения требований к той или иной категории, то проектная команда, пытаясь удовлетворить всех, в результате окажется парализованной из-за отсутствия необходимых ресурсов. К сожалению, “суровая реальность” такова, что в большинстве организаций нет дисциплины, опыта и политической силы, чтобы определить приоритет тре­ бований в самом начале проекта. Все, что я описал в предыдущих абзацах, вовсе не является чем-то заум­ ным, и даже самый технологически необразованный менеджер или пользователь в состоянии это понять. Данный подход одинаково хорошо подходит для любых проектов с ограниченными ресурсами и недостатком времени. Однако, даже если все хорошо понимают, о чем идет речь, политические баталии вокруг безна­

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

5.2 Важность управления требованиями В безнадежном проекте необходимо уделить особое внимание такому относительно новому аспекту жизнен­ ного цикла разработки ПО, как требования. Почему я употребил определение “ новому” ? В конце концов, каж­ дый проект содержит требования, и нельзя сказать, что­ бы разработчики были совсем уж незнакомы с этим по­ нятием. Традиционные методологии создания ПО (включая различные “структурные” и “объектно-ориентированные” методологии, разработкой которых некоторые мои коллеги и я занимались более 20 последних лет) сосре­ доточены на моделировании требований, осуществляе­ мых с помощью таких графических средств, как диа­ граммы потоков данных или диаграммы “сущностьсвязь” . В данной главе я говорю именно об управлении требованиями в той лихорадочной обстановке, которая присуща безнадежному проекту.

Эти два понятия — моделирование и управление — не являются противоречивыми или несовместимыми. Можно потратить время и силы как на одно, так и на другое. Если команда безнадежного проекта считает, что для лучшего понимания требований к системе полезно построить объектно-ориентированную модель, у меня нет никаких возражений. Я только хотел бы посовето­ вать проектной команде делать то, что она сама считает важным и полезным, а не то, что считают “правильным” блюстители чистоты методологии (здесь частично затра­ гиваются вопросы “наилучшей” практики, которые бу­ дут обсуждаться ниже). Мой опыт доказывает, что в большинстве безна­ дежных проектов не используются формальные мето­ ды моделирования, такие как SA /SD (Structured Analysis/ Structured Design) или OOA/OOD (Object Oriented Analysis/Object Oriented Design). Причины этого могут быть следующими: методологии кажутся проектной команде слишком громоздкими и бюрокра­ тическими; CASE-средства, поддерживающие эти ме­ тодологии, неудобны для использования; трудно пред­ ставить себе, каким образом можно преобразовать полученные в результате анализа модели в работаю­ щий код — единственное, что в конечном счете нуж­ но пользователю. В “ нормальном” проекте SA/OOAмодели сами по себе воспринимаются как весьма по­ лезные. Пользователи и специалисты, определяющие бизнес-политику организации, будут толпиться вокруг диаграмм потоков данных и тихо бормотать друг дру­ гу: “Так вот в чем заключается наш бизнес! Может быть, имеет смысл провести реинжиниринг бизнеспроцессов и изменить все это перед тем, как созда­ вать новую автоматизированную систему”. В самом деле, в экстремальной ситуации проектная команда даже не будет документировать ни одно из пользовательских требований. В свое оправдание (кото­ рое наверняка слышал каждый менеджер проекта!) они

говорят, что для документирования требуется слишком много времени, требования часто меняются и, кроме того, пользователи сами точно не знают, что им нужно. Таким образом, команда обычно полагается на методы и средства прототипирования, с помощью которых можно наглядно продемонстрировать всю важную проектную работу, а также выявить реальные требования к сис­ теме. С точки зрения “приоритетности” (см. раздел 5.1) все это порождает одну главную проблему: невозможность организованно управлять требованиями. Можно ли в любой момент времени сказать, какие требования “не­ обходимо выполнить” , какие “следует выполнить” и ка­ кие “можно выполнить” ? Интересно отметить, что и ме­ тодологии SA /SD и OOA/OOD не дают ответа на этот вопрос. Можно, конечно, определять приоритеты, рас­ крашивая кружочки на диаграммах потоков данных, но они изначально предназначены вовсе не для этого. Ме­ тодологии SA /SD и OOA/OOD нужны в первую очередь для понимания и объяснения требований, а не для управления ими в динамике. Именно динамическая составляющая управления требованиями обычно вызывает наибольшие трудно­ сти. Если бы вам в самом начале проекта удалось убедить всех акционеров и заинтересованных лиц со­ гласиться с приоритетностью требований и если бы эти приоритеты никогда не менялись в течение проек­ та ... ну что ж, если вы в самом деле в это верите, то вы верите в фей и колдунов. В реальных же безна­ дежных проектах обычно возникают в различных ва­ риантах следующие дилеммы: • Акционеры и заинтересованные лица не могут полностью согласиться с предложенными при­ оритетами. Разумеется, если они совсем не согласны, проект будет просто парализован. Однако часто можно столкнуться с такой ситуа­ цией, когда для 80% требований устанавлива-

ются приоритеты и начинается работа над про­ ектом, в то время как политиканы продолжают спорить относительно оставшихся 20%. В ре­ зультате дискуссий требования с высоким при­ оритетом иногда появляются в самый послед­ ний момент. Проектная команда оказывается в трудной ситуации, однако вряд ли возможно этого избежать. В процессе работы над проектом изменяется ситуация в команде. Например, в одно пре­ красное утро менеджер приходит в офис и об­ наруживает, что два его лучших программиста, Матильда и Эзекиель, решили создать реггибэнд и только что уехали в Нэшвил в поисках контракта для записи диска. Никто не предпо­ лагал, что такое может случиться, однако это произошло. Первые три вопроса, которые вы­ нужден выяснить менеджер, заключаются в следующем: “ Над какими обязательными тре­ бованиями работали эти мерзавцы, каков ста­ тус этих требований и кому я могу их перепору­ чить?” Изменяются обстоятельства вовне проектной команды. В зависимости от финансовых успехов компании увеличивается или уменьшается бюд­ жет. Срок окончания работы над проектом ото­ двигается или приближается в зависимости от того, насколько департамент маркетинга осве­ домлен относительно изменения конкурентной ситуации на рынке. Меняются решения прави­ тельства, технологии (не всегда в лучшую сто­ рону!), поставщики приходят и уходят и т.д. Ка­ ждое из подобных внешних событий может оказать некоторое воздействие на решения, принятые в отношении приоритетов требо­ ваний.

• Нередко наступает “момент истины”, когда пользователи, высшее руководство и участники проектной команды вынуждены признать, что система не будет готова в срок. Разумеется, если в начале работы над проектом была проде­ лана квалифицированная работа по определе­ нию приоритетов требований, такой кризис мо­ жет и не наступить. Но если команда вынуждена признать, что она не может выполнить в срок даже все необходимые требования? Как было отмечено выше, менеджеру проекта обычно “снимают голову” и заменяют на другого; при этом, если новому менеджеру удается отодви­ нуть конечный срок, то приоритеты могут быть оставлены без изменения. Однако в этот мо­ мент ранее принятые решения подвергаются серьезному пересмотру. Конечный срок выпол­ нения проекта уже не за горами, и пользователи могут волей-неволей согласиться с тем, что не­ которые требования, считавшиеся ранее абсо­ лютно необходимыми, вообще перестают быть таковыми. Этот перечень можно продолжить, но думаю, что вывод ясен: управление приоритетом требований яв­ ляется критически важной частью “процесса” безна­ дежных проектов. Конечно, если безнадежный проект содержит всего дюжину требований, то управлять ими будет совсем несложно; можно нацарапать их на бу­ мажной салфетке и просто пересматривать по мере необходимости. Однако большинство проектов вклю­ чает сотни требований, а многие — даже тысячи; проект самолета Боинг-777 (который вполне можно считать мешком программ с крыльями) включал, по слухам, 300 ООО требований. Но это еще не все, ведь требования обычно не являются независимыми; неко­ торые из них зависят от других требований, а некото­ рые порождают следующие требования.

Поэтому для описания зависимостей между требова­ ниями и управления большим числом таких зависимо­ стей необходимы методы, процессы и средства. В реше­ нии данной проблемы помогут такие известные методы, как структурный и объектно-ориентированный анализ. Однако до сих пор эти методы традиционно игнорирова­ ли атрибуты требований, такие как приоритет, стои­ мость, риск, план, владелец и разработчик, который за­ нимается его реализацией. В результате проектным командам, испытывающим потребность в управлении требованиями, приходилось использовать доморощен­ ные средства, базирующиеся на электронных таблицах, текстовых процессорах или наспех созданных приложе­ ниях, чтобы обеспечить хотя бы некоторую степень ав­ томатизированной поддержки. К счастью, в настоящее время появилось новое поколение средств, обеспечивающих комплексную и сложную поддержку управления требованиями. Вот не­ которые из доступных на сегодняшний день средств: Requisite Pro (IBM Rational Software), DOORS (Zycad Corp.), RTM (Marconi Systems). Поскольку данная гла­ ва посвящена в основном процессам, а не средствам, я не буду вдаваться в детали этих трех продуктов; но по­ скольку средства влияют на процессы, важно знать хотя бы об их существовании (ветераны-разработчики ПО вспомнят старую поговорку: “ Если единственным вашим инструментом является молоток, то все ваши проблемы выглядят как гвозди” ). Существует один аспект в комбинации процессов и средств, который следует особо отметить. Как было сказано выше, многие команды безнадежных проектов отказываются от использования формальных методо­ логий SA/SD или OOA/OOD, поскольку они выгля­ дят слишком громоздкими и бюрократическими. Что интересно, акционеры и заинтересованные лица рас­ суждают точно так же. Если предоставить им выбор, то они предпочли бы, чтобы их не заставляли изучать,

как читать диаграммы потоков данных; в самом деле, руководители и конечные пользователи высокого уровня иерархии жалуются, что они ничего не пони­ мают во всех этих “технических” диаграммах. У них также не хватает терпения продираться сквозь сотни страниц с диаграммами и мелкими деталями описаний элементов данных или спецификаций процессов. Ко­ нечно, если времени и терпения достаточно, то про­ ектная команда в состоянии преодолеть сопротивле­ ние и убедить конечных пользователей в том, что тщательно разработанные модели приносят большую пользу, — однако в безнадежных проектах вечно не хватает ни времени, ни терпения. Пользователи в состоянии понимать родной язык, например английский для большинства североамери­ канских проектов. И большинство из них предпочитают читать небольшой документ из 10— 20 страниц, сумми­ рующий все требования к системе. Требования в таком документе могут называться “характеристиками”, а сам документ в целом — “Требования к системе” (“Product Requirements Document” — PRD), или “спецификация высокого уровня” , или еще какой-нибудь подходящей фразой. Главное, что этот документ небольшой и на анг­ лийском языке. Он не должен содержать рекламной “шелухи” , а также непонятной терминологии или обо­ значений, заставляющих пользователей задумываться, что бы это значило. В идеальном случае каждый аб­ зац или отдельное предложение должны соответство­ вать конкретному требованию, чтобы и пользователи, и участники проектной команды могли использовать их в качестве отправной точки для своей дальнейшей работы. Во всем этом есть один интересный момент — мы имеем знакомое всем средство для создания таких доку­ ментов; оно называется “текстовый процессор”. В са­ мом деле, начальная версия такого документа обычно исходит от пользователей — например в виде записки

от вице-президента по маркетингу к исполнительному директору по поводу возникшей потребности в новом замечательном продукте со свойствами X, Y и Z, кото­ рый мог бы соперничать с продуктом конкурента, — даже когда департамент информационных технологий еще ничего об этом не знает. На этой ранней стадии пользователи рассматривают текстовый процессор как свое средство, а записку службы маркетинга — как свой документ; в результате они проявляют большую готовность участвовать в последующих дискуссиях по поводу приоритетности требований, если при этом про­ должают использоваться аналогичные средства и доку­ менты. Таким образом, мы наблюдаем тенденцию, ведущую к основанному на документе управлению тре­ бованиями,' когда средства, используемые специали­ стами по IT (например, Requisite Pro, DOORS или RTM), тесно интегрируются с текстовыми процессора­ ми идокументами, в которых пользователи хорошо раз­ бираются (я должен честно признаться, что это в какой-то степени рекламный трюк, поскольку такая ин­ теграция является одним из основных свойств Requisite Pro и я был одним из членов правления компании Requisite, когда писал эту книгу. Но поскольку я играю роль объективного автора, я искренне рекомендую вам познакомиться со всеми тремя перечисленными здесь продуктами). Еще одно соображение: очень важно, чтобы все ак­ ционеры и заинтересованные лица участвовали в про­ цессе выработки начальных требований, их документи­ рования и определения приоритетов. Разумеется, это касается любых проектов, однако нехватка времени и политические баталии, присущие безнадежным проек­ там, нередко соблазняют менеджера проекта рассуждать следующим образом: “Ладно, мы будем двигаться даль­ ше и обойдемся без этого идиота Мелвина из департа­ мента маркетинга; все, на что он способен, — это не соглашаться никогда и ни с чем” . При этом может воз­

никнуть следующая проблема: Мелвин, получив серьез­ ную “ политическую” пощечину и чувствуя, что его игно­ рируют (и что менеджер проекта считает его идиотом!), скорее всего найдет способ саботировать проект. Теоретически каждый понимает и соглашается с та­ кой точкой зрения, однако на практике просто удиви­ тельно наблюдать, как безнадежные проекты потихонь­ ку обрастают все новыми и новыми требованиями. Дополнительные требования, модификации существую­ щих требований и недвусмысленные предложения игно­ рировать некоторые требования — все это сваливается на проектную команду в виде телефонных звонков, по­ сланий по электронной почте и разговоров с глазу на глаз с менеджером проекта. Многие из этих предложе­ ний предваряются такими успокаивающими фразами, как “извини, что я забыл об этом сказать на нашем по­ следнем совещании, но... ” или “я рассчитывал, что у на­ шей группы управления будет время справиться с этой проблемой, но...” . Существует ли у менеджера проекта такая фор­ мальная группа управления, т.е. группа, состоящая из акционеров и заинтересованных лиц, которая оцени­ вает полученные в проекте результаты и принимает определенные решения относительно приоритетности требований, в данном случае не имеет значения. Это зависит от того стиля управления и организации про­ ектов, который сложился в каждой организации. Но что действительно имеет значение для успешного за­ вершения безнадежного проекта — это тщательное документирование каждой модификации, вносимой в исходные требования, и извещение о ней всех акцио­ неров и заинтересованных лиц. Если вице-президент по финансам хочет потихоньку вставить в проект еще одно приоритетное требование, это замечательно; од­ нако при этом менеджер проекта должен позаботить­ ся, чтобы об этом узнали вице-президент по марке­ тингу и исполнительный директор.

5.3 SEI, ISO-9000. Формальные процессы против неформальных Некоторые менеджеры, прочтя предыдущий раздел данной главы, могут выказать недовольство: “Вот здо­ рово! Это выглядит более формальным, чем все, что мы когда-либо делали!” Я заходил в тупик, когда сталкивался с такой реакцией в некоторых консалтин­ говых проектах. С одной стороны, я уверен, что доку­ ментирование, определение приоритетов и управление требованиями просто необходимы (независимо от того, какие средства и методы для этого используют­ ся); с другой стороны, я опасаюсь следующего: когда проектной команде, и без того заваленной работой, навязывается совершенно новый и незнакомый про­ цесс, то этот процесс — например управление требо­ ваниями — может оказаться последней каплей, пере­ полнившей чашу терпения. В подобной ситуации остается лишь надеяться на то, что проектная команда все же сможет понять одну но­ вую идею среди прочих своих средств и процессов. Вы­ зывают беспокойство те команды, которые предприни­ мают свой первый безнадежный проект с решением (или, что более вероятно, с указанием, навязанным им блюстителями методологии), обязывающим их исполь­ зовать формальные процессы, например те, которые регламентируются SEI-CMM или ISO-9000. Формаль­ ные процессы — это великая вещь, если вы хорошо знаете, что делаете, и если вы уже использовали их пре­ жде. Однако реальность такова, что подобные формаль­ ные процессы ранее вообще не использовались в орга­ низации, и безнадежный проект представляет собой пилотный проект для апробации структурного анализа или ISO-9000. Какое безумие! Это действительно последняя кап­ ля, которая переполнит чашу терпения. В конце кон­ цов, работая над безнадежным проектом, вы пытае­

тесь выполнить то, что раньше никогда не делалось. И несмотря на мои предостережения (см. главу 4), команда нередко состоит из людей, которые никогда не работали вместе. Мало того, они еще вынуждены осваивать использование незнакомой методологии или процесса, не будучи уверенными в том, что это им не­ обходимо в первую очередь, а напротив, убежденные в том, что это только затормозит их работу. Чему же тогда удивляются блюстители методологии, когда они в подобных обстоятельствах сталкиваются с сопро­ тивлением? Консультант Даг Скотт недавно привел мне пример такой ситуации: В одном проекте, насколько мне известно, потребовался диаграммер для ERD, и они при­ обрели Excelerator. Обнаружив, что он поддер­ живает методологию SSA D M , они внедрили ее без какого-либо обучения персонала. После этого обнаружилось, что темп работы над проектом значительно снизился (фактически, работа просто остановилась), в то время ка­ ждый был занят чтением руководств, освое­ нием средств и решением проблемы, что де­ лать дальше (или переделывать то, что было сделано в "неправильном” порядке). Почти иде­ альный сценарий для тех, кто наблюдает за безнадежными проектами.

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

жет напрасно потерять время проектная команда (во многих случаях эти деятели не совершают ничего по­ лезного, они суетятся вокруг департамента информа­ ционных технологий и надоедают и без того уставшей проектной команде). Значит, менеджер безнадежного проекта должен безоговорочно настаивать на выполнении тех процес­ сов, которые он считает принципиально важными, — например: “Каждый, кто посмеет внести изменения в исходный код, минуя процесс управления изменения­ ми, будет немедленно уволен!” Или проектная коман­ да должна сама сознательно пойти на внедрение про­ цесса, понимая, что это позволит сократить затраты. Такое может быть скорее в том случае, если участни­ ки команды ранее уже работали вместе и приобрели общий опыт использования различных процессов со­ здания ПО; и наоборот, это маловероятно, если толь­ ко один из участников команды встанет и скажет: “Я глубоко уверен, что структурный анализ является критически важным для успеха нашего проекта” , в то время как другие и понятия не имеют, о чем он го­ ворит. Еще одно утверждение, следующее из этого правила: попытка внедрить в безнадежном проекте новый, незнакомый процесс может закончиться ката­ строфически, даже если команда верит, что он может помочь в работе. Проблемы с освоением, неизбежная путаница и споры по поводу деталей процесса обычно сводят на нет все выгоды. Это означает, что формальные подходы (типа SEIСММ, ISO-9000 или внедрение новых методологий анализа/проектирования) должны иметь место где-ни­ будь за пределами безнадежного проекта. Внедрение таких процессов имеет смысл как часть долговремен­ ной корпоративной стратегии. Оно должно начинаться с выполнения пилотного проекта (но не безнадежно­ го), сопровождаясь организацией необходимого обу­ чения.

Если все это уже сделано и другие разработки ПО в организации уже выполняются на третьем уровне SEIСММ, то интересно выяснить, следует ли использовать подобные процессы в безнадежном проекте. Как однаж­ ды заметил Уоттс Хамфри на конференции в докладе по поводу SEI-CMM: “ Если процесс нельзя использовать в критических условиях, его вообще не следует использо­ вать” . Я не уверен, что многие согласятся с этим утвержде­ нием, особенно, если безнадежный проект рассматри­ вать как единственное в жизни исключение из правил. Если это так, то, возможно, имеет смысл отказаться от формальных процессов и разрешить проектной команде использовать любые методы, которые она сочтет прием­ лемыми. Однако не забывайте утверждение, высказан­ ное в главе 1: безнадежные проекты становятся нормой, а не исключением. Тогда официально принятые в орга­ низации процессы следует усовершенствовать, чтобы сделать их пригодными для использования в безнадеж­ ном проекте. Только при этом утверждение Хамфри бу­ дет иметь смысл. Если вы в самом деле столкнулись с потребностью усовершенствовать сложившуюся практику работы команды безнадежного проекта, я рекомендую обра­ титься к методологии PSP (Personal Software Process). Ее автор — Уоттс Хамфри. Основные положения мето­ дологии изложены в моей книге “Rise and Resurrection of the American Programmer". Можно также прочесть книгу [2], хотя предупреждаю: в ней 789 страниц.

5.4 “Достаточно хорошее” программное обеспечение Определение приоритетов требований может быть одним из способов, помогающих безнадежному проекту двигаться в “разумном” направлении. Для достижения успеха не обязательно реализовывать все требования.

Будет “достаточно хорошо” , если мы сможем реализо­ вать требования, которые “ необходимо выполнить” , и приемлемое количество тех, которые “следует выпол­ нить". Существует еще один аспект в разработке ПО. Он порождает трудности в безнадежных проектах: неявно подразумеваемое требование достижения идеального качества. Обычно оно выражается в терминах количест­ ва дефектов (ошибок), переносимости, независимости от платформы, гибкости, потенциала и других. Даже в “нормальных” проектах достаточно трудно удовлетво­ рить всем этим требованиям, а в безнадежных — сде­ лать это просто невозможно. Вместо этого проектная команда должна прийти к решению ( и по возможности согласовать его с акционерами и заинтересованными лицами) относительно того, какое качество является достаточно хорошим.

Важность такого решения объясняется тем, что достижение абсолютного качества съедает все ресур­ сы проекта — особенно время. Если вы хотите разра­ ботать сертифицированную, не содержащую ошибок программу и математически доказать ее корректность, на это потребуется время. Для этого нужны более та­ лантливые и способные специалисты. А их недоста­ точно в проектной команде. Кроме того, одному или более участникам команды придется расходовать до­ полнительную энергию, следовательно, они не смогут работать над другими задачами. Короче говоря, вы­ полнение таких требований, как надежность, перено­ симость и сопровождаемость, невозможно без ком­ промиссов, и это необходимо учитывать в процессе определения приоритетов требований. Командам безнадежных проектов приходится стал­ киваться лицом к лицу с такой неприятной реально­ стью. Ведь альтернатива — “совершенное” ПО, ко­ торое не будет готово даже тогда, когда пройдут все мыслимые сроки. Лучше всего, когда команда с само­

го начала работы над проектом настроена на создание достаточно хорошего ПО. Однако по опыту я знаю, что многие обычные разработчики ПО соглашаются с понятием достаточно хорошего ПО только тогда, ко­ гда заходят в тупик — например оказавшись в кри­ зисном положении за месяц или два до окончания проекта. До самого последнего момента они выражают свое недовольство: “Как вам понравится, если мы будем ис­ пользовать ваш “достаточно хороший" подход примени­ тельно к ПО ядерного реактора или системы управления воздушным движением?” Разумеется, я отвечу, что мне совсем не нравится; и, если кто-нибудь вздумает затеять безнадежный проект для создания такого рода высоко­ надежных приложений, тогда я просто перестану летать на самолетах и буду держаться как можно дальше от вдерных реакторов. С другой стороны, нам обычно и не приходится сталкиваться с безнадежными проектами та­ кого рода; скорее, это может быть кадровая система на ядерном предприятии или система резервирования авиа­ билетов. Это, конечно, не означает, что кадровые систе­ мы и системы резервирования авиабилетов должны ра­ ботать со сбоями, но все же их последствия будут не столь серьезны. В любом случае совершенная надежность, сопрово­ ждаемость, переносимость и т.д. не являются необходи­ мыми, практичными или желательными в большинстве безнадежных проектов. Достичь такого совершенства невозможно даже в “нормальных" проектах, хотя в них мы не связаны такими жесткими ограничениями на вре­ мя, бюджет и людские ресурсы. Что же касается безна­ дежных проектов, то пользователям в действительности нужна система, которая достаточно дешева, достаточно производительна, обладает необходимыми возможно­ стями, достаточно устойчива и будет готова достаточно скоро — вот в чем заключается их определение “доста­ точно хорошего” ПО.

Почему же нам не удается создать “достаточно хоро­ шее" ПО? Это обычно объясняется совокупностью сле­ дующих причин: • Мы стремимся определять качество только в терминах дефектов, не задумываясь о других его аспектах, которые, с точки зрения пользовате­ ля, включают, например готовность к опреде­ ленной дате. • Мы предполагаем, что малое количество дефек­ тов равносильно лучшему качеству, и полагаем, что пользователь всегда предпочитает такое ка­ чество. Хотя существуют обстоятельства, когда пользователь готов пойти на компромисс и при­ мириться с некоторыми ошибками в обмен на более скорое завершение работы или возмож­ ность продукта работать на различных про­ граммных/технических платформах и др. • Мы стремимся определить требования к качест­ ву (дефектам) один раз, в самом начале работы над проектом, и зафиксировать их, хотя обстоя­ тельства могут измениться не однажды. • Мы твердим, что процессы являются критиче­ ски важными, но при этом зачастую забываем об их “нейтральности” — дурак, вооруженный процессами и средствами, все равно останется дураком. Невозможно обеспечить качество, если просто слепо следовать всем деталям ме­ тодологии структурного анализа или рекоменда­ ций SEI-CMM. • Мы рассматриваем обеспечение качества как процесс, укладывающийся в жесткую схему, за­ данную в начале проекта раз и навсегда (или, что еще хуже, для всех проектов во всей ком­ пании).

• Мы недооцениваем нелинейный характер зави­ симостей между такими ключевыми параметра­ ми проекта, как численность персонала, плано­ вые сроки, бюджет и количество дефектов — все эти аспекты в безнадежных проектах явля­ ются ключевыми. • Мы игнорируем динамику процессов: запазды­ вания, циклы обратной связи и т.д. Например, большое количество сверхурочной работы в те­ чение данной недели повысят продуктивность работы над проектом в целом. Но уже на сле­ дующей неделе оно может стать причиной боль­ шего количества ошибок (о них конечные поль­ зователи и высшее руководство могут не узнать), которые снизят продуктивность работы (в терминах конечных результатов) и, может быть, даже отбросят проект назад. • Мы игнорируем такие факторы, как моральное состояние команды, адекватные условия для ра­ боты и др. Каким же образом мы сможем создать “достаточно хорошее” ПО? Как отмечает Джеймс Бах [3], для этого требуется несколько вещей: • Утилитарная стратегия — искусство ко­ личественного анализа и максимизации чисто­ го выигрыша в неопределенных ситуациях — обобщает идеи системного анализа, управле­ ния рисками, экономики, теории принятия ре­ шений, теории игр, теории управления и нечет­ кой логики. • Эволюционная стратегия — рассматривае­ мая не только по отношению к жизненному цик­ лу проекта, но также к людям, процессам и ре­ сурсам.

• Героические команды — не Могучие Гениаль­ ные Программисты, а обычные умелые специа­ листы, способные к эффективному сотрудниче­ ству.

• Динамическая инфраст рукт ура — противо­ положность бюрократии и засилию политики. Высшее руководство уделяет необходимое вни­ мание проектам, положению на рынке, преду­ преждает и разрешает конфликты между проек­ тами и становится на сторону проекта в случае конфликта между ним и бюрократами.

• Динамические процессы — процессы, поддер­ живающие работу в эволюционирующей среде. Динамический процесс, в свою очередь, являет­ ся частью идентифицируемого мета-процесса и всегда может подвергаться изменениям. Один из читателей чернового варианта данного изда­ ния книги (Майкл Черч) нашел удачное название для момента в конце проекта, когда появляется “достаточно хорошее” ПО, — “эндшпиль” . Он привел пример одно­ го безнадежного проекта, который показал, что крите­ рии “достаточно хорошего” ПО во многом определяются пользователями. Именно поэтому сообщество пользова­ телей должно активно участвовать в переговорах и дис­ куссиях относительно конечных результатов проекта, чтобы сформулировать понятие “достаточно хорошего” . Это решение не только влияет на нормальное заверше­ ние проекта (когда поставщики смогут получить свои деньги, уставшие программисты получат отпуск, а выс­ шее руководство сможет объявить об успехе проекта), но и определяет продуктивность использования системы в последующие несколько лет.

5.5 Наилучшая практика и наихудшая практика Не один раз уже в этой книге я предупреждал об опасностях, связанных с вмешательством блюстите­ лей методологии и попытками насильно внедрить в практику проектной команды лишенные гибкости ме­ тодологии или процессы создания ПО. То же самое касается внешних консультантов, гуру, знахарей, це­ лителей, заклинателей змей и книг. Даже этой книги: если то, что я рекомендую, не находит должного по­ нимания и проектная команда не испытывает по этому поводу особого энтузиазма, то такую рекомендацию лучше проигнорировать! Однако это особенно справедливо по отношению к методологиям и процессам создания ПО. Вместо того чтобы следовать рекомендуемой кем-либо практике или навязываемой сверху руководством и комитетами по ме­ тодологии, которые обычно сами не знают то, о чем го­ ворят, — гораздо лучше следовать той, которую сама команда считает “ наилучшей” в данных обстоятельствах. В этом заключается существо подхода “ наилучшей прак­ тики” , который стал популярным в последние два года: основного подхода, принятого на вооружение организа­ циями-разработчиками ПО, признанного удачным на­ стоящими разработчиками. К сожалению, у команд безнадежных проектов прак­ тика такого рода часто отсутствует, поскольку их проект рассматривается как первый проект такого рода в орга­ низации. Если он даже не первый, то все равно рассмат­ ривается как исключение. Поэтому заранее никто не составил свода методов, хорошо и плохо зарекомендо­ вавших себя. Что еще хуже, большой процент безна­ дежных проектов заканчивается провалом (иначе они не назывались бы “смертельными маршами” !). Таким об­ разом, люди, которые могли бы помочь полезными сове­ тами в следующих безнадежных проектах, уже ушли,

были уволены, покончили жизнь самоубийством, зара­ ботали нервное расстройство или превратились в зако­ ренелых циников. Если вы в самом деле начинаете первый в организа­ ции безнадежный проект, попытайтесь документально фиксировать все реально работающие процессы, кото­ рые могли бы пригодиться в следующих безнадежных проектах. Один из способов сделать это — провести “ревизию" в самом конце проекта. Тем не менее, это де­ лается редко, и результаты обычно настолько неинте­ ресны, что никто не хочет с ними знакомиться. Причины этого очевидны: к концу работы над проектом команда находится в таком измочаленном и потрепанном состоя­ нии, что предложение документально описать их опыт будет скорее всего встречено градом насмешек; кроме того, многие из тех, кто внес наибольший вклад в рабо­ ту, к концу проекта уже исчезли. Таким образом, альтернативой может быть серия “мини-ревизий” в течение работы над проектом. Если ваша работа состоит из мини-этапов, таких как передача новой версии прототипа пользователю, запланируйте полдня на проведение мини-ревизии сразу после окон­ чания этапа. Решите, что в практике работы было хоро­ шим, а что оказалось негодным; что заслуживает особо­ го внимания на следующем этапе, а от чего следует отказаться. Заметьте, что такого рода “самокопание” полезно для всей проектной команды, и тот факт, что их опыт будет полезен для будущих команд безнадежных проектов, может подсластить пилюлю. Кроме того, подведение итогов в конце этапа обычно вдохновляет команду, их суждения становятся более оригинальными, искренними и не такими циничными. Для организаций, которым недоступен положитель­ ный опыт других команд, я бы порекомендовал несколь­ ко источников. Данная тема затронута в одной из глав моей книги Rise and Resurrection of the American Programmer, другие материалы, касающиеся наилучшей

практики, можно найти на сайте консультанта Кристины Комафорд www.christine.com. Возможно, наиболее ам­ бициозным проектом, находящимся в настоящее время в процессе разработки, является проект министерства обороны США, информацию о котором можно найти на сайте spmn.com. Ниже перечислены “наилучшие практики”, рекомен­ дуемые в этом проекте (не забывайте данный мною ра­ нее совет о том, что не нужно воспринимать эту инфор­ мацию буквально как “заповедь”, которой необходимо следовать; наоборот, она может служить полезной от­ правной точкой для ваших собственных идей относи­ тельно наилучшей практики):

• Формальное управление рисками — будем обсуждать его позже в данной главе.

• Согласованные интерфейсы — аппаратные интерфейсы, программные интерфейсы и ин­ терфейсы между вашей системой и другими внешними системами.

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

• Планирование и управление, основанное на метриках — речь идет о том, что в основу на­

ших планов и оценок должны быть положены данные, накопленные в предыдущих проектах. Однако, как было сказано выше, предыдущих

безнадежных проектов может просто не быть, а если даже они и были, маловероятно, чтобы кто-нибудь позаботился записать полезные дан­ ные (кроме подсчета потерь, понесенных коман­ дой). Все же, если имеются в распоряжении какие-либо данные, полученные в “ нормальных” проектах, их можно было бы использовать для выверки оценок, сделанных в безнадежном про­ екте — хотя бы для того, чтобы убедиться в их безумной оптимистичности! Двоичная оценка качества по результатам этапов — другими словами, вместо того чтобы

заниматься подведением итогов каждые три ме­ сяца, во время которых команда рапортует, что она написала 97% кода, следует подводить про­ межуточные итоги еженедельно или даже еже­ дневно, фиксируя достигнутые результаты с по­ мощью двоичных признаков. Одним из способов выполнения этого является стратегия “еже­ дневного завершения проекта” , которая обсуж­ дается в следующем разделе. Свободный доступ к информации о проект ­ ных планах и фактических результатах —

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

идей данного проекта заключается в том, что де­ фекты идентифицируются, фиксируются и уст­ раняются на ранних стадиях процесса разработ­ ки. Это решение позволяет не только точно установить уровень дефектности в разработан­ ной системе, но и устранить дефекты на ранних

стадиях процесса разработки, не дожидаясь тес­ тирования системы.

• Управление конфигурацией — может назы­ ваться по-разному: управление версиями, управ­ ление исходными кодами, или как-нибудь еще. Оно всегда рассматривается как важная практи­ ческая составляющая проектов, протекающих в экстремальных условиях.

• Ответственность и подотчетность руко­ водства перед сотрудниками — увы, в боль­

шинстве безнадежных проектов этому моменту не уделяется достаточно внимания; как было от­ мечено выше, многие безнадежные проекты от­ носятся к типу “самоубийственных" или “ками­ кадзе” . Одно из наиболее значительных достижений данного проекта министерства обороны — это понятие наихуд­ шей практики. Особенно хорошо оно применимо к безнадежным проектам, где зачастую бывает важнее предотвращать катастрофы, а не заниматься поисками наилучшего решения проблем. Список таких практик приведен ниже:

• Не следует ожидать более чем 10%-ного сокращения сроков по сравнению со средне­ статистической нормой для аналогичных проектов — разумеется, если вы действитель­

но в это верите, то не следует даже и начинать безнадежный проект!

• Не пытайтесь использовать новую техно­ логию как средство для сокращения сро­ ков — у вас будет и без того достаточно про­

блем, кроме поиска ошибок в бета-версиях но­ вых средств и технологий, добытых у знакомого поставщика (см. главу 10).

Не навязывайте заказчику решения, специ­ фичные только для него — полезный совет

для любого проекта. Не следует заниматься поиском панацеи

—

об этом стоит вспомнить, когда ваше руко­ водство (сразу же после визита настойчиво­ го поставщика!) предлагает использовать для “спасения” проекта какое-нибудь “поражающее воображение” средство или методологию разра­ ботки. Не упускайт е возможност и удалить из критического пути те элементы, которые находятся вне сферы вашего управления , —

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

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

• Не следует ожидать, что в результате бо­ лее чем 1 0 % - н о г о отставания от плана удастся избежать более чем 1 0% -н ого сни­ жения функциональности разработанного П О — эта рекомендация является критически

важной для команды безнадежного проекта, по­ скольку вероятность отставания от плана более чем на 10% во время выполнения проекта до­ статочно высока. В самом деле, для безнадежно­ го проекта опасно даже 10%-ное запаздывание. Поскольку у команды, которая трудится сверх­ урочно, может не хватить сил, чтобы тратить каждый день на работу еще на 10% времени больше. Однако самым главным в этой реко­ мендации министерства обороны является сле­ дующее: менеджер проекта должен помнить, что зависимость между временем работы команды и функциональностью ПО не является линейной. В прошлом году, проводя много семинаров в раз­ ных концах света, я задал нескольким сотням менед­ жеров проектов два вопроса: “Если ваш коллега предпринимает свой первый безнадежный проект, ка­ кой единственный совет для достижения успеха вы могли бы ему дать? И что единственное вы бы посо­ ветовали ему не делать?" Я был весьма заинтригован, обнаружив, что никто даже не упомянул средства или технологии в качестве “одной самой важной вещи”; не были также упомянуты и формальные методы, та­ кие как структурный анализ или объектно-ориентиро­ ванное проектирование. Некоторые рекомендовали “ нанять хороших исполнителей” и “добиться, чтобы команда была действительно нацелена на успех”. Од­ нако почти все советы были направлены на проведе­ ние переговоров, контроль над выполненным объемом работ (которому хорошо способствует обсуждавшееся ранее определение приоритетов требований) и управ­ ление рисками (о котором речь пойдет ниже).

Последний подход, заимствованный из упоминавше­ гося проекта министерства обороны, может оказаться полезным для безнадежных проектов. Правда, он пред­ назначен для менеджеров, не работающих над проек­ том. Он называется “тест на алкоголь”: какие вопросы следует задать команде безнадежного проекта, чтобы быстро определить, не утратили ли они чувство реально­ сти до такой степени, что проект пора прекращать? Вопросы такого рода часто задаются консультантами, которых высшее руководство уполномочило проанали­ зировать состояние проекта. Я сам был в таком положе­ нии. И встречая безнадежный и испуганный взгляд ме­ неджера, я могу заключить, что проект находится в плачевном состоянии. Иногда безобидный вопрос типа “Знаете ли вы, кто является вашим заказчиком?” приводит всех в полное замешательство, и в гробовом молчании каж­ дый озадаченно смотрит на своего соседа, а потом все внимательно вглядываются в пол. Если вас интересу­ ют некоторые вопросы “теста на алкоголь” , ниже приведен их список: • Используете ли вы (и поддерживаете в актуаль­ ном состоянии) сетевой график работ? • Располагаете ли вы утвержденным планом и бюджетом? • Знаете ли вы, за разработку какого ПО несете ответственность? • Можете ли вы перечислить первые десять про­ ектных рисков? • Известен ли вам процент сжатия вашего плана по сравнению с нормальным? • Каков оценочный объем вашего ПО? Каким об­ разом он вычисляется?

• Известна ли вам та часть внешних интерфейсов, которая находится вне вашего управления? • Достаточными ли знаниями о предметной об­ ласти располагают ваши специалисты? • Располагаете ли вы достаточным количеством специалистов для решения поставленных задач в отведенное время? “Тест на алкоголь" проводится в том случае, когда кто-либо в организации (как правило, не менеджер про­ екта, а кто-либо из высшего руководства) почувствует, что работа над проектом идет не так, как надо. Для того чтобы выжить в политических схватках, менеджеру про­ екта и всей команде периодически следует задавать друг другу подобные вопросы. Менеджеру проекта все время следует быть начеку, чтобы заметить признаки, говоря­ щие о тревожном состоянии проекта, даже если в соот­ ветствии с официальным графиком PERT все выгладит как положено. Такими признаками могут быть:

• Уход ключевых участ ников команды — это может произойти по ряду причин, однако важно вовремя почувствовать, не утратили ли участни­ ки проекта веру в свою способность завершить проект. Если начнут уходить ключевые разра­ ботчики, другие могут последовать за ними.

• “Ф акт ор обратной

корреляции Дилберт а" — чем больше карикатур Дилберта появ­

ляется на дверях в офисе и на досках объявле­ ний, тем хуже идут дела в проекте.

• Чрезмерный юмор висельников — если про­ ектная команда начнет носить в офисе черные рубашки и проигрывать на аудиосистеме погре­ бальные мелодии, значит, что-то идет не так.

• Проект у дают ся новые имена, например ‘Проект Тит аник" — другая разновидность

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

• Зловещее молчание конечных пользователей и высшего руководства, которые обычно каждый день интересовались ходом проек­ та — к тому моменту, когда вы это осознаете,

может оказаться слишком поздно, чтобы навер­ стать упущенное, однако у вас может быть по крайней мере несколько дней, чтобы обновить свое резюме.

• Бестолковая суета — бурная деятельность при отсутствии видимых результатов. Выходом из такой ситуации может быть использование идеи “мини-этапов” и стратегии “ежедневной сборки проекта” .

5.6 Безнадежные проекты и экстремальное программирование Одна из наиболее интересных и популярных идей в области процессов разработки ПО, появившихся в кон­ це 1990-х и начале 2000-х — это экстремальное про­ граммирование (ХР). Если проектная команда использу­ ет ХР, то их проект вовсе не обязан обладать всеми характеристиками безнадежного проекта. Кроме того, ХР и методы, обсуждавшиеся в этой книге, не перекры­ вают полностью друг друга. С другой стороны, я думаю, что в них есть много общего — в конце концов, само слово “экстремальное” предполагает амбициозность проекта, превышающую возможности обычных людей, работающих в обычном режиме.

Через большинство книг, статей, учебных курсов и презентаций ХР красной нитью проходит тема сотруд­ ничества между разработчиками и всеми заинтересо­ ванными лицами, которые помогают сформулировать требования к системе, работают с прототипами и прини­ мают решения относительно их доведения до работоспо­ собного состояния и сдачи в эксплуатацию. Такое поло­ жение вещей вполне можно ожидать от проекта типа «невыполнимая миссия», изображенного в верхнем правом квадранте рис. 2.1. К сожалению, большинство безнадежных проектов относится к трем остальным категориям — “камикад­ зе” , “самоубийство” или “отвращение”. Такие проекты зачастую представляют собой поле боя между агрессив­ но настроенными поставщиками (в лице системных ин­ теграторов, софтверных компаний, консалтинговых фирм и т.д.) и обороняющимися клиентами, которые не совсем представляют, что с ними будут делать: петь се­ ренады, покорять или грабить. В таких условиях врадли удастся реализовать большинство из принципов ХР (особенно, если у организации нет опыта использования такого подхода). Тем не менее, я думаю, что менеджер безнадежного проекта вполне может использовать некоторые основные принципы ХР в той степени, в какой это имеет смысл в его проекте. К ним можно отнести следующие: • Планируйте выпуск версий или релизов через короткие, двухнедельные интервалы времени. + Функциональность каждой новой версии/релиза подлежит согласованию с пользователя­ ми. + Если необходимо, функциональность может быть формально документирована, например, зафиксировано использование объектно-ори­ ентированных методов (UML). Однако при сжатых сроках и большом объеме работ, ко-

торый надо выполнить за две недели, такое документирование будет иметь самый низкий приоритет. + В каждом новом релизе команда разработчи­ ков обязана реализовать такое же количест­ во функций, как и в предыдущем. Конечно, разработчики могут стремиться делать все больше и больше в каждом релизе, но такое сверхусердие может рано или поздно привес­ ти к катастрофе. Если проект будет продолжаться более полугода, его график должен рассчитываться, исходя из 40-часовой рабочей недели. Здесь играют роль не только соображения гуманности, но и просто здравого смысла: спринт годится для стометровки, а если ваш проект — марафон, то надо правильно распределить свои усилия, что­ бы не сгореть в начале дистанции. Не пытайтесь предвосхищать будущие потреб­ ности пользователей, занимайтесь тем, что не­ обходимо сегодня. + Это утверждение существенно изменяет ста­ рую парадигму, согласно которой ошибки в требованиях считались недопустимыми, вследствие чего тратилось много времени и усилий на детальную спецификацию требова­ ний. ♦ ХР делает акцент на новую парадигму, счи­ тающую невозможным полное и корректное описание требований в начале проекта. Нуж­ но затратить ровно столько усилий, чтобы обеспечить “достаточно хорошее” понимание требований. Эта парадигма хорошо работает именно сегодня, когда в распоряжении разра­ ботчиков имеются гораздо более мощные

средства разработки, чем 10—20 лет назад, позволяющие быстрее и проще вносить изме­ нения в систему. Время, усилия и ресурсы, которые раньше рас­ ходовались на детальную спецификацию требо­ ваний, теперь можно потратить на постоянную реорганизации объектов, модулей и других ком­ понентов создаваемой системы. Такой подход лучше всего работает в объектно-ориентиро­ ванной среде разработки, оснащенной необхо­ димыми инструментальными средствами. Важной частью ХР является “парное програм­ мирование” — совместная работа двух разра­ ботчиков над каждой частью системы. Такой подход не только дает возможность подстрахо­ ваться на случай выхода из строя одного из раз­ работчиков в середине проекта, но также обес­ печивает более быстрое и качественное написание кода. Коллективное владение кодом означает, что лю­ бой участник проектной команды может изме­ нить код, написанный другим участником. Это допустимо только при наличии у разработчиков таких средств управления конфигурацией, как PVCS или Microsoft SourceSafe. Средства, по­ добные им, распространены сегодня достаточно широко (для тех, у кого бюджет ограничен, име­ ются и свободно распространяемые продукты). Это позволяет избежать таких ситуаций, когда из-за серьезной ошибки, обнаруженной в коде одного из разработчиков, вся команда должна прекратить работу и ждать, пока он ее испра­ вит. С другой стороны, такой подход может при­ вести к политическим баталиям, если проектная команда с ним не знакома или не уверена в его преимуществах.

• Программисты пишут тесты до написания кода, исходя из следующего постулата: если вы не знаете, как будете проверять код на коррект­ ность, то не следует его и писать. И здесь раз­ ные политические течения могут сыграть свою роль, если такой подход ранее не использовал­ ся. Логическим следствием использования та­ кого подхода является накопление и ведение библиотеки тестов для последующего регресси­ онного тестирования.

5.7 Заключение Довольно легко оставить за бортом многие из тех идей, которые обсуждались в этой главе, и впоследствии оказаться в плену пустопорожней бюрократии. Однако, как отмечает Стивен Несбит (я получил его сообщение как раз тогда, когда добрался до конца этой главы и не знал толком, как ее закончить): Отсутствие стандартов и методологии само по себе может превратить проект в без­ надежный. Например, в моем последнем проек­ те сжатый и нереальный план был применен для того, чтобы отказаться от таких дейст­ вий, как: 1) Использование системы управления кон­ фигурацией для контроля проектного исходно­ го кода, сосредоточенного в трех различных компьютерных системах, расположенных в двух территориально удаленных местах. В ре­ зультате значительное время было потеряно впустую при попытках: а) осуществить сборку программного обес­ печения; б) определить, кому какая версия П О при­ надлежит;

в)

определить, почему П О работает на од­

ной системе и не работает на другой. 2) Регистрация узких мест и дефектов с помощью системы управления конфигурацией. В результате стало совершенно невозможно оперативно выяснить, какие ошибки устраня­ ются, а какие проигнорированы; какие компо­ ненты закончены и могут тестироваться. 3) Документальная фиксация основных тре­ бований, проектных решений и вариантов, уз­ ловых точек в процессе разработки и исполь­ зуемых тестов. В результате участникам проектной команды оказалось чрезвычайно трудно добиться взаимопонимания не только относительно текущего состояния проекта, но также и основных решений, принятых в са­ мом начале проекта.

Итак, не надо воспринимать эту главу как предлог для отказа от каких-либо процессов, методологий или методов вообще; это может погубить безнадежный про­ ект. Фокус заключается в том, чтобы отыскать те про­ цессы, методологии или методы, которые действительно работают и которым команда будет следовать естествен­ ным образом и бессознательно. Последнее особенно важно: команда испытывает такой стресс и давление, что должна многое делать чисто инстинктивно. Посту­ пайте проще — запомните только одно — приоритет­ ность.

Библиография 1. Stephen R. Covey. First Things First. Fireside Books. 1996. 2. Alan M. Davis. Software Requirements: Objects, Functions, and States. Englewood Cliffs, N J- Prentice Hall, 1993.

3. Mark С. Paul, Charles V. Weber, Bill Curtis, Mary Beth Chrissis, et al. The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, MA: Addison-Wesley, 1995. 4. Watts Humphrey. A Discipline of Software Engineering. Reading, MA: Addison-Wesley, 1995. 5. James Bach. The Challenge of ‘Good Enough’ Software. American Programmer, October 1995. 6. Jim McCarthy. Dynamics of Software Develop­ ment. Redmond, WA: Microsoft Press, 1995. 7. G. Pascal Zachary. Show-Stopperl New York: Free Press, 1994.

ГЛАВА 6

ДИНАМИКА ПРОЦЕССОВ

Во многих безнадежных проектах наиболее серьез­ ные проблемы носят не столько технический характер, сколько политический, социальный, культурный и чело­ веческий. И хотя существует ряд хороших подходов, ориентированных на учет человеческого фактора (набор лучших специалистов, их мотивация и организация про­ дуктивных коллективов), проблема в том, что все это должно работать в рамках некой реальной организа­ ции, которая может оказаться настолько сложной, что непонятно, как она вообще работает. На самом деле, за­ частую она и не работает, при этом деятельность про­ ектной команды оказывается парализованной из-за непонятных и неожиданных решений и политики руко­ водства. Это происходит, несмотря на героические усилия, предпринимаемые многими 1Т-организациями для упо­ рядочения и усовершенствования своих процессов, ис­ пользуя RAD, ХР, SEI-CM M и т.д. Многие из этих уси­ лий затрачиваются впустую, поскольку не понимается динамика процессов (особенно временные задержки и циклы обратной связи) и игнорируются неформальные процессы, играющие главную роль в софтверных проек­ тах. По этой причине в последние несколько лет моде­ лирование и имитация динамики таких процессов вызы­ вают особый интерес. Имитация будет обсуждаться в главе 1 1, а в этой главе мы рассмотрим некоторые фун­ даментальные принципы, которые могут помочь менед­

жеру безнадежного проекта принимать более обосно­ ванные решения. Динамика систем — это не новое понятие, ему уже несколько десятков лет. В США одни из первых работ в этой области выполнил в начале 1960-х годов в Масса­ чусетском технологическом институте Джей Форрестер [2]. С тех пор многое изменилось: теперь у нас есть пер­ сональные компьютеры, позволяющие работать с ими­ тационной моделью в интерактивном режиме, в отличие от пакетных систем с недельным циклом обработки; у нас имеются языки визуального моделирования, и мы применяем общие принципы динамики систем для реше­ ния небольших конкретных задач, в отличие от того про­ екта “глобальной модели”, который профессор Форре­ стер и его коллеги пытались реализовать в 1960-х. Один из примеров таких конкретных задач — про­ цессы создания ПО. Начиная с первых работ Тарика Абдель-Хамида в Массачусетском технологическом ин­ ституте в начале 1990-х годов, исследователи и специа­ листы в области совершенствования процессов экспе­ риментируют с динамическими моделями, пытаясь глубже разобраться в процессах создания ПО. Если это поможет менеджеру безнадежного проекта лучше по­ нять, что происходит в его проекте, то вероятность успе­ ха может повыситься.

6.1 Модели процессов разработки программного обеспечения Многие из нас воспринимают слово “модель” в кон­ тексте процессов разработки ПО как набор графических абстракций ПО — например, диаграммы UML, блоксхемы, диаграммы “сущность-связь” и др. В контексте реинжиниринга бизнес-процессов — это диаграммы по­ токов работ или технологические карты. Однако в реальном мире менеджеры проектов мало что используют из всей этой кухни в своей повседневной

деятельности. Такие модели используются скорее для планирования и согласования общей стратегии, а для принятия ежедневных оперативных решений используют­ ся другие модели, наиболее важными из которых являют­ ся мысленные (mental) и табличные (spreadsheet) модели.

6.1.1 Мысленные модели Мысленную модель следует буквально понимать как модель, которая существует только в голове. Она может основываться на опыте или интуиции, или на мифах иле­ гендах, на нее оказывают влияние политика и весь спектр человеческих эмоций. Однако главная особенность мыс­ ленной модели заключается в том, что ее невозможно вы­ разить в письменной форме; во многих случаях ее даже невозможно озвучить, это глубоко личная практика ме­ неджера, которой он руководствуется в своей работе. “Официальная” часть процессов создания ПО в ор­ ганизации обычно выражена в письменной форме (хотя все по-разному ее читают, понимают и используют). На­ пример, официальный процесс может регламентировать следующее; “Сначала мы определяем требования к про­ граммному продукту, и до тех пор, пока эти требования не будут утверждены отделом тестирования, каждый, кто посмеет написать код или заняться детальным про­ ектированием, будет казнен на рассвете, потому что от­ дел тестирования должен разрабатывать тестовые про­ цедуры параллельно с программированием, и они не смогут делать это, пока не будут готовы все требова­ ния”. Все это порождает проблемы, решению которых может способствовать построение моделей описанной выше деятельности в виде диаграмм потоков данных или чего-то подобного. Но представьте себе такую ситуацию — половина проекта позади, утром программисты приходят в офис к менеджеру и хмуро заявляют: “ Не знаем, как это случи­ лось, но когда мы проснулись сегодня утром, то обнару­

жили, что отстаем от графика на полгода!” Простая мысленная модель неопытного менеджера проекта пред­ лагает следующий план действий — немедленно нанять побольше людей. Почему? Потому что его мысленная модель говорит примерно следующее: «Нам необходимо выполнить больше работы в ограниченное время, по­ скольку мы не можем отодвинуть срок окончания проек­ та. Больше людей сделают больше работы, поэтому, чтобы выполнить всю требуемую работу, надо нанять дополнительных сотрудников». Разумеется, у опытных менеджеров совершенно дру­ гая мысленная модель. Она опирается на их собствен­ ный опыт и Закон Брукса, который он сформулировал в своей знаменитой книге “Мифический человеко-месяц ”: если проект не укладывается в сроки, то добав­ ление рабочей силы задержит его еще больше. По­ этому реакция многих менеджеров, особенно в безна­ дежных проектах, будет иной: “ В нашем распоряжении неограниченное и бесплатное сверхурочное время. Если проект отстает от графика, попросим команду “добро­ вольно” поработать сверхурочно некоторое время, пока проект опять не войдет в график. Если с самого начала проекта ясно, что график чересчур оптимистичен, то следует заранее объявить, что сверхурочная работа бу­ дет обязательной, и довести до сведения каждого, что все продвижения по службе и поощрения будут зависеть от их энтузиазма в выполнении своих обязанностей”. Есть еще и третий вариант мысленной модели, ис­ пользуемый в некоторых безнадежных проектах: если к середине проекта вы отстаете от графика, разделите проектную команду пополам. Согласно теории Дарвина, выживут сильнейшие, и они примутся за дело, начав ко­ дировать в бешеном темпе; у них не будет времени посе­ щать собрания, писать докладные записки и заниматься прочей пустой тратой времени. Если спустя пол года вы все еще отстаете от графика, снова разделите проект­ ную команду пополам.

Если вы считаете этот способ сомнительным, могу привести в пример мысленную модель одного жесткого и последовательного менеджера, который успешно и в сжатые сроки выполнил ряд проектов для финансовых компаний Уолл-Стрит. Она выглядит так: все проекты отстают от графика по определению, вопрос только в том, когда вы это обнаружите и как на это отреагирует проектная команда..Чтобы предвосхитить эту ситуацию, создайте “искусственный” кризис в самом начале проек­ та и посмотрите, что произойдет. Скорее всего, некото­ рые люди уйдут из проекта, не выдержав стресса, неко­ торые проигнорируют кризис и продолжат работать в обычном режиме, у кого-то произойдет нервный срыв, кто-то начнет совершать разные антисоциальные по­ ступки (например, принесет ружье в офис). А некото­ рые — те, кого считали самыми тихими и скромными членами проектной команды, — сделают карьеру и ста­ нут героями, приняв вызов и справившись с кризисом. Менеджер с Уолл-Стрит сравнивает этот процесс с первым плаванием на военном корабле. Искусственный кризис позволяет ему проверить, на что способна про­ ектная команда в условиях настоящего кризиса. Закон­ чив проверку, он объявляет о преодолении кризиса, и работа продолжается в нормальном режиме. Можно соглашаться или не соглашаться с любой из мысленных моделей, однако реальность заключа­ ется в том, что в вашей собственной организации су­ ществует дюжина вариаций на тему этих моделей, и вы никогда не обсуждали их со своими коллегами. Ра­ зумеется, большинство из этих моделей можно спо­ койно обсудить, однако представьте себе, какие горя­ чие дебаты с переходом на личности могут возникнуть по поводу модели “искусственного кризиса”. Очень сложно объяснить последствия использования своей модели на пальцах, не переходя на крик. Методы ви­ зуального моделирования, которые рассматриваются в этой главе, помогают просчитать последствия

принимаемых решений и тем самым перевести дискуссию в разумное русло.

Еще одно замечание по поводу приведенных приме­ ров: они почти никогда не становятся частью “офици­ альной” модели процесса разработки ПО в организации, поскольку связаны в основном с “социальными” вопро­ сами. Как отмечает Тарик Абдель-Хамид [3]: Исследования показали, что менеджеры за­ частую справляются с проблемами, используя мысленные модели, не учитывающие всех ас­ пектов ситуации. Например, менеджеры с техническим обра­ зованием склонны недооценивать влияние со­ циальных факторов. Результатом чаще всего становится дисфункциональное поведение.

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

6.1.2 Табличные модели Чем же еще пользуются менеджеры проектов поми­ мо мысленных моделей, основанных на опыте, интуиции и суевериях? Разумеется, многие менеджеры использу­ ют сетевые графики PERT (Program Evaluation-andReview Technique — метод оценки и пересмотра планов) или графики Гантта, которые сегодня поддерживаются обычными средствами управления проектами на ПКВ самом деле, если вы заглянете в офис менеджера про­

екта, то, скорее всего, обнаружите группу людей, изу­ чающих «критический путь» проекта на сетевом графи­ ке; такие диаграммы действительно помогают наглядно отобразить важнейшие аспекты проекта. Обычное дело также видеть менеджеров проектов, склонившихся над своими рабочими столами и внима­ тельно изучающих строки и столбцы таблицы; не будет преувеличением предположить, что Microsoft Excel — наиболее широко используемое средство управления проектами в IT-организациях. Рассмотрим в качестве примера таблицу 6.1, в которой содержатся некоторые плановые показатели гипотетической организации-раз­ работчика ПО. Такого рода модель дает полезную ин­ формацию относительно процесса, проекта или органи­ зации, и большинство менеджеров с этим согласятся. Всем известны возможности электронных таблиц: если изменить число или формулу в любой из ее ячеек, то из­ менения будут автоматически внесены во все остальные ячейки. Тем не менее, глядя на таблицу 6.1, можно обнару­ жить принципиальную проблему: таблица статична, глядя на нее, мы не видим динамику процессов, во вся­ ком случае, она не наглядна. Если нам нужны данные более чем по восьми бюджетным кварталам, то в такой таблице мы их не увидим. (Разумеется, можно добавить столбцы, но тогда таблица не поместится на одном лис­ те. Можно развернуть лист на 90’, но это не слишком красивое решение.) С таблицами связана еще одна любопытная пробле­ ма. Поскольку они зачастую связаны с финансовым пла­ нированием, мы стремимся наполнить их только “ося­ заемыми” показателями, которые можно измерить, — количество сотрудников, денег, рабочих станций, строк кода и т.д. В результате мы уходим в сторону от оценки неформальных параметров проекта — морального со­ стояния, мотивации, качества и уровня понимания мето­ дологии разработки ПО.

Таблица 6.1 Типичная модель для планирования проекта Бюджетный квар­ тал

1

2

3

4

5

6

7

8

CASE-средства ($000)

$75

$75

$75

$75

$75

$75

$75

$75

Обучение CASEсредствам ($000)

$50

$50

$40

$30

$20

$20

$10

$5

Y

Y

Y

Y

Y

Y

Y

0.05

0.05

0.05

0.05 0.05 0.05

Свободный график Y рабочего дня Повышения зар­ платы (%/год)

0.05 0.05

Офисные помеще­ ния

$650 $650 $650 $650 $650 $650 $650 $650

Коэффициент заня­ 0.7 тости

0.7

0.7

0.7

0.7

0.7

0.7

0.7

Капитальные за­ траты ($000)

$17.5 $17.5 $17.5 $17.5 $17.5 $17.5 $17.5 $17.5

Эксплуатационные затраты ($000)

$9.8

$9.6

$9.4

$9.0

$8.6

$8.0 $7.4 $6.7

Незавершенные задания

147

144

141

136

132

126

121

115

Количество новых сотрудников

45

43

41

39

37

35

34

33

154

156

158

160

161

162

163

Количество ветера­ 152 нов Темп разработки

15.19 14.58 14.14 13.72 14.31 14.91 16.01 17.15

Текучесть кадров

3

4

5

6

5

4

4

3

Чтобы убедиться, насколько это может быть важ­ ным, представим себе поведение менеджера проекта, наблюдающего за попытками проектной команды при­ менить новую методологию разработки ПО, например

объектно-ориентированное проектирование, в критиче­ ски важном проекте со сжатыми сроками. Главный во­ прос для менеджера в этой ситуации: “Сможет ли про­ ектная команда быстро накопить достаточные знания относительно этой новой технологии, чтобы воспользо­ ваться ее преимуществами и закончить проект раньше намеченного срока?” Если обнаружится, что команда терпит поражение в сражении с новой технологией, то нужно успеть отказаться от нее прежде, чем проект ока­ жется в критическом состоянии. “ Накопленные знания” — это хороший пример не­ формального параметра; в то время как опытные экс­ перты могут располагать некоторыми количественными метриками в данной области, большинство менеджеров будут утверждать, что знания невозможно выразить в дюймах, галлонах или фунтах на квадратный дюйм. Сле­ довательно, незачем пытаться измерять их и учитывать при планировании. Однако, несмотря на нехватку коли­ чественных метрик, можно все же грубо оценить уро­ вень знаний проектной команды, и определить, повы­ сился он или понизился. Этого может оказаться вполне достаточно. Важно то, что отказ от измерения показате­ ля означает, что его как бы не существует, и большинст­ во менеджеров согласится с тем, что учет или отсутствие учета накопленных знаний имеет существенное зна­ чение. Поскольку такой параметр является неформаль­ ным по своей природе, мы должны относиться к по­ добным метрикам с некоторой предосторожностью и использовать их в основном для качественной оценки порядка изменений и прогнозирования тенденций. На­ пример, менеджер может задать такой практический вопрос: “Что произойдет с бюджетом и графиком про­ екта, если я направлю участников проектной команды на учебные курсы и в результате они потратят вдвое меньше времени на освоение объектно-ориентирован­ ной методологии?”

6.1.3 Статические и динамические модели В предыдущем подразделе я определил таблицу 6.1 как “визуальную статическую” модель, однако есть го­ раздо более важные соображения по поводу статических и динамических моделей, которые следует обсудить. Все нетривиальные процессы, которые мы рассматриваем, взаимодействуют между собой, и эти взаимодействия со временем изменяются. Один из примеров — это ситуа­ ция с накоплением знаний, которые изменяются каждый день, и менеджер должен уметь оценить эти изменения, чтобы принять наилучшее решение. Большое значение имеет также природа взаимодей­ ствий между различными компонентами процесса. Если мы изменим какой-либо компонент процесса, то это, ве­ роятно, скажется на каком-нибудь другом. Кроме того, при взаимодействии могут иметь место временные за­ держки и циклы обратной связи. Эти взаимодействия можно отразить в табличной модели, но они не будут видны постороннему наблюдателю. Взаимодействия вы­ ражаются в виде связей между ячейками таблицы за счет использования различных математических формул, встроенных в ячейки. Если мы пользуемся табличным процессором, то сможем видеть эти формулы, но если мы просто смотрим на таблицу, то не увидим никаких связей между ее ячейками. Сочетание нескольких взаимодействующих компо­ нентов может привести к появлению “волнового эффек­ та” в организации. Рассмотрим две первые строки в таблице 6.1. Согласно этим данным, гипотетическая ор­ ганизация-разработчик ПО делает существенные инве­ стиции в CASE-средства, но с каждым кварталом тратит все меньше и меньше денег на обучение. Если работа с CASE-средствами требует использования формальной и строгой методологии, а персонал не освоил ее в доста­ точной степени, не удивительно, что продуктивность

разработки в начальном периоде снижается; это видно из последней строки таблицы 6.1. Вместе с падением продуктивности и разочарованием в новых CASE-средствах ухудшается и моральное состояние команды. Хотя моральное состояние, будучи неформальным парамет­ ром, не включено в таблицу 6.1, от него невозможно отмахнуться. Если оно ухудшается, растет текучесть кадров. Здесь начинается самое интересное. Если сотрудники организации увольняются, то кто уходит в первую оче­ редь? Самые продуктивные! Во-первых, у них самые лучшие приглашения на работу от других организаций и, во-вторых, они испытывают наибольшее разочарование в нынешней ситуации. В результате их ухода средняя продуктивность организации падает еще больше, что вызывает дальнейшее ухудшение морального состоя­ ния... которое повышает текучесть кадров ... которая за­ ставляет увольняться оставшихся продуктивных сотруд­ ников... и так до тех пор, пока в организации не останутся одни зомби из фильма “Ночь Живых Мерт­ вецов".

Если этот пример выглядит слишком надуманным (хотя эта ситуация вполне реальна, я наблюдал ее в ряде компаний и правительственных организаций), рассмот­ рим более приземленную ситуацию. При оценке различ­ ных параметров проекта почти все менеджеры учитыва­ ют фактор “безопасности” (известный также как фактор случайности, подгона под нужный результат и поддругими красивыми названиями), и они это делают без учета какой-либо динамики. Как отмечают Абдель-Хамид и Мэдник [6], различные факторы безопасности порожда­ ют различные проекты. Если проектная команда знает, что ее менеджер опубликовал официальный график про­ екта с нулевым запасом прочности, участники проекта немедленно скорректируют свое поведение, исключив любую деятельность, которую они считают несущест­ венной. В зависимости от характера проекта, это может

означать отказ от документирования, тестирования, обеспечения качества, присутствия на еженедельных со­ вещаниях, ответов на сообщения электронной почты или участия в школьной жизни своего ребенка. И наобо­ рот, если график проекта составлен с большим запасом, то начинает действовать Закон Паркинсона: работа за­ нимает все отведенное для нее время. Некоторые организации, достигшие третьего, четвер­ того или пятого уровней СММ, осознали важность про­ блем, связанных с динамикой процессов. Даже если ис­ ключить неформальные факторы, временные задержки и циклы обратной связи все равно могут оказать значи­ тельное воздействие на успех проекта. В качестве про­ стого примера рассмотрим влияние дефектов проекти­ рования, допущенных на стадий анализа в классическом “каскадном” процессе и обнаруженных только в начале стадии программирования или тестирования. В фор­ мальном, строгом процессе разработки это означает, что мы должны снова вернуться на стадию анализа для ис­ правления ошибок и затем провести все изменения че­ рез проектирование и кодирование, пока не доберемся снова до тестирования. Разумеется, возможно, что в процессе исправления ошибок мы что-то сделали не так, и тестирование выявит новые ошибки. В итоге может потребоваться несколько циклов исправлений, пока тестирование не даст удовлетворительных результатов. Все это может существенно повлиять на общее время процесса, который наша организация пытается усовер­ шенствовать.

6.2 Визуальные модели Если динамика процесса разработки ПО настолько важна, то как в ней можно разобраться? Таблицы для этого не очень подходят, поскольку они не отражают взаимозависимости и обратные связи между компонен­ тами процесса. Напротив, визуальные модели обычно

лучше подходят для иллюстрации “целостной" природы процесса, такие модели вызывают дискуссии, критикуй аргументацию типа “да ... но ...”. Для большинства профессионалов визуальные моде­ ли не являются чем-то необычным, поскольку они давно используются в разных технических системах. Посколь­ ку программное обеспечение на порядок сложнее, при его создании тем более имеет смысл использовать раз­ личные средства моделирования, такие, как диаграммы потоков данных, диаграммы “сущность-связь”, объект­ но-ориентированные диаграммы и т.д. Здесь имеется только одна проблема: все эти гра­ фические модели статичны. За небольшим исключе­ нием, они были изобретены до появления современ­ ных C A SE-средств, поэтому мы привыкли рисовать их на бумаге или отображать на пассивном дисплее. Если вы построили диаграмму потоков данных с помощью типичного CA SE-средства, то она не “дви­ жется” — не показывает динамику моделируемого процесса. Для этого требуется анимация, которой большинство поставщиков CASE-средств никогда не занималось. В результате организации-разработчики, пытающие­ ся достичь более глубокого понимания своих процессов, обращаются к средствам имитационного моделирова­ ния, которые могут отобразить динамику системы. Один из таких продуктов — iThink (High Performance Systems, Inc., www.hps-inc.com) использует нотацию, похожую на диаграммы потоков данных. Простой при­ мер модели, построенной средствами iThink, приведен на рис. 6.1. Разумеется, когда такая диаграмма напечатана на бу­ маге, она тоже статична. Но если она построена на ком­ пьютере, то средства моделирования позволяют аними­ ровать ее путем задания инструкций iThink для запуска имитации процесса. В дополнение к возможностям ани­ мации, можно построить обычный набор схем и графи-

Рис. 6.1 Типичная модель IThink

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

6.3 Пример: модель Тарика Абдель-Хамида Возможно, наиболее известная динамическая модель процесса создания ПО была разработана профессором Тариком Абдель-Хамидом и опубликована в учебнике Абдель-Хамида и Мэдника [1]. Она отражает виды ра­ бот в процессе управления проектом среднего размера, использующего традиционные средства разработки и классическую “каскадную” модель процесса разработки. Хотя она не учитывает особенности сегодняшних проек­ тов, использующих быстрое прототипирование, средст­ ва визуальной разработки, библиотеки повторно ис­ пользуемых компонентов и т.д., тем не менее, она может служить в качестве отправной точки для организаций.

желающих более глубоко разобраться во взаимодейст­ виях между различными компонентами их процесса раз­ работки ПО. Данная модель включает компоненты, описывающие управление человеческими ресурсами, разработку ПО, тестирование, обеспечение качества и планирование проекта. Если вас интересует полное описание модели, включая ее реализацию на языке имитационного моде­ лирования DYNAMO, обратитесь к книге [1]. Далее я расскажу о той части модели, которая связана с управ­ лением человеческими ресурсами. Как показано на рис. 6.2. с точки зрения менеджера, участников проектной команды можно разделить на две категории: новички и ветераны. Абдель-Хамид и Мэдник используют термины “ новобранцы” и “профессионалы”. Такое разделение вполне естественно, поскольку со­ трудники этих категорий существенно различаются в продуктивности, зарплате и др. “Динамика” процесса управления человеческими ресурсами включает наем новых сотрудников по мере необходимости, их адапта­ цию (превращение новобранцев в профессионалов) и уход из проекта по разным причинам. В графической но­ тации iThink “облачка” представляют собой границу мо­ дели; мы не знаем или нас не интересует, откуда берутся новобранцы и куда уходят профессионалы. Участники проекта “текут” по “трубопроводам” , изображенным в виде стрелок, и задерживаются на некоторое время в “резервуарах” -прямоугольниках (рис. 6.2). “Пузырьки”,

Рис. 6.2 Модель управления человеческими ресурсами Абдель-Хамида и Мэдника, часть 1

присоединенные к трубопроводам, являются “ регулято­ рами потока” , наподобие вентиля на водопроводном кране; они контролируют скорость перемещения по тру­ бопроводам. Одно из достоинств любой визуальной модели за­ ключается в том, что она дает нам предмет для обсужде­ ния. Например, при рассмотрении модели на рис. 6.2 возникает ряд вопросов: • Можно обсудить основную предпосылку моде­ ли: все вновь нанимаемые сотрудники являют­ ся новобранцами. Почему бы не предполо­ жить, что могут наниматься опытные профессионалы? В ответ на этот вопрос Аб­ дель-Хамид и Мэдник утверждают, что все но­ вые участники проекта — новобранцы, даже если они проработали в компьютерной индуст­ рии 25 лет. Хотя они могут быть экспертами в части технических средств или ПО, они обычно не представляют себе всех нюансов самого проекта, которые заключаются в разных хит­ рых терминах и сокращениях, политике, персо­ налиях, технических деталях уже выполненной работы. Конечно, люди с 25-летним опытом работы адаптируются в условиях проекта го­ раздо быстрее, чем недавние выпускники кол­ леджа; поэтому, как станет ясно из дальнейше­ го изложения, регулятор адаптации на рис. 6.2 не является постоянной величиной. • Еще одна предпосылка модели: новобранцы не уходят из проекта. Рис. 6.2 подразумевает, что новобранцы либо так и остаются ими навсегда (задерживаясь в “резервуаре” новобранцев), либо перемещаются по “трубопроводу” и при­ обретают статус профессионалов; модель ясно показывает, что только профессионалы исчеза­ ют в “облачках”. Очевидно, что для некоторых

организаций это допущение не слишком разум­ но, и модель следует изменить. Следует отметить, что второй вопрос не имеет ника­ кого отношения к динамике. Иначе говоря, обычная диа­ грамма потоков данных, так же, как и статическое визу­ альное представление на рис. 6.2, вполне подходит для того, чтобы убедиться в наличии у всех руководителей организации общей мысленной модели процесса найма и увольнения разработчиков ПО. В реальности процесс управления человеческими ре­ сурсами гораздо сложнее изображенного на рис. 6.2. Уточненный вариант модели показан на рис. 6.3. На данной версии модели показаны три “конверте­ ра”, управляющие регуляторами трубопроводов. В ре­ альных условиях можно предположить, что частота адаптации и ухода характеризуется “нормальным рас­ пределением” — это означает, что некоторый процент профессионалов уйдет из проекта почти сразу же после

Рис. 6.3 Модель управления человеческими ресурсами Абдель-Хамнда и Мэдника, часть 2

попадания в свой резервуар, а некоторые останутся в этом резервуаре, пока не умрут от старости. Если мы принимаем вариант с нормальным распределением, то его параметром можно считать “среднее время занято­ сти", которое отражается на средней частоте ухода. Пузырек “задержка найма” на рис. 6.3 представляет собой временную задержку. Не вдаваясь в подробности ее реализации в iThink, поговорим о содержательной стороне дела: что происходит в большинстве организа­ ций, когда менеджер проекта обращается в отдел кадров с просьбой принять на работу еще двух программистов для его проекта. Типичный ответ: “Хорошо, нам потре­ буется для этого три месяца” . Между тем, проект дол­ жен непонятно как продолжаться, а менеджер должен гадать, успеет он закончить проект вовремя или нет. В такой ситуации, особенно при сжатых сроках без­ надежного проекта, возникает один из типичных вопро­ сов “динамики системы” — что произойдет с проектом, если задержка найма, создаваемая отделом кадров, уменьшится до одного месяца? Что будет, если она во­ обще исчезнет? Два пузырька в левой верхней части рис. 6.3 отража­ ют другую характеристику вновь нанимаемых сотрудни­ ков: потребность в обучении. В сочетании с другими компонентами модели Абдель-Хамида/Мэдника, эта ха­ рактеристика иллюстрирует одно из проявлений упомя­ нутого выше Закона Брукса: добавление новых участни­ ков в проект потребует затрат на их обучение, отвлекая уже работающих над проектом. На рис. 6.4 показана следующая уточненная версия модели, учитывающая вероятность перехода участников проектной команды в другие подразделения организа­ ции. Правда, кто-то может возразить, что с точки зрения менеджера проекта между таким “ переходом” и уходом из проекта вообще нет никакой разницы. Однако такая разница все же имеется, она отражается в регуляторах потока под названием “задержка перехода". Это вполне

Рис. 6.4 Модель управления человеческими ресурсами Абдель-Хамида и Мэдника, часть 3

согласуется с опытом многих менеджеров: когда сотруд­ ник уходит из проекта, он делает это сразу, а когда ктото хочет переманить его в свой проект, то вы обычно за­ держиваете этот переход на несколько недель или меся­ цев, чтобы он доделал свою работу. Окончательная версия модели показана на рис. 6.5. Ее дополнительные компоненты отражают очень важ­ ный для менеджера проекта вопрос, с которым ему при­ ходится иметь дело каждый день: сколько новых сотруд­ ников нужно набрать в проектную команду? Для этого

Рис. 6.5 Модель управления человеческими ресурсами Абдель-)ймида и Мэдника, часть 4

нужно рассчитать “ количество необходимой рабочей силы” (сам расчет на диаграмме, естественно, не пока­ зан), исходя из продуктивности участников проекта, вре­ мени, оставшегося до завершения проекта, и разных других факторов, определяющих “готовность” менедже­ ра к набору новых сотрудников. Это количество может быть ограничено: в правом верхнем углу рис. 6.5 имеет­ ся пузырек с названием “потолок найма”, вычисляющий предельное количество нанимаемых сотрудников с уче­ том “временного эквивалента” количества участников проекта (FTE — full time equivalent). Обратите также внимание, что пузырек “дефицит ра­ бочей силы” служит входом для пузырьков “частота пе­ рехода новобранцев” и “частота перехода профессиона­ лов”. Он означает, что менеджер проекта может инициировать переход своих сотрудников в другие под­ разделения и сокращение проектной команды, если он обнаружит избыток сотрудников (например, по причине более высокой их продуктивности, чем ожидалось, или небольшого количества дефектов, подлежащих устране­ нию, и т.п.). Обычная реакция на такую модель может быть сле­ дующей: “Да, все это очень интересно, но слишком сложно. И непонятно, какое это имеет отношение к объ­ ектно-ориентированной технологии и новым средствам программирования, с помощью которых я собираюсь повысить продуктивность моей команды”. Да, отчасти это так, однако модель помогает глубже разобраться в динамике процесса изменения состава участников про­ екта, что зачастую может повлиять на его успех сильнее, чем выбор языков программирования. (И не следует за­ бывать, что я показал только небольшую часть модели Абдель-Хамида/Мэдника; другие ее компоненты непо­ средственно связаны с разработкой ПО, и менеджер мо­ жет экспериментировать с различными допущениями относительно влияния новомодных CASE-средств и языков программирования на продуктивность разработ­

чиков. В модели есть также компоненты, связанные с дополнительными неформальными проблемами — на­ пример, что произойдет, если менеджер проекта обнару­ жит отставание от графика и попросит проектную команду поработать сверхурочно?) И хотя рис. 6.5 вы­ глядит сложным на первый взгляд, потребуется совсем немного времени, чтобы в нем разобраться. Вряд ли ме­ неджеру проекта стоит “ прятать голову в песок” и ут­ верждать, что процесс, описанный данной моделью, на­ столько сложен, что о нем вообще не следует думать. Реальные проблемы будут существовать независимо от того, хотим мы знать о них или нет.

6.4 Заключение В идеальной ситуации менеджеру безнадежного про­ екта желательно располагать временем, финансами, на­ стойчивостью и техническими ресурсами для создания динамической модели своего проекта, наподобие той, которую мы только что разобрали, но более полной. Основная причина для построения такой модели за­ ключается в том, что ее можно использовать для отве­ тов на вопросы типа “что, если”, анализируя “ нелиней­ ные” аспекты динамики проекта. Например, может оказаться, что существенное увеличение некоторого параметра (такого, как количество новых сотрудников, нанимаемых за месяц) окажет совершенно незначи­ тельное воздействие на какой-либо из основных пара­ метров, например, на “ожидаемую дату завершения проекта” . В других случаях, незначительное изменение незначительного, на первый взгляд, параметра (напри­ мер, “частоты ухода" профессионалов на рис. 6.5) мо­ жет оказать на проект такое существенное воздейст­ вие, которого никто не ожидал. Это происходит изза наличия множества взаимодействующих факторов, взаимное влияние которых друг на друга достаточно сложно количественно оценить.

К сожалению, мы живем в реальном, а не идеальном мире. Очень немногие менеджеры безнадежных проек­ тов располагают временем или ресурсами для создания моделей. Однако даже у менеджеров, находящихся в са­ мых стрессовых ситуациях, все же есть некоторое вре­ мя и ресурсы, и если они потратят хотя бы час или два на анализ временных задержек и обратных связей, то уже и это сможет существенно повлиять на динамику проекта. Использование графических нотаций, описанных в данной главе, может, как минимум, быть удобным и эф­ фективным способом формирования “общей мысленной модели”, которая может определить успех или неудачу проекта. Например, если менеджер проекта скажет, что ключевым фактором успеха проекта является сокраще­ ние времени рассмотрения и утверждения основных ре­ шений заинтересованными лицами с двух недель до одного дня. было бы здорово, если бы все высшие руко­ водители и основные заинтересованные лица имели воз­ можность посмотреть, каким образом этот параметр по­ влияет на динамику проекта. Мой опыт работы в качестве консультанта говорит, что постоянная спешка и суматоха не позволяют остано­ виться и подумать о таких проблемах в самом начале проекта. К сожалению, влияние различных нелинейных факторов на динамику проекта иногда становится оче­ видным только после его провала, и даже тогда оно за­ частую игнорируется. Все усиленно занимаются поиска­ ми “последней капли, переполнившей чашу терпения". Из политических соображений, может быть, выгодно найти козла отпущения, единственное решение или единственную ошибку, из-за которых весь проект потер­ пел крах, но даже элементарный “посмертный” анализ динамики проекта покажет, что имело место влияние множества взаимодействующих и взаимозависимых факторов. К тому времени, когда такой анализ будет выполнен, проект уже потерпел крах, менеджер проекта уволен,

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

Библиография 1. Tarek Abdel-Hamid, Stuart Е. Madnick. Software Project Dynamics: An Integrated Approach. Englewood Cliffs, NJ: Prentice Hall, 1991. 2. Jay Forrester. Industrial Dynamics. Cambridge, MA: MIT Press, 1961. 3. Tarek Abdel-Hamid. Organizational Learning: the Key to Software Management Innovation. American Programmer, June 1991. 4. G.P. Richardson, G.L. Pugh, III. Introduction to Systems Dynamics Modeling with Dynamo. Cambridge, MA: MIT Press, 1981. 5. Tarek Abdel-Hamid, Stuart E. Madnick. Impact of Schedule Estimation on Software Project Behavior.

IEEE Software, May, 1986. 6. Tarek Abdel-Hamid, S. E. Madnick. Lessons Learned from Modeling the Dynamics of Software Project Management. Communications of the ACM,

December, 1989. 7. Peter M. Senge. The Fifth Discipline: The Art and Practice of the Learning Organization. New York: Doubleday, 1994. 8. Tarek Abdel-Hamid. Thinking in Circles. American Programmer, May 1993. 9. Brad Smith, Nghia Nguyen, Richard Vidale. Death of a Software Manager: How to Avoid Career Suicide through Dynamic Software Process Modeling. American Programmer, May 1993.

10. Karim J. Chichakly. The Bifocal Vantage Point: Managing Software Projects from a Systems Thinking Perspective. American Programmer, May 1993. 11. Ernst W. Diehl. The Analytical Lens: StrategySupport Software to Enhance Executive Dialog and Debate. American Programmer, May 1993. 12. Chi Y. Lin. Walking on Battlefields: Tools for Strategic Software Management. American Programmer, May 1993. 13. Kenneth G. Cooper, Thomas W. Mullen. Swords and Plowshares: The Rework Cycles of Defense and Commercial Software Development Projects. American Programmer, May 1993. 14. Rembert Aranda, Thomas Fiddaman, Rogelio Oliva. Quality Microworlds: Modeling the Impact of Quality Initiatives over the Software Product Life Cycle. American Programmer, May 1993. 15. Tony Variale, Bob Rosetta, Mike Steffen, Howard Rubin, Ed Yourdon. Modeling the Maintenance Process. American Programmer, March 1994.

ГЛАВА 7

МЕТОД КРИТИЧЕСКИХ ПОСЛЕДОВАТЕЛЬНОСТЕЙ И ТЕОРИЯ ОГРАНИЧЕНИЙ

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

Эта идея настолько радикальна, что большинство ме­ неджеров отвергнет ее, не задумываясь, и будет настаи­ вать, чтобы мы спустились на землю и занялись поиском практических способов достижения успеха в безнадеж­ ных проектах. Однако, если попытаться подавить свое неверие и поразмыслить немного над этой идеей, тогда, возможно, возникнут следующие четыре вопроса: • Какие примеры “дисфункционального” поведе­ ния организации порождают IT-проекты (да и любые другие проекты), которые длятся вдвое дольше положенного? • Каким образом можно убедить высшее руковод­ ство и заинтересованных лиц, что такое поведе­ ние действительно дисфункционально, и, что более важно, как преобразовать всю корпора­ тивную культуру в более рациональную? • Если поведение организации рационально, то какая стратегия планирования проекта будет наилучшей? • Каким образом можно перейти от такой страте­ гии к конкретным процедурам, руководствам и критериям для ежедневного использования? Хорошие ответы на эти вопросы дают “теория огра­ ничений” и “ метод критических последовательностей", разработанные в последние двадцать лет, в основном, благодаря усилиям доктора Элии Голдрата [2, 4]. На са­ мом деле, эти идеи получили такое широкое признание и поддержку и позволили достичь таких впечатляющих ре­ зультатов, что удивительно, почему они не стали основ­ ным направлением в управлении проектами. Один из возможных ответов заключается в том, что многие орга­ низации дисфункциональны, и очень трудно изменить их поведение, не имея квалифицированного “терапевта" и в отсутствии кризиса, угрожающего самому существова­ нию организации.

Полное изложение метода критических последова­ тельностей и теории ограничений заняло бы целую кни­ гу. На самом деле, несколько замечательных книг на эту тему уже опубликовано [2, 4], их перечень приведен в библиографии. Моя цель — дать общее представление об этих концепциях и некоторые практические рекомен­ дации для менеджеров безнадежных проектов. Кроме того, я настоятельно рекомендую прочесть одну или не­ сколько из этих книг. Возможно, они убедят вас, что ваша организация дисфункциональна, и с этим нужно что-то делать.

7.2 Что означает дисфункциональное поведение организации? За те годы, что прошли с момента публикации перво­ го издания этой книги, Америку не раз сотрясали скан­ далы, связанные с дисфункциональным поведением корпораций, которое было вызвано жадностью, самона­ деянностью, высокомерием и полным пренебрежением этическими нормами. Но в данной главе речь пойдет не об этом. Нашей целью не является анализ причин фиа­ ско Enron или Worldcom, мы должны сосредоточиться на дисфункциональном поведении, связанном с графи­ ками, оценками и каждодневными попытками уложиться в ограниченные сроки и бюджет. Возможно, в экстре­ мальной ситуации это может довести и до арестов и судебных процессов, но, как правило, результат — на­ рушение сроков, раздраженные заказчики и деморали­ зованные исполнители. Многое в таком дисфункциональном поведении мож­ но понять, если воспользоваться концепцией “динамики систем”, рассмотренной в предыдущей главе. В самом деле, система организации намного сложнее, чем боль­ шинство менеджеров может себе представить. Она со­

держит целый ряд неформальных факторов, таких, как моральное состояние коллектива, которые невозможно изобразить простым способом на графике руководителя среднего или высшего уровня. Представим себе, в частности, что произойдет, если некоторое событие (например, непопулярное решение руководства об отмене годовой премии) повлечет за со­ бой ухудшение морального состояния сотрудников ITорганизации. Одним из многих возможных последствий станет рост текучести кадров, сразу или через несколь­ ко месяцев, и уходить будут специалисты высшей квали­ фикации, которые всегда смогут найти работу, даже в условиях экономического спада. В результате средняя продуктивность сотрудников организации снизится, воз­ никнут проблемы в проектах и моральное состояние ухудшится еще больше. Таким образом, одно единствен­ ное событие (результат которого вполне можно было предвидеть) создало “ порочный круг”, ситуация вышла из-под контроля, и так будет продолжаться до тех пор, пока в организации не останутся одни неудачники и не­ довольные, которые просто не могут найти никакой дру­ гой работы. Конечно, этот пример сам по себе не имеет отноше­ ния к планированию и управлению проектами, но он ка­ сается поощрения и вознаграждения сотрудников. Как правило, организации поощряют, наказывают, оценива­ ют и контролируют деятельность своих сотрудников, ис­ ходя из мелких локальных соображений, хотя сами они заинтересованы в достижении глобальных результатов. С точки зрения динамики систем, это может привести к дисфункциональному поведению, что вовсе не входило в намерение действующих из лучших побуждений менед­ жеров или лояльных сотрудников. Например, руководство организации может сказать менеджеру проекта: “ Все, что нас интересует, — это своевременное завершение проекта; нам не важно, как вы его организуете. Если проект закончится успешно,

вся команда будет премирована” . Но в большинстве ор­ ганизаций корпоративная культура заставляет менедже­ ра разбивать проект на небольшие задачи, и каждый сотрудник знает, что все, что от него требуется, — за­ вершить свои задачи вовремя. В результате сотрудник, успешно выполнивший свои задачи, будет поощрен не­ зависимо от результатов всего проекта, и наоборот, со­ трудник, не выполнивший в срок некоторые из своих за­ дач, будет наказан даже в том случае, если проект завершится успешно. Такое положение, скорее всего, явно нигде не доку­ ментируется. Возможно даже, что руководители средне­ го или высшего уровня будут твердо это отрицать. Но для рядовых исполнителей дела значат больше, чем сло­ ва. Поскольку они видят, как оценивают их работу, то и ведут себя соответственно. Даже если они не могут признать это открыто, выбор между успехом проекта и личным успехом почти всегда решается в пользу по­ следнего. На практике это означает, что исполнитель поста­ рается рассмотреть наихудший вариант и максимально завысить время выполнения своих собственных задач, чтобы свести вероятность опоздания к минимуму. В некоторых случаях он может быть так красноречив и убедителен, что сумеет доказать менеджеру свою правоту, а в других ситуациях он будет делать все воз­ можное, чтобы скрыть резерв времени, который он заложил в свою оценку, и не дать менеджеру лишить его этого резерва. Теперь давайте рассмотрим, что происходит, если дело не доходит до “наихудшего ва­ рианта". Допустим, что в “нормальной" ситуации не возникает никаких неожиданных проблем, и задачи выполняются досрочно. Сколько исполнителей (программистов, раз­ работчиков баз данных или рабочих на заводском кон­ вейере) скажут своему начальнику, что они уже закон­ чили свою работу раньше срока? Исполнитель найдет

тысячу причин, чтобы скрыть это, и не последней из этих причин является боязнь получить взбучку от начальника ( “Ага! Значит, ты действительно раздул свой график! В следующий раз я урежу твою оценку наполовину!”). Этот феномен подчиняется хорошо известному Закону Паркинсона: работа занимает все отведенное для нее время. Такое поведение настолько вошло в привычку, что уже и не считается дисфункциональным, но с точки зрения, которая излагается в данной главе, его никак нельзя считать « рациональным ». Перед тем как перейти к обсуждению рациональ­ ного поведения, рассмотрим другую дисфункциональ­ ную реакцию на описанную выше ситуацию. Если все исполнители представят наихудшую оценку времени выполнения по всем задачам, а затем будут тщательно ее придерживаться, то проект, скорее всего, завер­ шится гораздо позже намеченного срока. И если ме­ неджер проекта или заинтересованные лица, перед которыми он отчитывается, это поймут, то их реакция будет вполне предсказуемой: они просто урежут гра­ фик, чтобы добиться своевременного завершения проекта. Это урезание на “ глобальном" уровне аук­ нется на всех индивидуальных заданиях, и каждый ис­ полнитель может услышать следующее: “Да, я знаю, что твоя “умеренная” оценка для этой задачи состав­ ляет 10 дней, но мы вынуждены урезать график на 20% , чтобы выполнить проект в обещанный срок. Хотя я понимаю, что это не совсем справедливо, но не могу дать тебе больше 8 дней” . Предположим, что начальная оценка исполнителя (10 дней) была тщательно рассчитана, и он имеет ос­ нование сказать своему менеджеру, что вероятность выполнения задачи за 10 дней составляет 99%. Это замечательно, однако вряд ли можно предположить, что исполнитель заодно вычислил и вероятность вы­ полнения задачи за 8 дней. И, наверное, он не будет ее вычислять, если ему навязали восьмидневный срок.

оачем, и ф а ш и в а с к -н ,

делан», если у nv,.x>

г

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

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

7.3 Как можно изменить дисфункциональное поведение организации? Изменить такое дисфункциональное поведение не­ просто. В самом деле, оно настолько глубоко укорени­ лось во многих организациях, что это кажется невоз­ можным. Так же, как и борьба с алкоголизмом и

другими подобными явлениями, такое изменения долж­ но начаться с полного, честного и всестороннего осозна­ ния и понимания, что нынешнее поведение дисфункцио­ нально. В условиях современного общества, которое предпочитает мгновенные решения серьезных проблем (например, диетические пилюли для избавления от лиш­ него веса, принимая которые, мы продолжаем поедать огромное количество всякой дряни), это не так просто сделать. Мой коллега Том ДеМарко любит рассказывать ис­ торию о клиентах, которые спрашивают его: “Можно ли сделать только что-нибудь одно для усовершенствования нашей системы управления проектами, и если да, то что именно?” Ответ Тома обычно прост: “ Перестаньте по­ ручать сотрудникам одновременную работу над пятью или шестью не связанными между собой проектами; дайте каждому один проект и оставьте его в покое, пока он его не закончит.” Том утверждает, что слышит в от­ вет одно и то же: “Да, это звучит весьма разумно. Но вам трудно понять, поскольку вы не работали в нашей организации, что мы сталкиваемся с ограничениями А, В и С, вынуждены иметь дело с политическими проблема­ ми X, Y и Z ... поэтому подскажите нам что-нибудь дру­ гое.” Любое предложение, которое вдет вразрез с дис­ функциональным поведением организации, почти всегда отвергается со следующими словами: “Может быть, это и работает в идеальном мире, но в реальном мире этого не будет никогда, потому что X, Y и Z ...” И организация продолжает заниматься поиском “ пилюли" — нового средства разработки, новой методологии системного анализа или чего-нибудь еще суперсовременного, что может принести некоторое облегчение, но не решит глу­ бинные проблемы. Даже если организация согласна с тем, что ее управ­ ление проектами дисфункционально, она может не раз­ бираться в причинах настолько глубоко, чтобы что-то изменить. Это не удивительно, поскольку то же самое

происходит с отдельными людьми. Люди с избыточным весом, злоупотребляющие алкоголем или наркотиками, могут не понимать психологических, физиологических и социальных причин их нынешнего состояния. Могут по­ требоваться месяцы или годы лечения, и не у каждого хватит на это терпения или ресурсов. То же самое справедливо для организаций в целом, особенно по причине сложной динамики их дисфунк­ ционального поведения. В самом деле, до недавнего времени, как было сказано в главе 6, у нас не было даже “языка” для обсуждения таких проблем. Основ­ ные концепции динамики систем известны уже при­ мерно 30 лет, но только в последнее десятилетие были предприняты серьезные усилия (например, изы­ скательская работа Тарика Абдель-Хамида) по их применению в области разработки ПО. К сожалению, этим концепциям и средствам уделяется совсем не­ много внимания, особенно по сравнению с разными любимыми “ пилюлями” нашей отрасли — новыми языками программирования и средствами визуального программирования, новомодными методологиями (RAD, JAD, ХР, 0 0 , UML и др.). В результате дисфункция продолжает здравствовать. Однако в этой книге я не преследую цель справиться с дисфункциональным поведением целой организации, и типичный менеджер проекта тоже не собирается устраи­ вать революцию в своей организации. Его ближайшая задача — выжить и победить в своем безнадежном про­ екте, или, если препятствия окажутся слишком серьез­ ными, найти в себе смелость уйти из проекта. Точно так же жена алкоголика мечтает о решении проблемы алко­ голизма в национальном масштабе, но в первую очередь ей надо помочь своему собственному мужу, а если это невозможно, то найти в себе силы оставить его. Это в некоторой степени противоречит началу данной главы: если мы хотим решить глобальную проблему, этого нельзя сделать, сосредоточившись только на решении

локальных проблем. Но в организации решить глобаль­ ную проблему может только высшее руководство, по­ скольку оно располагает необходимыми ресурсами и полномочиями, а мы говорим о том, что в состоянии сде­ лать менеджер проекта. Менеджеру безнадежного проекта необходимо в пер­ вую очередь определить, все ли в управлении проектами делается так, как надо, и если нет, то можно ли это из­ менить. Если вашу позицию по этому поводу можно сформулировать следующим образом: “Все, о чем гово­ рится в этой главе, — полная ерунда! В нашей компа­ нии планирование, оценка и управление проектами вы­ полняются наилучшим образом!” , то одно из двух: либо это действительно так, и я сошел с ума, либо ваша орга­ низация настолько дисфункциональна, что вы этого даже не осознаете. В любом случае вы можете пропус­ тить оставшуюся часть этой главы и попытаться найти что-нибудь полезное в остальных главах. С другой стороны, допустим, вы полностью согласны с наличием беспорядка в управлении проектами и счи­ таете, что если вас оставят в покое, то вы сможете на­ вести порядок в своем проекте. Тогда можно столкнуть­ ся с более простой проблемой: как добиться, чтобы “ они” оставили вас в покое? Под словом “они” я подра­ зумеваю тех людей, которые плетут нити заговора, что­ бы ввергнуть вас и ваших подчиненных в хаос. Это мо­ жет быть ваш непосредственный начальник, кто-то из высшего руководства, блюстители чистоты методологии, отдел кадров, конечные пользователи, заинтересован­ ные лица проекта или вообще кто угодно в вашей ор­ ганизации. В любом случае весь фокус в том, как оградить себя и свою команду от окружающего беспорядка. По-моему, именно в этом причина популярности “ка­ бинетов скунса", т.е., маленьких изолированных отде­ лов, функционирующих самостоятельно и без контро­ ля начальства. Проектная команда может просто тихо

и незаметно исчезнуть из офиса и перебраться в ка­ кой-нибудь пустующий склад на окраине города. Аль­ тернативным вариантом в современном мире комму­ никаций может быть работа на дому с еженедельными (или ежедневными) встречами в местной пивной. Еще один вариант — работа в ночную смену. Если проект длится не более полугода, то, может быть, это не слишком отразится на личной жизни сотрудников, и бюрократы не сразу поймут, куда испарилась вся команда. К сожалению, что бы я здесь ни предлагал, обычный ответ умного, добропорядочного и искреннего менедже­ ра проекта таков: “Да, это звучит замечательно, и в иде­ альной ситуации я определенно попытался бы сделать что-нибудь подобное. Но в реальности ничего не выйдет, потому что вице-президент по разработкам устроит ис­ терику, мы получим выговор от отдела кадров, возник­ нут политические проблемы X, Y и Z ..." И дисфункция по-прежнему продолжает здравство­ вать.

7.4 Жизнь в разумном мире В дальнейшем изложении будем исходить из пред­ положения, что вам каким-то образом удалось создать островок здравомыслия в океане хаоса, бушующем вокруг. Какие стратегии управления вам хотелось бы реализовать? Каким должен быть ваш “разумный мир”? Перед тем как углубиться в детали, поговорим о не­ которых философских аспектах такого разумного мира. По мнению Роберта Ньюболда [5], они сводятся к четы­ рем постулатам:

1. Мы располагаем методами планирования и логистики, которые защищают нас от дей­ ствия Закона Мерфи.

2. Люди концентрируют свои усилия на гло­ бальных усовершенствованиях в большей сте­ пени, чем на локальных. 3. Все понимают и принимают политику, процедуры и оценки, которым они подверга­ ются. 4. Мы верим, что сможем добиться значи­ тельного прогресса.

Все перечисленное, безусловно, очень важно само по себе. Однако мы вынуждены вынести детали этих поло­ жений за рамки нашего обсуждения и оставить знаком­ ство с замечательной книгой Ньюболда на ваше усмот­ рение. Что касается первых двух положений из списка Нью­ болда, мы уже приводили рекомендации по этому пово­ ду. Вместо того чтобы поощрять каждого исполнителя скрывать свой резерв времени на случай возможных не­ приятностей, нам следует добиваться составления тако­ го графика, в котором досрочное завершение работы и опоздание были бы равновероятны. В простейшем проекте, состоящем из единственной линейной последо­ вательности задач, можно рассчитывать, что время, сэкономленное в досрочно выполненных задачах, ком­ пенсирует потери времени в задачах, выполненных с опозданием. В более сложных (и реалистичных) ситуа­ циях этого недостаточно, нам нужен резерв времени, чтобы защититься от разных непредвиденных ситуаций и от “глобального” проявления Закона Мерфи (самые сложные и критически важные задачи всегда выполня­ ются с опозданием). В разделе 7 .5 мы увидим, что такой резерв можно запланировать, сохранить и использовать только по мере необходимости. Таким образом, некоторые локальные задачи могут завершиться позже намеченного срока, а другие — раньше. Чтобы вся эта схема работала, нужно поощрять исполнителей завершать свою плановую работу как можно раньше и не придумывать несуществующую ра-

ооту. Самый лучший вариант — сразу после заверше­ ния своих задач поручать исполнителям новые задачи, а все, кто ожидал завершения, смогут начать свою работу. В реальности не всегда можно точно предсказать про­ должительность выполнения задач, поэтому приходится устраивать перекуры. Хотелось бы, чтобы наше поведение в разумном мире опиралось на честное признание невозможности дать точные ответы на сложные и нечеткие вопросы. Если кто-либо просит вас оценить время выполнения слож­ ной задачи, с которой вы никогда раньше не сталкива­ лись, то бессмысленно отвечать следующим образом: «Я определил, что потребуются три дня, один час и че­ тыре минуты, и вероятность выполнения на минуту раньше или позже составляет 50% .» В зависимости от степени вашей уверенности и честности перед самим со­ бой и вашим менеджером, ответ может быть таким: «Я определил, что потребуется около трех дней, и веро­ ятность выполнения на день раньше или позже состав­ ляет 50% » или даже таким: «потребуется около недели, и вероятность выполнения на неделю позже или раньше составляет 50% .» (Последнее означает наличие мизер­ ной вероятности немедленного завершения задачи почти сразу после ее начала, если вдруг будет найдено какоенибудь гениальное решение.) Элия Голдрат утверждает [2], что стратегия менедже­ ра проекта должна базироваться на “теории ограниче­ ний” , которую иллюстрирует рис. 7.1. Важно понимать, что ограничение, упомянутое в первом блоке на рис. 7.1, может и не быть таким же очевидным и понятным, как сложная задача програм­ мирования. Оно может быть связано с дефицитом или отсутствием ресурса (например, разработчика баз данных, нового оборудования или просто помещения для совещаний команды), или политикой организации, тормозящей продуктивную работу. Все ограничения нужно идентифицировать, использовать в своих целях

Рис. 7 .1 Последовательность применения теории ограничений

и постоянно отслеживать, и заниматься этим должен не только менеджер проекта, но и все участники про­ ектной команды.

7.5 Метод критических последовательностей Когда дисфункциональное поведение организации осознано и менеджер проекта идентифицировал основ­ ные ограничения, нужно сформировать график проекта, содержащий критические последовательности. Состав­ лению графика предшествует планирование и расчеты.

которые могут быть довольно объемными. Для их авто­ матизации существуют специальные пакеты, например ProChain (ProChain Solutions, Inc., ) и Concerto (Reali­ zation Technologies, ). Планирование методом критических последователь­ ностей начинается с традиционной идентификации тре­ буемых задач, ресурсов и зависимостей, аналогично по­ строению сетевого графика PERT. Самым важным моментом является идентификация критической после­ довательности (critical chain): самого длинного по вре­ менной продолжительности пути проекта с учетом воз­ можных ресурсных ограничений и усилий, требуемых для выполнения задач. Если в начальном варианте графика существует конфликт ресурсов (т.е. один и тот же ресурс требует­ ся одновременно для двух и более задач), то он дол­ жен быть разрешен до выбора критической последо­ вательности (с помощью переупорядочения задач). (Если ресурсные ограничения отсутствуют, то началь­ ная критическая последовательность совпадает с из­ вестным “ критическим путем” сетевого графика, для построения которого используются такие средства, как Microsoft Project.) После этого может быть разра­ ботан начальный план/график, который базируется на обсуждавшихся выше оценках типа “50-50”: вместо пессимистической оценки дается оценка с равноверо­ ятным досрочным завершением и опозданием. При необходимости в конец графика помещается резерв, позволяющий справиться с разными непредвиденными обстоятельствами. На рис. 7.2 показано начало кри­ тической последовательности с тремя задачами (обо­ значенными своими ресурсами X, Y и Z), за которыми следует резерв. X

Y

Z

резерв

Рис. 7.2 Начало критической последовательности

Разумеется, даже в простом проекте помимо крити­ ческой последовательности могут быть другие “ потоки” задач. Более сложный вариант нашего графика может выглядеть так, как на рис. 7.3.

Рис. 7.3 Более реалистичный график

Предположим, что критическая последователь­ ность — это основное наше ограничение, и мы должны сделать все необходимое, чтобы его соблюсти. Эта по­ следовательность на рис. 7.3 связана с двумя рисками. Так, в верхней части рис. 7.3 видно, что ресурс Y занят в то же самое время, что и ресурс X на критической по­ следовательности. Нужно, чтобы ресурс Y оказался сво­ бодным для работ критической последовательности, как только закончится ресурс X, значит, нам нужно иметь ресурсный резерв. Аналогично, поток задач в нижней части рис. 7.3 “входит” в критическую последовательность как раз пе­ ред началом работы ресурса Z. Чтобы минимизировать риск задержки его работы, нужно поместить резерв “входа” в конец нижнего потока. Уточненный график приведен на рис 7.4. Как однажды сказал генерал Эйзенхауэр: “План — ничто, планирование — все”. План на рис. 7.4 может выглядеть реалистичным в начале проекта, но его обя­ зательно нужно отслеживать в течение проекта. В тер­ минах графика менеджер проекта может использовать

Рис. 7.4 График с резервами

резервы как основные средства для соблюдения всего графика в целом. Если для спасения безнадежного про­ екта необходимо чем-то пожертвовать, то надо действо­ вать, исходя из рассмотренных ранее соображений при­ оритетности и “достаточно хорошего” ПО.

7.6 Заключение Работа Голдрата [4], связанная с планированием методом критических последовательностей, уже не яв­ ляется такой новой и радикальной, какой она была в конце 1980-х и начале 1990-х. К настоящему времени этот метод широко используется рядом крупных и авторитетных промышленных компаний. Однако в ин­ дустрии ПО о нем мало кто знает: менеджеры проек­ тов знакомы только с Microsoft Project и традицион­ ным планированием. Я сделал всего лишь краткий обзор теории ограниче­ ний и метода критических последовательностей. Этого, конечно, мало, чтобы вы могли использовать их в следую­ щем проекте без дополнительного изучения. Тем не ме­ нее, я надеюсь, что этого достаточно, чтобы разжечь ваш аппетит и, по крайней мере, побудить более серьезно за­ думаться о непродуктивности или даже дисфункциональности культуры планирования и управления проектами

в вашей организации. Если это так, то вы можете обра­ титься к источникам, приведенным в библиографии, а также воспользоваться полезными ресурсами Интернета, такими, как Web-сайт Фрэнка Патрика “ Focused Perfor­ mance” ( www.focusedperformance.com) и форумы на cmsig@lists. apics. org, [email protected]. com и [email protected]. Самое важное, что мы можем сделать, — это осо­ знать, что определенная организационная культура гу­ бит безнадежные проекты еще до того, как они начнут­ ся. Вице-президенты корпораций и заинтересованные лица проектов могут согласиться с таким утверждением, но только внешне, а вести себя они будут по-прежнему, несмотря на все свои добрые намерения. Настоящее по­ нимание, и не внешнее, а глубокое, возникает у менед­ жера безнадежного проекта и его команды, потому что именно они работают по 80 часов в неделю, страдают от язвенных болезней, и именно их карьера зависит от ус­ пеха проекта. Если вы — менеджер проекта, то вряд ли сможете изменить корпоративную культуру вашей организации. Однако, если вы осознаете, в чем выражается дисфунк­ циональное поведение организации, сумеете изолиро­ вать от этого самого себя и свою команду (по крайней мере, на время выполнения проекта) и сможете хотя бы в небольшой степени воспользоваться методами, кото­ рые были описаны в этой главе, то ваши шансы на успех могут значительно возрасти.

Библиография 1. Eliyahu Goldlratt. The Goal. North River Press, 2nd Revision edition, 1992. 2. Eliyahu Goldlratt. Theory of Constraints. North River Press, 1999. 3. Eliyahu Goldlratt. It’s Not Luck. North River Press. 1994.

4. Eliyahu Goldlratt. Critical Chain. North River Press, 1997. 5. Robert C. Newbold. Project Management in the Fast Lane: Applying the Theory of Constraints. St. Lucie Press, 1998. 6. Lawrence P. Leach. Critical Chain Project Management. Artech House, 2000. 7. Peter Senge. The Fifth Discipline. Doubleday, 1990.

ГЛАВА 8

УПРАВЛЕНИЕ РАБОЧИМ ВРЕМЕНЕМ

В безнадежном проекте приходится иметь дело с ограниченными ресурсами — временем, рабочей силой, финансами, компьютерами и даже офисными помеще­ ниями. Ограничения по некоторым ресурсам диктуются только политическими решениями, которые можно из­ менить. Например, с согласия основных действующих лиц можно привлечь в проект дополнительных сотруд­ ников, увеличить его бюджет и найти хорошее помеще­ ние для работы. Однако время невозможно ни купить, ни остановить. Если час потерян, то это уже навсегда. В то время, как в нормальном проекте график может иметь достаточный резерв времени, чтобы компенсировать потерянные часы, дни или даже недели, безнадежный проект не мо­ жет позволить себе такой роскоши. Для менеджера без­ надежного проекта эффективное использование рабо­ чего времени является критически важным. Это никак не затрагивает проблему сверхурочной работы. Независимо от того, сколько часов в неделю ра­ ботают участники проекта (40 или 80), они должны эф­ фективно использовать это время. Это, конечно, не означает, что сотрудники должны носиться по офису с безумным взглядом или печатать 100 слов в минуту на клавиатуре. На самом деле, в этой главе предлагаются доста­ точно простые и ясные вещи. Мне приходилось ви­

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

8.1 Влияние корпоративной культуры на управление рабочим временем К сожалению, многие менеджеры проектов, следуя глубоко укоренившейся практике и привычкам корпора­ тивной культуры, совершенно не обращают внимания на потери времени. Безнадежный проект, может быть, не самый лучший повод для культурной революции, но ме­ неджер проекта может хотя бы на время отказаться от нормальных ежедневных ритуалов, на которые уходит много времени. Один из наиболее известных подобных ритуалов — это совещания. Во многих организациях совещания обычно начинаются на 15— 30 минут позже установлен­ ного срока, поскольку (а) все предполагают провести первые 15— 30 минут, общаясь друг с другом; (б) в на­ чале совещания подаются освежительные напитки и кофе и за ними выстраивается длинная очередь; (в) ини­ циаторы совещания опаздывают на 15 минут, потому что их предыдущее совещание закончилось на 15 минут поз­ же; (г) начальник опаздывает, и никто не берет на себя смелость начать совещание без него. Еще больше помех в работе создает организация, в которой собирается совещание, чтобы обсудить некото­ рый вопрос, затем тратится целый час на бесконечное обсуждение деталей и вопросов, которые могли быть ре­ шены любым из присутствующих до начала совещания, и наконец, вырабатывается решение — вернуться к тому же самому обсуждению на следующем совещании чеоез неделю. Иногда это происходит потому, что участ-

ники совещания не желают брать на себя ответствен­ ность и предпочитают принять временное решение, что­ бы иметь возможность отказаться от него через неделю. А может быть, одного или двух участников совещания не устраивает первоначальное решение, и они рассчиты­ вают, что при повторном рассмотрении смогут его изме­ нить. Это только два примера потерь времени из-за неэф­ фективной организации совещаний, их можно привести гораздо больше. Важно, что мы не считаем участников совещаний ленивыми, некомпетентными или неоргани­ зованными; просто такое поведение отражает корпора­ тивную культуру. Вряд ли она изменится в ходе безна­ дежного проекта, если только проект не охватывает всю организацию и возглавляется ее руководителем. Для большинства безнадежных проектов наиболее прагма­ тичной стратегией будет дипломатичное лавирование, а не прямая конфронтация. Поэтому менеджер проекта может сказать своей команде: “Я знаю, что мы обычно начинаем наши совещания с распевания гимна компа­ нии, поедания разных домашних сладостей и разгляды­ вания последних фотографий своих детей, но боюсь, что в этом проекте нам придется отказаться от этих удоволь­ ствий” . В этой книге я не собираюсь учить вас, как эффек­ тивно организовывать и проводить совещания; на Web-сайтах Amazon или Barnes & Noble можно найти уйму таких книг. В большинстве случаев достаточно простых вещей: иметь четкую цель и повестку дня для каждого совещания, начинать совещание вовремя, не позволять уводить дискуссию в сторону от темы, пре­ кращать бесконечные повторы одних и тех же вопро­ сов и аргументов, четко фиксировать намечаемые действия в конце каждого совещания и заканчивать совещание вовремя, чтобы сотрудники не опоздали на следующее совещание.

8.2 Отставание от графика из-за разногласий между заинтересованными лицами Как было сказано в главе 2, безнадежные проекты нередко провоцируют разногласия между основными за­ интересованными лицами. Обычно это случается в нача­ ле проекта при обсуждении бюджета, сроков и распре­ деления ресурсов, но может произойти и в ходе проекта, когда документируются детальные функциональные тре­ бования, обсуждаются критерии приемочного тестиро­ вания или детали прототипа пользовательского интер­ фейса. В одном из возможных сценариев развития событий заинтересованные лица могут просто “махнуть рукой” на проект, согласившись с тем, что он будет продолжаться без документированных требований, интерфейсов, кри­ териев приемки, которые настолько неопределенны и абстрактны, что программистам надо дать возможность самостоятельно “додумать" все детали. Другой возмож­ ный сценарий — заинтересованные лица все отвергают и ни с чем не соглашаются. Проект становится похо­ жим на продолжительную осаду, когда оба противника окопались и время от времени швыряют друг в друга гранаты. Тем временем менеджер может обнаружить, что про­ ект забуксовал. Пока не будет подписан договор с по­ ставщиком оборудования, не поставляется никакого оборудования; пока заинтересованные лица не примут решение по спорным аспектам функциональных требо­ ваний, невозможно разработать прототип. Между тем, часы продолжают тикать, а срок завершения проекта никто не отменял. Наилучшее решение данной проблемы — это акцен­ тировать на ней внимание всех основных заинтересован­ ных лиц в самом начале проекта. Конечно, они все кивнут головой и выразят формальное согласие по пово­

ду важности скорейшего решения основных вопросов, дабы не ввергнуть проект в состояние паралича. Вы мо­ жете пойти дальше и настоять на принятии положения, согласно которому все вопросы, требующие согласова­ ния и утверждения, рассматривались не более 24 часов. Скорее всего, в ответ вы услышите сплошное хмыканье, бормотание и отговорки типа «да, мы бы очень-очень хотели уложиться в 24 часа, но это совершенно невоз­ можно». В конце концов, люди заняты, они могут уйти в отпуск, отправиться в путешествие, нужно посещать другие совещания и т.д., и т.п. Тогда, если утвердить такое положение не удается, то остается только документально оформлять и вывеши­ вать на доску объявлений сведения об отставании от графика по причине несвоевременного принятия важ­ ных решений. Поскольку заинтересованные лица почти никогда не допускают изменения официально утвер­ жденного срока завершения проекта, эти сведения должны иметь следующую форму: “Несмотря на офици­ ально утвержденный срок завершения, вы сорвали при­ нятие решения, не ответив на мой запрос в течение 24 часов, поэтому проект задержится на один день. Та­ ким образом, вместо сдачи системы к 10 октября, как было указано в моем последнем отчете, она переносится на 11 октября”. Иногда существует объективная причина задержки в принятии решения — например, заинтересованные лица могут ждать решения своих юристов или государст­ венных органов. Но это ничего не меняет по существу: если выполнение плана зависит от важных решений, ко­ торые должны приниматься в ограниченное время (это все можно наглядно продемонстрировать на сетевом графике или графике Гантта), то, независимо от причи­ ны задержки, последствия будут одинаковыми. (Разуме­ ется, может оказаться, что решение не связано с “кри­ тическим путем”, но в большинстве случаев это не так.) Мой опыт показывает, что большинство задержек не

имеет никакого отношения к внешним обстоятельствам, которые неподвластны заинтересованным лицам; наобо­ рот, они возникают из-за политических разборок внутри компании. Конечно, менеджер проекта может быстро получить распоряжение прекратить публично вывешивать свои малоприятные записки. По крайней мере, он должен фиксировать задержки как ключевые факторы риска для всего проекта, поскольку, если проект потерпит неудачу, все заинтересованные лица проявят удивительную за­ бывчивость относительно проблем, которые они сами создали. На самом деле, серьезные проблемы такого плана могут заставить менеджера хорошенько подумать, стоит ли вообще участвовать в таком проекте. В конце концов, если заинтересованные лица ведут себя безответственно и не выполняют свои обязанности по отношению к про­ екту, то почему должна болеть голова у менеджера и его команды? Во многих ситуациях поведение высшего ру­ ководства и основных заинтересованных лиц можно предсказать заранее, поскольку оно определяется кор­ поративной культурой. Если у менеджера проекта возникает ощущение проблемы, то имеет смысл провести небольшой экспе­ римент, пока его официально не назначили на роль “капитана Титаника” : например, направить основным заинтересованным лицам сообщение следующего содер­ жания: “Перед тем, как я приму назначение, мне необ­ ходимо знать, буду ли я иметь право запрещать назначе­ ние специалистов из других подразделений в мою проектную команду” . Если в течение 24 часов все недву­ смысленно ответят “да” или “нет", то это уже хорошо. Но если половина заинтересованных лиц вообще не от­ ветит, а остальные скажут, что им надо обсудить этот вопрос на совещании у руководства в следующем меся­ це, то вероятнее всего остальные важные решения так­ же будут откладываться на неопределенное время.

8.3 Как повысить эффективность использования рабочего времени проектной команды В дополнение к тому, что было сказано, я полагаю, что менеджер проекта может внести значительный вклад в его успех, если поможет участникам своей команды более эффективно использовать рабочее время. Хорошие и традиционные идеи по этому пово­ ду можно найти в книге Стивена Кови [1]. Кови реко­ мендует располагать задачи по приоритетам в двумер­ ной системе координат, осями которой являются срочность и важность задач (рис. 8.1). Все задачи разбиваются на четыре квадранта: Q1 (высокая важ­ ность, высокая срочность) — первоочередные жиз­ ненно важные задачи; Q2 (высокая важность, низкая срочность) — регулярные задачи планирования, орга­ низации и анализа, сопровождающие предыдущие; Q3 (низкая важность, высокая срочность) — разные срочные отвлечения, ответы на почту, телефонные звонки; Q4 (низкая важность, низкая срочность) — непродуктивная потеря времени. За прошедшее десятилетие мы научились избавлять­ ся от большинства задач Q4 в течение рабочего дня; мы оставляем их на вечер, когда сидим перед телевизором с бокалом вина. Однако типичный рабочий день перепол­ нен задачами Q3, которые могут вытеснять задачи Q2. Задачи Q1 невозможно проигнорировать, поскольку промедление с их выполнением “смерти подобно". Но

Рис. 8.1 Расположение задач по срочности и важности

никто специально не настаивает на выполнении задач Q2, поскольку со стороны их выполнение выглядит как пустая трата времени и потому не приветствуется. Как часто возникают задачи Q3? Утверждают, что ти­ пичный директор по маркетингу Интернет-компании по­ лучает ежедневно от 80 до 100 сообщений по электрон­ ной почте, от 100 до 150 телефонных звонков, от 20 до 25 сообщений голосовой почты, от двух до трех записок, и встречается с 10— 12 людьми. Получается около 300 отвлечений за день, и если каждое отвлечение занимает 2 минуты, это означает 10-часовой рабочий день без перерывов. Хотелось бы посмотреть на того, кто в со­ стоянии справиться с этим бешеным валом, и у него еще осталось бы время на анализ и планирование. Команды ГГ-проектов зачастую работают в подобной среде, и менеджеры могут помочь им, научив различать срочность и важность. Например, нужно фильтровать почтовые сообщения. Я завел в своей почтовой про­ грамме 4 папки, обозначил их Q l — Q4 и накопил посте­ пенно около тысячи фильтров, которые автоматически распределяют приходящую почту по папкам. При этом уничтожается большая часть спама, сообщения от по­ сторонних и назойливых попадают в Q3 или Q4, а менее 109& сообщений, требующих немедленного ответа, по­ падают в Q 1. Существует вполне практичная стратегия, позволяю­ щая справиться с отвлечениями в виде сообщений элек­ тронной почты: не отвечать на них вообще. Все зна­ ют, что вы заняты, и, вероятно, понимают, что вы получаете сотню сообщений в день, поэтому отсутствие немедленного ответа вряд ли будет воспринято как умышленное оскорбление. И если отправитель “срочно­ го” сообщения не поинтересуется через несколько дней, почему вы до сих пор не ответили, то, наверное, это со­ общение было не таким уж важным. Менеджер может также научить своих сотрудников заранее планировать рабочую неделю. Самое лучшее —

это последовать совету Тома ДеМарко из его новой кни­ ги [2] и запланировать небольшой резерв времени в те­ чение недели. Мы можем даже посоветовать участникам проектной команды отвести специальное время, чтобы положить ноги на стол и поразмыслить о своей работе. По крайней мере, разработчики должны уделять задачам Q2 столько времени, сколько они заслуживают, а не от­ влекаться постоянно на задачи Q3. Это важно, посколь­ ку планирование и анализ помогают избежать серьезных проблем, связанных с задачами Q1. Все это может показаться чересчур оптимистичным. В конце концов, участие в безнадежном проекте застав­ ляет постоянно крутиться, чтобы успеть справиться со всеми задачами за ограниченное время. Вероятно, одной из наиболее важных задач менеджера является постоян­ ное напоминание участникам своей проектной команды, чтобы они, получая очередное “сверхважное” сообще­ ние от заинтересованного лица или конечного пользова­ теля, делали минутную паузу. Эта пауза нужна, чтобы спросить себя: “Да, я знаю, что это сообщение срочное, но насколько оно действительно важно? И если я отло­ жу его на час, день или неделю, как это отразится на моем графике и задачах?”

Библиография 1. Stephen R. Covey. First Things First. Fireside Books, 1996. 2. Tom DeMarco. Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. Bantam Books, 2001.

ГЛАВА 9

УПРАВЛЕНИЕ И КОНТРОЛЬ ЗА ПРОДВИЖЕНИЕМ ПРОЕКТА

Безусловно, очень важно в самом начале проекта договориться с требовательными заказчиками относи­ тельно реалистичных сроков и бюджета, сформировать проектную команду, определить необходимые рабочие процессы и процедуры. К сожалению, некоторые менед­ жеры проектов полагают, что это самая трудная часть работы и после того, как она сделана, все пойдет гораздо легче. В безнадежных проектах можно наблюдать два яв­ ления, неизбежность которых сравнима со смертью и сбором налогов. Во-первых, несмотря на тяжесть пере­ говоров и скептицизм заинтересованных лиц, оценки графика, бюджета и количества разработчиков получа­ ются чересчур оптимистичными. Причем не просто оп­ тимистичными, скажем, на 10%, а оптимистичными до истерики — на 50% , 100% или 1000%. Причины этого уже обсуждались в начале книги — наивность и не­ опытность, переговоры, граничащие с запугиванием и принуждением, и т.д. Реальные последствия этого исте­ рического оптимизма зачастую становятся очевидными только к середине проекта. Во-вторых, случаются всякие неприятности. Они случаются и с хорошими людьми, несмотря на все их благие намерения, или, как грубовато выразился персо­ наж Тома Хэнкса в фильме “Ф оррест Гамп", “Shit happens'' (в мягком варианте — проблемам свойствен­

но возникать. — Прим. пер.). Управление и контроль за продвижением (иначе говоря — прогрессом) безнадеж­ ного проекта — это срочная и важная работа, отнимаю­ щая много времени; ее нельзя игнорировать или зани­ маться от случая к случаю. Именно это самая важная обязанность менеджера проекта после завершения всех тяжелых переговоров в начале проекта. Чтобы преуспеть в этой деятельности, менеджер про­ екта должен уметь отличать реальный прогресс от “ка­ жущегося” прогресса. Многие менеджеры проектов давно усвоили, что синдром “выполнено на 90% ” явля­ ется опасной иллюзией, и они знают, что в безнадежном проекте не менее опасно утверждать “мы выполнили анализ и проектирование на 100%, но еще не закончили написание кода и не тестировали его” . Практичной и эф­ фективной альтернативой это дилемме является прин­ цип “ежедневной сборки” ( “daily build” ).

9.1 Принцип ежедневной сборки” В дискуссии по поводу прототипирования, контроль­ ных точек и мини-этапов неявно подразумевалось, что очередные результаты, получаемые проектной коман­ дой, появляются через интервалы, измеряемые месяца­ ми или неделями. К этому большинство из нас приучил прежний опыт “нормальных” проектов, и это согласует­ ся с обычным темпом деловой жизни — например еже­ недельными совещаниями персонала, ежемесячными отчетами о состоянии работ, ежеквартальными презен­ тациями для высшего руководства и т.д. Однако безнадежные проекты нуждаются в другом подходе. Когда проект приходит к прототипированию и пошаговой разработке, работу над ним надо органи­ зовать на основе принципа “ежедневной сборки” . Под этим подразумевается следующее: компиляция, сбор­ ка, установка и тестирование всей совокупности раз­ работанного командой кода должны выполняться ка­

ждый день, как если бы этот день был последним

перед завершением проекта и на следующее утро было бы необходимо сдать законченную систему поль­ зователям. Разумеется, реалии таковы, что с первого дня невоз­ можно приступить к ежедневной сборке. Правда, уже на второй день работы можно написать подпрограмму типа “ Hello, World", и трудно сегодня удивить кого-то совер­ шенно новыми технологиями (в частности, многие из проектов, использующих Java, во время написания этой книги уже находились в процессе разработки). Однако существуют определенные требования, которым должна удовлетворять версия прототипа системы при первой “официальной” демонстрации: помимо того, что она включает необходимую совокупность компонентов, про­ цедур или модулей и несколько сотен, а может быть и тысяч строк кода, она должна выполнять реальный ввод данных, производить реальную обработку или вычисле­ ния и формировать реальный выход. Именно с этого мо­ мента следует начинать ежедневную сборку и формиро­ вать каждый день новую (желательно улучшенную) версию системы. Почему это так важно? Как любит говорить Джим Маккарти, менеджер продукта Microsoft Visual C + + и автор книги Dynamics of Software Development [9]: “Ежедневная сборка — это биение сердца проекта. Она дает знать, что жизнь продолжается”. Для менеджера проекта подобная стратегия может быть приоритетом номер один. Если в течение недели никто не сможет со­ общить менеджеру проекта, что разрабатываемое ими клиент-серверное приложение не хочет правильно взаи­ модействовать с новой замечательной объектно-ориен­ тированной базой данных, то в результате проект может безнадежно отстать от графика. До тех пор, пока менед­ жер судит о состоянии проекта по устным отчетам, за­ пискам или диаграммам потоков данных, будет слишком легко перепутать движение с прогрессом и усилия с ре­

зультатами. Однако, если менеджер проекта настаивает на ежедневной физической демонстрации результатов, будет нелегко скрыть возникающие трудности, кото­ рые в конечном счете могут способствовать провалу проекта. Некоторые менеджеры проекта будут кивать голова­ ми и подтверждать, что они всегда именно так и поступа­ ют, однако большинство согласится с тем, что они довольствуются еженедельным, ежемесячным или полу­ годовым контролем реализации системы. В то время как вряд ли кто-нибудь вправе претендовать на “изобрете­ ние” данного подхода, многие знают, что он впервые стал популярным во время разработки операционной системы Windows NT (интересную дискуссию на эту тему можно обнаружить в описании данного проекта, приведенном в [10]). Любопытно также отметить, что при разработке Windows 95 использовался принцип ежедневной сборки; заключительная бета-версия перед выпуском конечного продукта была реализована в авгу­ сте 1995 г. и называлась “ Проект 951” . Важно осознавать, что подобный подход становится неотъемлемой составляющей процесса разработки сис­ темы, которому следует проектная команда. Представь­ те себе, каково быть участником команды, которая должна демонстрировать работающую версию про­ граммного обеспечения 951 день подряд! (Правда, если быть честным, я не уверен, что команда Microsoft дейст­ вительно свято соблюдала такой порядок каждый день. Возможно, что формирование более чем одной версии укладывалось в 24-часовой промежуток и команда могла день или два отдохнуть). Кроме того, процесс ежеднев­ ного завершения работы над проектом должен быть ав­ томатизированным и выполняться ночью без участия программистов, отправившихся домой спать. Тогда он будет эффективным. Такой подход подразумевает нали­ чие автоматизированного управления конфигурацией ПО и механизмов управления исходными кодами, а так­

же разнообразных “скриптов” для выполнения компи­ ляции и сборки приложений. Но что еще более важно, он подразумевает наличие системы автоматизированно­ го тестирования, которая может работать всю ночь, вы­ полняя гору тестов для проверки работоспособности системы. Таким образом, чтобы реализовать на практи­ ке принцип ежедневной сборки, необходимо иметь в своем распоряжении адекватный набор средств и техно­ логий (см. главу 10). Действие данного принципа может дополнительно усилить ряд следующих мер: • Менеджеру проекта следует переместить свой офис к месту разработки и тестирования системы, как только начнется процесс ежедневной сборки. Так поступил Дейв Катлер в Microsoft. Рассказы­ вают страшные истории, как он метал громы и молнии, когда появлялся в офисе и обнаруживал, что сборка очередной версии в полночь накры­ лась. Важно, чтобы менеджер был почти всегда на випу и непосредственно участвовал в ежеднев­ ном процессе, а не уподоблялся генералу, кото­ рый получает ежедневные сводки с поля боя, на­ ходясь в глубоком тылу. • Поскольку вполне вероятно, что ночной про­ цесс ежедневного формирования версии потре­ бует минимального человеческого вмешатель­ ства, будет полезно установить следующий порядок: любой программист, допустивший ошибку в коде, которая привела к аварийному завершению ежедневной сборки, удостаивается высокой чести наблюдать за очередной сборкой, пока не появится следующая жертва. Разумеет­ ся, такой порядок имеет как плюсы, так и мину­ сы, но по крайней мере благодаря ему команда “ближе” знакомится с принципом ежедневной сборки.

• Поручите одному из программистов, которым обычно приходит в офис рано утром, проверять успешность завершения ежедневной сборки и вывешивать результаты на видное место. Если ни у кого нет желания или возможности появ­ ляться в офисе так рано, наймите студента. В одной компании студенту велели поднимать над офисом флаг, чтобы предупреждать сотруд­ ников, какой день ожидается: зеленый флаг означал успешное завершение процесса еже­ дневной сборки, а красный — аварийное завер­ шение.

9.2 Управление рисками Хотя ежедневная сборка весьма эффективна с точки зрения мониторинга продвижения безнадежного проек­ та, она не слишком помогает справиться со многими серьезными проблемами. Важно понимать семантиче­ ское различие между тем, что некоторые менеджеры на­ зывают “issue” (вопрос, незначительная проблема, по­ добная комариному укусу), и рисками (подобными укусу гремучей змеи). Комариные укусы раздражают, но толь­ ко в очень редких случаях могут быть опасными для здо­ ровья, а укус гремучей змеи требует незамедлительных действий по спасению человеческой жизни. Если бы понятие “ риска” не было столь критическим, тогда мы не употребляли бы по отношению к проекту определение “безнадежный” . Интересно отметить, что один из вопросов “теста на алкоголь” , упоминаемого в разделе 5.5, связан с идентификацией проектных рис­ ков. И, если ответом на такой вопрос со стороны менед­ жера “нормального” проекта может быть удивленный взгляд (даже если проект оказался в плачевном состоя­ нии), то менеджер безнадежного проекта даст четкий и ясный ответ. Менеджер был бы просто глупцом, если бы приступил к безнадежному проекту, не имея серьез­

ного представления об основных рисках и о том, как с ними бороться. Увы, но в ходе работы над проектом ситуация может выйти из-под контроля. Это происходит потому, что управление рисками строится в основном на эмоциях и инстинктах, а не на формальных процессах, и менеджер в процессе работы зачастую может вовремя не заметить появление новых рисков. В лучшем случае риски, оче­ видные в самом начале проекта, будут устраняться. В нормальной ситуации они являются поводом для бес­ покойства в течение всей работы над проектом (напри­ мер, риск ухода ключевого разработчика). Однако не­ ожиданно могут возникнуть совершенно новые риски, которые окажутся убийственными для проекта. Если дискуссию относительно рисков разработки ПО вы считаете чересчур раздутой или вообще не от­ носящейся к делу, можете смело переходить к сле­ дующей главе. Меня больше всего заботит менеджер проекта, который успешно завершил несколько “нор­ мальных” проектов, справляясь с рисками на интуи­ тивном уровне; такой подход в безнадежном проекте обычно не работает. На самом деле, существуют эф­ фективные формальные процессы управления риска­ ми, позволяющие предпринимать безнадежные проек­ ты, которые в противном случае наверняка стали бы самоубийственными. Об управлении рисками написано много книг, их об­ зор не является предметом данной книги. Необходимую информацию вы можете получить из первоисточников [ 1— 6], хотя важно остерегаться, чтобы “служба управ­ ления рисками” не похоронила проект под формами, от­ четами и другими бюрократическими штучками. Напри­ мер, некоторые менеджеры безнадежных проектов следуют очень простой практике идентификации и мони­ торинга десяти основных рисков проекта; их можно от­ печатать на одной странице и еженедельно проводить оперативный анализ их состояния.

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

Команда безнадежного проекта преследует в основном тактические цели; она пытается не изменить культуру организации, а всего лишь выжить и нормально закон­ чить проект. Тем не менее, могут возникнуть некоторые пробле­ мы, связанные с культурой организации. Такое часто происходит в случае, если существует мнение, что в других проектах риск отсутствует, и данный проект — это первый, последний и единственный безнадежный проект, когда-либо имевший место в организации. Про­ блема заключается в том, что проектная команда не на­ ходится на необитаемом острове; если бы это было так, то можно было бы решить все вопросы, “убрав вестни­ ка” , который докладывает о проблемах руководству. С другой стороны, как отмечает Роб Чарет [2], основ­ ные причины провалов проектов часто кроются в среде, окружающей проект. Это либо среда самой организа­ ции, либо внешняя среда (см. рис. 9.1). Менеджер про­ екта может и не подозревать о наличии этих “внешних" рисков, пока они не обрушатся на проект. Разумеется, верно и обратное: проект порождает риски, которые могут воздействовать на среду организа-

Рис. 9.1 Область действия проектных рисков

ции и внешнюю среду, и об этом знает каждый. В самом деле, менеджер проекта не должен забывать, что его безнадежный проект может подвергнуть опасности всю организацию — если не цивилизацию и всю вселен­ ную! Менеджеры, которые жалуются, что их команда трудится над завершением проекта всего лишь 127 ч в неделю, зачастую находятся в блаженном неведении от­ носительно происходящего у них под носом, что может привести к крушению проекта. Поэтому столь важно использовать формальные про­ цессы управления рисками, с помощью которых можно оценить проектные риски по различным аспектам дея­ тельности организации и попытаться отыскать золотую середину между ними. В конце концов то, что проекти­ ровщику и разработчику ПО кажется риском, департа­ ментом маркетинга может рассматриваться как благо­ приятная возможность. Такой подход к “глобальному” управлению рисками очень важен. Однако в работе над безнадежным проектом мне приходилось встречаться с ним не так часто, как хотелось бы. У проектной команды не хватает времени, энергии или политического влия­ ния, чтобы пытаться изменить культуру организации с помощью внедрения глобального процесса управления рисками. Следовательно, отсутствие такого процесса в организации само по себе становится риском, который команда должна оценить. Оценка риска выполняется обычно путем оценок сложности разрабатываемой системы или продукта, а также клиентской среды и среды проектной команды. Сложность продукта можно оценить в терминах объема (например, количества функциональных точек), ограни­ чений производительности, технической сложности и т.д. Риск, связанный с клиентской средой, определяется в основном такими факторами, как число пользовате­ лей, вовлеченных в проект, их уровень квалификации, значение разработки для пользовательского бизнеса, вероятность того, что внедрение новой системы (если

оно произойдет) приведет к реорганизации или даунсайзингу и т.д. Наконец, риск, связанный со средой проект­ ной команды, зависит от ее способностей, опыта, морального состояния и физического/эмоционального здоровья. Как правило, достаточно полная модель риска может включать сто или более факторов риска. Как отмечено ранее, некоторые проектные команды сознательно ограничиваются рассмотрением десяти наиболее суще­ ственных. Некоторые из рисков можно оценить количе­ ственно — например требования к производительности (скорости реакции системы) или объем системы, выра­ женный в количестве функциональных точек. Другие факторы (например, степень расположенности или вра­ ждебности пользователей) могут быть оценены только качественно. Такие факторы принято характеризовать значениями “высокий” , “низкий” или “средний". После того, как риски подверглись идентификации и оценке, менеджер и команда могут выбрать подходящую стратегию минимизации или исключения по возможно­ сти большего числа рисков. Эта деятельность носит, ко­ нечно, общий характер. Однако не следует забывать: сама природа безнадежного проекта такова, что количе­ ство рисков превышает обычное, они более серьезны, и от них нельзя просто так избавиться. С другой стороны, если риски являются экстраординарными, то и решения должны быть адекватными: в то время как проектная команда “нормального” проекта может никогда не на­ браться смелости, чтобы обратиться к исполнительно­ му директору или первому вице-президенту с просьбой уменьшить риск путем существенного увеличения бюд­ жета или снятия серьезных бюрократических ограниче­ ний, участникам безнадежного проекта будет вполне ра­ зумным обратиться с такой просьбой. Если вы этого не сделаете (а для этого вам придется посетить начальни­ ков разных уровней), вы никогда и не узнаете, удалось бы вам решить ваши проблемы или нет.

d jir ju u m

случае, если сущ ествую т серьслгши т .......

ры риска, воздействие которых исключить невозмож­ но — а в безнадежных проектах почти всегда так оно и есть, — их следует зафиксировать в специальном доку­ менте, идентифицировав для каждого риска возможные последствия и разработав план действий в непредвиден­ ных ситуациях. Это не будет чисто политическим “при­ крытием задницы”. Поскольку, если риск повлечет за собой провал проекта, то последствия, как правило, бу­ дут печальными для всех, имеющих отношение к работе. В конце концов, таковы реалии безнадежных проектов. Тем не менее, отрицание реальности — довольно рас­ пространенное явление в безнадежных проектах. Участ­ ники проектной команды, пользователи и руководители различных уровней часто оказываются близорукими и игнорируют существование серьезных проектных рис­ ков. Вполне можно ожидать, что менеджер проекта и участники команды будут уделять особое внимание “внутренним” рискам; .забывая о внешних рисках, по­ скольку они связаны с проблемами организации и биз­ неса, неподвластными команде. Таким образом, доку­ ментирование рисков является важной практической деятельностью, подталкивающей пользователей и руко­ водство к пониманию того, что они предпочитали не за­ мечать и игнорировать. До сих пор речь шла в основном об управлении рис­ ками, но важно также понимать значение управления проблемами (issue management). Хотя не все риски имеют фатальные последствия и высокую вероятность, их все же лучше рассматривать как “укусы гремучей змеи”; их нужно избегать всеми силами, но если уж они случились, то нужно действовать немедленно, чтобы не умереть. С другой стороны, проблема подобна комари­ ному укусу: он раздражает и беспокоит, но не представ­ ляет угрозу для жизни. Однако если вас покусает целый комариный рой, в котором есть еще и носители инфек­ ции, это может вызвать серьезное заболевание.

Все это предполагает, что у менеджера безнадежного проекта недостаточно времени, энергии и ресурсов, что­ бы всерьез заниматься предотвращением незначитель­ ных проблем. Однако их нужно идентифицировать, от­ слеживать и со временем решать. Наконец, ими нужно управлять, поскольку сегодняшняя проблема может превратиться в завтрашний риск. Например, на ранней стадии проекта один из разработчиков может заметить: “Хм, я думаю, что кто-то был обязан заказать средство тестирования, однако, мы его до сих пор не получили. Оно определенно понадобится нам через пару месяцев, когда мы будем готовы к серьезному тестированию”. Очевидно, это замечание нужно внести в “журнал проблем” и отслеживать. В противном случае, если че­ рез пару месяцев средство тестирования не появится и резерва времени не будет, то может произойти катаст­ рофа. Существуют специальные программные продукты от­ слеживания проблем с возможностями автоматического извещения и распространения информации. Они входят в категорию полезных средств, которые будут рассмат­ риваться в главе 10. Для большинства небольших про­ ектов и проектов среднего размера вполне достаточно простой электронной таблицы или базы данных Access. Технология не так важна, как сама дисциплина создания списка проблем и их постоянного отслеживания.

9.3 Дополнительные способы мониторинга продвижения проекта: периодические оценки Менеджеры проектов традиционно использовали се­ тевые графики и графики Гантта для планирования про­ движения своих проектов. Они пытались разбить весь проект на набольшие задачи с “двоичным" результатом (т.е., либо “ выполнено” , либо “не выполнено”) и кон­

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

При этом нужно обратить особое внимание на нефор­ мальные экспертные оценки и доступность их результа­ тов для всех активных участников проекта. Этой теме посвящен ряд хороших книг, например [7, 8]. Самое важное — избегать бюрократического стрем­ ления крупных организаций к сохранению результатов всех оценок для “ посмертного” разбора проекта. В та­ ком разборе основные участники проектной команды вместе с представителями различных групп (Финансы, Обеспечение качества. Совершенствование процессов, Обучение) определяют, принес ли на самом деле проект те выгоды, которые были обещаны, в рамках запланиро­ ванного бюджета. “ Посмертный” разбор определяет также уроки, извлеченные из проекта, чтобы помочь высшему руководству в распределении полномочий и бюджета будущих IT-проектов, и в равной степени по­ мочь менеджерам проектов и разработчикам лучше вы­ полнять их собственную работу. Насколько полезны такие “ посмертные” разборы для высшего руководства — это вопрос спорный. Неудачи многих безнадежных проектов “прячутся под сукно”, а быстрая смена высших руководителей делает шансы на извлечение уроков из проектов мизерными. Для менед­ жеров проектов и разработчиков тоже мало толку от таких разборов, поскольку в большинстве компаний ключевые решения, влияющие на успех или неудачу проектов, принимаются людьми, которые успевают ис­ чезнуть из компании до завершения проекта. И хотя их решения могут быть документированы, вряд ли в этой документации можно найти причины принятых решений. В свое время рассматривались различные альтернати­ вы, оценивались компромиссные решения и риски, но когда через год или два происходит «посмертный» раз­ бор, вся эта информация обычно уже недоступна. Уцелевшие участники последних стадий проекта обычно испытывают слишком сильное нервное истоще­ ние и усталость, чтобы писать мемуары наподобие гене­

ралов или бывших президентов. А если даже они -ми дс лают, кто их читает? Когда вы в последний раз слышали, как менеджер проекта говорит своей команде: “ Пока мы не начали работать, пожалуйста, потратьте несколько дней на чтение “посмертных” отчетов последних 25 про­ ектов нашей Acme Widget Corp. После этого мы прове­ дем совещание и обсудим, какие из этого уроки можно извлечь для нашего проекта". Решение этой дилеммы совсем простое и может при­ нести реальную пользу для текущего проекта: нужно проводить небольшие разборы по завершении каждой стадии проекта, или каждого прототипа, или каждой очередной версии системы, поставляемой заказчику. В зависимости от конкретного проекта это означает, что разбору подвергается работа, выполненная в течение пары недель или месяцев, поэтому большинство основ­ ных игроков еще участвуют в проекте и, скорее всего, помнят, что они делали и почему. Такой разбор можно провести на одном совещании за несколько часов вместо привычного “посмертного" разбора в конце проекта, ко­ торый продолжается несколько дней или недель. Мно­ гие проектные команды считают, что презентацию поль­ зователям нового прототипа или версии системы нужно планировать в пятницу с утра, затем отправиться отме­ чать это дело в ближайшее питейное заведение, после чего нетвердой походкой вернуться в офис на послеобе­ денный разбор, потом пойти домой и отоспаться за вы­ ходные, вместо того, чтобы сразу браться за следующую версию системы. В идеальном случае уроки, извлеченные из таких не­ больших разборов, помогают в первую очередь самим участникам проекта, а не абстрактному сообществу бу­ дущих разработчиков. “Посмертные” разборы в конце проекта порождают разные общие фразы типа “Привле­ кайте пользователей к участию в проекте”, в то время как результатом небольших разборов, как правило, яв­ ляются обоснованные утверждения, например “Мы чуть

было не провалили эту версию системы, потому что за­ были привлечь Мэри к сбору требований; а Фред из бух­ галтерии очень сильно помог нам в подготовке тестовы> данных для приемки, поэтому его следует еще раньше привлечь к работе над следующей версией”.

Библиография 1. Robert N. Charette. Application Strategies for Risk Analysis. New York: McGraw-Hill, 1990. 2. Robert N. Charette. Software Engineering Risk Analysis and Management. New York: McGraw-Hill, 1989. 3. Tom DeMarco, Tim Lister. Waltzing with Bears: M anaging Risks in Software Projects. Dorset House, 2003. 4. Capers Jones. Assessment and Control of Software Risks. Englewood Cliffs, NJ: Prentice Hall, 1994. 5. Elaine Hall. M anaging Risk: Methods for Software Systems Development. Addison Wesley, 1998. 6. Carole Edrich. Risk Management for e-business. Cutter Consortium Distributed Computing and Architec­ ture/e-business Advisory Service, Executive Report, Vol.

3, No. 12, Dec. 2000. 7. Tom Gilb, Dorothy Graham, Suzannah Finzi. Software Inspection. Addison-Wesley, 1993. 8. Norm Kerth. Project Perspectives: A Handbook for Team Reviews. Dorset House, 2001. 9. Jim McCarthy. Dynamics of Software Development. Redmond, WA: Microsoft Press, 1995. 10. G. Pascal Zachary. Show-Stopper! New York: Free Press, 1994.

ГЛАВА 10

ТЕХНОЛОГИЯ И ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА БЕЗНАДЕЖНЫХ ПРОЕКТОВ

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

такой ответ, я спросил, какое средство типичная проект­ ная команда считает наиболее важным? “ На днях я задал одной из проектных команд такой же вопрос”, — ответил один из менеджеров. “Как вы ду­ маете, что они ответили?” “Какой-нибудь высокопроизводительный компилятор C + + ? ” , — спросил я. “Ассемблер? Или мощное сред­ ство отладки для устранения множества ошибок в их коде (хи-хи-хи)?” “ Ничего подобного”, — ответил менеджер, игнори­ руя мое гнусное хихиканье. “Они ответили: электрон­ ная почта. Средний разработчик Microsoft получает сотню сообщений в день; он живет в электронной поч­ те. Уберите электронную почту, и проект умрет”. Рассказывая этот анекдотический случай, я неспро­ ста в самом начале упомянул 1992 г. События происхо­ дили до начала эры Интернета и World Wide Web. Сотня почтовых сообщений в день потрясла мое воображение; в 1992 г. я был безумно счастлив, если получал два или три сообщения вдень. Однако можно представить себе, что если бы такой же вопрос о “наиболее важном сред­ стве” был задан в 1996 г., ответом могло быть “World Wide Web” ; по аналогии, “факс” в 1987-м, “ПК” в 1983-м., “онлайновый терминал” в 1976-м и “мой собст­ венный телефон на рабочем столе" в 1964 г., когда я только начинал свою карьеру программиста. Очевидно, не следует ожидать, что команда безна­ дежного проекта сможет ограничиться только одним средством. Большинство команд (даже в “нормальных” проектах) пользуется в своей повседневной работе са­ мыми разнообразными средствами и технологиями. Правда, подчас количество средств становится чересчур большим, технологии — слишком новыми, а иногда не­ желательные средства навязываются им некомпетент­ ными менеджерами. Если вас встревожили эти обстоятельства, позвольте мне уверить вас, что я вовсе не собираюсь агитировать

за использование экзотических, суперсовременных средств, которые, телепатически взаимодействуя с про­ граммистом, преобразуют его беспорядочные мысли в хорошо структурированный код. Напротив, я хочу обсудить понятие “ минимально необходимого набора средств" для безнадежных проектов. Я хочу также обра­ тить особое внимание на критически важные взаимосвя­ зи между средствами и процессами, поскольку процессы в безнадежном проекте, скорее всего, отличаются от тех, которые используются в организации. И, наконец, я хочу предостеречь вас от применения в безнадежном проекте совершенно новых средств.

10.1 Минимально необходимый набор инструментальных средств В главе 5 я настоятельно рекомендовал устанавли­ вать приоритеты для пользовательских требований. Такой же подход используется по отношению к средст­ вам и технологии: существуют средства, которые “необ­ ходимо использовать” , “следует использовать" и “мож­ но использовать” . Подобный подход разумно применить в самом начале проекта, и тому есть ряд причин. Наиболее очевидная причина — экономия средств. Даже если средства хорошо работают и все знакомы с ними, их приобретение может стоить слишком дорого. Кроме того, на их получение может уйти много време­ ни — процесс приобретения их в условиях обычной кор­ поративной бюрократии может завершиться уже после окончания работы над проектом. Для большинства безнадежных проектов следует выбрать небольшое ко­ личество критически важных средств и убедить высшее руководство (или соответствующую службу) в необходи­ мости их приобретения. С другой стороны, предположим, что команда рабо­ тает в крупной корпорации, имеющей в своем распоря­ жении сотни различных средств, приобретавшихся в те­

чение целог о ряда лет. Следует ли их все использовать? Конечно, нет! Даже если все они работают, те умствен­ ные усилия, которые необходимо затратить, чтобы за­ помнить, как ими пользоваться, а также дополнитель­ ные усилия для обеспечения их совместной работы обычно сводят на нет всю выгоду. Можно провести ана­ логию с командой альпинистов, которые собираются штурмовать вершину и пытаются решить, какое снаря­ жение им использовать. Существуют необходимые вещи (палатки, питьевая вода и т.д.); и, если маршрут не слишком сложный, можно взять с собой некоторые но­ вомодные приспособления, о которых написано в альпи­ нистском журнале. Однако, если они собираются штур­ мовать Эверест, им не обойтись без помощи ослов или носильщиков из местных жителей, иначе они будут не в состоянии тащить на спине по 300 фунтов снаряжения на человека. Команда безнадежного проекта должна самостоя­ тельно, независимо от принятых в организации стандар­ тов, решить, какие средства являются необходимыми, а без каких можно обойтись. Меня удивляет подход к без­ надежным проектам в ряде организаций, в которых я побывал. Менеджер жалуется, что все проекты застав­ ляют разрабатывать на C + + (в других организациях в таком качестве может фигурировать Visual Basic или Oracle или что-нибудь еще ...), даже если эта технология совершенно не подходит для него. Чепуха! Пошлите их подальше! Используйте те средства и технологии, в ко­ торых есть смысл! Иначе это можно сравнить с ситуаци­ ей, в которой кто-либо говорит руководителю коман­ ды альпинистов, собирающейся штурмовать Эверест: “Наш комитет решил, что ваша проектная комавда должна взять подробную схему нью-йоркского метро, поскольку в большинстве проектов ее сочли очень по­ лезной” . (Иногда вмешивается политика. В середине 90-х мне приходилось видеть несчастных сотрудников IBM, вынужденных использовать Lotus Freelance вме­

сто PowerPoint и Lotus 1-2-3 вместо Excel, поскольку у них не было никакого желания ввязываться в политиче­ ские баталии. Аналогично, я не хотел бы оказаться в проектной команде Microsoft, которая решила бы при­ мерно в августе 1996 г. использовать Netscape Navigator вместо Internet Explorer.) Очень важно участникам команды прийти к единому мнению относительно используемых в проекте средств, иначе наступит хаос. Разумеется, это утверждение не следует понимать буквально; оно не означает, что все участники команды должны обязательно использовать один и тот же текстовый процессор для подготовки сво­ их документов, хотя, скорее всего, важен один и тот же компилятор C + + . Одна из проблем, связанных с безна­ дежными проектами, заключается в том, что разработ­ чики ПО считают допустимой полную анархию на индивидуальном уровне (например, если им хочется ис­ пользовать никому не известный компилятор C + + , ко­ торый они переписали с университетского Web-сайта, то они считают это своим неотъемлемым правом). Но это не так: неотъемлемым правом обладает команда, и менеджер проекта должен неуклонно проводить его в жизнь во всех ситуациях, когда несовместимые средства могут привести к значительным разногласиям. Следовательно, пока участники команды не порабо­ тают вместе над несколькими безнадежными проектами, они не придут к единому мнению относительно “ мини­ мального" набора средств. Определив набор средств, команда выбирает те; которыми “следует” пользоваться. При этом возникает еще одна проблема — добиться со­ гласия в команде и получить разрешение руководства на приобретение новых средств. Менеджер проекта должен настаивать на достижении консенсуса; в самом деле, это может быть одним из кри­ териев, используемых менеджером для выбора потенци­ альных участников команды. Отметим, что то же самое можно сказать относительно процессов, которые мы об­

суждали в главе 5. Далее мы увидим, что это имеет еще большее значение, поскольку средства и процессы тесно связаны друг с другом. Помня обо всех высказанных предостережениях, практически невозможно для такого “дилетанта”, как я, с ходу перечислить все средства, рекомендуемые для безнадежного проекта. Мой ответ на такой вопрос — “ все зависит от... ” . Это обычный подход консультанта, стремящегося уходить от прямого ответа на любой во­ прос. Итак, поскольку вы крепко запомнили мои преды­ дущие советы, познакомьтесь с перечнем средств, кото­ рые я рекомендую для безнадежных проектов:

• Элект ронная почта, П О для групповой ра­ боты, средства Internet/Web, видеоконфе­ ренции и т.д. — так же, как и в эпизоде с

Microsoft, эти средства находятся в начале мое­ го списка. Причина заключается в следующем: электронные средства общения и взаимодейст­ вия являются не только более эффективным средством коммуникации, чем записки и факсы, но они также способствуют координации и со­ трудничеству. Мне безразлично, какие именно средства использовать: Microsoft Outlook или Lotus Notes; важно только, чтобы вся команда работала в сети и хранила там общие проектные данные. Помимо этого, существуют и другие хо­ рошие новые средства, но они скорее относятся к категории “следует использовать”, а не “необ­ ходимо использовать” .

• Средства прототипирования/быстрой раз­ работ ки прилож ений (R A D ) — почти все без­

надежные проекты используют в той или иной степени прототипирование и пошаговую разра­ ботку; следовательно, им необходимы соответ­ ствующие инструментальные средства. Сегодня не так просто отыскать популярную среду раз­

работки приложений, которая заявляла бы о себе иначе, чем среда RAD. Большинство таких средств обладают визуальным пользователь­ ским интерфейсом, выполненным в стиле “drag and drop”, облегчающим и ускоряющим процесс разработки. Я не берусь давать общие рекомен­ дации, какие средства лучше использовать — Delphi, C + + , Visual Basic или Java (или множе­ ство других). Важно только, чтобы вся команда использовала один и тот же набор средств от од­ ного и того же поставщика. Если часть команды использует среду разработки Java компании Sun, а другие — Microsoft Visual J + + , то это явно глупо, хотя и допустимо с точки зрения технологии. • Средства управления конфигурацией (С М )/ версиями — некоторые из моих коллег полага­ ют, что они должны быть на первом месте в списке. Джон Бодди, автор Crunch Mode, вы­ сказал такое мнение: Я хотел бы отметить, что средства управления конфигурацией действительно *необходимо использовать ”. По мере разра­ ботки будет возникать множество нестыко­ вок между отдельными частями проекта, по­ этому менеджер и команда нуждаются в средствах, позволяющих фиксировать и от­ слеживать версии системы по мере продвиже­ ния к завершению проекта.

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

том в его пользу. Аналогично, многие другие средства раз­ работки приложений интегрированы с PVCS от InterSolv или другими подобными средствами СМ. Средства тестирования и отладки — многие из нас автоматически включают эти средства в “базовый” на­ бор средств разработки приложений, позволяющих со­ здавать, компилировать и выполнять код Однако, когда мы перешли от онлайновых приложений на мэйнфрей­ мах к клиент-серверным системам с графическим поль­ зовательским интерфейсом, то постепенно поняли, что необходим совершенно новый набор средств тестирова­ ния. В то же время средства таких поставщиков, как Rational Software и Mercury Interactive, еще не получили достаточного распространения в тех организациях, где мне удалось побывать. Проектные команды, разрабаты­ вающие приложения в среде Интернета, скорее всего нуждаются в полностью новых средствах тестирования и отладки.

• Средст ва управления проектом (оценка, планирование, P E R T / G A N T T и т.д.) — обыч­

но их считают средствами менеджера проекта и, наверное, так оно и есть; возможно, только ме­ неджеру проекта приходится каждый день пере­ считывать “ критический путь” . Однако к той же категории следует отнести такие средства оценки, как ESTIM ACS от Computer Associa­ tes (автор — Говард Рубин), CHECKPOINT от Software Productivity Research и SLIM от Quantitative Software Management. Эти средст­ ва являются важными, поскольку позволяют в ходе выполнения проекта динамически пере­ сматривать планы и сроки.

• Наборы повт орно используемых компонен­ тов — если проектная команда знакома с кон­

цепцией повторного использования ПО и рас­ сматривает ее как стратегическое оружие.

позволяющее достичь высокого уровня продук­ тивности разработки, то набор повторно ис­ пользуемых компонентов должен быть в списке тех средств, которые “необходимо использо­ вать” . Это может быть набор компонентов VBX для Visual Basic, компоненты Java компании Sun или библиотека классов БТЬдля C + + . Ра­ зумеется, можно использовать и компоненты, разработанные другими проектными командами в организации. Выбор их обычно зависит от ис­ пользуемого языка программирования, и это еще одна проблема, нуждающаяся в выработке единого подхода со стороны проектной команды. • C A SE -средства для анализа/проектирова­ ния — некоторые проектные команды рассмат­ ривают CASE-средства как “ костыли” для но­ вичков, а другие считают их не менее важными, чем текстовые процессоры. Я сам отдаю пред­ почтение простым, недорогим и гибким CASEсредствам, но избегаю рекомендовать какой-либо конкретный продукт или поставщика, по­ скольку самым разумным ответом на вопрос, какие CASE-средства использовать, будет “это зависит от ...” . В самом деле, как заметил Даг Скотт, может вообще не понадобиться никакой технологии: Самое лучшее средство — это большая диаграмма, приколотая к стене. Она может содержать (частично полные) E R -диаграммы, потоки данных или что-нибудь другое. Важно то, что она служит отправной точкой для об­ суждения проектных решений и почти не тре­ бует затрат.

Как я говорил ранее, самая большая проблема, свя­ занная с CASE-средствами, заключается в том, что онн

поддерживают (а иногда навязывают) определенную ме­ тодологию, которую проектная команда не понимает и не желает использовать.

10.2 Средства и процессы Упомянутая выше проблема CASE-средств, вероят­ но, представляет собой наиболее очевидный пример трюизма: средства и процессы связаны друг с другом сложным образом. Бессмысленно браться за объектноориентированное CASE-средство, поддерживающее анализ, если вы никогда не слышали об иерархии клас­ сов или диагра!#мах вариантов использования. Исполь­ зование такого CASE-средства будет не только беспо­ лезным, но и чрезвычайно обременительным, если проектная команда искренне полагает, что диаграммы классов представляют собой лишенные смысла формы бюрократических документов, преследующие единст­ венную цель: чтобы блюстители методологии могли при­ крыть свои задницы. Но ситуация не всегда бывает черно-белой. Напри­ мер, проектная команда считает, что диаграммы потоков данных полезны, но только как “ неформальное” средст­ во моделирования. Таким образом, “гибкое” CASEсредство может рассматриваться как нужное и полез­ ное, в то время как “жесткое” CASE-средство может быть отвергнуто. Проведем аналогию с текстовым про­ цессором: мы все способны оценить достоинства опера­ ции проверки орфографии, но не хотим, чтобы нас за­ ставляли ее использовать. Вполне вероятно, что мы ее никогда не применяли, поскольку проверка орфографии осуществляется слишком медленно (по крайней мере, это мое мнение). Мы еще больше раздражаемся, если текстовый процессор настойчиво отвергает слово “ain’t" как ошибочное, или требовать, чтобы любые фразы, со­ держащие высказывания расистского или женоненави­ стнического характера, утверждались специальным ко­

митетом. Нескольких таких “замечательных" свойств может оказаться достаточно, чтобы вынудить нас вер­ нуться к бумаге и карандашу. Все это означает, что команда безнадежного проекта должна в первую очередь нормально воспринимать те процессы и методологии, которым она собирается сле­ довать. Кроме того, она должна решить, каким из них надо подчиняться беспрекословно, а каким — следовать духу, но не букве закона. После принятия такого реше­ ния можно соответственно выбрать (или отвергнуть!) средства и технологию. Таким же образом менеджер проекта может решить использовать какое-либо средст­ во для усиления процесса, необходимость которого все понимают, но на практике следуют ему достаточно не­ брежно; примеры таких процессов — контроль версий и управление конфигурацией. Один из величайших мифов, касающихся использо­ вания инструментальных средств в любых проектах (и особенно опасных в безнадежных проектах), заклю­ чается в отношении к средству как к “серебряной пуле” , которая позволит творить чудеса. Разумеется, поиском чудес занимается в основном высшее руководство. Од­ нако даже менеджера проекта могут соблазнить реклам­ ные заявления поставщика, уверяющего, что с помощью его гениальных средств можно в десять раз повысить производительность программирования, тестирования или какой-нибудь другой деятельности. Помимо проблемы, заключающейся в новизне таких средств и в неумении их использовать (о чем будет гово­ риться ниже), существует более важный момент: сред­ ство станет подобным “серебряной пуле” только в том случае, если оно позволит разработчиков изменить свои процессы или заставит их сделать это. Например, если я пишу программу, а затем компилирую ее, я делаю это в соответствии с определенным процессом. При этом про­ граммированию может предшествовать процесс сквоз­ ного контроля или тщательного формального проекти­

рования. Теперь, если вы дадите мне компилятор, который работает на 10% быстрее, чем предыдущий, это облегчит мою работу и сделает ее эффективнее. Но мне не придется менять свой процесс. С другой стороны, если мне дадут компилятор, кото­ рый работает в десять раз быстрее, то он изменит мой процесс. Так произошло, когда мы перешли в 70-е годы от ночной пакетной компиляции к онлайновой, в 80-е годы к компиляции на собственных ПК и рабочих стан­ циях. Затем мы работали с различными сочетаниями по­ шаговой компиляции (а ля Delphi) и интерпретации (а ля Visual Basic). Вследствие этого многие разработ­ чики отказались от тщательного проектирования, пред­ шествующего кодированию. При этом они руководство­ вались тем, что смогут писать программы на ходу и импровизировать в процессе кодирования. Во многих проектах они отказались от практики сквозного кодиро­ вания, полагая, что программист и так сможет быстро обнаружить и исправить свои ошибки. Едва ли кто-нибудь станет возражать против исполь­ зования усовершенствованных технологий, позволяю­ щих избавляться от рутинных и утомительных процес­ сов. Труднее внедрить новую технологию, требующую введения новых процессов или модификации сущест­ вующих процессов, к которым мы привыкли. Хорошим примером служит процесс повторного использования и связанная с ним технология библиотек повторно ис­ пользуемых компонентов, браузеров и других средств. Проектные команды, работающие с подобной техноло­ гией, могут повысить уровень повторного использования кода приблизительно от 20% (уровень, который я назы­ ваю “случайным” ) до 60% и более; разумеется, если технология применяется в масштабе всей организа­ ции, то уровень повторного использования может быть 80— 90% и более. Разница между 20%-ным и 80%-ным уровнем по­ вторного использования эквивалентна четырехкратному

постепенное последовательное повышение уровня по­ вторного использования приносит больше выгод, чем можно было бы ожидать. Если уровень повторного ис­ пользования возрастает с 80 до 90% , это означает, что вместо разработки “с нуля” 20% кода проектной коман­ де придется разрабатывать только 10%. Таким образом, их загрузка снизится вдвое. Все это замечательно и вполне достойно называться “серебряной пулей” . Однако это совершенно бесполез­ но, если проектная команда (и вся организация) окажет­ ся неспособной или не пожелает менять свои процессы в соответствии с требованиями технологии повторного использования. Ирония заключается в том, что боль­ шинство организаций в своих провалах винит техноло­ гию. Они приобретут дорогостоящую библиотеку клас­ сов или поменяют свою старую методологию разработки ПО на объектно-ориентированную методологию, исходя из предположения, что объекты и повторное использо­ вание — это одно и то же. Обнаружив, что не добились сколько-нибудь ощутимых результатов, они будут ви­ нить во всем объектную технологию, библиотеку клас­ сов, поставщика и др. Между тем, все процессы оста­ лись в точности такими же, какими были до внедрения новой технологии. Культура такой организации может быть выражена следующей фразой: “Только бездари пользуются чужим кодом; настоящие программисты, черт возьми, пишут свой!” С точки зрения работы над безнадежным проектом мораль проста: если внедрение новых средств потребует серьезного изменения “стандартных” процессов коман­ ды, то это значительно увеличит риск и, возможно, будет способствовать провалу проекта. Необходимость обуче­ ния и освоения практического использования новых средств (они будут обсуждаться ниже) создает дополни­ тельные проблемы. Однако наиболее серьезной из них является изменение режима работы, который целиком

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

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

Иногда можно встретить проектную команду, добиваю­ щуюся разрешения использовать какое-либо мощное средство, с которым она уже имела дело в предыдущей работе. Однако это редкое явление. В большинстве слу­ чаев никто из участников проектной команды и вообще никто в организации никогда прежде не видел или не ис­ пользовал подобное средство. Как отмечалось раньше, любое нетривиальное сред­ ство обычно предъявляет жесткие требования к соот­ ветствующим процессам: новое средство обычно подра­ зумевает новый процесс. Хотя такая зависимость очевидна, поразительно то, что часто представители по­ ставщика, занимающиеся обучением, после пятидневно­ го семинара по использованию средства обнаруживают, что сотрудники так ничего и не поняли в процессах, под­ держиваемых данным средством. Чрезвычайно неприят­ но провести два дня, объясняя лишенному какого-либо энтузиазма студенту, как рисовать ER-диаграммы, и за ­ тем услышать от него вопрос: “Между прочим, а что та­ кое сущность? Поскольку я собираюсь программировать все на C + + , зачем мне вся эта чепуха?” Предположим, что участники команды разбираются в процессах, поддерживаемых (или автоматизируе­ мых) данным средством, и готовы с энтузиазмом ис­ пользовать его в практической работе. Правда, мой 25-летний опыт преподавания структурных и объект­ но-ориентированных методов говорит о том, что такое предположение наивно и бессмысленно продолжать обсуждение этой проблемы. Итак, если мы предполо­ жим, что не существует никаких проблем, связанных с данным средством, тогда все, что остается — это обучение и практика. Как много времени на это потребуется? Очевидно, это зависит от характера и сложности средства, а также от его пользовательского интерфейса, возможностей онлайновой подсказки и др. В лучшем случае разработ­ чики могут самостоятельно разобраться в использова­

нии средства. В такую возможность ужасно хочется верить менеджеру проекта и разным другим руководите­ лям, поскольку они считают любое обучение потерей времени и отвлечением от “ работы” над проектом. Бо­ лее реалистичная оценка заключается в том, что на ос­ воение средства потребуется час, день или неделя. Не­ зависимо от формы обучения (занятия в классе, чтение книги или просто “ игры” со средством) на это все равно потребуется какое-то время. Однако в результате недельного обучения мы не получим опытного пользователя, в совершенстве вла­ деющего средством. Это должно быть очевидным, од­ нако нарушает планы высшего руководства, которые склонны ворчать и возмущаться: “Хорошо, мы потра­ тили кучу денег на этих высокооплачиваемых препо­ давателей и напрасно потеряли столько времени в классах, чтобы эти ленивые бездельники-программи­ сты могли научиться кодировать. Теперь мы хотим увидеть реальную отдачу от этого “замечательного” средства, за которое вы так агитировали!” Наверное, в такой наивности высшего руководства нет ничего удивительного, поскольку они сами практически не сталкивались с инструментальными средствами; одна­ ко, к сожалению, мне приходилось наблюдать похо­ жую реакцию со стороны многих менеджеров безна­ дежных проектов, гораздо лучше разбирающихся в технических вопросах. В интересной статье [4] мой коллега Мейлир ПейджДжонс утверждает, что в разработке ПО существуют семь ступеней мастерства. Статья сосредоточена в ос­ новном на методологиях, но я думаю, что она в такой же степени применима к средствам и технологиям. К спис­ ку, приведенному ниже, я добавил свои собственные оценки, касающиеся времени достижения разработчи­ ком средней квалификации различных ступеней мастер­ ства, предполагая, что средство или технология облада­ ют средней сложностью:

Таблица 10.1

Семь ступеней мастерства в разработке ПО 1. Наивный новичок. Никогда не слышал о технологии X (очевидно, для этого не требуется никакого времени). 2. Осведомленный разработчик. Прочел статью о технологии X (в большинстве случаев разработчику ПО достаточно одного часа, чтобы разобраться в общих чертах и высказать свое мнение о пре­ имуществах и недостатках средства, даже если он никогда его не видел или не использовал). 3. Начинающий разработчик. Посетил пятидневный семинар (неде­ ля, возможно, сжатая до двух дней ввиду того прессинга, под кото­ рым находится безнадежный проект. Следует отметить, что при этом разработчик, скорее всего, успел всего лишь поработать с ком­ пьютерными руководствами, предоставленными поставщиком, или пробежаться по небольшим примерам, иллюстрирующим возможно­ сти средства. Ему не пришлось столкнуться с какими-либо пробле­ мами и недостатками средства, у него не было возможности мас­ штабировать средство (если это вообще возможно) для больших и сложных проектов; он не пытался интегрировать средство с боль­ шинством остальных средств в данной среде). 4. Практикующий разработчик. Готов использовать технологию X в реальном проекте (по-видимому, достаточно месяца, чтобы в ос­ новном постичь все нюансы использования средства и быть вполне готовым к его применению в “реальном" проекте). 5. Квалифицированный разработчик. Постоянно использует техно­ логию X в своей работе и очень недоволен, если по какой-то причи­ не лишается этой возможности (для достижения такого уровня обычно требуется 6-12 месяцев, и если средство действительно по­ добно “серебряной пуле", то разработчик превращается в проповед­ ника и пытается всеми способами убедить каждого, что это средст­ во — самое замечательное в мире). 6. Мастер. Усвоил все детали технологии X; знает, как обходить ее правила (на это требуется два или три года, это также означает, что разработчик прошел через две или три новые реализации продукта, познакомился со всеми пользовательскими сообществами в Интерне­ те, знает все отсутствующие в справочниках номера телефонов спе­ циалистов по технической поддержке в организации поставщика). 7. Эксперт. Пишет книги, выступает с докладами на конференциях, ищет способ распространить технологию X на другие галактики (Пейдж-Джонс в своей статье говорит о методологиях, поэтому это не совсем применимо по отношению к средствам и технологии).

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

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

Библиография 1. Michael Schrage. No More Teams! Mastering the of Creative Collaboration. New York: Doubleday-Dell Publishing Company, 1995. 2. Paul G. Basset. Framing Software Reuse: Lessons from the Real World. Upper Saddle River, NJ: Prentice Hall, 1996. 3. Bo Leuf, Ward Cunningham. The Wiki Way: Quick Collaboration on the Web. Reading , MA: Addison Wesley, 2001. 4. Meili'r Page-Jones. The Seven Stages in Software Engineering. American Programmer , July-August 1990. Dynamics

ГЛАВА 11

ИМИТАТОРЫ И “ВОЕННЫЕ ИГРЫ”

11.1 Введение Ранее я затрагивал вопросы обучения проектной команды новым процессам и средствам. Но традицион­ ное обучение подразумевает методологии, процессы, ин­ струменты и технологии, с которыми команда разработ­ чиков незнакома. Но каким образом можно научить “опыту” участия в безнадежном проекте? Как научить справляться со стрессами и кризисами? И как насчет способности менеджера проекта заваливать один проект за другим, не ощущая никаких реальных последствий от сорванных планов, пущенных на ветер средств и “пере­ горевших” программистов? Короче говоря, почему бы не попытаться имитировать ход безнадежного проекта, чтобы менеджер проекта и участники команды смогли подготовиться к реальному проекту? Когда в 1996 г. готовилось первое издание этой кни­ ги, такие вопросы считались не просто спорными, а крайне радикальными и нереалистичными. Напрашива­ ются аналогии с другими профессиями: на своих семина­ рах я просто спрашиваю участников, хотели бы они от­ правиться в полет на самолете, пилот которого ни разу не тренировался на тренажере. Да, конечно, пилоты чи­ тают учебники и занимаются в классах, они обязательно летают на настоящих самолетах с опытными инструкто­ рами. Но они также проводят много часов на тренаже-

pax, чтобы научиться правильно вести себя в критиче­ ских ситуациях. И они возвращаются к тренажеру даже после нескольких лет полетов, чтобы отточить свое мас­ терство и освоить новые сценарии. Я еще не встречал никого, кто считал бы такие тренировки напрасной тра­ той времени и денег. Весной 2003 г., когда готовилось второе издание кни­ ги, идея “имитаторов” стала гораздо более знакомой и широко используемой. Например, мы видели в новостях репортажи о военных играх перед вторжением в Ирак; в следующем разделе мы обсудим военные игры более де­ тально. Мы также видели многочисленные примеры практической учебы, на которой имитировались биоло­ гические, химические и ядерные атаки террористов. Мы все надеемся, что 11 сентября 2001 г. никогда не повто­ рится, но если такое все же случится, никто не хотел бы, чтобы пожарные, полиция и скорая помощь оказались неподготовленными к такой ситуации. Как вы, наверное, уже догадались, в данной главе го­ ворится о важности практического обучения IT-профес­ сионалов участию в безнадежном проекте. Если это важно для опытных программистов, разработчиков баз данных и менеджеров проектов, это тем более важно для новых сотрудников организации. Новички — например, выпускники колледжей, которые никогда не занимались разработкой ПО полный рабочий день, — могут и не знать, что безнадежные проекты отличаются от описан­ ных в учебнике (разумеется, исходя из того, что они во­ обще изучали в колледже управление проектами). Разу­ меется, их нужно научить методам, процессам и средствам, которые считаются эффективными в безна­ дежных проектах и существенно отличаются от извест­ ных им старых методов. Ирония, однако, заключается в том, что как только вчерашний новобранец придет в свой первый проект, менеджер проекта велит забыть все, чему его научили, и использовать чисто прагматиче­ ский подход к разработке ПО. Во всяком случае.

новички должны понимать, что процессы и средства без­ надежного проекта выбираются активно и осознанно, а не от безысходности.

11.2 Концепция военных игр Вместо того, чтобы спорить, чем аудиторное обуче­ ние лучше “ поля боя” в безнадежном проекте, я считаю, что IT-организации должны использовать компромисс­ ное решение — имитатор безнадежного проекта. Скептики могут возразить, что такой имитатор не в состоянии воспроизвести тот постоянный цейтнот и на­ пряжение, которые имеют место в реальном проекте. Пилоты авиалиний, использующие свои имитаторы для отработки действий в аварийных ситуациях, будут возра­ жать против такой точки зрения. Однако, если нам действительно необходимо смоделировать стрессовую ситуацию в софтверном проекте, мы можем позаимство­ вать хорошо знакомую тактику из военной области: “во­ енные игры” . Разумеется, фраза “ военная игра” вызывает в во­ ображении военные образы, и это делается намерен­ но. Независимо от вашего мнения по поводу войны и мира, суть дела заключается в том, что военные стра­ теги и преподаватели используют это понятие в самых разных целях: эксперименты с различными стратегия­ ми, борьба с вражескими стратегиями, обучение но­ вобранцев и ветеранов в обстановке, приближенной к боевой. Военные игры использовались в Англии во время Второй Мировой Войны при отработке страте­ гии “Битвы за Англию” , когда ее военно-воздушные силы существенно уступали в численности герман­ ским Люфтваффе. Голливуд тоже увлекся военными играми, это видно по таким фильмам, как ‘Top Gun". Продажу сложных компьютерных военных игр можно отнести к наиболее доходной части игровой индустрии. Настоящие воору­

женные силы не так давно пришли в бизнес военных игр “виртуальной реальности” в Интернете. Один из наибо­ лее известных примеров — сайт , принадлежащий Ар­ мии США. В первые три месяца после его создания летом 2002 г. около 873000 посетителей зарегистриро­ вались как “игроки". К октябрю 2002 г. 520000 зареги­ стрировавшихся получили статус “ прошедших базовое обучение” в армии, что требует от трех до шести часов игрового времени. Подобным образом военная игра по отношению к безнадежным проектам может заключаться в следую­ щем: несколько разных проектных команд получают один и тот же “проектный сценарий” — одинаковые требования, одинаково сжатый временной интервал, одни и те же ресурсы для работы. А если культура без­ надежных проектов в организации еще не получила над­ лежащую формализацию и стандартизацию, предоставь­ те каждой команде возможность использовать любые средства и процессы, которые она захочет, — все, что они смогут выпросить, одолжить или украсть в честной игре. Начиная с 1994 г., Australian Computer Society рассказывает о подобных играх на своих ежегодных кон­ ференциях. Некоторые местные консалтинговые фирмы используют эти игры как часть своего собственного про­ цесса обучения. Чтобы организовать в безнадежном проекте военную игру или любой другой “ имитатор полетов” , необходимо иметь имитационную модель, на которой можно было бы испытать последствия технических и управленческих ре­ шений. Хорошим примером такой модели является мо­ дель Тарика Абдель-Хамнда [1], которая рассматрива­ лась в главе 6. Имитационная модель может быть в принципе реализована на любом языке программиро­ вания, однако для этих целей существуют специали­ зированные языки и средства. Возможно, наиболее из­ вестными из них являются SIM SCRIPT, DYNAMO и G PSS; модель, описанная в книге [1], реализована на

DYNAMO (в приложении к книге приведен полный текст программы). Несколько позже появился ряд средств визуального моделирования, таких, как iThink, большинство из которых достаточно дешевы. Одним из достоинств использования таких моде­ лей, как отмечалось в главе 6, является возможность обсуждения неформализуемых “ мысленных моделей” различных аспектов проекта — морального состояния команды, сверхурочной работы и др. В контексте без­ надежного проекта сценарий военной игры может по­ зволить участникам проектной команды поэкспери­ ментировать со своими мысленными моделями и определить, какие из них работают, а какие нет; это намного дешевле, чем устраивать такую проверку в реальном проекте. Например, я сам однажды провел военную игру, в ко­ торой каждая из соперничающих команд имела девять различных возможностей (в течение трехдневного со­ стязания) для оценки своих собственных результатов и результатов других команд, после чего могла внести из­ менения в свои текущие и будущие “проектные парамет­ ры” , а также в прошлые параметры (т.е. она могла по­ вторить имитацию, начиная с ранних стадий своих проектов, задавая различные размеры бюджета, числен­ ность персонала и решения относительно методологии). Весьма примечательно, что все соперничающие коман­ ды изменяли только один параметр: увеличивали размер годовой премии. (Он действительно часто рассматри­ вался как основной параметр, поскольку размер годовой премии влияет не только на бюджет проекта (можно уд­ ваивать премию каждый год и скоро остаться без денег), но и на текучесть кадров.) Поскольку все команды хоро­ шо понимали, что в непредвиденных ситуациях важно проявлять гибкость, для них оказалось настоящим шо­ ком неспособность использовать данные им безгранич­ ные возможности (вплоть до переписывания собствен­ ной истории).

Одним из наиболее важных свойств имитаторов во­ енных игр является возможность методичного “ проиг­ рывания” значимых событий и решений проекта. По крайней мере, он предоставляет хорошую возможность для дискуссий. Например, организатор военной игры может провести “ посмертный” разбор и сказать: “ По­ смотрите, что произошло в этот момент, когда пользова­ тель внес три или четыре небольших изменения в специ­ фикацию требований. Команда “ красных” приняла изменения без пересмотра графика и бюджета; команда “синих” отказалась вносить изменения и продолжала действовать в соответствии со своим первоначальным планом; команда “зеленых” приняла изменения, но до­ говорилась с пользователем об исключении некоторых первоначальных требований, чтобы уложиться в имею­ щиеся ресурсы. Давайте рассмотрим последствия этих трех различных решений Таким образом, механизм “проигрывания” позволяет экспериментировать с раз­ личными альтернативными решениями. Даже при наличии хороших средств и множества опубликованных материалов невозможно отрицать тот факт, что для создания модели, отражающей среду кон­ кретной компании и предоставляющей руководству воз­ можность проигрывать разнообразные сценарии безна­ дежных проектов, необходимо серьезное отношение к делу и немалые инвестиции. Исходя из своего личного опыта участия в ряде подобных проектов по созданию имитаторов и сценариев военных игр, могу сказать, что на построение адекватной и хорошо настраиваемой мо­ дели требуется несколько человеко-месяцев. В качестве дополнительной иллюстрации интересно отметить, что модель, опубликованная в [ 1], была предметом диссер­ тации Абдель-Хамида. Это означает, что работа лежит за пределами воз­ можностей одного-единственного менеджера проекта, если он хочет использовать такой подход в процессе обу­ чения. Ясно, что эти инвестиции носят стратегический

характер, и ими должна заниматься корпорация в целом, причем вряд ли они под силу небольшой компании из де­ сяти человек. Однако для организации-разработчика, в штате которой работают сотни и даже тысячи человек, такие инвестиции будут весьма скромными. Напомним, о чем идет речь: руководство пытается найти способы утвердить процессы и технологии, которые могли бы обеспечить уверенность в выполнимости планов, бюд­ жетов и функциональности, являющихся вдвое или втрое более претенциозными по сравнению с “нормаль­ ными” проектами. Планируя такие радикальные измене­ ния, руководство зачастую готово затратить огромные суммы денег (в некоторых случаях буквально миллионы долларов ) на оснащение разработчиков новыми рабочи­ ми станциями, средствами визуального программиро­ вания и объектно-ориентированными методологиями. Ворчать по поводу затрат шести человеко-месяцев на разработку имитатора смешно, а лишать свои проект­ ные команды возможности получить опыт на модели безнадежного проекта перед тем, как рисковать миллио­ нами долларов, глупо. Увы, высшее руководство обычно негативно относит­ ся к затратам времени, усилий и средств на любое обу­ чение, а на затраты, связанные с имитацией безнадеж­ ных проектов, посмотрит еще более косо. В результате менеджер проекта вынужден искать “неофициальные” способы, чтобы заниматься имитацией. В идеальном случае этим должны заниматься опытные специалистыпреподаватели, чтобы менеджер проекта не изобретал велосипед. Семинар с военными играми должен продол­ жаться не более трех дней, и в случае необходимости — даже в выходные дни, чтобы корпоративные бюрократы не смогли придраться. К сожалению, все сегодняшние видеоигры и игры “виртуальной реальности” в Интернете впрямую никак не связаны с управлением софтверными проектами. В конце 1990-х появилась замечательная компьютерная

игра “Project Challenge", почти точно соответствующая тому типу военных игр безнадежного проекта, который описан в этой главе, но она ушла в небытие во время спада в области высоких технологий в начале 2000-х. Некоторые консультанты и небольшие софтверные ком­ пании используют средства типа iThink для разработки собственных имитаторов управления проектами. Одной из таких компаний является Exteco (), другие можно отыскать с помощью поисковых машин, используя такие термины, как “ management flight simulator” .

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

рентной борьбе с крупными корпорациями. И, если начинающая компания приходит к выводу, что ее успех полностью обусловлен тактикой ее поведения, то она, вероятно, постарается утвердить такую тактику на бу­ дущее. Разумеется, мои утверждения носят общий характер и существует множество причин, по которым такой под­ ход может не дать никаких результатов. Интересным, например, является тот факт, что ветераны разработки ПО, покидая большие бюрократические корпорации и создавая новые софтверные фирмы, приносят с собой почти все свои привычки и традиции. Но в настоящее время так же, как и в начале моей карьеры, молодое по­ коление разработчиков ПО, очертя голову, бросается в новые проекты, считая 18-часовой рабочий день “отды­ хом” . Однако среди всех происшедших драматических изменений я бы особенно выделил характер и темп ра­ боты, который многие организации в области высоких технологий называют просто “ время Интернета”. Для предыдущих поколений разработчиков ПО такого поня­ тия просто не существовало, оно является одной из серьезных причин, порождающих безнадежные проекты. Независимо от того, принимает ли промышленность безнадежные проекты как норму и насколько успешно справляется с ними ваша компания, факт остается фак­ том — безнадежные проекты выполняются отдельными личностями. Я не возлагаю слишком много надежд, на высшее руководство и бюрократические структуры большинства софтверных организаций, но всерьез бес­ покоюсь о тех людях, которые работают долгими ночами и по выходным над проектами, нередко обреченными с самого начала. Безусловно, важно довести безнадежный проект до успешного завершения, и я надеюсь, что дан­ ная книга дает некоторые практические советы. Однако еще более важно в таком проекте сохранить себя! В лучшем из миров наши безнадежные проекты могут дать замечательные результаты для конечных пользова­

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

Библиография 1. Tarek Abdel-Hamid, Stuart Е. Madnick. Software Project Dynamics. Englewood Cliffs, NJ: Prentice-Hall, 1991. 2. Tarek Abdel-Hamid, S. E. Madnick. Lessons Learned from Modeling the Dynamics of Software Project Management. Comm, of the ACM, Dec 1989. 3. The Management Flight Simulator. John Saunders. http://users.erols.com/jsaun-ders/papers/mfs.htm 4. John A. Byrne. Flight Simulators for Management. Business Week, Sept. 21, 1998, http://www.businessweek. со m/1998/38/b3596135.htm 5. John D. Sterman. Teaching Takes Off: Flight Simulators for Management Education, http://web.mit. edu/jsterman/www/SDG/beergame.html