КАК УСПЕШНО РУКОВОДИТЬ
ПРОЕКТАМИ
СЕРЕБРЯНАЯ ПУЛЯ
Фергус
О'Коннэл
Фредерик Брукс: «Из всех
монстров, которыми наполнены
кошмары нашего фольклора,
самыми страшными являются
оборотни, поскольку нас пугает
неожиданное превращение того,
что нам хорошо знакомо, в нечто
ужасное. Мы ищем серебряные
пули, которые могли бы
волшебным образом уложить
оборотней наповал...»

Эта книга посвящается моему другу
Джиму Ф алло ну,
чья трагичеческая смерть лишила мир
по-настоящему хорошего человека

Fergus O'Connell
HOW TO RUN
SUCCESSFUL PROJECTS III
THE SILVER BULLET
Addison-Wesley

Фергус О'Коннэл
КАК УСПЕШНО
РУКОВОДИТЬ ПРОЕКТАМИ
СЕРЕБРЯНАЯ ПУЛЯ
перевод с английского
третье издание
КУДИЦ-ОБРАЗ
Москва • 2005

ББК 65.050.2
Фергус О'Коннэл
Как успешно руководить проектами. Серебряная пуля. 3-е издание.
Пер. с англ. - М.: КУДИЦ-ОБРАЗ, 2005. - 336 с.
ISBN 0-201-74806-1
ISBN 5-93378-103-7 (рус.)
Считалось и считается до сих пор, что проекты в среде высоких технологий, таких как разра-
разработка программного обеспечения или информационные технологии, очень трудно планировать
и выполнять, и что доказательство этого - низкие показатели успешности таких проектов.
Эта книга продемонстрирует, что, хотя такие проекты имеют свои собственные уникальные
характеристики, нет причин, по которым ими нельзя управлять с высокой степенью уверенности
в успешном исходе. Она содержит множество полезных методик, практических советов и рекомен-
рекомендаций, а также вводный учебный курс по применению Microsoft Project для управления проектами.
ВНИМАНИЮ ТОВАРОВЕДОВ! Данная книга для отделов компьютерной и деловой литературы.
Фергус О'Коннэл
Как успешно руководить проектами. Серебряная пуля
Учебно-справочное издание
Корректор М. Матекин
Перевел с английского В. Король
Литературный редактор К. Вагнер
Макет С. Красильникова
НОУ "ОЦ КУДИЦ-ОБРАЗ"
119034, Москва, Гагаринский пер., д. 21, стр. 1. Тел.: 333-82-11, ok@kudits.ru
Подписано в печать 18.10.04.
Формат 70x90/16. Бумага офсетная. Печати офсетная.
Усл. печ. л. 24,57. Тираж 2000. Заказ 2224
Отпечатано в ОАО "Щербинская типография"
117623, Москва, ул. Типографская, д. 10
ISBN 0-201-74806-1 © Pearson Education Limited, 2001
ISBN 5-93378-103-7 © Перевод, макет и обложка НОУ "ОЦ КУДИЦ-ОБРАЗ",
(рус.) 2003, 2004, 2005
Настоящий перевод книги "How To Run Successful Projects: The Silver Bullet. Ill Third Edition" пуб-
публикуется по соглашению с Pearson Education Limited,
Цитаты из книги Фредерика Брукса "Мифический человеко-месяц" на обложке и в тексте настоя-
настоящей книги приводятся по изданию "Мифический человеко-месяц", Фредерик Брукс, издательство
"Символ-Плюс".

ПРЕДИСЛОВИЕ К РУССКОМУ ИЗДАНИЮ
Я очень рад, что меня попросили написать предисловие к русскому изданию
"Серебряной пули". Когда я первоначально писал эту книгу, она очень во мно-
многом была ответом на тенденцию - особенно широко распространенную на Запа-
Западе - изображать управление проектами как дисциплину, требующую очень
сложных методологий, средств и техник. Считалось и считается до сих пор, что
проекты в среде высоких технологий, таких как разработка программного обеспе-
обеспечения или информационные технологии, очень трудно планировать и выполнять
и что доказательство этого - низкие показатели успешности таких проектов.
Цель этой книги продемонстрировать, что, хотя такие проекты имеют свои
собственные уникальные характеристики, нет причин, по которым ими нельзя
управлять с высокой степенью уверенности в успешном исходе. Очевидно, есть
много перспективных компаний высоких технологий в русскоязычном мире.
Я надеюсь, что практичный подход и здравый смысл, представленный здесь,
найдет отклик в этих компаниях и позволит гораздо большему их числу всегда
выполнять успешные проекты.
Фергус О 'Кониэл
Ирландия, июнь 2002
ПРЕДИСЛОВИЕ К НОВОМУ ИЗДАНИЮ
Я очень рад, что издательство Addison-Wesley решило переиздать мою книгу.
Ее происхождение и эволюция достаточно полно описаны в предисловиях
к первому и второму изданиям, и я не могу добавить к ним что-либо полезное.
Книга первоначально увидела свет благодаря Вики Вильяме (Viki Williams),
лучшему редактору в мире. Невероятно, но восемью годами позже Вики снова
вернулась к ней, и это издание - результат ее упорного труда и веры. Сьюзен
Харрисон (Susan Harrison) проделала такую необычайно дотошную работу по
подготовке книги для публикации, что ее нужно в действительности считать со-
соавтором. Мои благодарности, Сьюзен.
Ирландия, Май 2001

Ф. О'Коннэл. Как успешно руководить проектами
ПРЕДИСЛОВИЕ КО ВТОРОМУ ИЗДАНИЮ
Если вы занимаетесь книгописательством, то одна из вещей, на которую вы
тратите множество времени, это поиск вступительных строк. Тому есть множе-
множество причин, но, возможно, наиболее личная состоит в том, что, если только вы
не слишком плодовиты, то вам не приходится писать вступления очень часто.
В моем собственном случае прошло уже три года с тех пор, как я писал послед-
последнее, и бог знает сколько теперь времени пройдет, пока я доберусь до следующе-
следующего вступления.
Первая строка книги "People Ware" A987) Тома Де Марко (Tom De Marco)
и Тимоти Листера (Timothy Lister) стала классической: "Где-нибудь сегодня, -
гласит их замечательное вступление, - какой-то проект терпит неудачу". И сего-
сегодня, девятью годами позже, несмотря на всеобщие усилия, проекты все еще тер-
терпят неудачи. Французский генерал Дюкро (Ducrot) выразился еще более красоч-
красочно после поражения французских сил в битве при Седане, когда сказал: "Nous
sommes dans un pot de chambre, et nous у serons emmerdes" *. И сегодня, даже в то
время, когда я пишу или когда вы читаете, кто-то просыпается, чтобы обнару-
обнаружить, что он действительно в pot de chambre и что он очень emmerdes.
Так быть не должно, таков был главный тезис первого издания этой книги,
а теперь это даже больше, чем тезис.
Я думал, что все сказал о том, как успешно руководить проектами, что вряд
ли можно добавить к этому что-либо существенное, однако прошедшие годы
доказали мою неправоту.
Самая значительная вещь, которую я узнал за это время, состоит в том, что
истинность того, что я знал в 1992 г., теперь могут независимо подтвердить дру-
другие: а именно, что Метод Десяти Этапов действительно решение самой боль-
большой проблемы в программной индустрии - проблемы программных проектов,
не выполняющихся в намеченные сроки, превышающих свой бюджет или не
дающих тех результатов, которые требовались от них. Я знал это три года назад,
когда я писал первое издание этой книги, но я не думал тогда, что мир вполне
готов к такому заявлению. Теперь я могу выйти из своего укрытия и без стыда
сделать это заявление, защищенный тем знанием, что меня поддержат люди, на
деле применявшие Метод Десяти Этапов. Конечно, в некотором смысле это не
удивительно в силу происхождения Десяти Этапов. Поскольку Десять Этапов
Дословно данная фраза могла бы быть переведена как: «Мы в параше, и нам это действует на
нервы» (фр). Думаю, дальнейшее использование частей сего изречения автором книги не ну-
нуждается в переводе. - Прим. редактора.

Предисловия и благодарности
были получены из понимания, почему некоторые проекты выполняются успеш-
успешно, а другие нет, тот факт, что они работают для проектов в области программ-
программного обеспечения, просто подтверждает мои мысли в течение многих лет: что -
несмотря на всю пропаганду обратного - проекты в области программного обес-
обеспечения не отличаются от любых других видов проектов.
Я узнал кое-что еще. Десять Этапов не просто гарантируют успех проекта,
это также тот минимум, который должен быть сделан для успешного проекта.
Математики назвали бы Десять Этапов необходимым и достаточным условием
для успешного проекта - вы обязаны сделать то, что требуют Десять Этапов,
причем этого вполне достаточно. Иначе говоря, Десять Этапов сообщают вам,
когда вы сделали достаточно в руководстве проектом. Ваши хождения среди
ночи в мучительных размышлениях о том, все ли сделано, уходят в прошлое, как
только вы начинаете применять Десять Этапов.
Это свойство Десяти Этапов открывает замечательную перспективу, которую
мы назвали Ленивым Руководителем проекта. Ленивый обычно используется как
уничижительный термин, но здесь он употребляется как отличный комплимент.
Ленивый Руководитель проекта делает минимум возможного и всегда имеет ус-
успешный результат - к изумлению своих коллег.
В подробностях основные изменения, которые вы найдете в этом издании
книги, таковы:
¦ Поскольку Десять Этапов гарантируют успех, мы попытались максимально
облегчить вам возможность начать их применение. Многие из соображений,
которые мы приводим здесь - это вещи, о которых наши заказчики спраши-
спрашивали последние три года.
¦ Индикатор Вероятности Успеха (PSI) перестал быть чем-то типа примечания
и теперь интегрирован в Десять Этапов. Вклад каждого этапа в PSI объясня-
объясняется более подробно. Мы можем сделать это, потому что с момента появле-
появления первого издания книги мы уже применили PSI к нескольким тысячам
проектов.
¦ Оценивание программного обеспечения было упрощено и стало гораздо бо-
более пригодным для использования. Оглядываясь назад, я понимаю, что пу-
путался в оценивании ПО. Я долго видел его как нечто отличное от оценивания
в других дисциплинах. Теперь я знаю, что это не так.
¦ Управление временем было интегрировано в Десять Этапов. Это обусловлено
тем, что мы теперь хотим, чтобы вы были не просто успешным руководите-
руководителем проекта, но Ленивым Успешным Руководителем проекта.

Ф. О'Коннэл. Как успешно руководить проектами
БЛАГОДАРНОСТИ
В развитии этого материала за последние три года я узнал многое от многих
людей, и вот некоторые из них, которым я особенно благодарен.
Ди Карри (Dee Carri) и Мэри Мартин (Mary Martin) из Elan Corporation;
Майкл Рис (Michael Rice) и Колм Квинн (Colm Quinn) из Kerry Group; Пол О'Деа
(Paul O'Dea) и Пол Фокс (Paul Fox) из Credo Group; Дермот Гилсон (Dermot
Gilson) из Avid Technology; Тони Мулквин (Топу Mulqueen) из ISOCOR; Аллан
Янг (Allan Young) из Scottish Equitable в Эдинбурге; Саша Йованович (Sacha
Jovanovic) из МРА Stuttgart; Гвидо Хесен (Guido Haesen) и Питер Лоу (Peter
Lowe) из Европейской Комиссии в Люксембурге; мои прежние боссы в Retix,
Тони Фонз (Tony Fonze) и Рон Рудолф (Ron Rudolf); Рассел Альтендорф (Russell
Altendorff) из Travelex Corp; Ян Мидлтон (Jan Middleton) из SSA Europe; Тим
Грининг-Джэксон (Tim Greening-Jack son) из KNX; Пол Ренехан (Paul Renehan)
из ITP; Дермот Болгер (Dermot Bolger) и Редмонд Свини (Redmond Sweeny) из
Telecom Ireland Software и Джон О'Лири (John O'Leary) из ВР Exploration в Ко-
Колумбии. Все они, знают ли они это или нет, помогли мне увидеть связи между
вещами и достичь нового понимания.
Материал приложения 1 сначала появился в статье, имеющей заголовок "How
to become a world class estimator" ("Как стать оценщиком мирового класса")
в выпуске 4 Journal of Structured Project Management. Затем он был расширен
в рамках внутреннего проекта ЕТР. Однако я хотел бы выразить признатель-
признательность за ряд вкладов в его конечную форму компании Telecom Ireland Software,
которая использует эту процедуру.
Шин Макэвой (Sean McEvoy) и Дэвид Конвей (David Conway) подготовили
руководство по пакету MS Project, включенное в Приложение 6.
Книга пишется, а затем небольшая группа профессиональных, увлеченных
и талантливых людей доносит ее до вас. Это люди, занятые в ее производстве,
в моем случае Энн Гринвуд (Ann Greenwood), Луиза Вилсон (Louise Wilson)
(в последний раз!) и Вал Джонс (Val Jones). Это редакторы - их было трое: Вики
Вильяме (Viki Williams), которая делала свою обычную очень высокопрофес-
высокопрофессиональную работу; было одно удовольствие работать с ней, а затем как только
я сдал рукопись, она снялась и уехала. Удачи тебе в путешествиях, Вики. Я до-
догадываюсь, что уже никогда не получу эти 2 фунта! Кристофер Гленни
(Christopher Glennie), который оборонял крепость; Джейсон Дунн (Jason Dunne),
который был лучшим из руководителей проектов - энтузиазм, помощь, творче-
творчество, поддержка, а еще (лучшее из всего) он установил мне крайние сроки, кото-

Предисловия и благодарности
рые я смог выдержать! (Если бы только он дал мне ту экранную заставку. Я был
бы действительно счастлив!!)
Это дизайнеры обложки - Морис Фаррелл (Maurice Farrell), Джон О'Реган
(John O'Regan) и Мартин Свордс (Martin Swords). Кто знает, сколько журналов
они перебрали, пытаясь получить правильные дырки!
Майлс Дунн (Myles Dunne), верстальщик-аристократ, подготовил типограф-
типографский макет со своим обычным искусством, сделав книгу из груды бумаги, дис-
дискет и моих беспорядочных пометок.
Но шоу не кончается до тех пор, пока книга не окажется у вас в руках. За это
я должен благодарить людей из отдела сбыта: Алана, Крейга, Делию, Карен,
Лесли, Венди и Сэма. Я знаю, что книги не сидят и сами не продают себя, это
коммивояжерам приходится разъезжать и впаривать их. Я торговал сам, так что
знаю, как это бывает тяжело. Спасибо за всю вашу упорную работу для меня.
Это ваше чувство долга и преданность своему делу обеспечили успех первому
изданию.
И наконец, есть Хью и Бернадетт. Хью был еще мал, чтобы прочесть первое
издание, так что у него есть оправдание, у Бернадетт оправдания нет! Я уверен,
что они оба получат бесконечные часы удовольствия от чтения этого издания!!
И наконец, замечание относительно сексуальной дискриминации в языке.
Это - одна из областей, где вы не можете победить. Использование повсюду
он и его, даже с оговоркой, что никакого оскорбления в этом не содержится,
с некоторыми людьми не проходит. Если сделать противоположное и повсюду
использовать она и ее, обвинят в гиперболизации символов или в чрезмерно
серьезном отношении к тому, что следует считать тривиальным. Что бы вы ни
выбрали, можно гарантировать, что оскорбите или раздражите кого-то. Увы!
Вот политика, принятая мною. Я использовал он/его и она/ее там и тогда, ко-
когда у меня было соответствующее настроение! Я сделал это, потому что сосед-
соседство женского и мужского рода иногда (а) удивляет людей и (Ь) вызывает раз-
различные мысленные картины.
Ирландия, март 1996
ПРЕДИСЛОВИЕ К ПЕРВОМУ ИЗДАНИЮ
В 1979 году я купил книгу Тома Де Марко (Tom De Marco) A978) "Structured
Analysis and System Specification". К тому времени я работал около трех лет в ка-
качестве программиста, но имел амбиции стать системным аналитиком. Те, кто
знал о моих амбициях, ясно намекали, что не каждый годится на роль системно-

10 Ф. О'Коннэл. Как успешно руководить проектами
го аналитика. Весьма вероятно, что у меня нет "правильных наклонностей" - той
специфической комбинации индивидуальности, интеллекта и взгляда на вещи,
которые характеризуют системного аналитика. Короче говоря, бытовало мнение,
что системный анализ близок к искусству и так же, как не каждый рождается,
чтобы стать великим пианистом, не каждый может стать системным аналитиком.
После чтения книги Де Марко не было бы преувеличением сказать, что я из-
избавился от шор. Попросту, я был ошеломлен! Большая тайна системного анализа
была изложена совершенно открыто. Это не было искусством, во всяком случае
не настолько искусством, это был метод, подход, техника. Хотя было бы диким
упрощением сказать, что любой мог сделать это, конечно, это определенно не
было уделом волшебников или гениев. Книга описывала метод, и если вы при-
придерживались этого метода, вы выполняли системный анализ. Системный анализ
давно уже прекратил рядиться в мистические одежды, так что теперь нам, прак-
практикам программирования, пришлось найти другую черную магию, другую тай-
тайну, которая будет окутывать нас. Эта черная магия - руководство проектами,
и вам достаточно посмотреть на статистику успехов проектов, чтобы понять,
почему мир в целом воспринимает ее именно так. Предпосылкой этой книги яв-
является тот факт, что руководство проектом - не более черная магия, чем систем-
системный анализ. Руководство проектом также может быть представлено как метод,
и именно об этом прежде всего говорит настоящая книга. Книга Де Марко со-
содержала метод, состоящий из семи этапов; моя - метод из десяти этапов. Метод
получен из исследования других проектов, почему некоторые из них являются
успешными, а другие терпят неудачу.
Аргумент достаточно прост: если в вашем проекте вы делаете достаточное
количество вещей, которые сделали другие проекты успешными, велик шанс,
что ваш проект также будет успешным, и наоборот, если вы применяете то, что
практиковалось в неудавшихся проектах, да поможет вам бог.
Части 1 и 2 настоящей книги содержат Метод Десяти Этапов и предназначе-
предназначены для последовательного чтения. За исключением данного ограничения, вы
можете рыться в книге как вам захочется. Хотя в книге для иллюстрации многих
из ее идей используется отрасль разработки программного обеспечения, Метод
Десяти Этапов применим не только к программному обеспечению. Он может
применяться в любом деле, в любой отрасли; он равно применим к коллектив-
коллективным и личным проектам. Действительно, один человек, посещавший один из
курсов моей компании, сказал, что это изменило ему жизнь. Хотя это, может,
и не изменит вашу жизнь, могу в значительной степени гарантировать, что вы
узнаете здесь много нового.

Предисловия и благодарности 11
Руководство проектами занято осуществлением изменений, принуждением
событий к их свершению. В мире, где нам требуется множество изменений -
и это так же верно для моей собственной маленькой страны, как и в любом дру-
другом месте, - именно руководители проектов заставляют мечты становиться
явью. Плохое руководство проектом приводит к колоссальным растратам миро-
мировых ресурсов. Тому есть достаточное количество примеров, и мы должны пы-
пытаться не добавлять к ним свои.
Но больше, чем что-либо еще, руководство проектом - это удовольствие.
У программистов есть тенденция думать, что из их жизней уходит вся радость,
когда они переходят от "выполнения работы инженера" к "руководству людь-
людьми". Ничто не может быть дальше от истины. Из-за бесконечного разнообразия,
постоянного вызова, непредсказуемости, накачки адреналина и высочайшего
чувства достижения цели руководство проектом трудно сравнить с чем-либо;
и если эта книга преуспеет в передаче вам части этого энтузиазма, это будет сто-
стоить той борьбы, которая потребовалась для ее написания.
Многие люди - заказчики, студенты, коллеги, сослуживцы, начальники,
бывшие и настоящие - внесли, сознательно, а иногда и не желая того, свой вклад
в эту книгу. Вместо того чтобы изменять имена для защиты невинных, я решил
опустить все имена. Однако две группы людей заслуживают особого упомина-
упоминания. Одна - это те, кто читали и комментировали черновики книги. Другая груп-
группа - те, кто посещали курсы по содержанию этой книги, пока материал был все
еще в процессе формирования и рос от "Методологии ЕОТР" через "ЕТР" до его
нынешнего простого названия "Структурное Руководство Проектом". Есть неко-
некоторые люди и организации, которых я хотел бы упомянуть: Telecom Ireland
Software (TIS) дала мне разрешение использовать некоторые из примеров в тек-
тексте, за что я очень благодарен. Кроме того, Том Мойлан (Tom Moylan) и Юджин
Смит (Eugene Smyth), оба из TIS, дали мне возможность применить и таким об-
образом отточить многие из идей книги.
Компания Beaumont Hospital была достаточно любезна, чтобы позволить мне
использовать пример, который составила их штатный сотрудник Кэти Кини
(Cathy Keany).
Знают ли они или нет, но Рэй Веланд (Ray Welland) из университета в Глазго
и Пат О'Рейли (Pat O'Reilly) из Siemens Nixdorf - оба поддержали меня в момен-
моменты, когда я начал уже отчаиваться, что этот материал когда-либо увидит дневной
свет. Часто маленькие случайности изменяют жизнь, и разговоры, которые эти
люди, возможно, забыли, были решающими в эволюции материала, так же как
и в укреплении моего желания продолжать работу.

12 Ф. О'Коннэл. Как успешно руководить проектами
Как она сама знает, Вики Вильяме (Viki Williams) из Prentice Hall будет иметь
постоянное место в моем сердце за то, что она предоставила мне мой первый
шанс. Вики все еще должна мне 2 фунта, с того времени, как мы встретились
в первый раз, но это не важно. Вики, поставишь мне пинту [пива] в следующий
раз, когда будешь в Ирландии!
Майлс Дунн (Myles Dunne) собрал мой законченный труд, отгладил помятые
страницы, отжал водянистые и т. п., и окончательный вид книги - это его заслуга.
Бернадетт Макхуг (Bemadette McHugh) перенесла (относительную) бедность
и все вытекающие из нее последствия за то время, пока писалась эта книга. Спа-
Спасибо, Берни, зато, что ты вынесла это - и меня! Fortitudinam vincimns*.
Хью О'Коннэл (Hugh O'Connell) и некоторые его (пушистые) друзья были со
мной, пока я писал большую часть этой книги, как это видно по старым черно-
черновикам с отпечатками грязных лап или цветными каракулями на них. Спасибо,
ребята, может, вы и не облегчили мою работу, но наверняка сделали ее более
веселой!
Ирландия, январь 1993
Дословно: «Побеждаетхрабрость» (лат.). -Прим. редактора.

ОБ АВТОРЕ
Фергус О'Коннэл (Fergus O'Connell) закончил Университетский колледж
в Корке (Ирландия) с отметкой "Лучший в математической физике". Он занимал-
занимался информационными технологиями, разработкой программного обеспечения
и общей руководящей деятельностью в таких компаниях, как СРТ, ICL и Retix.
В 1992 г. он основал ЕТР, которая в настоящее время является одной из мировых
лидирующих компаний по программным разработкам и управлению проектами.
Его опыт включает проекты по всему миру, он обучал управлению проектами
в Европе, Северной Америке, Южной Америке и на Дальнем Востоке.
Фергус - автор пяти книг:
¦ "How То Run Successful Projects ~ The Silver Bullet" (Third edition, Addison-
Wesley, August 2001);
¦ "How To Run Successful High-Tech Project-Based Organizations" (Artech House,
1999);
¦ "How To Run Successful Projects In Web-Time" (Artech House, 2000);
¦ "Simply Brilliant - The Competitive Advantage of Common Sense" (Financial
Times Prentice Hall, 2001);
¦ "Call The Swallow" (The Collins Press, March 2002).
Первая из них, иногда известная просто как "Серебряная пуля", стала и бест-
бестселлером, и классикой. "Simply Brilliant" - также бестселлер - была номиниро-
номинирована на книжную премию W. H. Smith Book Awards в 2002 г. Call The Swallow
в 2002 г. попала в шорт-лист ирландской литературной премии Kerry Ingredients
Irish Fiction Prize.
Фергус писал об управлении проектами для "The Sunday Business Post",
"Computer Weekly" и "The Wall Street Journal". Он читал лекции по управлению
проектами в Университетском колледже в Корке, Колледже Бентли (Bentley
College), Бостонском университете, Высшей школе бизнеса Майкла Смурфита
(Michael Smurfit Graduate School of Business) и по телевидению для Националь-
Национального технологического университета.
У него двое детей и он живет в Ирландии.

ВВЕДЕНИЕ
СЕРЕБРЯНАЯ ПУЛЯ
В 1987 году я вместе с большинством работающих в отрасли программного
обеспечения читал известную статью Фреда Брукса (Fred Brooks) 'Wo Silver
Bullet" A987). (Для тех из вас, кто не знает - это должны быть мои ровесники,
потому что было время, когда каждый знал, кто он - декан руководителей про-
программных проектов, автор наиболее известного из трактатов по руководству
проектами, The Mythical Man-Month.)
Точка зрения Брукса была проста: несмотря на все достижения в оборудова-
оборудовании и технологии программирования, казалось, не было никакого соответст-
соответствующего "развития ни в технологии, ни в методике управления" (курсив мой),
которое бы позволило людям из области информационных технологий выпол-
выполнять проекты вовремя, в пределах согласованного бюджета и номенклатуры по-
поставки. Брукс сказал это, и мир согласился не потому, что это был Брукс, хотя
я уверен, что это помогло, но больше потому, что это также выглядело соот-
соответствующим нашему опыту. Сказав это, Брукс просто поставил на этом во-
вопросе утверждающую печать.
Так откуда же появился я? Назвав эту книгу "The Silver Bullet" "Серебряная
пуля", обнаружил ли я неизвестный прорыв? Если это не так, то я что, рехнулся?
Или, что еще более серьезно, я начинаю верить моим собственным рекламным
материалам?? Самое важное, действительно ли у меня есть Серебряная Пуля?
Хорошо, ответ - и да, и нет. "Нет" в том смысле, что у меня нет оригинальной
разработки в технологии или технике управления, некоторого изящного нового
алгоритма или методики управления, извлеченной из записей неизвестного фи-
философа XII столетия. Прошу прощения за то, что разочаровал вас в этом.
Но, видите ли, я думаю,что Брукс и все остальные из нас "лаяли не на то де-
дерево". Мы искали развитие. Поскольку компьютеры и программное обеспече-
обеспечение были новы, мы думали тогда, что нужна некая новая вещь, чтобы работать
с ними. По какой-то причине мы никак не могли себе представить, что могли бы
сработать старые вещи.
Возможно, вы позволите мне остановиться здесь на мгновение, потому что я
полагаю, что знаю, откуда произошло это мнение.
Люди моего поколения - люди, помнящие универсальные ЭВМ, перфокарты
и термин "обработка данных", - вспомнят, на что это было похоже в те ранние

Введение 15
дни (я думаю, в конце 60-х - начале 70-х гг. прошлого века). Я помню вычисли-
вычислительный центр, когда я учился в колледже: комнаты с воздушным кондициони-
кондиционированием, машина с мигающими огоньками и очень делового вида служители,
которые заботились о ней - одетые с иголочки инженеры IBM и более небрежно
одетый, но не менее ученого вида персонал ВЦ. Иногда машина ломалась или
надо было устанавливать новую версию операционной системы, и когда мы,
студенты, спрашивали, как долго это будет продолжаться, нам говорили: "Мы не
знаем. Это займет столько времени, сколько потребуется".
Мы, студенты-компьютерщики, стремились влиться в ряды этих служителей
науки. Изучать новые технологии. Обслуживать машину. Иметь право говорить
тем, кто не понимает новых технологий: "Мы не знаем. Это займет столько вре-
времени, сколько потребуется".
И так был рожден миф. La Grande Illusion^, как я называю его. La Grande
Illusion поддерживает миф о том, что проекты в области информационных тех-
технологий (и особенно в области программного обеспечения) трудно, если не не-
невозможно оценивать. В значительной степени именно поэтому ИТ-проекты об-
обладают таким печально известным послужным списком.
La Grande Illusion - фундаментальный постулат веры программной индуст-
индустрии. Это аргументация, подобная следующей: "Программные объекты более
сложны из-за своих размеров, чем, возможно, любая другая человеческая конст-
конструкция". (Слова в кавычках - снова из нашего старого друга Брукса (Brooks,
1975).) Поэтому все ставки исключаются при оценке программного обеспечения.
Вещи, у которых есть разумный смысл в других областях, не имеют смысла при
производстве программного обеспечения.
Именно поэтому разработчики ПО делают вещи такого рода, как:
¦ Соглашаются на контракт с фиксированной ценой на нечто, что еще не опре-
определено; контракт, который при этом вполне может содержать штрафные
санкции за просроченную поставку.
¦ Разрабатывают планы и рабочие графики, основанные на том, что люди рабо-
работают по 7 дней в неделю и по 15 часов в день.
¦ Создают реалистичные планы, но затем отступают от них при первом при-
признаке сопротивления со стороны руководства или заказчика.
¦ Отказываются вообще оценивать хоть что-нибудь на том основании, что оце-
оценивать программное обеспечение могут только профаны.
Великая иллюзия (фр). - Прим. переводчика.

16 Ф. О'Коннэл. Как успешно руководить проектами
И они делают все эти вещи не моргнув глазом - все из-за того же постулата
веры программной индустрии, который гласит, что программные проекты труд-
трудно, если не невозможно оценивать. (Где еще можно найти такую карьеру: техни-
технически многообещающую, относительно высоко оплачиваемую, и где, наконец,
можно пожать плечами и сказать: "Слушайте, откуда мы могли знать, что эти
вещи займут так много времени?")
Вся индустрия поднялась на этом постулате веры. В Европе, даже когда мы
сейчас говорим, до сих пор существуют исследовательские программы, рабо-
работающие с внешними пределами проблемы. У меня есть многочисленные книги -
каждая почти в 800 страниц объемом, огромная работа науки, - которые предла-
предлагают пути решения проблемы. Во всем мире миллионы, если не миллиарды дол-
долларов исследователей тратятся на поиск прорыва, о котором говорил Брукс -
путях точной оценки программных проектов.
И все это, я уверен, "лай на неправильное дерево". Поскольку ответ был на
поверхности и ждал нас все это время.
Были попытки - до некоторой степени успешные - сравнения построения
программного обеспечения со строительной индустрией. Я думаю, однако, что
намного лучше будет сравнение создания программного обеспечения с создани-
созданием фильма. Оба берут записанное представление чего-то - сценарий в случае
фильма, спецификации (технические требования) в случае программного обес-
обеспечения - и преобразовывают его в образы на определенном носителе (кадры на
кинопленке или биты на диске или ленте).
Сейчас кинопроизводство содержит примечательные примеры - Revolution,
Heaven's Gate, Waterworld, это всего несколько названий навскидку - фильмов,
которые беспрецедентно превысили бюджет и график. Но в наши дни фильмы
создаются на вполне деловой основе почти полностью предсказуемым спосо-
способом, чтобы уложиться в указанный бюджет, график и требования по качеству.
И каков же ключ к этому? Ключ этот - этап подготовки к производству.
В книге "My Indecision is Final" Джеком Эбертсом (Eberts и Ilott, 1990) описан этап
подготовки к производству сэром Ричардом Аттенборо (Richard Attenborough) его
фильма "Ганди":
Он [Аттенборо] должен был снимать фильм в течение холодного сезона в Индии, кото-
который начинается в ноябре и заканчивается в апреле или мае. (Лето было просто слишком
жарким: съемочная группа не смогла бы работать при 110 градусах по Фаренгейту.) Но
чтобы начать в ноябре, ему надо было провести подготовительную работу сейчас, за
шесть месяцев до начала: нанять актеров и съемочную группу, построить декорации, по-
подобрать костюмы, получить все разрешения, необходимые для съемок в Индии, отпра-
отправить оборудование и так далее. Эти задачи, известные как подготовка к производству,

Введение 17
достаточно просты, если вы снимаете в своей собственной стране, но чудовищно услож-
усложняются при съемках за границей. Возьмите простой пример: если вам надо 125 человек,
чтобы сделать фильм, вам надо забронировать гостиничные номера и заплатить за них
или по крайней мере обеспечить их некоторым видом депозита, сильно заранее. Это
означает точное знание того, где вам нужен каждый из этих 125 человек в любой за-
заданный день из этих четырех или шести месяцев съемки фильма [курсив мой].
Если вы замените 125 человек на размер вашей конкретной команды про-
программистов и замените фразу "фильм будет сниматься" на "программное обес-
обеспечение будет разрабатываться", то, в сущности, вы имеете Серебряную Пулю.
И эта Серебряная Пуля не пришла из какого-либо прорыва - она пришла из хо-
хорошо испытанных методов, которые развивались свыше ста с лишним лет кино-
кинопроизводства, а те, в свою очередь, пришли из проектов в других дисциплинах
и областях производства. Вот это и есть Серебряная Пуля. Предпосылка этой
книги проста.
Если вы делаете вещи, которые я описал в этой книге, в ваших проектах, то ваши
проекты всегда будут успешными. Никаких "если", "и", "но", "может быть", "при
условии если" или чего-нибудь еще.
Эта книга - о методе под названием "структурное руководство проектом".
Структурное руководство проектом - результат более чем 25 лет исследований
того, почему некоторые проекты выполняются успешно, а другие терпят крах.
Хотя структурное руководство проектом не привязано ни к какому специфиче-
специфическому виду проекта, эта книга сосредоточена в основном на информационных
и программных проектах, областях, печально известных своими неудачами.
Программисты найдут, что структурное руководство проектом соотносится
с обычным руководством проектом так же, как:
¦ структурный анализ и проектирование соотносятся с обычным анализом
и проектированием;
¦ структурное программирование соотносится с обычным программированием
то есть оно заменяет сильно индивидуальный процесс на процесс, который явля-
является стандартным, повторяемым, предсказуемым и непротиворечивым. Нас час-
часто спрашивают, является ли структурное руководство проектом "методологией"
- программисты любят упоминания о методологии, - и ответ будет и да, и нет.
В своей замечательной книге "People Ware" A987) Том Де Марко (Tom De
Marco) и Тимоти Листер (Timothy Lister) определяют две версии слова "методо-
"методология": "методология" и "Методология". Методология с большой буквы опреде-
определяется как "общесистемная теория того, как должен выполняться целый класс
интеллектуально интенсивной работы. Она появляется в виде толстенной ("за-

18 Ф. О'Коннэл. Как успешно руководить проектами
нимающей не менее фута C0 см) на книжной полке") книги, которая определяет
подробно и точно, какие шаги предпринимать в любое время, вне зависимости
от того, кто делает работу, где и когда".
Если ваш вопрос состоит в том, является ли структурное руководство проек-
проектом такой методологией, ответ определенно нет.
Методология, начинающаяся на маленькую "м", - это другая порода. Мето-
Методология со строчной "м" определяется как "основной подход, который каждый
выбирает для выполнения полученного задания. Она размещается не в толстой
книге, а скорее, в головах людей, выполняющих конкретную работу". Структур-
Структурное руководство проектом - это методология со строчной "м".
Хотя в этой книге мы будем иметь дело в основном с программными проек-
проектами, структурное руководство проектом утверждает, что любая человеческая
деятельность или начинание могут интерпретироваться как проект, а значит,
книга может использоваться любым лицом, ответственным за руководство такой
деятельностью или начинанием. Предполагается, что у книги будет три типа чи-
читателей:
¦ Руководители проекта, управляющие своим первым проектом.
¦ Закаленные руководители проектов, которые извлекут пользу из применения
формализованного метода руководства проектом.
¦ Опытные руководители проекта, чувствующие потребность в совершенство-
совершенствовании своего профессионализма, в курсе освежения [своих знаний]; в тонкой
настройке того, как они делают вещи; или потребность в некоторой опорной
точке для сравнительного оценивания своих проектов.
Книга разделена на пять частей. Части 1 и 2 представляют Десять этапов
структурного руководства проектом. Части 1 и 2 показывают вам, как успешно
вести любой проект.
Большинство из нас не могут позволить себе роскошь концентрации всех
своих усилий на единственном проекте. Большинство из нас одновременно за-
заняты во многих проектах, и в части 3 показано, как вести несколько параллель-
параллельных проектов.
По мере прочтения вы увидите, что большинство проектных катастроф мо-
может быть предсказано намного раньше, чем они случаются. Десять этапов дока-
доказывают, что в очень значительной степени успех или крах проекта закладывает-
закладывается на стадии его планирования. Чтобы дать вам возможность быстро и эффек-
эффективно оценивать планы проектов, мы предлагаем подход, базирующийся на Де-
Десяти этапах, который позволяет это сделать. Он описан в части 4.

Введение 19
Часть 5, названная "Остальные средства", представляет ряд глав по предме-
предметам, которые должен знать руководитель проекта. Многое из этого излагается
в других книгах по управлению или в учебных программах. Здесь есть главы по:
¦ решению проблем и принятию решений,
¦ работе со стрессами,
¦ подбору правильных людей,
¦ переговорам,
¦ совещаниям,
¦ презентациям,
¦ сокращению проектных сроков посредством ускоренного анализа и разработки.
Наконец, имеется несколько приложений, которые упомянуты в тексте.
Поскольку многие организации теперь переходят от традиционных структур
управления (иерархической, матричной и т. д.) к проектно-ориентированным
подходам, есть надежда, что эта книга породит новые исследования в этой кри-
критической области. Главное внимание повсюду в книге направлено на:
¦ упрощение и поиск основы любой проблемы,
¦ полезные и практические идеи,
¦ интересную и стимулирующую подачу идей.
БЛАГОДАРНОСТИ ЗА РАЗРЕШЕНИЯ
Автор благодарен за разрешения воспроизвести цитаты из указанных ниже
работ:
А.Р. Watt Ltd, представляющей интересы Роланда Хантфорда (Roland Huntford),
за разрешение цитировать его книгу "Scott and Amundsen".
Verso за разрешение цитировать книгу Judgement Over the Dead Тревора
Гриффитса (Trevor Griffiths).
Унвину Химану (Unwin Hyman) из HarperCollins Publishers Ltd за разрешение
цитировать книгу "The Lord of the Rings" Дж. Р. Р. Толкиена (J. R. R. Tolkien).
Цитирование по изданию The Fellowship of the Ring J.R.R. Tolkien, Copyright
© 1954, 1965 J.R.R. Tolkien. Copyright © renewed by 1982 Christopher R. Tolkien,
Michael H.R. Tolkien, John F.R. Tolkien and Priscilla M.A.R. Tolkien. Reprinted by
permission of Houghton Mifflin Co. All rights reserved.

20 Ф. О'Коннэл. Как успешно руководить проектами
Bantam Doubleday Dell Publishing Group Inc. за разрешение цитировать книгу
"Voices of Freedom" Генри Хамптона (Henry Hampton) и Стива Фрейера (Steve
Frayer).
После некоторого времени они пересекли Водью к западу от Хоббитона по узким доща-
дощатым мосткам. Поток там был не больше, чем вьющаяся черная лента, обрамленная оль-
ольховыми кронами. Через милю или две дальше на юг они поспешно пересекли большую
дорогу от Моста Брэндивайн; они были теперь в Тукленде и, забирая на юго-восток,
двинулись в Страну Зеленых Холмов. Карабкаясь по ее первым склонам, они оглянулись
назад и увидели далеко позади мягкое мерцание огней Хоббитона, рассеянных по лас-
ласковой долине Водьи. Вскоре она исчезла в складках погружающейся в темноту местно-
местности, и появилось Приречье с его серым прудом. Когда свет окон последней фермы ос-
остался далеко позади, проглядывая сквозь деревья, Фродо обернулся и помахал рукой на
прощание. "Интересно, увижу ли я когда-нибудь нашу долину", - сказал он тихо.
The Lord of the Rings
Дж. P. P. Толкиен
(J. R. R. Tolkien)
Поздно вечером 6-го июня Амундсен вышел из своего дома, закрыл за собой дверь, ос-
оставив все, как будто собирался вернуться через час или два, быстро прошел через рощу
и поднялся на борт "Фрама". Послышался скрежет цепей, якорь был поднят, и корабль
медленно вышел во фьорд. "Отплыли в полночь", - гласила первая запись в дневнике
Амундсена.
Scott and Amundsen
Роланд Хантфорд
(Roland Huntford)
Каждый пишет некоторым своим способом, потому что каждый - некоторый сорт челове-
человека; каждый - некоторый сорт человека, потому что каждый вел некоторый сорт жизни.
А.А. Милн (A. A. Milne)

ЧАСТЬ 1
АНАЛИЗ И ПЛАНИРОВАНИЕ
ПРОЕКТОВ
ПРИРОДА ПРОЕКТОВ
Эта книга имеет дело прежде всего с проектами по разработке программного
обеспечения, хотя многое из того, что здесь сказано, справедливо и для проектов
в любой другой области. В частности, я буду использовать термин "проект"
в том смысле, что любая комбинация предмета и действия вместе составляет
проект. Таким образом, в соответствии с этим определением любое из следую-
следующих предложений может быть проектом:
¦ стать первым человеком, достигшим Южного полюса,
¦ получить продвижение по службе и повышение зарплаты,
¦ достичь рекордных продаж нового продукта,
¦ создать новое отделение фирмы,
¦ снизить себестоимость производственного процесса,
¦ создать завод по перегонке нефти,
¦ высадить человека на Луне,
¦ разработать новую компьютерную систему,
¦ создать самолет А-12.
Обратите внимание, что это определение рекурсивно: оно определяет вещь
в терминах самой себя. Например, проект "разработать новую компьютерную
систему" сам состоит из ряда проектов:
¦ разработать аппаратное обеспечение,
¦ разработать программное обеспечение,
¦ интегрировать аппаратуру и программное обеспечение,
¦ выпустить систему.

22 Ф. О'Коннэл. Как успешно руководить проектами
Каждый из этих проектов может быть еще более детализирован. Для проекта
"Разработать программное обеспечение" мы могли бы иметь:
¦ идентифицировать технические требования,
¦ разработать верхний уровень,
¦ выработать функциональные спецификации и т. д.
Ключевой фактор в проектах - это то, что они имеют фазы рождения, жизни
и смерти. Это не те сущности, которые длятся вечно. Идентификация рождения,
жизни и смерти - особенно смерти - является ключом к успеху проекта. В ходе
этой книги я буду использовать различные аналогии при обсуждении проектов.
Проект как путешествие
Проект подобен путешествию: он включает необходимость определения мес-
места назначения, экипировки, самого процесса путешествия и окончания где-
нибудь - будем надеяться в месте, в которое вы намеревались попасть.
Проект как изменение состояния
Весь проект состоит в достижении некоторой цели. Вселенная до начала про-
проекта находится в одном состоянии, затем переходит в другое состояние, а их
различие и есть задача проекта. В приведенных выше примерах цели/задачи/состо-
цели/задачи/состояния формулируются следующим образом:
¦ человек достиг Южного полюса,
¦ вы получили продвижение по службе и повышение зарплаты,
¦ вы достигли рекордных продаж нового продукта,
¦ новое отделение фирмы создано и работает,
¦ себестоимость производственного процесса была снижена,
¦ завод по перегонке нефти был построен,
¦ человек высадился на Луне,
¦ новая компьютерная система доступна пользователям,
¦ самолет А-12 летает.
Эта книга представляет методологию, названную Структурное руководство
проектами и предназначенную для управления проектами. В принятой выше
терминологии структурное руководство проектом поможет вам сформулиро-
сформулировать, чего Вы хотите достигнуть. Далее оно даст вам средства планировать ваше
путешествие, совершить его и достигнуть места назначения. Другими словами,
используя данную методологию, вы достигнете вашей цели.

Часть 1. Анализ и планирование проектов 23
СТРУКТУРНОЕ РУКОВОДСТВО ПРОЕКТОМ: ДЕСЯТЬ
ЭТАПОВ
Десять этапов - краеугольный камень структурного руководства проектом.
Они описываются в следующих десяти главах этой книги.
Вот эти Десять этапов:
1. Наглядное представление цели; сосредоточьтесь на призе.
2. Разработка списка задач, которые должны быть выполнены.
3. Должен быть только один лидер.
4. Закрепление людей за задачами.
5. Управление ожидаемыми результатами, расчет резервов для ошибок, выра-
выработка запасных позиций.
6. Использование подходящего стиля руководства.
7. Знание того, что происходит.
8. Информирование исполнителей о том, что происходит.
9. Повторение этапов 1-8 до этапа 10. И наконец,
10. Приз.
Я сказал в первом издании, что первые пять этапов должны производиться
при планировании вашего проекта, а другие пять - при осуществлении плана
и достижении цели. В то время как это утверждение остается истиной на все сто
процентов, я могу отметить, что существует более глубокое интуитивное обос-
обоснование того, что этапы структурированы таким образом.
На этапах 1-5 действительно вырабатывается план вашего проекта. Однако
на них также определяется один возможный путь, по которому будет выпол-
выполняться проект. Позвольте мне сформулировать это иначе. Если вы включаете
в ваш план проекта уровень детализации, который я предлагаю выполнять
в этапах 2 и 4, то план отразит один из путей, по которому, возможно, будет вы-
выполнен проект.
Ключом ко всему вышесказанному является слово "детализация". Общепри-
Общепринятое мнение гласит, что вы не можете знать много о проекте, особенно о про-
программном проекте, в его начале. Это синдром: "Я не знаю, как долго это будет
продолжаться, до тех пор пока я это не сделаю". У меня на занятиях были слу-
слушатели, которых, по их словам, критиковали за то, что их планы были "слишком

24 Ф. О'Коннэл. Как успешно руководить проектами
детализированы". Я слышал от кого-то, что слишком много деталей на ранних
этапах в проекте "неэффективно".
Это - полная ерунда!
Если и есть во всем уже изложенном "Серебряная Пуля", т. е. некий новый
подход, то это утверждение, что каждая деталь проекта должна учитываться как
можно раньше. Только таким образом вы можете сформировать возможный
сценарий того, как будет выполняться проект.
В действительности вы делаете нечто более сложное, чем создание одной-
единственной модели. Фактически, вы создаете набор моделей.
Позвольте мне объяснить. Этапы 1-4 заставляют вас формировать прогноз
пути, по которому проект мог бы выполняться. Одна часть этапа 5 - подэтап
5а- заставляет вас формулировать некоторые непредвиденные обстоятельства
или границы (диапазоны) ошибок вашей модели. Это означает, что до некоторой
степени все может происходить отличным от вашего прогноза образом, однако
это еще не будет проблемой, если эти различия охвачены вашим диапазоном
ошибок. Затем подэтап 5Ь учитывает тот факт, что некоторым людям - вашему
начальнику, вашему заказчику - может не нравиться то, о чем говорит ваш про-
прогноз. Это снова не будет проблемой. В этом случае все, что вам нужно сделать, -
это использовать вашу начальную модель для производства достаточно полного
набора моделей. Например, если они не согласны с существующей датой по-
поставки, вы можете сказать: "Хорошо, вот - модель, показывающая, что мы мо-
можем сделать к дате, которую вы требуете" или "Вот - то, что мы можем сделать,
если вы даете нам дополнительных людей".
Этот процесс подробно описан в главах 1-5. Каждый этап описывается от-
отдельно. В приложении 1 мы объединяем все этапы в программное приложение
оценивания, чтобы вы могли: а) использовать его и б) сделать его частью про-
программы контроля качества, соответствующей стандарту ISO 9000 или другой,
в процедуре управления проектом.
Сделав уже так много, мы, конечно, хотим, чтобы все происходило именно
так, как мы наметили, т. е. заставить действительность твердо придерживаться
плана, превратить план в самореализующийся прогноз. Именно это делают эта-
этапы 6 - 10. И как вы увидите, чтобы заставить действительность твердо придер-
придерживаться плана, не требуется божественного уровня способностей, которые, ка-
казалось бы, подразумеваются этой задачей. На самом деле вы увидите, что созда-
создание действительности, которая твердо придерживается плана - одна из наиболее
концептуально простых вещей, поддающихся воображению.
Таким образом, вы получаете два шанса сделать ваш проект успешным:

Часть 1. Анализ и планирование проектов
25
¦ до, планируя ваш проект как можно более подробно;
¦ после, заставляя ваш план стать самовыполняемым предсказанием.
Не все Десять этапов одинаково важны. Каждому этапу приписывается опре-
определенный вес, и эти веса совместно вносят вклад в нечто, называемое нами Инди-
Индикатором вероятности успеха (Probability of Success Indicator, или PSI). PSI - мгно-
мгновенная мера того, насколько вероятно или нет успешное выполнение проекта. Вы
можете прочесть об исходной методологии получения значений PSI в приложении
3. В общем случае весовые коэффициенты распределяются следующим образом:
ШАГ
1
2
3
4
5
б
7
8
9
10
Общее количество
ВЕСА (ВКЛАД В PSI)
20
20
10
10
10
10
10
10
0
0
100
В главах, описывающих каждый из Десяти этапов, я покажу, как вычисляется
индивидуальный вес этапа и как сумма этих весов, в свою очередь, вносит вклад
в PSI. В тексте эти места будут обозначаться заголовком "вклад в PSI", помечен-
помеченным значком, показанным на полях.
В главе 1 "Дома в Уголке Пуха" (The House at Pooh Corner - А. Милн, 1923)
мы находим следующие комментарии Иа-Иа, потрепанного ослика, обитающего
в этой книге:
"Это только показывает то, что можно сделать, затратив немного усилий, - сказал
Иа-Иа. - Видишь, Пух? А ты, Пятачок? Сначала Ум, а затем Тяжкий Труд. Смотрите!
Вот - способ построить дом", - сказал Иа-Иа гордо.

26 Ф. О'Коннэл. Как успешно руководить проектами
Сначала ум, а затем тяжкий труд. Это не только способ построить дом: это -
основа для выполнения любого проекта. Структурное управление проектом пре-
предусматривает следование этому подходу в той половине из его Десяти этапов,
которые относятся к планированию проекта, то есть они применяются прежде,
чем проект действительно начинает выполняться. Это отражает мою собствен-
собственную твердую веру в то, что большинство проектов выполняется успешно или
терпит крах из-за решений, принятых на этой самой стадии планирования. Мно-
Многие из разбираемых примеров, приведенных на этих страницах, будут иллюст-
иллюстрировать эту мысль. Что касается Винни Пуха, мы возвратимся к нему снова
в главе 16 "Борьба со стрессами".

ГЛАВА 1
Этап 1: НАГЛЯДНОЕ ПРЕДСТАВЛЕНИЕ ЦЕЛИ;
НАЦЕЛЬТЕСЬ НА ПРИЗ
ВВЕДЕНИЕ
Первый этап в структурном руководстве проектом предназначен для опреде-
определения вашей цели, вашего места назначения. Наглядно представьте, какова цель:
нацельтесь на приз. Как показывается в следующих разделах, есть целый ряд
причин, почему вы должны это сделать.
ИДЕНТИФИКАЦИЯ ЦЕЛИ
Этап 1 четко определяет цель. В гонке по достижению Южного полюса меж-
между Скоттом и Амундсеном (Huntford, 1993) цель Амундсена была обозначена
с самого начала: он намеревался быть первым человеком, который достигнет
Южного полюса. Цели Скотта были гораздо более расплывчатыми. Его экспе-
экспедиция планировалась как научная; полюс был дополнительным аттракционом.
Его команда должна была выполнять научные исследования; достижение полюса
также планировалось, однако в тот момент, когда это будет удобно. Действитель-
Действительно, когда Скотт обнаружил, что Амундсен направляется к Южному полюсу, он
счел ниже своего достоинства принимать участие в гонке. Как руководитель этого
проекта, Скотт посылал противоречивые сигналы и самому себе, и своей команде.
Или полюс был целью, или не был. Если был, то надо было запускать соответст-
соответствующий проект. Если нет, то единственным проектом была научная работа.
ТОЧНОЕ ОПРЕДЕЛЕНИЕ ЦЕЛИ
Наглядное представление цели, т. е. ее формулировка и ее письменная фик-
фиксация немедленно запускает два взаимосвязанных процесса. Начинается суже-
сужение определения цели, и стартует процесс планирования, который является
предметом следующей главы.
Сужение определения цели
Цель Амундсена - быть первым человеком, который достиг бы Южного по-
полюса- сразу порождает важный пункт: безопасное возвращение группы. Эрнест
Шэклтон (Ernest Shackleton) направился к Южному полюсу в 1909 году

28 Часть 1. Анализ и планирование проектов
(Huntford, 1985), но в 97 милях от него, когда приз уже был в пределах досягае-
досягаемости, он повернул обратно и не попал в историю великих свершений человече-
человечества. Его цель была та же, что и у Амундсена, - быть первым человеком, дос-
достигнувшим Южного полюса. За девяносто семь миль от полюса он понял, что
нехватка продовольствия и ресурсов не даст его группе возможности вернуться.
Он повернул обратно. Таким образом, и для него, и для Амундсена неотъемле-
неотъемлемой частью цели была необходимость вернуться живым вместе со всей группой.
Наглядное представление сужает определение основной цели, идентифици-
идентифицированной в предыдущем разделе. Обратите внимание, что в таких примерах, как,
например, наступление англичан на Сомме в 1916 году - этот пример я буду ис-
использовать позже, - определение цели может занять не одну страницу.
Определение цели чрезвычайно важно. Что представляет собой завершение
проекта? Для некоторых проектов ответ может быть проще пареной репы, одна-
однако вы обязаны тщательно проанализировать этот аспект. Если цель кажется со-
совершенно очевидной, сделайте контрольный перечень всех операций, необхо-
необходимых для завершения проекта. Другими словами, запишите все изменения со-
состояния, которые должны произойти для того, чтобы проект мог считаться за-
завершенным.
Запуск процесса планирования
При наглядном представлении цели вы включаете свое воображение и пред-
представляете, как будет выглядеть жизнь после завершения проекта. Мысленно вы
уже совершили путешествие от настоящего момента к этому новому месту
и времени. Неизбежно при таком представлении некоторые из проблем, с кото-
которыми вы встретитесь в этом путешествии, начнут проявляться более отчетливо.
ОБОСНОВАНИЕ ЦЕЛИ
Фокусировка внимания на призе дает вам все причины для того, чтобы взять-
взяться за данный проект. Жизнь коротка, и мы проживаем ее только однажды. Если
вы собираетесь посвятить некоторый период своей жизни проекту, то вы долж-
должны чувствовать, что он стоит этого. Наглядное представление - фокусировка
внимания на призе - дает вам представление того, что вы будете чувствовать,
когда проект завершится.
Наглядное представление предполагает создание мечты. При этом вы начи-
начинаете мысленно представлять себе, какой будет жизнь после завершения проек-
проекта. Вы можете представить себе заработанную сумму, признание коллег и руко-
руководства, то, насколько сильнее будет выглядеть ваше профессиональное резюме,
или, возможно, чувство личного удовлетворения. Независимо от того, что имен-

Глава 1. Этап первый: наглядное представление цели - нацельтесь на приз 29
но движет вами, вы можете получить предварительное представление того, что
будете чувствовать, когда все закончится. Если этот взгляд в будущее не зажи-
зажигает вас, то, вероятно, не стоит заниматься этим проектом. Но если вы чувствуе-
чувствуете, что в крови стало больше адреналина, нырните в эту мечту с головой. Радуй-
Радуйтесь ей. Купайтесь в ней. Думайте о том, как великолепно вы будете себя чувст-
чувствовать, когда проект будет закончен.
МОТИВАЦИЯ КОМАНДЫ
Наглядное представление цели дает вам видение, которым вы будете вдох-
вдохновлять людей, работающих с вами над проектом. Это очень хорошо, что вы за-
загорелись идеей, но как обстоит дело с людьми, которые будут работать с вами -
а проекты любого размера всегда требуют привлечения других людей?
Наглядное представление цели дает вам образ, описание места где-то в буду-
будущем, к которому вы привязаны. Это втягивает других в вашу мечту. Впереди мо-
могут быть черные дни - в большинстве проектов они случаются, и видение цели -
это то, что будет поддерживать вас и вашу команду в эти дни. Лучший пример
настройки на приз, какой я знаю, принадлежит Мартину Лютеру Кингу, который
в своей вашингтонской речи в 1963 году (Hampton и Freyer, 1990) сказал:
"...Я сегодня говорю вам, моим друзьям, что даже при том, что мы сталкиваемся с труд-
трудностями сегодня и завтра, у меня все еще есть мечта. Это - мечта, глубоко укоренившая-
укоренившаяся в сути американского'символа веры: "Мы считаем самоочевидной истиной, что все
люди созданы равными". Я мечтаю, что однажды на красных холмах Джорджии сыновья
прежних рабов и сыновья прежних рабовладельцев смогут сесть вместе за стол братст-
братства. Я мечтаю, что однажды даже штат Миссисипи, штат, изнемогающий от душной не-
несправедливости, пышущий жаром угнетения, преобразится в оазис свободы и справед-
справедливости. Я мечтаю, что мои четверо маленьких детей будут однажды жить в нации, где
их будут оценивать не по цвету их кожи, но по их характерам...".
ИЗМЕНЕНИЯ ЦЕЛИ И КОНТРОЛЬ ИЗМЕНЕНИЙ
Никто, и уж точно не я, не настолько наивен, чтобы верить, что однажды постав-
поставленная цель не будет и не может быть изменена никогда. В реальном мире мы ожи-
ожидаем, что в процессе выполнения проекта некоторые вещи будут забыты, пропуще-
пропущены, проявятся с другой стороны, изменятся или станут лишними. У нас не будет
с этим никаких проблем при наличии механизма для контроля этих изменений.
Любой механизм контроля изменений, который мы устанавливаем, должен
работать в соответствии с Первым законом руководства проектом. Вы уже знае-
знаете Первый закон; возможно, вы просто не знали его в той формулировке, кото-

30 Часть 1. Анализ и планирование проектов
рая следует ниже. Первый закон руководства проектом гласит, что в любом про-
проекте разработки продукта или системы существует функция следующих четырех
переменных:
1) функциональность [выходного продукта],
2) дата сдачи [продукта],
3) объем работ (или стоимость),
4) качество
- и что эта функция является константой, то есть
Функция (функциональность, дата сдачи, объем работ, качество) = Константа.
(А если вам захочется узнать побольше о том, какой вид эта функция может
иметь в проектах разработки программного обеспечения, то не худшим вариантом
будет знакомство с книгой "Measures for Excellence" (Puttnam и Myers, 1992).)
При изменении любой из этих переменных соответствующим образом изме-
изменяются все остальные. Мы все видели этот эффект. Например, расширьте функ-
функциональность продукта, скажем добавив новую функцию, и сдвинется дата сда-
сдачи, или увеличится объем работ, или понизится качество, или же будет наблю-
наблюдаться некоторая комбинация этих явлений, так что значение функции будет
оставаться неизменным.
Многое из того, о чем говорится в этой книге, - частное мнение (обычно мое)
или анализ некоторых случаев или ситуаций. Однако это такой закон, как, скажем,
закон всемирного тяготения. Вы можете, конечно, претендовать на то, что закон
всемирного тяготения к вам неприменим. С равным успехом вы можете претендо-
претендовать на то, что обсуждаемый закон вас не касается. В обоих случаях ваш образ
действия имеет право на существование настолько же, насколько и любой другой.
Если вы верите в существование Первого закона руководства проектом, он
будет вашим настоящим другом и защитником. Заявите себе, что он не сущест-
существует, и вы найдете его самым неумолимым врагом в мире.
Одна из бессмертных фраз в проектах разработки программного обеспечения -
"мы учли это в графике работ". Первый закон руководства проектом объясняет,
почему ничто не может быть полностью включено в график. Позже, на этапе 5,
я покажу вам способ, которым можно имитировать всеобъемлющий учет, однако
только имитировать. В действительности это всего лишь удобная управленческая
техника и не более, способ исключения необходимости дополнительных обсуж-
обсуждений контракта с руководством или заказчиком каждый раз, когда что-то изме-
изменяется. Но это - имитация, иллюзия. Закон работает, и лучше верить в это.

Глава 1. Этап первый: наглядное представление цели - нацельтесь на приз 31
Контроль изменений можно реализовать очень просто, используя журнал ре-
регистрации изменений. Для этого достаточно папки, содержащей по странице на
каждое изменение и оглавление (по строке на каждое изменение), которая сво-
сводит в одном месте все изменения. Каждая страница изменений в первую очередь
описывает:
¦ характер изменения,
¦ анализ его воздействия [на проект],
¦ предпринятые действия.
Образцы двух страниц, одной для изменений и одной для оглавления, пред-
представлены в приложении 5.
МЕТОДЫ НАГЛЯДНОГО ПРЕДСТАВЛЕНИЯ ЦЕЛИ
Так как же осуществляется наглядное представление и установка цели? Здесь
предлагается два возможных метода: один - использование вопросника, нацелен-
нацеленного, среди прочих аспектов, на день завершения проекта; другой - использование
метода, который мне нравится называть "И все они жили долго и счастливо".
ПЕРЕЧЕНЬ КОНТРОЛЬНЫХ ВОПРОСОВ
ДЛЯ СОЗДАНИЯ НАГЛЯДНОГО ПРЕДСТАВЛЕНИЯ
¦ Что будет значить цель проекта для всех занятых в нем, когда проект завер-
завершится?
¦ Что в действительности производит проект? Куда денутся все результаты?
Что случится с ними? Кто будет использовать их? Как они будут воздейство-
воздействовать на пользователей?
¦ Что означает завершение проекта для команды в целом и для каждого из ее
членов?
¦ Почему они хотят выполнить этот проект?
¦ Почему вы хотите сделать это?
¦ На что будет похожа жизнь в тот день/неделю, когда проект завершится?
¦ Что вы будете делать в этот день? В течение этой недели? Чем вы будете за-
заниматься? Каким будет ваш график? Где вы будете есть? С кем вы встрети-
встретитесь? О чем вы будете разговаривать с этими людьми?

32 Часть 1. Анализ и планирование проектов
¦ Что будут говорить люди относительно проекта и его результатов? Вы? Ваш
начальник? Люди, которые работали над проектом? Заказчик, для кого вы
выполняли проект?
¦ Что бы вы хотели видеть в отчете по независимой проверке проекта
(см. "Итоги" в главе 10)?
¦ Как вы будете себя чувствовать?
¦ Как вы думаете, что люди будут говорить о вас? Ваш начальник? Коллеги? Под-
Подчиненные? Заказчик проекта? В других подразделениях вашей организации?
¦ Каковы будут ваши амбиции/надежды/мечты в этот день?
¦ Изменится ли ваш уровень жизни?
¦ Изменится ли ваше положение в организации?
¦ Изменится ли ваш собственный взгляд на себя? Если да, то как?
¦ Вы считаете, что данный проект - это сложная задача, к которой вы готовы?
¦ Можете ли вы потерпеть неудачу?
¦ Как бы вы чувствовали себя тогда? Что бы вы делали?
¦ Будете ли вы иметь силы, которых у вас нет в настоящее время?
¦ Вы изменитесь как личность? Если да, то как?
¦ Какого понимания этого проекта вы достигнете?
¦ Чем бы вам хотелось заняться после завершения этого проекта?
¦ Что было бы лучшим возможным результатом для этого проекта?
Метод "И все они жили долго и счастливо"
Этот метод предполагает интерпретацию цели вашего проекта в терминах
трех взаимно перпендикулярных осей, как показано на рис. 1.1.
Первая ось - функциональность [продукта]. Нулевая точка на этой оси озна-
означает минимальную функциональность, максимальная точка означает, что все
пляшут и поют от радости. Насколько вы собираетесь приблизиться к этой точ-
точке? Вплотную, весьма далеко от нее или где-то в середине?
Вторая ось - время. Когда ваш проект завершится? Завершается ли он вместе
со сдачей выходного продукта? Или это произойдет, когда ваши заказчики нач-
начнут его использовать и присылать хвалебные отзывы? Или когда он покроет
расходы на разработку и начнет приносить вам прибыль? Точно так же для раз-
разрабатываемой системы - завершается ли проект, когда система передана пользо-
пользователям? Или когда пользователи освоили новую систему и чувствуют себя

Глава 1. Этап первый: наглядное представление цели - нацельтесь на приз 33
с ней достаточно комфортно? Или когда система принесла те деловые выгоды,
которые были заложены в бизнес-план? Или...? Определение момента заверше-
завершения проекта в значительной степени произвольно, т. е. предоставляется на ваше
усмотрение. Действительно важно то, что вы устанавливаете, что лежит в пре-
пределах проекта и что вне его; то, что вы знаете о том, какие элементы формируют
часть вашей цели и какие элементы определенно этого не делают.
Наконец, вопрос, который, кажется, очень редко задается, хотя, возможно, он
наиболее важен из всех - он образует третью ось. Выполненный проект может
быть оценен как плохой, средний, хороший, невыполненный плюс бесконечное
множество промежуточных оценок между вышеупомянутыми. Какова наилуч-
наилучшая возможная оценка с вашей точки зрения: счастливый финал в сказочном
духе, оценка, которая заставит всех "снять шляпы"? А кстати, кто эти "все"? Под
всеми я подразумеваю команду, ваше руководство и заказчика. Учитывая, что
проект может получить любую из всех этих возможных оценок, почему оста-
останавливаться на средней, в духе доползания до финиша, если можно заложиться
на большее?
Функциональность
Качество Время
Рис. 1.1.
Концептуально точки, которые вы выбираете на этих трех осях, задают точку
в трехмерном пространстве, которая представляет собой цель вашего проекта.
Анализ этих трех аспектов вашего проекта выявляет границы цели и определяет,
что лежит внутри и вне вашего проекта.
2 - 2224

34 Часть 1. Анализ и планирование проектов
ИСПОЛЬЗОВАНИЕ В РАЗРАБОТКЕ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Когда я писал первое издание этой книги, моя компания работала над проек-
проектом разработки крупного программного продукта для одной из ведущих теле-
телекоммуникационных компаний. По оценке полный проект требовал более 600
человеко-лет и должен был длиться несколько лет. Он находился на самой пред-
' варительной стадии сбора технических требований.
Была по крайней мере одна часть проекта - с объемом трудозатрат примерно
в 20 человеко-лет, - которая должна была быть завершена самое позднее к кон-
концу 1993 года. Давайте посмотрим на применение этапа 1 структурного руково-
руководства проектом к этой части работы.
Как я утверждал ранее, важно идентифицировать, чем должен кончиться про-
проект. До некоторой степени это может быть почти произвольное решение. На-
Например, мы могли бы объявлять концом проекта день отгрузки программы. Не-
Несколько лучшей идеей может быть объявление в качестве конечной даты дня
отгрузки плюс, скажем, три месяца. Это дало бы нам шанс увидеть, что заказчи-
заказчики думают о продукте. Давайте так и сделаем. Скажем, что мы ожидаем отпра-
отправить продукт в конце 1993 года, а тремя месяцами позже объявим о завершении
проекта. Этим мы подразумеваем, что переведем продукт в проект сопровожде-
сопровождения и доводки и проведем независимую проверку (см. главу 10) в качестве по-
последнего акта нашего проекта.
Таким образом, мы ожидаем, что это случится в конце марта 1994 года, при
условии что все будет в порядке. Давайте применим этап 1 в соответствии
с вопросником наглядного представления:
¦ Этот проект будет действительно очень важен для всех, кто занят в нем. Ор-
Организация, с которой работает моя компания, - совсем новая, и это будет их
первый крупный проект и поставка продукции. Все люди, работающие над
проектом, - новые для организации, и создать качественный продукт, уло-
уложившись при этом в сроки и бюджет, будет для них очень мощным стиму-
стимулом. Проект также позволит организации, с которой работает моя компания,
сказать своему заказчику (не говоря уже о своем вышестоящем руководстве):
"Мы можем делать это, мы оправдали доверие, которое вы оказали нам".
¦ Мы сосредоточились главным образом на том, какие продукты будут произ-
произведены в данном проекте. Для этого мы представили себе каталог программ-
программного обеспечения, в котором были перечислены по отдельности все компо-
компоненты, которые должны были быть произведены в проекте. Это была основ-

Глава 1. Этап первый: наглядное представление цели - нацельтесь на приз 35
ная программа, три дополнительных модуля и два набора документации. Ко-
Когда проект закончится, эти вещи должны быть переданы другим проектным
группам, которые будут создавать намного большую F00 человеко-лет) сис-
систему вокруг наших компонентов. Эти компоненты также в конечном счете
пойдут к конечному пользователю (заказчику), однако это произойдет в от-
отдаленном будущем.
¦ Мы уже говорили о том, что проект будет означать для членов проектной
группы и какой может быть их мотивация в выполнении проекта.
¦ Причиной, по которой я хочу сделать это, является то, что на данный момент
это самый большой проект, в котором будет применяться структурное руко-
руководство проектом. Я очень хочу увидеть, как оно будет работать.
¦ Какова будет жизнь через день/неделю, когда проект будет завершен? Этот
вопрос и другие подобные ему, которые позволяют вам создавать мечту, мы
обсуждали ранее. Хорошо, конечно, говорить о мотивациях, возвышенных
идеях и пр., но это вещи, которые могут со временем изменяться или уходить
из поля зрения. В то же время размышления о том, что вы будете делать од-
однажды в будущем, когда возникнет определенный набор обстоятельств, бу-
будут намного более конкретными и создадут представление, которое вы може-
можете зафиксировать и нести в себе.
¦ Какова же будет жизнь, когда этот проект завершится? Это будет день в кон-
конце марта. Заказчик получит продукт уже в течение трех месяцев после даты
сдачи, и мы будем знать по приходящим сообщениям об ошибках (или об их
отсутствии!), насколько он оказался успешным. Чего мы хотели бы, так это
чтобы не было никаких сообщений об ошибках. (У меня когда-то был такой
опыт; в течение шести месяцев не было сообщений об ошибках. Причем про-
программа действительно использовалась!)
¦ Вернемся к мечте: мы, вероятно, запланируем встречу на этот мартовский
день. Скорее всего, с тех пор как продукт будет отправлен, у нас будут регу-
регулярные рабочие встречи для того, чтобы знать, как идут дела у заказчика, но
в этот особый день встреча будет заключительной.
¦ Я, вероятно, встану рано, сделаю пробежку, а затем направлюсь в офис.
Я могу вообразить себе людей, которые будут на этой встрече - сотрудников
моей компании, людей из организации моего клиента и (вероятно) предста-
представителей заказчика, хотя более вероятно, что они подтвердят свою приемку
продукта электронной почтой, факсом или по телефону.

36 Часть 1. Анализ и планирование проектов
¦ Мы ожидаем, что весь день там будет много счастливых людей. Организа-
Организация-клиент, довольная хорошими отзывами заказчика о продукте и его на-
надежности; члены проектной группы, некоторые из них уже, возможно, назна-
назначены на другие проекты, но присутствуют здесь для участия в предпоследнем
акте этого проекта (последним будет независимая экспертиза); сотрудники
моей компании, довольные тем, что мы сделали то, что хотели.
¦ Встреча будет недолгой, обсудим ошибки, о которых сообщалось последние
три месяца, зафиксируем то, чему они нас научили, выявим, где ошибки про-
проскочили наши тесты, и выработаем меры, чтобы такие вещи не случались
снова. Возможно, будет шампанское или торт, или еще какой-нибудь не-
небольшой праздник. Может быть, кто-то выиграет пари (см. главу 15, решение
проблем!). Возможно, будут некоторые лестные комментарии о продукте, ко-
которые мы можем немного посмаковать. Возможно, будет праздничный ленч.
¦ Ладно, я уверен, что вы поняли идею. Это - картина, которую можно разно-
разнообразить, на бумаге или в голове, любыми эпизодами, людьми и словами. Что
здесь важно, так это понять, что вы будете чувствовать, когда проект закон-
закончится, потому что это даст вам стимул. Я знаю, что я буду чувствовать: гор-
гордость победы, счастье людей, которые так усердно работали, чтобы заставить
это случиться.
¦ Что же до того, что скажет независимая экспертиза, давайте запишем ответы
на вопросы экспертов, которые мы хотели бы дать.
¦ Мы закончили там, где и предполагали? Да. В точности. Достигнутая цель не
имеет существенных отличий в сравнении с запланированной. Она никогда
не изменялась, и мы постоянно знали, что и не изменится.
¦ Используя "карты распределения ресурсов" в главе 14 (альтернатива - отче-
отчеты, генерируемые используемым средством планирования проекта), мы фик-
фиксировали расхождения плана и реальности для проекта и могли анализиро-
анализировать их, чтобы понять, где наши оценки нуждаются в уточнении.
¦ Мы сможем сказать, что мы сделали очень многое правильно и совсем не-
немногое неправильно, и вот уроки, которые мы можем извлечь из того, что мы
делали неправильно.
¦ Мы сможем сказать, что в работе возникало очень немного неожиданностей
любого вида; и снова о том, что из них мы извлекли уроки на будущее.

Глава 1. Этап первый: наглядное представление цели - нацельтесь на приз 37
¦ Мы сможем сказать, что нам не пришлось выходить за границы прогнози-
прогнозируемых ошибок; а если мы иногда их достигали, то опять-таки извлекли из
этого уроки.
¦ Все это вещи, которые мы хотели бы сказать при будущей экспертизе нашего
проекта.
¦ Для моей компании этот проект будет главным трофеем, и я надеюсь, что мы
можем использовать его как трамплин к другим, более крупным проектам.
Я надеюсь, что люди будут говорить, что только компания, подобная моей,
могла сделать проект так здорово. Я надеюсь, что люди будут говорить о том,
что работать над этим проектом было одно удовольствие и что они хотели бы
работать с моей компанией снова.
¦ Изменился ли мой уровень жизни? Бросьте, руководство проектом не столь
хорошо оплачивается!
¦ Я не думаю, что изменится моя самооценка, однако для относительно новой
компании подобно моей приятно добавить что-нибудь такое к своему по-
послужному списку. Я думаю, задача, которую мы поставили, достаточно труд-
трудна и в ней много места для неудач. Я не мог бы перенести, если бы этот про-
проект потерпел неудачу.
Остающиеся вопросы мы, вероятно, охватили в этом нашем "потоке созна-
сознания". Не обязательно ответить на все из них, более существенно, чтобы вы по-
постигли мыслительный процесс, стоящий за ними. Если вы закончили с мечтами,
которые начали крутиться в вашей голове, то, вероятно, можете активно продви-
продвигаться к следующему этапу.
ВКЛАД В PSI
Этап 1 дает 20 пунктов в PSI. Вы можете считать 20 максимальной оценкой
того, насколько точно сформулирована цель проекта. Вначале, когда цель про-
проекта представляет всего лишь смутную идею в головах людей, вместо 20 оценка
будет близка или равна 0. Сама же оценка 20 достигается только в день закрытия
проекта. Только тогда вы будете знать точно, чем оказалась цель проекта.
Вес этапа 1 изменяется в диапазоне 0-20 на протяжении жизни проекта.
Предположим, например, что цикл жизни вашего проекта имеет ряд следующих
стадий:
¦ сбор технических требований,
¦ проектирование,

38 Часть 1. Анализ и планирование проектов
¦ реализация,
¦ сборка,
¦ тестирование,
¦ выпуск.
Тогда PSI постепенно увеличивается по мере завершения каждой из этих ста-
стадий. Если интерпретировать вес как меру того, насколько четкой стала цель про-
проекта в результате каждой стадии, то вы можете присвоить оценки каждой из
этих шести стадий следующим образом:
Сбор технических требований
Проектирование
Реализация
Сборка
Тестирование
Выпуск
4
9
14
17
19
20
Чтобы использовать PSI для собственных проектов, необходимо аналогич-
аналогичным образом распределить 20-балльную оценку по стадиям цикла вашего проек-
проекта. Помните, основной метод состоит в анализе того, насколько четче стала цель
проекта в результате каждой стадии.
Альтернативный вариант состоит в разбиении цели проекта на блоки и на-
назначении каждому блоку максимально допустимой оценки таким образом, что-
чтобы сумма этих максимальных оценок по всем блокам составляла бы 20.
СТРУКТУРНОЕ УПРАВЛЕНИЕ ПРОЕКТОМ
Планирование проекта
1. НАГЛЯДНО ПРЕДСТАВЬТЕ СЕБЕ ЦЕЛЬ;
НАЦЕЛЬТЕСЬ НА ПРИЗ.

ГЛАВА 2
Этап 2: СДЕЛАЙТЕ СПИСОК ЗАДАЧ,
ПОДЛЕЖАЩИХ ВЫПОЛНЕНИЮ
ВВЕДЕНИЕ
Как-то у меня был босс родом с севера Англии. Никакой проект не отпугивал
его, будь то разработка программного обеспечения или переделка дома. Я ездил
домой с работы мимо дома, который он тогда перестраивал. Часто, причем
в любую погоду, его дети помогали ему: сгребали мусор, смешивали бетон, пе-
переносили вещи.
"Делайте список работ, которые нужно сделать" - было одним из его люби-
любимых высказываний. Он также называл своих детей салагами1. В работе мы со-
соединили эти его словечки вместе и придумали: "Сделай список задач и отдай
салагам", причем произносилось это с йоркширским акцентом. Это выглядело
главным объяснением того, как он успел в своей жизни сделать так много.
"Сделай список задач и отдай салагам" - составьте список задач, которые
нужно выполнить, и вы получите план вашего проекта. Есть только одна труд-
трудность: а что, если вы не знаете всего, что должно быть сделано?
Нет проблем. Рискуя достать вас ссылками на полярную экспедицию, скажу
снова, что проект очень похож на путешествие по однообразной пустынной ме-
местности. Вы знаете, куда хотите добраться и общее направление движения, но не
имеете ни малейшего понятия, что лежит между "здесь" и "там"; все, что можно
видеть, - это горизонт. Полярные путешественники в этом случае направляются
к некоторому ориентиру на этом горизонте. Только добравшись до него, можно
решать, как выбрать следующий отрезок пути.
Точно так же обстоит и с проектами. Самое первое, что нужно сделать при
запуске нового проекта, - это составить план. Даже если вы можете записать
одну или две первых задачи, вы уже продвигаетесь вперед. Доберитесь до этого
первого ориентира на горизонте, затем оцените, что нужно сделать далее. Вы
всегда будете знать весьма много подробностей, лежащих между вами и первым
горизонтом, даже при том что сюрпризы неизбежны. Для остальной части про-
1 В оригинале "sprogs", и одно из значений действительно представляет собой сленговое название
новичка в английских ВВС. Похоже, автор не был чужд "дедовщины". -Прим. переводчика.

40 Часть 1. Анализ и планирование проектов
екта достаточно, чтобы вы наметили в самом общем виде остающиеся промежу-
промежуточные ориентиры (горизонты) пути.
Придет время, когда придется прогнозировать остаток проекта, однако по-
постарайтесь оттягивать этот момент как можно дольше, пока вы не соберете мак-
максимально возможное количество информации, на базе которой придется прини-
принимать решения.
В компьютерной индустрии мы называем эти прогнозы НИП - научно-
идиотическими предположениями', - но, как мы увидим, это не так плохо, как
кажется. Да, вам действительно приходится только предполагать, однако, срав-
сравнивая свои ранние предположения с тем, что на самом деле произошло, можно
оценить, насколько точны ваши предположения, и соответственно корректиро-
корректировать план.
Ваш план становится компасом, с помощью которого вы направляете проект.
При достижении очередного горизонта вы проверяете лежащие перед вами зем-
земли, а затем устремляетесь к новому горизонту. Этап 2 нашего метода - "Сделать
список задач, которые надо выполнить".
Список может быть в любой форме. Это может быть настоящий список, по-
подобный списку покупок в магазине, он может быть включен какой-нибудь про-
программный пакет планирования проектов - мы делаем так для большого количе-
количества наших программных проектов, он может быть графиком. Многие крупные
компании имеют определенный стандарт и формы для плана проекта, и вам, ве-
вероятно, придется придерживаться их. Не важно, как это выглядит внешне. Не
имеет значения, что вы еще не знаете все задачи, которые надо выполнить. За-
Запишите те задания, которые, как вы знаете, должны быть выполнены, чтобы за-
запустить проект, а разглядывание деталей в магическом хрустальном шаре ос-
оставьте до того момента, когда вы почувствуете себя лучше информированным.
Полностью быть уверенным в своих прогнозах нельзя никогда. В некоторых
ситуациях, например в бизнесе или в военном деле, вам, скорее всего, придется
делать прогнозы, зная при этом, что в первом случае ценой неверного прогноза
может быть ваша работа, а во втором - человеческие жизни. Несомненно, мно-
многие проекты затрагивают серьезные вещи, и многим руководителям проектов
приходится принимать решения, влияющие на карьеры и/или жизни людей.
Еще один аспект задач - задачи должны быть ясными. Обдумайте или запи-
запишите последовательность событий, которые должны произойти для того, чтобы
поставленная задача была выполнена. Если вы не можете сделать этого или де-
делаете кое-как, то весьма вероятно, что задача недостаточно ясна для вас. Часто
В оригинале SWAGs - scientific wild-ass guesses. -Прим. переводчика.

Глава 2. Этап второй: создайте список задач, подлежащих выполнению 41
это связано с тем, что то, что вы считаете одной задачей, на деле представляет
собой набор задач. В этом случае надо детализировать исходную задачу. Помни-
Помните, что задачи могут быть по своей природе: (а) последовательными - задача
А должна быть выполнена прежде, чем может начать выполняться задача В; (б)
параллельными - задачи А и В могут выполняться в одно и то же время; (в) со-
составными - задача А на самом деле состоит из ряда подзадач, и все они должны
быть выполнены прежде, чем задача А может рассматриваться как выполненная.
(Присматривайте за этими мелочами - именно они добьют вас, если вы не буде-
будете аккуратны.)
КОНТРОЛЬНЫЕ ВОПРОСЫ
При составлении списка задач то, о чем написано ниже, может помочь вам
удостовериться, что все возможные задачи и сферы деятельности охвачены.
Предположив, что исходный перечень работ составлен, проверьте следующие
аспекты:
¦ Требуемые ресурсы (оборудование, комплектующие, услуги, средства).
¦ Требуемые навыки, и подразумевают ли они наем и/или обучение персонала.
¦ Перечень содержит ясные, отчетливо идентифицируемые вехи (этапы).
¦ Временные графики, расходы и финансовые сметы обосновывают ваши оценки.
¦ Ваши предположения (прогнозы) явно указаны.
¦ Четко указано, как зависит проект от тех вещей, которые не контролируются
вами.
¦ Явно указано, кто за что отвечает.
¦ Области высокого риска хотя бы обозначены.
ОПРЕДЕЛЕНИЕ ЗАДАЧ ПО ФОРМЕ 1
Форму, показанную на рис. 2.1, можно использовать для облегчения иденти-
идентификации всех задач в проекте. Сам проект вписывается в самое верхнее поле
формы, а ниже последовательно перечисляются задачи, которые составляют
проект. В силу нашего рекурсивного определения проекта любая задача может
быть разбита на подзадачи посредством вписывания ее в самое верхнее поле
формы.

42 Глава 2. Этап второй: создайте список задач, подлежащих выполнению
Форма 1
Проект
Задачи .
Задачи .
Задачи .
Задачи .
Задачи .
Задачи .
Задачи .
Задачи .
Рис. 2.1. Форма 1, список задач
ИСПОЛЬЗОВАНИЕ В РАЗРАБОТКЕ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Как только проект показывает любые признаки шевеления, для нас наступает
время создания его списка задач. Как мы уже обсудили, список должен быть дета-
детализирован до первой контрольной точки (завершения первого этапа) и содержать
последующие основные контрольные точки. Кроме того, можно добавить любые
другие доступные подробности для оставшихся контрольных точек. Это не обяза-
обязательно, но, учитывая, что такие подробности нам известны и что рано или поздно
нам все равно придется их записывать, почему бы не сделать это именно теперь.
Преимущество такого подхода состоит в том, что мы начинаем чувствовать объем
оставшейся части проекта. (Мы возвратимся к этой идее в приложении 1.)
В двух следующих подразделах я привожу примеры списков задач из реаль-
реальной жизни. Проект для Telecom Ireland Software (TIS) содержал четыре основ-
основные задачи (вспомните наше рекурсивное определение проекта):
¦ решение о вводе в организации ISO 9001,
¦ организационные мероприятия,
¦ создание и внедрение системы управления качеством,
¦ подача заявки на сертифицирование.
Первая задача разбивалась на четыре подзадачи, и оценочно на них было от-
отведено всего пять человеко-дней. Остаток списка задач дает нам всю доступную

Глава 2. Этап второй: создайте список задач, подлежащих выполнению 43
информацию об остальной части проекта. Обратите внимание, что я всюду, где
это возможно, опускаюсь к очень подробным уровням описания. Это основа на-
нашего метода оценивания в приложении 1.
Пример 1: предварительный план получения
сертификации по ISO 9001
Этот пример представляет собой проект получения сертификата соответствия
стандарту ISO 9001 (Rothery, 1991).
1. Решение о внедрении стандарта ISO 9001
Разработка положения о политике контроля качества, одобрение ее на прав-
правлении TIS и доведение до каждого сотрудника в ACME Software. Оценка трудо-
трудозатрат - 20 человеко-дней. Включает:
¦ Разработка положения.
¦ Внутреннее обсуждение в компании.
¦ Сбор правления компании для одобрения.
¦ Доведение документов до сведения каждого сотрудника.
¦ Обучение, т. е. комитет по стандартам (на видео или в другой доступной
форме) предоставляет вводный курс, постоянно действующие курсы обуче-
обучения контролю качества, информационное освещение программы контроля
качества, ее аспектов и результатов.
2. Организационные мероприятия
¦ Назначение управляющего (менеджера) по контролю качества.
¦ Формирование группы совершенствования системы контроля качества.
3. Создание и внедрение системы контроля качества
Этап включает внедрение и рабочую эксплуатацию системы, которая описана
в руководстве. Эта работа состоит из двух частей: написание руководства, опи-
описывающего систему контроля качества ("документировать, что делать"), плюс
внедрение и эксплуатация системы, описанной в руководстве ("делать то, что
документировано").
Эти две части работы обычно могут быть выполнены параллельно. Структура
для руководства по контролю качества уже составлена. Большая часть работы,
включенная в процедуру получения ISO 9001, состоит в разработке системы, ее
реализации и документировании в рамках структуры руководства.

44 Часть 1. Анализ и планирование проектов
Основной объем оставшейся части этого документа оценивает объем задачи,
как в терминах процедуры разработки/внедрения, так и в терминах документи-
документирования в руководстве по контролю качества. Некоторые замечания относитель-
относительно внедрения системы:
¦ было бы полезно обсудить содержание руководства по качеству с комитетом
по стандартам или экспертом/консультантом по контролю качества;
¦ план должен включать до десяти человеко-дней на консультанта;
¦ обязательными элементами в реализации системы контроля качества являются:
- измерение качества продукции и процессов ее производства,
- калькуляция стоимости качества,
- внесение корректив на основе вышеуказанных измерений.
Примечание: В следующем примере все оценки приводятся в человеко-днях.
Раздел в руководстве по контролю качества Процедура Процедура
разработки/внедрения документирования
1. Введение
1.1. Описание компании взять из 0 0,5
маркетинговых брошюр
1.2. Место руководства по контролю 0 0
качества в общей деятельности -
написано
1.3. Положение о качестве (взять из п. 1 20 1
выше) и программа обучения
1.4. Использовать организационную 0 0
структуру TIS
1.5. Определить процедуру внесения 0,5 0.5
изменений
1.6. Список и процедура рассылки 0,5 0
Всего 21 2
2. Документирование
2.1. Использование документа Майлса 0,5 0,5
2.2. Использование документа Майлса 0,5 0,5
2.3. Документооборот B документа)
- Написание 5
- Рецензирование 1
- Обновление 2
- Принятие 1

Глава 2.
Раздел е
Этап второй: создайте список задач,
i руководстве по контролю качества
- Публикация
Всего
подлежащих выполнению
Процедура
разработки/внедрения
1
11
45
Процедура
документирования
1
2
3. Управление проектами
3.1. Методология управления проектами 1 4
(принять? Документировать связанное
с книгой. Критерий завершения
проекта, пример плана проекта)
3.2. Оценивание и календарное 1 4
планирование (Документировать
связанное с книгой и MS Project.
Включить примеры. Историческая БД )
3.3. Контроль и отчетноаь (требует EV-систе- 5 б
мы; отчет о текущем состоянии проекта);
пример доклада о прогрессе проекта)
Включить табели учета рабочего 1 1
времени и запись времени
Всего 8 15
4. Цикл жизни проекта
4.1. Описание 0 1
4.2. Спецификация требований О
- Исследование 1
- Документирование (включая 2
поставляемые результаты, крите-
критерии рецензирования/завершения,
шаблон)
- Анализ (возможно при
использовании)
- Доработка 1
- Выпуск 0,5
4.3. Разработка верхнего уровня
- Исследование 1
- Документирование (включая 2
поставляемые результаты, крите-
критерии рецензирования/завершения,
шаблон)
- Анализ (в идеале при
использовании)
- Доработка 1
- Выпуск 0,5

46
Часть 1. Анализ и планирование проектов
Раздел в руководстве по контролю качества
Процедура
разработки/внедрения
Процедура
документирования
4.4. Разработка нижнего уровня (включая
пользовательскую документацию
и планы тестирования)
- Исследование
- Документирование (включая
шаблон)
- Анализ (в идеале при
использовании)
- Доработка
- Выпуск
0,5
4.5. Реализация (включая кодирование,
тестирование модулей, сборку
и тестирование)
- Исследование (включая папки
разрабатываемых модулей (UDF1),
прогонку и т. п.)
- Документирование (включая
поставляемые результаты, крите-
критерии рецензирования/завершения,
шаблон)
- Анализ (в идеале при
использовании)
- Доработка
- Выпуск 0,5
4.6. Альфа-тестирование
- Исследование
- Документирование (включая
поставляемые результаты, крите-
критерии рецензирования/завершения,
шаблон)
- Анализ (в идеале при
использовании)
- Доработка
- Выпуск 0,5
4.7. Бета-тестирование
- Исследование
Unit development folder. - Прим. переводчика.

Глава 2. Этап второй: создайте список задач, подлежащих выполнению 47
Раздел в руководстве по контролю качества Процедура Процедура
разработки/внедрения документирования
- Документирование (включая 3
поставляемые результаты, крите-
критерии рецензирования/завершения,
шаблон)
- Анализ (в идеале при
использовании)
- Доработка 1
- Выпуск 0,5
4.8. Техническая эксплуатация
и обслуживание
- Исследование 2
- Документирование (включая постав- 3
ляемые результаты, критерии рецен-
рецензирования/завершения, шаблон)
- Анализ (в идеале при использовании) -
- Доработка 1
- Выпуск 0,5
4.9. Управление структурой и контроль
изменений
- Исследование 3
- Документирование (включая постав- 5
ляемые результаты, критерии рецен-
рецензирования/завершения, шаблон)
- Анализ (в идеале при
использовании)
- Доработка 1
- Выпуск
Всего
5. Счета и бухгалтерия
Приблизительная оценка
б. Обучение
Будем ссылаться на план обучения TT.S
(оценивается отдельно)
7. Субподрядчики
Приблизительная оценка
8. Заказы и запросы
Не требуется ISO 9001, но имеет смысл
включить. Включает список перспектив
Приблизительная оценка
0,5
4
3
1
1
3
48
5
1
10
5

48 Часть 1. Анализ и планирование проектов
Раздел в руководстве по контролю качества
9. Персонал
9.1. Общая деятельность [компании]
9.2. Структура организации - уже есть
9.3. Описания квалификационной
шкалы/должностных инструкций
9.4. Нормативы окладов
Всего
10. Непосредственно система контроля
качества
10.1. Внутренние экспертизы - анализ/об-
анализ/обновление процедур (качество)
10.2. Стоимость качества - поддержка
учетных записей по контролю качества
(оценочно)
Всего
Процедура
разработки/внедрения
5
0
10
10
25
5
5
10
Процедура
документирования
5
0
20
10
35
5
5
10
4. Заявка на сертификацию
Последовательность событий здесь следующая:
Проведение внутренней экспертизы (возможно, ряда экспертиз) 20
Направление заявочной формы и копии руководства по контролю качества (QM1) 2
Комитет по стандартам исследует QM и уведомляет TIS обо всех 20
несоответствиях, которые должны затем быть исправлены
После исправления комитет по стандартам производит экспертизу 30
непосредственно в TIS и вновь выявляет несоответствия
Комитет по стандартам проверяет, что соответствующие коррективы 10
сделаны, и рекомендует выдать сертификат ISO 9001
Всего 82
Пример 2: план проекта разработки программного
обеспечения
Второй пример - проект разработки программного обеспечения, который по-
показан на рис. 2.2. Этот список задач был сделан с помощью пакета MS Project.
Не тратьте слишком много времени, вникая в детали этих картинок (хотя бы
потому, что они не закончены2, так что не предполагайте, например, что вы по-
1 Quality manual. -Прим. переводчика.
2 По этой же причине названия задач не переводились. - Прим. издателя.

Глава 2. Этап второй: создайте список задач, подлежащих выполнению 49
лучите сертификат ISO 9001, следуя им!). Это просто мгновенные снимки про-
проектов в отдельные моменты времени. Они даются здесь, чтобы проиллюстриро-
проиллюстрировать следующие важные аспекты создания списка задач:
¦ Используйте средства планирования проектов, такие как MS Project, если
есть возможность - они дают гораздо большую ясность, что, как я думаю, ил-
иллюстрируется различием между планами примера 1 и примера 2. Усилия, за-
затраченные на изучение и ввод информации в них, стократно окупятся пони-
пониманием, гибкостью, скоростью реакции и широтой восприятия, которые даст
эта компьютерная модель вашего проекта. Став с возрастом более уверенным
в себе, я осмелюсь предположить, что любой, кто не использует такие вещи,
ненормален!
¦ Записывайте главные контрольные точки (ориентиры, промежуточные этапы).
¦ Распишите первый промежуточный этап с максимальной подробностью.
¦ Распишите остающиеся этапы с максимально доступной степенью детализа-
детализации (можно использовать вопросник, который приводился выше, для облег-
облегчения этой задачи).
А о каком уровне детализации идет речь? Это то, что, кажется, всегда вызы-
вызывает у людей проблемы. Ну что ж, заметим, что в данном примере объем трудо-
трудозатрат - 500 человеко-дней. Список задач содержит 237 позиций. Это означает,
что в среднем каждая задача занимает от двух до трех человеко-дней. В более
общем случае, по моему мнению, приемлемый уровень подробности, к которому
нужно стремиться, лежит где-то между одним и пятью человеко-днями. Да по-
после этого же спину не разогнешь! Согласен. Однако это - единственный путь,
который может гарантировать успех вне зависимости от того, насколько велик
проект, обеспечить, чтобы каждый компонент был спланирован и отслежен кем-
то до уровня каждого дня. Это не обязательно должны быть вы, и на большом
проекте этого не будет, но кто-то должен делать это.
Я знаю, что нижесказанное является абсолютной истиной: когда вы нарушае-
нарушаете это правило, любые проекты заканчиваются множеством случаев, когда Джо
Мыло или Джилл Блоггс проводят два дня здесь или полдня там, выполняя зада-
задачу А до задачи В. Теперь у вас как у руководителя проекта есть две критические
проблемы, требующие решения. Это: A) собираемся ли мы сознательно решать,
кто будет работать над чем и когда? и B) если так, когда мы будем принимать
такие решения?
Первая проблема не столь бессмысленна, как это кажется. Все руководители
проектов оперируют с распределением работ, которые более или менее детали-

50 Часть 1. Анализ и планирование проектов
зированы. В этом случае интуитивно предполагается, что это распределение
и обуславливает "два дня здесь/полдня там", о котором мы только что говорили.
Если это так, хорошо. Но если не так, то это означает, что некая сила, отличная
от руководителя проекта - назовем ее Жизнью, - производит такое распределе-
распределение работ. Распределение работ (задач) все равно произойдет, не бойтесь, пото-
потому что, если вы его не сделаете, Жизнь сделает это за вас. Однако одна из осо-
особенностей Жизни состоит в том, что ее распределение может быть неправильным,
и, положившись в этом деле на Жизнь, вы напрашиваетесь на неприятности.
Давайте посмотрим на вторую проблему. В результате вы сознательно соби-
собираетесь распределять ваших людей по задачам, но когда надо это делать? Ну, тут
у вас есть выбор. Можно сделать это в начале на стадии планирования проекта,
когда обстановка относительно спокойна, а можно сделать это в середине про-
проекта, в пылу сражения, когда падают бомбы и земля разверзается под ногами.
Вы должны будете сделать это, так почему бы не облегчить себе жизнь и сде-
сделать все, что можно, вначале, когда давление не слишком велико? И не волнуй-
волнуйтесь, что это не доделано, потому что, как и прежде, Жизнь вмешается и додела-
доделает за вас. Но опять-таки такая помощь вам нужна так же, как дополнительная
дырка в голове.
Давайте попробуем подытожить все то, что мы говорили здесь об уровнях де-
детализации. Вероятно, в наиболее известной книге по руководству программны-
программными проектами "The Mythical Man-Month" (Brooks, 1975) есть интересное наблю-
наблюдение: "Когда слышишь о катастрофическом отставании проекта от графика,
то представляется ряд обрушившихся на него больших бедствий. Однако обыч-
обычно причиной катастрофы служит..." Что? "...отставание от графика каждый
раз еще на один день".
Знайте, куда уходят ваши человеко-дни, каждый из них. Тратьте их мудро.
Если вы не делаете этого, то быстро убеждаетесь, сколь переменчива Жизнь.
Однажды на семинаре я развивал идею относительно разработки плана до
ежедневного уровня, и кто-то спросил, не вызовет ли это неприемлемого уровня
затрат. Более конкретно, вопрос состоял в том, оценил ли я соотношение трудо-
трудозатраты/стоимость в управлении проектом Скотта против такового у Амундсена.
Есть два ответа на этот вопрос. Первый состоит в том, что, если принять, что
и Скотт и Амундсен сами осуществляли все руководство своими проектами, то
объем трудозатрат у обоих почти в точности одинаков - три года. Второй ответ,
причем он не претендует на утонченность, таков. Амундсен осуществил успеш-
успешный проект. Таким образом, сколько бы ни стоило управление им, оно стоило
этого. Цена проекта Скотта - жизни пяти человек. Для такой цены не может
быть недопустимого уровня затрат.

Глава 2. Этап второй: создайте список задач, подлежащих выполнению 51
ВКЛАД В PSI
Этап 2 дает до 20 баллов в PSI. Вы можете думать об оценке в 20 баллов как
о мере того, насколько полон и правилен, или наоборот, план проекта. Вначале,
когда проект только запускается, план, вероятно, не содержит ничего, кроме
главных контрольных точек с добавлением некоторых, скорее всего неполных,
деталей. Тогда оценка будет очень низкой. В день, когда проект завершается,
план будет полным и будет содержать мириады малых задач, объединенных
в единое целое, которое и есть осуществление проекта. Это единственное время,
когда оценка может достигать 20 баллов.
Таким образом, между началом и концом проекта оценка изменяется в преде-
пределах диапазона 0-20. Теперь предположим, что ваш цикл жизни проекта имел ряд
стадий, скажем:
¦ сбор технических требований,
¦ проектирование,
¦ реализация,
¦ сборка,
¦ тестирование,
¦ выпуск.
PSI постепенно увеличивается по мере завершения каждой из этих стадий.
Если считать оценку мерой того, насколько вы ближе к знанию всех задач, кото-
которые должны быть выполнены для завершения проекта, то можно присвоить
оценку каждой из этих стадий следующим образом:
Сбор требований
Проектирование
Выполнение
Сборка
Тестирование
Выпуск
4
9
и
17
19
20
Чтобы использовать PSI для собственных проектов, необходимо аналогич-
аналогичным образом распределить 20-балльную оценку по стадиям цикла вашего проек-
проекта. Помните, эта оценка - мера того, насколько вы близки к знанию всех задач,
которые должны быть выполнены, чтобы завершить проект.
Как и прежде, альтернативный вариант состоит в разбиении плана проекта на
субпланы для каждого из его индивидуальных компонентов. Затем каждому

52
Часть 2. Анализ и планирование проектов
субплану назначается максимально допустимая оценка таким образом, чтобы
сумма этих максимальных оценок по всем субпланам составляла 20.
СТРУКТУРНОЕ УПРАВЛЕНИЕ ПРОЕКТОМ
Планирование проекта
1. НАГЛЯДНО ПРЕДСТАВЬТЕ СЕБЕ ЦЕЛЬ; НАЦЕЛЬТЕСЬ НА ПРИЗ.
2. СДЕЛАЙТЕ СПИСОК ЗАДАЧ, ПОДЛЕЖАЩИХ ВЫПОЛНЕНИЮ.
ю
5
6
7
«
10
11
12
13
14
15
16
17
18
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
Task Name
Переделка
Подсистема В
Функциональные возможности, проектирован!
Реализация, тестирование модуля
Переделка
Структуры данных
Подсистема С
Функциональные возможности, проектирована
Реализация, тестирование модуля
Переделка
Подсистема D
Функциональные возможности, проектирован!
Реализация, тестирование модуля
Переделка
Спецификация базы данных.
Представление
Работа с существующей базой данных
Переделка
Система отчетов
Исследование отчетов
Спецификации
Реализация
Решения по документированию
Решения по оборудованию
Перенос на новое оборудование
Конец разработки
Тестирование Системы
Устранение ошибок
Выпуск версии 1
Поставка заказчику
Загрузка данных
Duration
35 days
29 days
lday
23 days
5 days
20 days
35 days
4 days
29 days
2 days
58 day.
27 days
20 days
5 days
111 days
lday
18 days
15 days
112 day»
14 days
3 days
15 days
Odays
Odays
10 days
lday
21 days
21 days
lday
lday
lday
1999 1 Qtr 1, 2000
Nov | Dec_J_bnJ Feo | Mar
С*2, 2000
Apr 1 May I Jun
¦¦¦hi
¦вР^Ч
hi
%
Щ
¦b
H
Щ
I
LJ
TbSiiiiJbsVI
ih •
И
1 i Wn
''¦¦ Ш
Я»
, ,
Ш| ¦
: В-Ы.01 I
Щ 14.01
r ¦ :
i 1 '¦¦¦
\ ВЯЯ
\ ¦¦¦
1
1
1
Рис. 2.2. Пример плана проекта

ГЛАВА 3
Этап 3: ДОЛЖЕН БЫТЬ ОДИН РУКОВОДИТЕЛЬ
ВВЕДЕНИЕ
"Ну конечно, есть руководитель, - слышу я вас. - Это первое, что мы делаем,
когда запускаем новый проект. Мы назначаем руководителя".
И это действительно может быть правдой. Что бы ни говорилось о большинст-
большинстве проектов, с которыми мы сталкиваемся, мы можем практически всегда иденти-
идентифицировать их руководителя. И разве это не весьма приятно звучащий титул, что-
чтобы присвоить его кому-то или иметь самому? "Руководитель проекта", "Лидер
проекта". Это титул, который легко ложится на плечи подобно хорошему пальто.
Мы становимся чуть выше от ответственности и нагрузки, которую мы теперь
несем. Да, действительно, мы можем всегда указать руководителя проекта - если
даже нет других признаков, мы всегда можем отличить его по походке!
Позвольте мне вновь сформулировать заголовок главы. Проект должен иметь
одного руководителя. Под этим я подразумеваю, что у него не может не быть
руководителя и что у него не может быть двух руководителей или комитета ру-
руководителей. Должен быть один руководитель.
Давайте посмотрим на это утверждение немного поближе. Когда я говорю
о руководителе, я подразумеваю не столько человека с титулом, сколько челове-
человека, который твердо намерен осуществить проект. Он живет, ест и дышит проек-
проектом. Он намерен выполнить его или умереть. В любое время он держит руку на
пульсе проекта и знает, как он идет. Его имя так тесно сливается с проектом, что
когда вы думаете об одном, вы думаете о другом. Весьма неверна интерпретация
его как человека, чей зад пришпилен к проекту и кого обязательно уволят, если
проект не будет сделан. В терминологии других книг он - чемпион проекта.
Я работал над проектом, где не было никакого лидера в том смысле, который
я описал выше. Я работал над другим проектом, где был формальный руководи-
руководитель и был человек, ставший неформальным лидером, что привело к наличию
двух руководителей проекта. Оба проекта были абсолютными катастрофами.
В первом случае человек с титулом руководителя проекта был уволен, а во вто-
втором были уволены и формальный, и неформальный руководители проекта.
Как вы можете видеть из нижеприведенных примеров, иногда проблема состоит
в том, чтобы найти нужного человека, и иногда конкурентов слишком много.

54 Часть 1. Анализ и планирование проектов
Пример 1
Одна из вещей, которая может случиться с вами как с руководителем проек-
проекта, состоит в том, что ваше лидерство может оспариваться другим членом ко-
команды. Это означает, что кто-то еще пытается стать неформальным лидером
проекта, отобрать у вас власть. Если это произойдет, вы должны нейтрализовать
вызов. Если вы этого не сделаете, все закончится проектом с несколькими руко-
руководителями.
У Амундсена как руководителя проекта был соперник во время его экспеди-
экспедиции на Южный полюс в 1911 году (Amundsen, 1912; Huntford, 1993). Один из его
людей, Хьялмар Йохансен (Hjalmar Johansen), сам был полярным исследовате-
исследователем. Он участвовал в более ранней экспедиции с Фритьофом Нансеном (Fridtjof
Nansen), родоначальником норвежских полярных исследований, и вместе они
сделали бросок на Северный полюс. Они не достигли его, но добрались на 170
миль дальше, чем кто-либо еще, достигнув 86° 14' северной широты. Амундсен
неохотно взял Йохансена в свою экспедицию, уступив просьбе Нансена.
С начала экспедиции Амундсена Йохансен начал сравнивать ее с экспедицией
Нансена, причем в пользу последнего. Йохансен был лучшим лыжником и по-
погонщиком собак, чем Амундсен, и чувствовал, что он знает больше о полярных
экспедициях. Часто он поправлял Амундсена, возражал ему, давал советы. Все это
вышло на передний план позднее, когда Амундсен нацелился на поход к полюсу.
Амундсен стремился двигаться к полюсу, его мучила мысль, что Скотт мог уже
стартовать и что у Скотта есть моторизованный транспорт. Его коллеги, и особен-
особенно Йохансен, предостерегали от слишком раннего старта. Амундсен хотел начать
24 августа, но, дважды поставив вопрос на голосование и проиграв, он отступил.
Наконец, 8 сентября 1911 года, когда все еще была полярная зима, Амундсен не
смог удержаться, и группа людей, саней и собак стартовала с их базы.
Начало оказалось катастрофой. Температура резко упала; собаки умирали от
холода; жидкость замерзала в компасах; и люди в конце концов повернули об-
обратно. Во время завтрака, после того как они все возвратились, Йохансен при-
призвал Амундсена к ответу за то, что произошло. Это посягательство на авторитет
руководителя оказалось для Амундсена невыносимым, Йохансен был исключен
из группы, идущей к полюсу. Несколькими годами позже он покончил жизнь
самоубийством.

Глава 3. Должен быть один руководитель 55
Пример 2
Я заявил, что отсутствие руководителя (лидера) гарантирует неудачу. К не-
несчастью, обратное утверждение неверно: наличие лидера не гарантирует успех.
Скотт (Huntford, 1993) - актуальный пример. Он обладал всеми качествами, ко-
которые я указал выше. Он жил, ел и дышал проектом. Он собирался выполнить
его или умереть. Скотт достиг Южного полюса месяцем позже Амундсена и по-
погиб со всеми четырьмя людьми из своей группы на обратном пути.
В терминах структурного руководства проектом это было неудачным выпол-
выполнением Скоттом этапов 2, 5, 6 и 8, что и решило его судьбу. Повторю, должен
быть один руководитель. Не нуль, не два и не комитет. Я уверен, что ваш проект
потерпит неудачу, если это не так.
Пример 3
Я помню мой первый день на работе в новой компании. Мне дали копию
книги состояния проектов. В соответствии с названием книга содержала состоя-
состояние каждого проекта в организации. Она обновлялась еженедельно, была хоро-
хорошо составлена и очень мила. Каждая страница наверху имела некоторую сум-
суммарную информацию о проекте; название, начальные и конечные даты, руково-
руководителя проекта и так далее.
Я был поражен, увидев одну и ту же горстку имен во всех полях, связанных
с руководством проектов. Там были люди, занимавшиеся десятью, пятнадцатью
проектами. Я тогда был молод, и это меня очень впечатлило; я думал, что эти
парни должны быть абсолютными суперменами, чтобы быть во главе стольких
вещей. И только позже я обнаружил, что они не были во главе всего этого и что
их имена там в заголовке не означали ничего. Конечно, они были ответственны-
ответственными лицами, возможно даже, они отвечали за эти проекты своими головами, одна-
однако, совершенно очевидно, что не они вели их. Должен быть один руководитель.
Пример 4
Одна из идей, с которой я несколько раз сталкивался в программных проектах,
состоит в том, что допускается наличие технического руководителя и организаци-
организационного или административного руководителя. Организационный руководитель
скорее человек административного, управленческого типа, не интересующийся
техническими проблемами, в то время как технический лидер не хочет быть
управленцем, однако хочет иметь большее право голоса в решаемых задачах.

56 Часть 1. Анализ и планирование проектов
Забудьте об этом. Если нет одного руководителя с правом последнего ре-
решающего голоса, то этот подход в стиле Лаурела и Харди (Laurel and Hardy) не
будет работать. Должен быть один руководитель.
РОЛЕВАЯ МОДЕЛЬ
Если мы ищем модель роли руководителя проекта, лучше всего посмотреть
что-нибудь из старых вестернов о перегонке скота с Джоном Уэйном (John
Wayne) в роли босса погонщиков. (Можно также прочесть роман "Lonesome
Dove" (McMurtry, 1990)). Думаю, вы все знакомы со сценарием: несколько тысяч
голов крупного рогатого скота должны быть доставлены с Рио-Гранде до желез-
железной дороги или в Канзас-Сити, или в Абилин, и весь фильм состоит из того, что
случается в дороге1.
Если мы сопоставим задачи из нашего списка с животными из перегоняемого
стада, мы получим очень хорошую аналогию того, как в действительности выпол-
выполняются проекты. В любой заданный момент перегона стада мы, вероятно, сможем
точно выделить некторые ситуации примерно по следующим сюжетным линиям.
Большинство стада движется в основном в направлении Абилина. (Исключе-
(Исключением является обязательный набор эпизодов бегства напуганных животных, ко-
когда все стадо направляется в совершенно другое место. Надеюсь, в ваших проек-
проектах не будет ситуаций с напуганным стадом!)
В то время как большинство стада ведет себя нормально, всегда можно с уве-
уверенностью предположить, что некоторые животные направляются назад к Рио-
Гранде - они совершенно не собираются идти в Абилин или любое другое ме-
место, куда их ведет главный погонщик (Джон Уэйн). Другие отбились к ущелью
(оврагу), где они нашли свежую траву и, довольные, пасутся. Еще часть живот-
животных застряла в прохладе на водопое и не имеет ни малейшего желания шагать
под знойным солнцем. И, наконец, еще одна часть стада, наверное, ушла вперед
и была украдена.
Джон Уэйн тем временем на протяжении всего фильма скачет вокруг стада,
подгоняя отставших, разведывая дорогу впереди на предмет потенциальных не-
неприятностей и вообще делая все, чтобы весь скот двигался в Абилин.
К сожалению, это действительно старые вестерны, как правило черно-белые, и их редко пока-
показывает российское телевидение. Такие перегоны скота на несколько тысяч километров, в ос-
основном по пустыне, в которой очень мало воды, зато вполне достаточно шаек грабителей - это
действительно более сложное занятие, нежели отстрел плохих ковбоев хорошими в более
поздних вестернах. - Прим. переводчика.

Глава 3. Должен быть один руководитель 57
Без всякого намерения дополнительно эксплуатировать нашу аналогию,
нельзя не заметить, что это в точности то, что должен делать руководитель про-
проекта - обеспечивать движение всех задач и перемещение всего стада задач
в правильном направлении.
Заметьте также, что если вы решите стать таким руководителем проекта, то
ваш собственный список задач может существенно увеличиться. Логика проста
и непробиваема: если вы хотите, чтобы проект был успешным, то любая задача,
которую необходимо выполнить для успеха, - на вашей ответственности. Будут
ли эти задачи формально на вашей ответственности или нет; будут ли люди, вы-
выполняющие их, непосредственно подчинены вам или это будут ваши коллеги,
вышестоящие лица или сотрудники совершенно других организаций, вне зави-
зависимости от всех этих обстоятельств эти задачи становятся частью вашего стада
и вы должны обеспечить их выполнение. Я не говорю, что вы выполняете их.
Ни в коем случае. Что я действительно говорю, так это то, что вы должны до-
добиться их выполнения. И если не сделать этого, не будет никакого оправдания.
Если проект закончится неудачно, малоутешительно иметь возможность сказать:
"Ну что ж, это была не моя задача".
Повторим этот момент снова, чтобы сделать его кристально ясным и недву-
недвусмысленным: если вы хотите успешно закончить проект, то любая задача, кото-
которую необходимо выполнить для такого успеха, лежит на ответственности руко-
руководителя проекта; он должен взять ее под свое крыло и двигать вперед. Именно
это и означает быть единственным руководителем.
ИСПОЛЬЗОВАНИЕ В РАЗРАБОТКЕ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Чтобы окончательно добить тему необходимости единственного руководите-
руководителя, вот еще пара примеров. Как обстоит дело с руководителем в проекте разра-
разработки программного обеспечения, с которым мы познакомились в главах 1 и 2?
Ну, здесь у нас небольшая команда из семи человек, большинство полностью
заняты в проекте, кроме парочки сотрудников, занятых в нем частично, а один
из полностью задействованных - руководитель. Прекрасно. Ничего не может
быть проще. Теперь давайте рассмотрим более сложный пример.
На рис. 3.1 показана предлагаемая организационная схема для большого про-
проекта, выполняемого консорциумом трех компаний - главного подрядчика - Р
и двух субподрядчиков - S1 и S2.

58
Часть 1. Анализ и планирование проектов
Исполнитель,
ответственный
за разработку
Руководитель
программы
Исполнитель,
ответственный
за установку
Физическая установка
(Р)
Подготовка данных
(S1)
Обучение
(S2)
Исполнитель,
ответственный
за техническую
поддержку
Руководитель проекта
(Р)
Руководитель проекта
(S1)
Руководитель проекта
(S2)
Рис. 3.1
Проект состоит из трех логических модулей:
¦ разработка,
¦ установка,
¦ техническая поддержка.
В каждом из этих модулей каждому из подрядчиков отводится определенная
роль. Например, в модуле установки подрядчик Р может, для примера, быть от-
ответственным за физическую установку системы, субподрядчик S1 - за подготов-
подготовку данных, a S2 - за обучение.
В каждом логическом модуле будет ответственный исполнитель. Кроме того,
у каждого подрядчика будет руководитель проекта, отвечающий за свои компо-
компоненты во всех трех модулях. Что неправильно, если вообще неправильно, в этой
структуре? Проверить просто. Каждый проект должен иметь руководителя, вот
и посмотрим, что у нас получается.
У проекта в целом есть руководитель - поле, помеченное как руководитель
программы. У каждого модуля также есть руководитель - ответственный испол-
исполнитель. О, а что делают руководители проектов? Ничего - потому что все дела-

Глава 3. Должен быть один руководитель 59
ют ответственные исполнители? Дублируют то, что делают ответственные ис-
исполнители? Я лично не знаю. Очевидно, есть два способа разобраться с этой
проблемой: 1) иметь трех человек, каждый из которых отвечает за отдельный
логический модуль, 2) иметь трех человек, каждый из которых отвечает за рабо-
работу конкретного подрядчика. При спуске вниз по дереву для каждой конкретной
части проекта должен быть определен один человек, отвечающий за нее своей
задницей. Именно в этом суть этапа 3.
Таким образом, в нашем примере на следующем уровне вниз должен быть
человек, ответственный за каждый из компонентов, таких как установка, подго-
подготовка данных, обучение и пр.
Остерегайтесь организационных схем. Они могут создавать иллюзию, что на
каждом уровне в иерархии есть единственный руководитель. Однако загляните
за схемы, изучите организационную структуру вашей собственной компании.
Например, проверьте, действует ли принцип единственного руководителя - дей-
действительно ли есть человек, который отвечает собственной задницей за каждую
часть проекта, каковым является ваша компания.
ВКЛАД В PSI
Набрать все или большую часть из десяти баллов здесь очень просто. Десять
баллов - мера того, насколько полно вы собираетесь контролировать все задачи
проекта и продвигать их. Остановитесь на мгновение, прежде чем вознаградить
себя автоматически десятью баллами.
Десятка означает, что вы собираетесь двигать небо и землю, делать все, что
должно быть сделано, чтобы проект свершился. И ничто, будь то бюрократиче-
бюрократические структуры, политические ситуации, нехватка ресурсов или кадров, голод,
пожар, наводнение, мор, война, - не может сбить вас с пути.
Думается мне, что как представители человеческого рода мы в состоянии
вложить столько энергии в некоторые проекты. Однако, по большому счету,
я не считаю, что мы можем делать это во всех проектах, в которых участвуем.
Это, конечно, просто отражает тот весьма очевидный факт, что некоторые про-
проекты являются более важными, чем другие. Таким образом, под нашим контро-
контролем могут быть некоторые проекты, для которых мы собираемся делать все воз-
возможное, чтобы они свершились. Тогда, по справедливости, мы рисуем наши де-
десять баллов. Точно так же существуют другие проекты, где мы решаем, что не
готовы вложить в них столько энергии. В этом нет особой проблемы при усло-
условии нашего признания, что более низкая оценка, которую мы выставляем себе,

60 Часть 1. Анализ и планирование проектов
отражает тот факт, что вещи могут забываться или забиваться в щели и мы
должны, вероятно, присматривать за ними.
СТРУКТУРНОЕ УПРАВЛЕНИЕ ПРОЕКТОМ
Планирование проекта
1. НАГЛЯДНО ПРЕДСТАВЬТЕ СЕБЕ ЦЕЛЬ; НАЦЕЛЬТЕСЬ НА ПРИЗ.
2. СДЕЛАЙТЕ СПИСОК ЗАДАЧ, ПОДЛЕЖАЩИХ ВЫПОЛНЕНИЮ.
3. ДОЛЖЕН БЫТЬ ОДИН РУКОВОДИТЕЛЬ.

ГЛАВА 4
Этап 4: РАСПРЕДЕЛЕНИЕ ЗАДАЧ ПО ЛЮДЯМ
ВВЕДЕНИЕ
Многие из проектов, с которыми мы сталкиваемся, слишком велики для од-
одного человека и выполняются с привлечением других людей. Когда я первый раз
готовил черновик этого раздела книги, бушевала война в Персидском заливе.
Это был проект, в котором участвовало почти три четверти миллиона человек
только на стороне Объединенных сил1.
О полной цели проекта можно думать как о картине, состоящей из множества
фрагментов - пазлов2. Фрагментов столько же, сколько людей. Если каждый че-
человек завершает свою часть, картина будет полной и цель достигнута. (Обратите
внимание, что по нашему определению каждый человек занят в своем собствен-
собственном индивидуальном проекте и может использовать для него принципы струк-
структурного управления проектом.)
Есть три вещи, которые вы должны сделать как части этого этапа:
1. Удостовериться, что напротив каждой задачи стоит имя исполнителя.
2. Принять во внимание другие занятия людей [исполнителей].
3. Попытаться максимизировать силы команды, которую вы получили.
Мы обсудим каждый из этих аспектов поочередно.
1 Возможно, не все в России помнят этот эпизод, произошедший в конце 80-х годов. После захвата
Ираком Кувейта Объединенные силы, состоявшие, как обычно, в основном из американцев
с привлечением европейцев и арабов, выбили иракские войска из Кувейта и вторглись на его тер-
территорию, заставив иракского лидера Саддама Хусейна пойти на значительные уступки в осуще-
осуществлении международного контроля над его военными программами. -Прим. переводчика.
2 К сожалению, это название уже закрепилось в русском языке за головоломками по складыва-
складыванию картинок.

62 Часть 1. Анализ и планирование проектов
У КАЖДОЙ ЗАДАЧИ ДОЛЖНО БЫТЬ ИМЯ
ИСПОЛНИТЕЛЯ
Одна из вещей, которые делаются в моей компании, - это перетряхивание
проектов, которые вышли из-под контроля. В основном эта операция состоит из
двух стадий. В первой мы пытаемся понять, почему данный проект идет так, как
он идет; во второй - создаем новый план (то есть применяем этапы 1-5), чтобы
вытащить проект из того места, где он находится, в то, где ему требуется быть.
Одна из первых вещей, которую мы делаем, пытаясь понять, почему в проекте
бардак, состоит, в первую очередь, в просмотре текущего плана проекта.
Иногда его вообще нет! Если это так, то расследование практически закончено.
Чаще некий план существует. В этом случае наиболее часто встречается то,
что у задач нет имен исполнителей, стоящих против них. Вместо этого обычно
находятся вещи, подобные следующим:
¦ ANO (иногда записываемый как A.N. Other),
¦ мистер (или миссис) X,
¦ программисты 1-6,
¦ инженеры ПО
и другие столь же таинственные персонажи. Другими словами, задачи никогда
не закреплялись ни за одним исполнителем. Можно было бы подумать, что ни-
никто не удивится, если эти задачи не будут выполнены. Однако все неизменно
удивляются.
Первым делом, при закреплении людей за задачами у каждой задачи напро-
напротив ее наименования должно быть имя человека. Любого из вышеупомянутых
обозначений или названий организации нужно избегать в той мере, в какой это
в человеческих силах. Даже если вы нанимаете компанию-субподрядчика дейст-
действительно работать над одной из задач в вашем проекте, имя исполнителя, кото-
которое должно стоять против этой задачи, - это имя представителя субподрядчика,
чья задница отвечает за успешное выполнение данной конкретной задачи.
Может быть, в начале проекта вы не будете знать всех его конкретных участ-
участников, и это нормально, но в этом случае одним из ваших приоритетных дел бу-
будет добиться того, чтобы все анонимы были заменены теплыми, живыми, любя-
любящими человеческими существами настолько быстро, насколько это возможно.

Глава 4. Распределение задач по людям 63
УЧЕТ ДРУГИХ ЗАНЯТИЙ
Мы как-то занимались разработкой программного проекта, который, как
предполагалось, должен был идти год, а в конечном счете продолжался почти
четыре года. Когда мы изучали его историю, пытаясь понять, в чем дело, вот что
мы обнаружили.
Первоначальные оценки трудозатрат "попали мимо" примерно на 50 процен-
процентов, что по моему опыту разработки программных проектов совсем неплохо.
В действительности даже весьма похвально. Но далее мы обнаружили, что руко-
руководитель проекта бессознательно предположил, что каждый участник проекта
будет занят в нем полный рабочий день. Когда мы проверили табели учета и
другие данные, выяснилось, что участники проекта фактически работали над
ним в среднем от 1,5 до 2 дней в неделю. Ладно, у меня есть ученая степень по
прикладной математике, но здесь не нужна никакая ученая степень, чтобы по-
понять, почему такой проект, скорее всего, должен был закончиться приблизи-
приблизительно на три года позже запланированной даты, что и произошло. Нет необхо-
необходимости добавлять, что начальное предположение об укомплектовании персо-
персоналом всех уровней - сознательно или нет - потерялось где-то в пути, и все, что
видел каждый, так это проект, отставший от графика на годы.
Главный момент здесь состоит в том, что необходимо учитывать занятость
исполнителей. Инструментальные средства планирования на основе ПК имеют
средства для реализации такого учета посредством распределения людей по
проектам на определенную долю времени (в процентах), однако простейший
способ в том, что вы создаете учетный лист для каждого человека, который мо-
может выглядеть примерно так:
Джон
Другой проект
Обучение персонала
ISO 9001 /Контроль качества
Таким образом, для моего проекта
2 дня в неделю
2 часа @,25 дня) в неделю
0,5 дня в неделю
2,25 дня в неделю.
Обратите внимание, в частности, на то, что ежегодный отпуск, праздники
и болезни - это тоже занятость, которую нужно учитывать.
Все это - сторона предложения в уравнении предложение/спрос, где спрос
составился из списка задач, производных зависимостей и трудозатрат, получен-
полученных из этапа 2. этап 2 идентифицирует кучу, которую нужно переместить, Этап
4 показывает, как она будет перемещена.

64 Часть 1. Анализ и планирование проектов
Следует также заметить, что эта проблема затрагивает и вас как руководителя
проекта. Часто, особенно в программных проектах, руководство проектом - это
то, что руководитель проекта делает, когда у него остается время от выполнения
технической работы. Мы предлагаем следующее эмпирическое правило: вы
должны закладываться на 6-8 % от полного объема трудозатрат проекта для ру-
руководства проектом: 6 % относятся к небольшим проектам - скажем, с шестью
или менее исполнителями, а 8 % - к проектам покрупней, с количеством испол-
исполнителей более 12.
Эти цифры покрывают работу любого члена проектной группы по следую-
следующим направлениям:
¦ деятельность по планированию проекта, включая разработку графика, оцени-
оценивание и обновление файлов инструментальных средств ПК;
¦ совещания по проекту для учета продвижения или выработки целей;
¦ отчетность по проекту;
¦ ежедневное распределение работ;
¦ "кадровые вопросы" для всей команды проекта, включая утверждение штата
и оценку его работы;
¦ решение повседневных задач и проблем;
¦ связь с всеми поставщиками, как внутренними, так и внешними;
¦ связь с руководством;
¦ связь с заказчиком;
¦ связь с взаимодействующими/подчиненными проектами;
¦ текущий набор персонала;
¦ контроль качества;
¦ план контроля качества /план управления структурой.
Хотя здесь представлены работы, допустимые для любого члена команды, на
деле большая часть всех их G5-80 % и даже больше) будет выполняться руко-
руководителем проекта и/или руководителями групп.
Используя это эмпирическое правило, можно посчитать общий объем трудо-
трудозатрат, требуемых для руководства проектом, скажем, в человеко-днях или че-
человеко-месяцах.

Глава 4. Распределение задач по людям 65
Распределив эту цифру по всему времени жизни проекта, можно увидеть
ежедневный и еженедельный объем трудозатрат на руководство проектом, из-
измеренный теперь в часах в день или днях в неделю.
Три приведенных ниже примера иллюстрируют вышесказанное.
Пример 1
Проект, продолжающийся 6 месяцев, с общим объемом трудозатрат 22 чело-
человеко-месяца. (Среднее число людей на проекте - 3,7.)
Принимая объем трудозатрат на руководство проектом за 6 % от общих тру-
трудозатрат, получим 1,32 человеко-месяца = 26,4 человеко-дня (предполагая, что
20 человеко-дней = 1 человеко-месяцу).
Таким образом, из 120 дней жизни проекта (принимая 20 рабочих дней за ра-
рабочий месяц), руководство проектом требует 26,4/120 = 0,22 дня (= 1,76 часа
в течение 8-часового дня) в день. Таким образом, при 8-часовом рабочем дне
руководитель проекта может считать, что он потратит в день на руководство
проектом именно столько часов.
Пример 2
Проект, продолжающийся 12 месяцев, с общим объемом трудозатрат 170 че-
человеко-месяцев. (Среднее число людей на проекте - 14,2.)
Принимая объем трудозатрат на руководство проектом за 8 % от общих тру-
трудозатрат, получим 13,6 человеко-месяца.
Таким образом, из 12 месяцев жизни проекта руководство проектом требует
13,6/12 =1,1 месяца в месяц. Итак, в этом сценарии руководитель проекта, веро-
вероятно, будет занят практически все рабочее время исключительно руководством
данным проектом и ничем другим.
Если вы не сможете тратить столько времени и усилий, то вы не выполняете
свою работу должным образом и фактически нарушаете положения этапа 3: хотя
проект имеет номинального руководителя, в действительности никто не делает
его работу.
Предыдущие примеры предполагают однородную структуру команды.
В этом случае руководитель проекта несет большую часть ответственности за
руководство проектом. Альтернативный вариант предполагает создание некото-
некоторой иерархии группы. Это даст эффект распределения нагрузки по руководству
проектом на руководителя проекта и руководителей групп.
3 - 2224

66 Часть 1. Анализ и планирование проектов
Следующий пример использует исходные данные примера 2 и демонстрирует
разбиение монолитной проектной команды на три группы, каждая из которых
отвечает за одну треть от полного объема трудозатрат проекта.
Пример 3
Для каждой группы объем трудозатрат на руководство проектом составляет
8 % от полного объема трудозатрат группы, равного 56,7 человеко-месяца, то
есть 4,5 человеко-месяца; поделенные на длительность проекта, они дают 0,38
месяца в месяц, приблизительно 3 часа в день.
Для руководителя проекта, у которого теперь есть команда из трех человек
(руководителей групп), руководящая нагрузка составляет 3 человека в течение
1 года = 36 человеко-месяцев, а 8 % трудозатрат на управление дает приблизи-
приблизительно 3 человеко-месяца B,83) или четверть его времени в течение года.
Примечание: этот расчет предполагает, что все три руководителя группы на
все 100 % столь же эффективны, как и руководитель проекта, и что нет дополни-
дополнительных трудозатрат на поддержание этой иерархии. В действительности руко-
руководитель проекта увеличивает свои трудозатраты по руководству проектом за
счет работы с руководителями групп.
Примеры 2 и 3 иллюстрируют корректные методы, которыми можно было бы
управлять этим проектом. В обоих случаях всегда следует пытаться держать
размеры групп минимально возможными. При выборе между плоской и иерар-
иерархической структурами надо иметь в виду, что преимущества и недостатки есть у
обоих. (Здесь нет наилучшего и наихудшего вариантов - в конечном счете это
просто выбор руководителя проекта.)
МОНОЛИТНАЯ КОМАНДА ИЛИ ПЛОСКАЯ СТРУКТУРА
Руководитель проекта берет все управление на себя. Однако это требует от
него больших трудозатрат на руководство проектом, которые должны быть
заложены в график.
ИЕРАРХИЧЕСКАЯ СТРУКТУРА КОМАНДЫ
Существенно разгружает руководителя проекта, и он может управлять дру-
другими проектами и/или выполнять техническую работу. Однако появляются сле-
следующие моменты:

Глава 4. Распределение задач по людям 67
1. Трудозатраты на руководство, требуемое от руководителей групп, нужно за-
заложить в графики работы.
2. Делегирование ответственности может первоначально втянуть руководителя
проекта в большее количество работ по управлению проектом, пока он не
убедится, что на руководителей групп можно полностью положиться.
МАКСИМИЗИРУЙТЕ СИЛЫ
Или, переформулируя это слегка негативно, но более прямолинейно: мини-
минимизируйте риск от дурака, затесавшегося в ваш проект!
Если вы удачливы, вы сможете точно определить нужное лицо для каждой
части работы. Когда я говорю о лице, я имею в виду ту комбинацию индивиду-
индивидуальности, навыков, опыта, побуждений, личных целей, сил и слабостей, которая
составляет каждого из нас. Гораздо чаще вам будут давать некоторую группу
людей и требовать, чтобы вы выполняли проект с ними.
Я помню, как в школе мы играли в различные игры, для которых необходимо
было набирать команды. В классе была горстка спортивных суперзвезд (или тогда
они казались мне такими), и из них неизменно выбирались капитаны двух команд.
Затем капитаны набирали членов команд из надежных ребят, которые состав-
составляли большую часть класса. Наконец оставалось пять или шесть человек, и пре-
преподаватель взмахом руки делил их пополам и отправлял эти половины по ко-
командам. Я всегда был в этой оставшейся компании! Это мое воспоминание при-
приведено здесь потому, что группа, с которой вы начинаете проект, почти всегда
представляет собой смешение множества индивидуальностей с разнообразными
характерами, способностями, амбициями и побуждениями, и из них вам пред-
предстоит выплавить свою команду.
НАЗНАЧЕНИЕ ЛЮДЕЙ НА ЗАДАНИЯ
Хорошо. У вас есть список задач из этапа 2 структурного руководства проек-
проектом, вы получили группу людей, где некоторые отлично подходят для отдель-
отдельных задач, а некоторые в меньшей степени. Теперь надо распределить задачи по
людям так, чтобы проект был выполнен.
Какой наилучший путь для этого? Для любой задачи из списка и для любого
человека в команде имеются следующие варианты:
1) данный человек может выполнить данную работу и хочет делать ее;
2) может выполнить данную работу и подготовлен, чтобы делать ее;

68 Часть 1. Анализ и планирование проектов
3) может выполнить данную работу, но не подготовлен, чтобы делать ее;
4) может быть обучен/проинструктирован, как выполнить данную работу;
5) не может выполнить данную работу.
Категория 1
Первая категория - идеал. Если бы вам пришлось взять только одну идею из
этой книги, то она такова: если в качестве составляющей своего проекта можно
получить человека, делающего то, что он или она хочет делать, значит, вы запо-
заполучили величайшую на Земле силу.
Человек этой категории может делать работу и любит это. Позже, в главе 17,
мы будем обсуждать формирование команды и я буду говорить, что ключевой
вопрос при интервьюировании кандидата - что вы хотите делать?. Если вы мо-
можете найти людей, которые хотят выполнять задачи, существующие в вашем
проекте, вам гарантирована ситуация категории 1.
Категория 2
Вторая категория - все еще нормальная. Слава богу, человек может выпол-
выполнить эту задачу - возможно, он делал это прежде или вы знаете, что это ему по
силам. Может быть, потребуется некоторое количество уговоров, чтобы убедить
его сделать это, и в главе 15 я привожу вам арсенал инструментов для использо-
использования в решении подобных проблем.
Тем не менее, предполагая, что вы получили ситуацию категории 2 и можете
поддерживать ее на протяжении всего проекта, никаких реальных проблем быть
не должно. Позвольте мне также сказать, однако, в качестве предостережения,
что есть предел тому, как часто вы можете уговаривать людей делать вещи, ко-
которые они в действительности не хотят делать. Если то, что просят делать лю-
людей, не соответствует их личным планам, то в долгосрочной перспективе, я по-
полагаю, вы поплывете против течения.
Категория 3
С третьей категорией у вас проблема: человек может сделать данную работу,
но не хочет. Возможно, он делал это прежде слишком много раз и ему надоело
или может быть, он чувствует, что ему недостаточно платят. Кто знает, какова
причина? Основное, что вы должны здесь сделать, так это заставить данную си-
ситуацию перейти либо в категорию 2 (он подготовлен, чтобы сделать это), либо
в категорию 5 (по любой причине он не собирается и не может сделать этого).
Снова можно использовать методы, изложенные в главе 15, в качестве помощи.

Глава 4. Распределение задач по людям 69
Категория 4
Четвертая категория (может быть обучен/проинструктирован для выполнения
данной задачи), при условии что:
¦ вы подготовлены, чтобы вкладывать в обучение время и деньги,
¦ а также закладываете время обучения в график проекта
¦ и учитываете дополнительные трудозатраты на управление
¦ и готовы работать с риском, что это может не подействовать,
часто может работать очень хорошо. Фактически, вы можете во многих случаях
обнаружить себя в ситуации категории 1, поскольку вам, возможно, удалось
втравить человека в более захватывающую работу, чем он хотел оказаться.
Категория 5
С пятой категорией у вас наибольшие проблемы. Вам может потребоваться
время, чтобы понять, что человек не может сделать данную работу, но если вы
наконец поймете это, необходимо найти в проекте такие задачи, которые данный
человек может выполнить. Если это не получается, человек оказывается вне
проекта. В этом процессе балансирования соответствия людей и задач можно,
очевидно, столкнуться с проблемой как недо-, так и переиспользования людей,
и здесь как раз полезно нечто вроде компьютеризированной системы управле-
управления проектами, хотя и не обязательно. Может потребоваться несколько итера-
итераций, прежде чем вы приемлемо сбалансируете все, т. е.:
¦ каждый человек будет использован на 100 % или меньше,
¦ все потребности в обучении/инструктировании выявлены (обратите внима-
внимание, что это генерирует новые задачи в списке),
¦ есть чувство, что, по большому счету, каждый будет доволен задачами, кото-
которые ему поручены.
Изучение случая 5
Интересно читать (Huntford, 1993) о различных методах, которыми пользова-
пользовались Скотт и Амундсен при назначении людей на работы.
Прежде всего велика разница в количестве людей, которых эти два руководи-
руководителя брали с собой в экспедиции. Скотт высадил в Антарктиде в общей сложно-
сложности 33 человека; Амундсен - только десять. До некоторой степени эту разницу
можно объяснить научным аспектом экспедиции Скотта, однако есть также впе-
впечатление, что экспедиция Скотта - это войско для генерального наступления,

70
Часть 1. Анализ и планирование проектов
чья цель состояла в том, чтобы победить числом. В экспедиции Амундсена,
с другой стороны, чувствуется привкус разведывательного рейда.
Скотт брал некоторых людей, потому что они оплатили свое участие, так как
его экспедиция нуждалась в деньгах. Есть некоторая логика в его выборе ученых,
но он еще взял большое количество людей, не имеющих «полярного» опыта.
Амундсен, напротив, выбирал людей подобно тому, как мастер выбирает ин-
инструмент. Ему необходимо было пройти через паковый лед, который окружает
Антарктиду в летний период, и он взял ледового лоцмана Андреаса Бека
(Andreas Beck). Он планировал идти к полюсу на лыжах, поэтому, не говоря уже
о том, что каждый его человек мог достаточно хорошо ходить на лыжах, он взял
с собой Олафа Бьяланда (Olav Bjaaland), лыжника, выступавшего за Норвегию
на международном уровне. Поскольку он использовал собак, он нуждался
в квалифицированном погонщике для них. Такого он нашел в лице Хельмера
Хансена (Helmer Hanssen).
Урок для наших проектов ясен: объедините маленькую группу высококвали-
высококвалифицированных и целеустремленных людей (в противоположность большой
группе обычных людей с разнообразными целями), и ваши шансы на успех
сильно увеличатся.
НАЗНАЧЕНИЕ ЛЮДЕЙ НА ЗАДАНИЯ ПО ФОРМЕ 2
Форма, показанная на рис. 4.1, могла бы быть полезна для анализа того, как рас-
распределялись люди по задачам. Все "единички" в столбце "Категория" были бы иде-
идеальным, но очень маловероятным случаем. Более вероятна смесь из 1, 2 и 4 катего-
категорий, плюс строки с 3 и 5 категориями, требующие отдельного внимания. Эта форма
снова появляется в главе 6, где используются два крайних правых столбца.
Работник
Задача
Категория
Надежность
Па
Нет
Рис. 4.1. Форма 2, распределение работ

Глава 4. Распределение задач по людям 71
ИСПОЛЬЗОВАНИЕ В РАЗРАБОТКЕ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
На рис. 4.2 показан пример применения Этапа 4, взятый из реального проек-
проекта. Руководитель проекта просто наложил нашу форму на график Гантта для
проекта. Это - идея для аккуратных, потому что начинающим она позволяет
проверить, что каждая задача за кем-то закреплена!
Знакомство с формой показывает, что у нас неплохие результаты. Есть некото-
некоторая потребность в обучении, проистекающая из наличия 4-й категории, и мы
должны проконтролировать, что это предусмотрено для соответствующих лиц из
списка задач. Если это не так, надо что-то добавить. Кроме того, категории 2 и 4
требуют несколько более пристального внимания, чем категория 1. Однако при
удачном раскладе многие из 4-й категории при соответствующем обучении и кон-
контроле могут превратиться в исполнителей 1-й категории.
Вы можете заполнять одну из этих форм на следующих возможных уровнях:
¦ для проектной группы в целом,
¦ для каждого человека, как мы и сделали выше,
¦ или для каждой пары "человек-задача", как мы говорили в начале этой главы.
Чем глубже вы спускаетесь, тем большее понимание обретаете. Кроме того, вы
можете делать это в разное время на протяжении всего проекта, скажем, в начале
каждой стадии. Разумный компромисс между неделанием этого вообще и повто-
повтором для каждой человеко-задачи мог бы состоять в том, чтобы проделывать эту
операцию для каждого члена группы либо однажды (когда он присоединяется
к проекту), либо, для очень протяженных проектов, в начале каждой стадии.
Наконец, еще одна полезная вещь иллюстрируется рисунками 4.3 и 4.4: таб-
таблицы, показывающие, кто распределен на какой проект и на какой период. Это
помогает вам отслеживать множество людей, занятых во множестве проектов,
и может также помочь в программе найма персонала. Мы привели два примера:
рис. 4.3 - для одного большого проекта; рис. 4.4 - для подразделения разработки
программного обеспечения.

72
Часть 1. Анализ и планирование проектов
111 сентябр!
>я 2000 г.
ДИАГРАММА ГАНТТА. ПИЛОТНОЕ РАСПРЕДЕЛЕНИЕ ЗАДАЧ
Страница 1
Пилотный перечень - Задачи
Начало проекта
Завершение подготовки контракта
Подписание контракта
Подготовка к реализации
Реализация
Установка программного и аппаратного обеспечения
Определение требуемого оборудования
Установка оборудования
Установка модема техподдержки
Установка программного обеспечения
Интерфейсы
Интерфейс персонала
Проектирование интерфейса персонала
Программирование интерфейса персонала
Программирование Ansos США
Программирование Beaumont
Тестирование
Тестирование Ansos Великобритания
Тестирование Beoumonf
Программирование Части 2
Программирование Ansos Великобритании
Программирование Beaumont
Интерфейс платежной ведомости
Проектирование интерфейса платежной ведомости
Утверждение проекта
Программирование платежной ведомости
Программирование Ansos США
Программирование Beaumont
Тестирование платежной ведомости
Тестирование Ansos Великобритания
Тестирование Beaumont
Программирование части 2
Программирование Ansos Великобритании
Программирование Beaumont
Исполнители
Тони Кении
Кэти Кини, Тони Кении, Artwork и по парню от
каждого поставщика
Кэти Кини и Artwork
Техотдел
Техотдел
Кэти Кини
Кэти Кини
Artwork
Кэти Кини
Artwork
Кэти Кини
Artwork
Кэти Кини
Кэти Кини
Кэти Кини и <финансисты>
Artwork
Кэти Кини
Artwork
Кэти Кини и <финансисты>
Artwork
Кэти Кини
Категория
1
1
1
2
2
4
1
2
1
2
1
2
1
1
to го
2
1
2
2
Надежность
Да Нет
¦
+
:
¦
¦

Глава 4. Распределение задач по людям
73
111 сентября 2000 г.
ДИАГРАММА ГАНТТА. ПИЛОТНОЕ РАСПРЕДЕЛЕНИЕ ЗАДАЧ
Страница 1 I
Пилотный перечень - задачи
Установка интерфейса персонала
Тестирование Ansos
Тестирование Ansos и Beaumont
Отчет о проблемах
Программирование Ansos Великобритании
Программирование Beaumont
Тестирование и приемка интерфейса
Реализация интерфейса персонала
Исполнители
Кэти Кини и <персонал>
Кэти Кини и <персонал>
Кэти Кини
Artwork
Кэти Кини
Кэти Кини и <персонал>
Кэти Кини
Категория Надежность
До Нет
1<2>
1<2> и
1 н
2
1 н
1<2> -1
1
Рис. 4.2
КОМПАНИЯ ACME: УКОМПЛЕКТОВАНИЕ ПЕРСОНАЛОМ БОЛЬШОГО ПРОЕКТА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ПРОЕКТ
Изучение осуществимости
Спецификации
Проектирование
Реализация
Сборка
ВСЕГО
1998
6
2
2
7
2
2
8
2
2
9
2
2
10 11
2
8
2 8
12
8
8
1999
1
8
8
2
8
8
3
8
3
11
4
8
3
11
5
8
3
11
6
1
1
7
11
1
12 12
8
11
4
9
11
8
10 11 12
11 11 11
8 22 22
15 19 19 33 33
2000
12 3 4 5 6 7 8
11
22 33 33 33 33 33 33 33
33 33 33 33 33 33 33 33
9
12
10 11
12 12
12 12 12
16
12
12
12
Мая
2001
1 2
12 12
3 4
12 12
12 12 12 12
Рис. 4.3. Пример распределения штата большого проекта
КОМПАНИЯ ACME: РАСПРЕДЕЛЕНИЕ ПЕРСОНАЛА ОТДЕЛА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ГРУППА/ПРОЕКТ
16 моя Май Июнь Кв.3 Кв.4
БАЗОВАЯ ТЕХНОЛОГИЯ (Фред)
Управление
Проект А
Проект В
11 11 Фред
3 3 2 2 Рой, Стив
11 11 12 12 Джилл, Грег №1,
Грег №2 и т. п.
Работа в H.Q.
ПРОДУКТЫ (Стив)
Продукт А
Продукт В установка
1
16
2
1
1
16
2
1
1
16
2
1
1
16
2
1
Элеонор
Алан, Кати
Ноэль

74
Часть 1. Анализ и планирование проектов
КОМПАНИЯ ACME: РАСПРЕДЕЛЕНИЕ ПЕРСОНАЛА ОТДЕЛА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ГРУППА/ПРОЕКТ
ЗАЯВКИ КЛИЕНТОВ (Милтон)
Управление
Сложная продукция
Простая продукция
Средний диапазон
АДМИНИСТРИРОВАНИЕ И УПРАВЛЕНИЕ
(Алекс/Джим)
Общее управление
Персонал/Администрация
РАБОТА С ТАМОЖНЕЙ
Технический директор
Программное обеспечение отделения
Предпродажи
Продукция ЕС
Продукция США
Большие заказные проекты
Доступно
ОБЩЕЕ КОЛИЧЕСТВО
16 мая Май
3
1
5
1
7
1
5
6
1
1
1
6
5
2
16
48
Июнь
3
1
5
1
7
1
5
6
1
1
1
8
3
4
18
50
Кв.З
3
1
5
1
7
1
5
6
1
1
1
8
3
5
19
51
Кв.4
3
1
5
1
7
1
5
6
1
1
1
8
8
19
51
Милт
Трейси, Лайза, Сид,
Майк, Берт
Джим
Новый наем
Берт
Джордж, Тэмми, Ники,
Вики, Ли
Марк
Алан
Новый наем
Лу, Джо, Ал, Робин,
Тони, Дик
Гэри, Гарри, Энн, Тим,
Дэйвин
Стив, Линда
Рис. 4.4. Пример распределения штата отдела программного обеспечения
ВКЛАД В PSI
При максимальном значении PSI, равном 10, вы получаете баллы на этапе 4
следующим образом:
Если напротив каждой задачи в вашем списке стоит имя человека, индекс PSI
считают равным 3,33. Как мы говорили, возможно, в начале проекта вы не знае-
знаете, кто все эти люди, однако вы должны стремиться выяснить это как можно бы-

Глава 4. Распределение задач по людям 75
стрее. Цифра ниже, чем 3,33, поможет вам (как я надеюсь) обратить внимание на
то, что здесь есть нерешенные проблемы.
Если учтены другие занятия людей, включая ваши собственные и особенно
руководство проектами, выставьте себе [еще] 3,33.
Если вы провели анализ максимизации сил, который мы описали выше, вы-
выставьте себе [еще] 3,33.
СТРУКТУРНОЕ УПРАВЛЕНИЕ ПРОЕКТОМ
Планирование проекта
1. НАГЛЯДНО ПРЕДСТАВЬТЕ СЕБЕ ЦЕЛЬ; НАЦЕЛЬТЕСЬ НА ПРИЗ.
2. СДЕЛАЙТЕ СПИСОК ЗАДАЧ, ПОДЛЕЖАЩИХ ВЫПОЛНЕНИЮ.
3. ДОЛЖЕН БЫТЬ ОДИН РУКОВОДИТЕЛЬ.
4. РАСПРЕДЕЛЕНИЕ ЗАДАЧ ПО ЛЮДЯМ.

ГЛАВА 5
Этап 5: УПРАВЛЯЙТЕ ОЖИДАНИЯМИ,
УСТАНОВИТЕ ДОПУСК НА ОШИБКИ,
ОБЕСПЕЧЬТЕ ЗАПАСНЫЕ ПОЗИЦИИ
ВВЕДЕНИЕ
К тому времени, когда вы завершили этапы 1-4, фактически вы закончили
планирование вашего проекта. Если эти этапы выполнены, как было описано, то
это означает, что вы сформировали рабочую модель того, как ваш проект может
разворачиваться во времени. В некотором смысле вы знаете ответ. Вы знаете,
что должно быть сдано, когда оно будет завершено, сколько людей вам нужно
и множество другой полезной информации. В теории теперь вы можете выле-
вылететь из своего офиса, отправиться к вашему шефу или заказчику и объявить:
"Мы знаем ответ. Это будет 27-го ноября", или что-нибудь в этом роде.
Вы можете. Однако остановитесь на мгновение, чтобы рассмотреть одно об-
обстоятельство. Что вы будете делать, если реальность не совпадет с прогнозами
вашей модели?
Видите ли, очень легко - особенно если вы прошли через процесс мучитель-
мучительного учета всех подробностей, о котором мы говорили выше, и даже в еще
большей степени, если ваш план является результатом применения компьютер-
компьютерных средств планирования проекта, - забыть, что все, что заложено в план, явля-
является предсказанием, догадкой, выстрелом наудачу, ставкой в азартной игре. Вы
не знаете в вашем плане ничего определенного. Фактически единственная вещь,
которая реально известна, состоит в том, что ваш план определенно неправилен.
Он не может реально существовать, это только предсказание будущего. Учиты-
Учитывая, что дело обстоит именно так, самое большее, на что можно надеяться, это
то, что большая часть плана правильна и что в неправильных местах он не
слишком сильно неправилен. Вам надо спросить себя: "Что я буду делать, если
это не сработает?" И ответ, который вы должны дать себе, состоит во встраива-
встраивании в план непредвиденных обстоятельств. Это - то, что составляет первую часть
этапа 5 - этап 5а. Он состоит в выборе границ ошибок и запасных позиций.
Встроив для себя в план непредвиденные обстоятельства, вам надо будет
"продать" ваш план непосредственному начальству и определить для него ожи-

Глава 5. Управляйте ожиданиями, установите допуск на ошибки, запасные позиции 77
даемые результаты, которые вы затем реализуете. Это вторая часть этапа 5 -
этап 5Ь. Мы опишем каждый из этих подэтапов отдельно.
НЕПРЕДВИДЕННЫЕ ОБСТОЯТЕЛЬСТВА: ЗАДАЙТЕ
ДОПУСК НА ОШИБКИ, ИМЕЙТЕ ЗАПАСНЫЕ ПОЗИЦИИ
Явные или скрытые непредвиденные обстоятельства
Если бы вы были руководителем проекта и работали в строительстве, то
в ваших планах люди ожидали бы видеть строку с названием Непредвиденные
обстоятельства. Она может быть задана, например, в виде 15 % от бюджета
проекта и/или затраченного времени. Если бы этой строки не было, то более
благодушный рецензент счел бы, что это просто ваше упущение, а другой бы
просто решил, что вы идиот. И они были бы правы, потому что исключение не-
непредвиденных обстоятельств подразумевает, что вы чувствуете себя в состоянии
уверенно предсказывать будущее.
Существует ряд компаний по созданию программного обеспечения - к сожа-
сожалению, надо сказать, что их немного, - где применяется подобная практика. Ру-
Руководство и заказчики этих компаний ожидают видеть непредвиденные обстоя-
обстоятельства встроенными в планы. Невыполнение этого расценивается как практика
управления проектами в диапазоне от неподходящей до преступно небрежной.
А что же происходит в других компаниях по созданию программного обеспе-
обеспечения? В них непредвиденные обстоятельства - это то, на что в первую очередь
нацеливается красный карандаш руководства или заказчика. "Так, а теперь, где
мы можем укоротить этого малыша [или сделать дешевле]?" - размышляет
Большой Босс из компании "Большая Горгонзола". А, непредвиденные обстоя-
обстоятельства, они вам не нужны, для начала".
Если ваша организация одна из просвещенных, вы можете явно включать
в план непредвиденные обстоятельства, причем в достаточно большом количе-
количестве - столько, сколько пробьете.
С другой стороны, если ваша организация принадлежит к разновидности лю-
любителей большого красного карандаша, то вам придется прятать непредвиден-
непредвиденные обстоятельства.
Машинные инструментальные средства сильно поспособствуют вам в том,
чтобы сделать это быстро. Другой полезный способ - и начальство никогда не
сможет распознать его - состоит в создании фальшивых работ. Вы можете за-
замаскировать их техническим жаргоном (существуют многочисленные пакеты

78 Часть 1. Анализ и планирование проектов
программ, которые генерируют для вас модные выражения и акронимы) и вклю-
включить работы типа:
¦ поиск обновлений таблицы,
¦ техническое обслуживание памяти,
¦ модификации существующего [ПО, оборудования, методик],
¦ принятие решения о выборе инструментальных средств,
¦ реконструкция.
Вы поняли, что я имею в виду - только найдите слова поближе к вашей об-
области деятельности, и можете время от времени использовать их повторно. Ко-
Конечно, лучше, если вы можете выложить карты на стол и заложить непредви-
непредвиденные обстоятельства явно, но если это не получится, их все равно надо зало-
заложить в план так или иначе1.
Не так давно я консультировал одну компанию. В сущности, это закончилось
тем, что я тратил послеобеденные часы на работу с руководителем проекта, по-
помогая ему спрятать непредвиденные обстоятельства в плане, созданном с помо-
помощью пакета MS Project. Именно его начальство оплачивало мою работу, а я го-
готовил материалы, чтобы в некотором роде обмануть их. Должен сказать, что
я был совершенно уверен в нравственной правоте моих деяний, поскольку знал,
что когда-нибудь они будут благодарить меня за это.
Так и случилось примерно месяц назад, когда их проект завершился вовремя
и уложился в бюджет - в то время и тот бюджет, которые включали в себя не-
непредвиденные обстоятельства.
Выявление непредвиденных обстоятельств
Во встраивании в ваш проект непредвиденных обстоятельств вам поможет
применение тех четырех параметров, которые мы изначально выделили в гла-
главе 1. Это:
¦ функциональность [выходного продукта],
¦ дата сдачи [продукта],
¦ объем работ (или стоимость),
¦ качество.
В советской практике при выполнении проектов (НИР, ОКР) для военных заказчиков исполь-
использовалась технология заделов, т. е. проект предлагался уже тогда, когда основные работы были
уже проведены "подпольно". Фактически это то же скрытое закладывание непредвиденных об-
обстоятельств. - Прим. переводчика.

Глава 5. Управляйте ожиданиями, установите допуск на ошибки, запасные позиции 79
Функциональные возможности
Некоторые проекты формируются таким образом, что в некий счастливый
день в будущем кто-то дернет большую рукоятку, и вся система включится
и будет работать идеально. (Система ядерного сдерживания, используемая су-
супердержавами в холодной войне, была именно такой системой! У меня был
друг, который владел маленькой фирмой по разработке программного обеспече-
обеспечения, и он был ветераном большего количества установок платежных систем, чем
то количество платежных документов, которые вам когда-либо приходилось
подписывать. Основываясь на своем собственном опыте, он был уверен, что
ядерная война никогда не произойдет: он никогда не видел, чтобы платежная
система сразу работала правильно, так почему с термоядерным Армагеддоном
будет иначе?) Либо все полностью сработает к обещанной дате поставки, либо...
оно не сработает вообще. Так рождаются некоторые проекты.
Вы можете, конечно, организовывать ваш проект таким образом, но тогда вы
действительно напрашиваетесь на неприятности. Вы не дали себе никакого мес-
места для маневра, никакой запасной позиции для отступления.
Альтернативой может служить то, что называется поэтапной поставкой. Име-
Имеется ли некоторый минимальный набор функциональных возможностей, обеспе-
обеспечиваемый вашим проектом, который оторвет вашего заказчика от земли (пре-
(предоставит ему возможность делать что-то реальное) и в то же время позволит вам
ближе знакомиться с системой и отлаживать ее? Далее, можете ли вы добавить
к этому набору еще немного функциональности, затем еще и еще? В любой точ-
точке, если обнаружится, что вы зашли не туда, вы можете всегда возвратиться
к последней поставленной версии.
Дата поставки и объем работ (стоимость)
Вы можете учитывать непредвиденные обстоятельства, просто добавляя до-
дополнительный процент для любого из этих параметров. Типичные значения до-
добавки лежат обычно в пределах 10-15 процентов, но я подозреваю, что единст-
единственное обоснование именно этих значений состоит в том, что, люди могут их
переварить. В качестве общего правила я бы сказал, что чем больше вам удастся
заложить, тем лучше. Определенно, чем более корректной смотрится ваша мо-
модель, тем больше шансов на успешный проект. Непредвиденные обстоятельства
можно включать:
¦ интегрально, т. е. на весь проект;
¦ поэтапно, т. е. на каждую стадию;
¦ в работы из критического перечня (критического пути).

80 Часть 1. Анализ и планирование проектов
Также, вероятно, лучше стремиться к добавлению процентов к дате поставки,
потому что это часто означает, что вы можете держать людей в проекте в тече-
течение этого дополнительного периода времени и таким образом получить гораздо
больший запас на непредвиденные обстоятельства по трудозатратам.
Качество
Если качество поставляемых компонентов вашего проекта можно измерить,
то вы можете использовать их в игре с непредвиденными обстоятельствами.
Например, при развитии программного продукта вы можете использовать
среднюю наработку на отказ (MTTD - mean time to defect) как меру качества.
(Прекрасное обсуждение этой темы см. в Puttnam и Myers A992)). Тогда можно
стремиться к значению MTTD, скажем, в 2 дня, но быть готовым к тому, что,
если вас прижмут, согласиться на 1 или 1,5 дня. Снова вы получаете некоторое
место для маневра, допуск на ошибки.
УПРАВЛЯЙТЕ ОЖИДАНИЯМИ
Окей, Вы сформировали модель вашего проекта, используя этапы 1-4. Вы
встроили непредвиденные обстоятельства, используя этап 5а. Теперь вы готовы
идти к наличествующему начальству, будь то ваш босс или ваш заказчик, и со-
сообщить ему ответ. Как правило, это тот самый момент, когда вы объявляете от-
ответ, а ваш босс или заказчик, фигурально выражаясь, всплескивает руками и го-
говорит: "Вы, наверное, шутите. Когда это вы собираетесь сделать?" Или: "Вы хо-
хотите столько людей?" И так далее. Уверен, вы с этим встречались; а если нет,
если вы только что пришли в этот бизнес, пройдет очень немного времени до
того, как встретитесь.
Так что же теперь делать? Ну, для начала, давайте скажем совершенно четко,
единственная вещь, которую не надо делать, - это соглашаться, что бы он ни
предлагал. То есть если ваша модель не показывает, что это возможно.
Путь вперед концептуально прост. Однако он может потребовать от вас оп-
определенной доли гражданского мужества. Вот что вы делаете.
Модель показывает один возможный путь, по которому ваш проект мог бы
успешно завершиться. Если вы а) ожидаете, что начальству не понравится этот
путь, или б) обнаруживаете, что то, что вы сказали, ему не понравилось, можно
использовать свою модель для генерации других возможных сценариев. Как это
сделать? Просто изменяя наши четыре испытанных параметра:
¦ функциональность,
¦ дату сдачи,

Глава 5. Управляйте ожиданиями, установите допуск на ошибки, запасные позиции 81
¦ объем работ (или стоимость),
¦ качество.
Так что вы можете, например, задать себе вопрос, какой эффект будет иметь
добавление большего количества людей. Или посмотреть, что (при снижении
функциональности) можно получить к дате поставки, которую уже объявил от-
отдел продаж. Или посмотреть, на что можно растрясти начальство, если отодви-
отодвинуть дату поставки. Можно пробовать комбинации всего этого. Для генерации
новых возможных сценариев вы всегда используете ту модель, которую разра-
разработали, думайте о новых сценариях, как о вкусовых добавках к основному блю-
блюду. Использование модели заставляет вас быть абсолютно честным. Это оста-
останавливает вас от подписания того, что гарантированно невыполнимо.
Если вы не используете модель, если вы просто уступаете давлению, то вы
делаете именно это. Вы подписываетесь под невыполнимой задачей1. Вы выби-
выбираете тихую жизнь теперь и пробуете изгнать из головы знание, что бомба упа-
упадет на вас потом, когда по осени начнут считать цыплят, а она неизбежно упа-
упадет, поскольку ваша модель говорит, что цыплят считать будут.
Единственная вещь, которую нельзя делать в этой игре, это подписываться
под невыполнимой задачей - независимо от того, как сильно и как грубо давят
на вас. А ваша модель будет действовать как защита. Часто в традиционном сти-
стиле этой игры переговоры становятся эмоциональным столкновением между сто-
сторонами. При использовании предлагаемого метода они становятся рациональ-
рациональным обсуждением фактов. Римский писатель Саллюст сказал: "Ubi res adsunt,
quid opus est verbis" - "Когда есть факты, зачем нужны слова". В нашей версии
игры люди могут быть настолько эмоциональны, насколько им этого хочется, и
это не имеет никакого значения. Модели, которые вы разрабатаете, холодно и
логически покажут, что может и что не может быть сделано. Держитесь корней,
и в конечном счете хорошие парни должны победить.
Другая хитрость, к которой может прибегнуть начальство, состоит в выраже-
выражении сомнений по поводу вашей модели, в попытке урезания содержащихся в ней
оценок. "Не может быть, чтобы на это требовалось две недели, - будет говорить
оно. - Вы завысили все оценки". Ваш ответ - само благоразумие. "Это - только
оценки, - говорите вы. - И, конечно, они не могут быть правильными на сто
процентов. Они действительно могут оказаться завышенными". Затем вы делае-
делаете драматическую паузу. "Но они также могут оказаться заниженными. Мы про-
просто не знаем. Мы думаем, что, исходя из детального рассмотрения, которое мы
В оригинале -mission impossible. Отечественные телезрители поймут. -Прим. переводчика.

82 Часть 1. Анализ и планирование проектов
выстроили (на этапе 2), они достаточно корректны, однако это только прогнозы.
Почему бы нам не попробовать поработать пару недель и посмотреть, что полу-
получится? Тогда при принятии окончательного решения мы будем иметь больше
шансов, что оно правильно".
Ключ ко всему этому - обсуждение и согласование позиций, попытка в лю-
любом случае оставаться на цивилизованном уровне. Позже в этой главе (см. "Ис-
"Использование в разработке программного обеспечения") мы покажем несколько
дополнительных тактических ходов, которые можно применить для поддержки
цивилизованного уровня обсуждения.
Наконец, вы можете нарваться на достаточно невменяемого начальника, ко-
который заявит: "Мне без разницы модели, цифры и прочая лабуда. Делайте вот
так, и разговор закончен". Если это произойдет, вы должны набраться смелости
и полностью отказаться от проекта в целом. Лихой совет, можете сказать вы,
если подходят сроки по закладным, а сотрудникам надо содержать свои семьи,
но какова альтернатива? Альтернатива в том, что где-то в конце вы останетесь
у разбитого корыта, причем именно на вас повесят всех собак за срыв проекта.
Поймите, жизнь слишком коротка для приобретения таких неприятностей.
В любом случае неудачных проектов хватает всегда, так что на хороших руко-
руководителей проектов спрос тоже есть всегда. Так что давайте подытожим:
¦ Этапы 1-4 формируют основную, базовую, модель.
¦ Этап 5а добавляет к базовой модели непредвиденные обстоятельства.
¦ Этап 5Ь создает ряд возможных разновидностей модели. Одна и только одна
из них - это то, что может "купить" ваш босс или заказчик.
¦ Как только босс или заказчик выбрал ту, которую он хочет, она становится
той, которую пытаетесь воплотить в жизнь. Это - ожидаемые результаты, ко-
которые вы определяете.
¦ Наконец, выбранный вариант документируется так, чтобы всем заинтересо-
заинтересованным лицам было ясно, кто под чем подписался.
СЛОВО ОБ ОБЯЗАТЕЛЬСТВАХ
Рано или поздно в проектах нам приходится принимать на себя обязатель-
обязательства. Делая это, мы обычно даем обещание, а затем пытаемся добиться, чтобы
это обещание сбылось. Если все случается нормально, как мы и предсказали, то
мы - герои; в противном случае наше имя втоптано в грязь.
Первое, что надо сказать о принятии обязательств, это то, что надо пытаться
отнести это мероприятие как можно дальше по времени в проекте. Чем дольше

Глава 5. Управляйте ожиданиями, установите допуск на ошибки, запасные позиции 83
вы сможете уворачиваться от обещаний, тем лучше для всех заинтересованных
лиц. С каждым прошедшим днем вы узнаете больше о природе проекта, и все те
детали, которые добавляются в модель проекта, увеличивают вероятность вы-
выполнения данного вами обещания.
Рано или поздно, однако, настает роковой день, и вам надо давать обещания.
Моя вера и мой опыт подсказывают, что если вы используете методы плани-
планирования, описанные в этапах 1-5, то есть немалый шанс, что проект будет дви-
двигаться к успешному завершению. Если так, то это честная игра для вас, и да по-
поможет нам Бог.
Если, однако, этого не происходит, если выясняется, что весь ваш запас не-
непредвиденных обстоятельств съеден и что нет никакой возможности выполнить
обещания, надо в этом признаваться. Нашей инстинктивной реакцией чаще яв-
являются обратные действия: все спрятать, изобразить, что ничего плохого не
происходит, и надеяться, что как-нибудь все устаканится. Это не тонкий расчет,
это - безумие.
Признание не будет приятным. На своих занятиях я уподобляю это взрыву
500-фунтовой бомбы рядом с каждым. Но снова, какова альтернатива? Альтер-
Альтернатива - это то самое разбитое корыто, о котором мы говорили ранее. Считайте,
что вы заменили 500-фунтовую бомбу теперь на примерно 20-мегатонную позже!
Итак, вы делаете признание. Вы снова выполняете этапы 1-5. Вы даете новое
обязательство, определяете новые ожидаемые результаты и стартуете. В конеч-
конечном счете ваше поведение будет увидено как то, чем оно и было: профессио-
профессиональным руководством проектом.
Некоторые заключительные мысли о предмете:
¦ Знайте то, что ожидает ваш заказчик. Его надежды полностью базируются на
том, к чему вы его подвели, во что смогли заставить его поверить. Вы можете
отойти от них, не слишком задевая его чувства? Вполне. Проверьте и найди-
найдите, чем его можно задобрить в критической ситуации. Убедитесь, что ваш
график разработки дает возможность поставить это в первую очередь.
¦ Встройте в ваш график работ ряд демонстраций и/или прототипов, чтобы ваш
заказчик мог потрогать систему руками на ранней стадии ее разработки и вы
могли удостовериться в том, что правильно прочли его ожидания.
¦ Посмотрите, что потребуется, чтобы дать больше, чем он ожидает, и запла-
запланируйте сделать это, если такое вообще возможно, - это действительно про-
произведет на него впечатление. Но это произойдет только в том случае, если вы
удовлетворили все его основные пожелания.

84 Часть 1. Анализ и планирование проектов
¦ Не делайте неприятных сюрпризов вашему заказчику. Заказчики очень мно-
многое прощают, если обращаться с ними, как с умными людьми. Но если они
начинают думать, что вы дурачите их, их реакция ужасна.
¦ Некоторые вещи не имеют никакого допуска на ошибки. Знайте, какие задачи
в вашем проекте именно таковы, следите за ними ястребиным оком и обяза-
обязательно добейтесь, чтобы они были нормально выполнены.
¦ Отступление на запасную позицию не обязательно должно быть позором; его
можно представить как мастерский штрих планирования и прогнозирова-
прогнозирования - еще один пример управления ожиданиями.
Пример б: управление ожиданиями
Скотт отплыл из Англии на пике всеобщего внимания. Британская империя
была на вершине славы. Любому рационально мыслящему стороннему наблю-
наблюдателю было ясно, что британец будет первым на Южном полюсе. Амундсен
ускользнул незаметно, и только после того как он был вне досягаемости, его
цель стала известна всему миру. Если бы он потерпел неудачу, то спокойно
ушел бы в забвение. Если бы Скотт потерпел неудачу, это была бы слишком
громкая публичная неудача.
Пример 7: заложить допуск на ошибки
Скотт поместил одну тонну запасов на пути, которым он собирался следовать
к полюсу. Эти склады были отмечены снежными пирамидами и одиночными
сигнальными флагами. Скотт позволил запасти ровно такое количество продо-
продовольствия и топлива, в котором он нуждался. Когда в последний момент он уве-
увеличил число людей в группе, идущей к полюсу, с четырех до пяти, это нарушило
все его расчеты. Чтобы решить эту проблему, был поспешно составлен новый
план, однако Скотт и его компаньоны умерли от голода, цинги (вызванной не-
недостаточностью витаминов) и болезней.
Амундсен поместил четыре тонны запасов по пути. Его склады были обозна-
обозначены наборами сигнальных флагов, расположенных по радиальным направлени-
направлениям от склада. К каждому сигнальному флагу была прикреплена записка с указа-
указанием расстояния от склада и направления движения от него. По возвращении из
экспедиции люди Амундсена прибавили в весе и оставили за собой на складах
две тонны продовольствия.

Глава 5. Управляйте ожиданиями, установите допуск на ошибки, запасные позиции 85
Пример 8: иметь запасную позицию для отступления
Мы ранее упоминали битву при Сомме в Первой мировой войне, когда британ-
британцы начали наступление, которое, как они надеялись, закончит войну (Macdonald,
1983). План британского командующего был замечателен. Весьма простодушно он
надеялся, что это будет легкой прогулкой для его людей.
Он собирался обеспечить это, подвергнув немцев самому большому артилле-
артиллерийскому обстрелу этой войны, да и любой войны. Она должна была длиться не-
непрерывно в течение недели. После этого его люди должны были буквально прой-
пройти через то, что осталось бы от немецких линий обороны. К сожалению, прогулки
не получилось. Немецкая оборона оказалась очень мало затронутой, и почти 60
тысяч британских солдат были убиты или ранены только в первый день наступле-
наступления. Убито было более 19 тысяч солдат, большинство из них в первую пару часов
сражения.
Британский план проекта был основан на предпосылке, что это будет легкая
прогулка. Когда эта предпосылка не материализовалась, у них не было никакого
плана на случай непредвиденных обстоятельств. Вы делаете одну из наиболее
рискованных вещей, которые только можно вообразить, когда запускаете проект
на основе отсутствия непредвиденных обстоятельств, без запасных позиций.
Это - человеческая природа: если вы сообщаете кому-то, что вы собираетесь
делать что-то, и делаете это, они довольны. Если вы делаете больше, чем сказа-
сказали - даете им дополнительные дивиденды - они восхищены. Но если вы не сде-
сделали то, что сказали, ваше имя втоптано в грязь. Как только план сделан, надо
посмотреть на него и спросить себя:
¦ Чего ожидают люди (вы сами, проектная группа, ваш заказчик, начальство,
коллеги, остальные сотрудники вашей организации, люди вне организации)
после завершения проекта? Можете ли вы дать им то, что они ожидают?
¦ Что, если что-то пойдет не так? Потратьте время на анализ того, что может
пойти не так, как надо. Используйте мозговой штурм или методы, обсуждае-
обсуждаемые в главе 11, посмотрите, насколько хорошо вы подготовлены, чтобы
иметь дело с этими проблемами. Есть некоторые вещи, для которых у вас не
будет допуска на ошибки, и они должны стать для вас критическими задача-
задачами. Многие вещи, однако, являются менее критическими, и вы, возможно,
сможете прожить без них некоторое время. Идентифицируйте критические
и менее критические задачи. Потребуют ли они модификации ожидаемых
людьми результатов?
¦ Есть ли запасная позиция? Если произойдет что-то катастрофическое, сможе-
сможете ли вы сохранить вашу шкуру и проект? Если нет, то, по крайней мере, вы

86 Часть 1. Анализ и планирование проектов
будете идти вперед, осознавая риски, однако часто есть вещи, с которыми вы
сможете справиться.
Это надо сделать для проекта в целом и для каждой задачи в вашем списке.
Попытайтесь ранжировать риск, связанный с каждым заданием, как высокий,
средний или низкий. Затем сосредоточьтесь на задачах с высоким уровнем риска
и убедитесь, что для них есть как минимум допуск на ошибки и запасные пози-
позиции. Мы уже говорили, что управление ожиданиями, закладка допуска на ошиб-
ошибки и наличие запасных позиций представляют собой аспекты одной проблемы.
Если коротко, то это можно сформулировать так:
¦ определите цель;
¦ идентифицируйте запасную позицию;
¦ определите ожидаемые результаты, адекватные запасной позиции;
¦ тогда ваш допуск на ошибки представляет собой все, что находится между
запасной позицией и реальной целью.
В таком подходе есть один скользкий момент. Здесь большая опасность в том,
что запасная позиция теперь становится целью, и вы снова остаетесь в ситуации,
когда у вас есть цель и нет запасной позиции. Вот заключительный пример из ис-
истории, который показывает все три вещи: управление ожиданиями, допуск на
ошибку, наличие запасной позиции - как аспекты одной и той же проблемы.
Пример 9
"Непотопляемый" (ожидание) "Титаник" был спущен на воду в 1912 году. Он
мог брать на борт 2000-2500 человек пассажиров и команды и имел вмести-
вместимость всех спасательных шлюпок примерно на 1100 человек (никакого допуска
на ошибки). Когда он столкнулся с айсбергом ночью 14 апреля 1912 г., свыше
тысячи людей лишились жизни (не было запасной позиции).
ИСПОЛЬЗОВАНИЕ В РАЗРАБОТКЕ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Мы обещали показать вам несколько тактических приемов для защиты от аг-
агрессивного начальства и заказчиков с одновременным сохранением цивилизо-
цивилизованного уровня общения. Вот эти приемы.
Начальство или заказчики часто хотят знать в начале проекта, когда он за-
завершится и сколько это будет стоить. Также часто от вас требуют установить

Глава 5. Управляйте ожиданиями, установите допуск на ошибки, запасные позиции 87
фиксированную цену за работу на очень ранней стадии разработки программы.
Что делать в таких случаях?
Я считаю, что единственное время, когда вы сможете точно оценить проект,
выполняемый по установленному графику и с фиксированным объемом трудо-
трудозатрат, это когда вся разработка завершена. В этот момент я с удовольствием
дам оценку фиксированной стоимости заказчику (другими словами, под залог
своей шеи определю дату поставки и уровень укомплектования персоналом).
Раньше этого сделать нельзя. Повторяю, раньше вы не можете давать таких
оценок. Если на вас оказывается давление, чтобы вы выдали эти оценки ранее,
есть несколько приемов, которые можно использовать.
Указание двух фиксированных цен: "Я дам вам фиксированное ценовое пред-
предложение для стадии разработки [программного продукта], а в конце ее я дам вам
фиксированное ценовое предложение на остальное. У вас будет разработка, так
что если вам не понравится мое предложение по ее реализации, вы сможете пе-
передать эту разработку в другое место". Другая интерпретация этого же - "я могу
только дать вам дату/трудозатраты на момент завершения разработки. В этой
точке я смогу дать вам дату/трудозатраты для остального".
Оценка Паркинсона: часто применяется давление в виде сообщения вам конеч-
конечной даты, к которой система должна быть готова, и размер группы, которую вам
дают, чтобы выполнить проект. Оценка Паркинсона обратным отсчетом от ко-
конечной даты может показать невозможность сделать то, о чем вас просят. Это
выполняется очень быстро. Вы подставляете ваши шесть (или другое количест-
количество, которое есть в вашем проекте) этапов в обратном направлении от конечной
даты. Типичные результаты в этом случае примерно таковы: чтобы завершить
разработку к заданному сроку, надо было начинать два месяца назад; выполнить
разработку в срок можно только в том случае, если программирование будет
сделано за два дня, или же уложиться в срок можно, если не проводить никакого
тестирования.
Завышение оценки: если вы поставлены в положение, когда вам надо дать
фиксированную цену, надо завысить оценку, чтобы дать себе достаточно места
для маневра. И вполне нормально здесь сообщить заказчику, что вы это делаете
и почему: "Мы не знаем, насколько велика эта работа, г-н заказчик, так что на
основе наших оценок и уровня знаний в настоящее время нам придется принять
самые худшие сценарии развития событий, это и объясняет нашу цену. Если
в конце стадии разработки мы обнаружим, что наша цена завышена, мы будем

88 Часть 1. Анализ и планирование проектов
очень счастливы вернуть лишнее вам. Да, кстати, если кто-то скажет вам по-
другому...он неправ".
Вы должны не снимать руки с курка. Если ваши оценки сделаны правильно
и верите в них, то ваша моральная позиция высоконравственна и безупречна.
Если вы берете на себя обязательства в том, что не можете выполнить, то вы бу-
будете руководить катастрофой и очень скоро будете выглядеть весьма глупо.
Я не знаю никого, кто был бы уволен из-за отказа отступить от своих оценок.
И я знаю множество случаев, когда людей увольняли из-за их мягкотелости
в этих вопросах!
Играйте с контролем изменений: если вас вынуждают дать фиксированное це-
ценовое предложение, убедитесь, что вы указываете его со всеми своими замеча-
замечаниями в печатном виде. Оговорите явно и до мельчайших деталей, что было
включено и что нет и все предположения, которые вы сделали. Тогда, как только
другие моменты всплывают в ходе стадий анализа и разработки, вы можете иг-
играть в игру с контролем изменений, когда каждый такой новый момент исполь-
используется для внесения изменений в контракт.
Сообщите им, что это невозможно: в этом случае вы беретесь за проект, но без
всякой ответственности за сопутствующие огрехи и провалы. Хорошая перспек-
перспектива? В этом сценарии кто-то предлагает вам то, что выглядит невыполнимой
миссией, и вы говорите - да! Не безоговорочное "да", однако, а с определенны-
определенными условиями.
Вообразите сцену. Вы смотрите на то, что они просят вас сделать, а ваша мо-
модель и все вытекающие из нее причины говорят вам, что это невозможно. Одна-
Однако они непреклонны - это обещано и это должно быть сделано. Тогда вы делаете
следующее предложение. Вы говорите: "Я посмотрел то, что вы просите меня
сделать, и я полагаю, что это невозможно по причинам, которые я изложил. Од-
Однако, учитывая ваше критическое положение, я готов сделать все, чем могу по-
помочь. Вот мое предложение. Я берусь за этот проект и буду его выполнять для
вас. Я не могу гарантировать вам, что я выполню эти обязательства, но я гаран-
гарантирую, что, как только я определю на деле, что это невозможно, я дам вам знать
это. Тогда вы сможете решать, как объяснить это заказчику".
Что мы теперь имеем. Они не могут обвинять вас в предательстве родной ко-
команды. Обратите внимание также на повторное использование слова ВЫ в тече-
течение этой небольшой речи, что гарантирует, на ком будет вина и кто будет нести
ответственность.

Глава 5. Управляйте ожиданиями, установите допуск на ошибки, запасные позиции 89
ВКЛАД В PSI
О непредвиденных случаях, или допуске на ошибки, можно думать как
о пространстве между вашей запасной позицией и вашей фактической целью.
Максимальный вклад в PSI - 10.
Вы набираете до 5 баллов в этапе 5, если включили ряд непредвиденных об-
обстоятельств в свой план. Чем больше непредвиденных обстоятельств, тем ближе
ваш счет к 5.
Вы получаете другие 5 баллов, если можете показать, что определенные вами
ожидаемые результаты лежат где-то между запасной позицией и целью. Чем
ближе ожидаемое находится к вашей запасной позиции, тем оценка ближе к 5.
Если ваш проект не имеет никакого допуска на ошибки, то здесь вы теряете
15 баллов из общей суммы.
СТРУКТУРНОЕ УПРАВЛЕНИЕ ПРОЕКТОМ
Планирование проекта
1. НАГЛЯДНО ПРЕДСТАВЬТЕ СЕБЕ ЦЕЛЬ; НАЦЕЛЬТЕСЬ НА ПРИЗ.
2. СДЕЛАЙТЕ СПИСОК ЗАДАЧ, ПОДЛЕЖАЩИХ ВЫПОЛНЕНИЮ.
3. ДОЛЖЕН БЫТЬ ОДИН РУКОВОДИТЕЛЬ.
4. РАСПРЕДЕЛЕНИЕ ЗАДАЧ ПО ЛЮДЯМ.
5. УПРАВЛЕНИЕ ОЖИДАНИЯМИ,
ЗАДАНИЕ ДОПУСКА НА ОШИБКИ, ОБЕСПЕЧЕНИЕ ЗАПАСНОЙ ПОЗИЦИИ.

ЧАСТЬ 2
КОНТРОЛЬ И ОСУЩЕСТВЛЕНИЕ
ПЛАНА
ДОСТИЖЕНИЕ ЦЕЛИ
ВВЕДЕНИЕ
До этой точки в своих трудах вы тратили все время, планируя проект; вы все
еще не отправились в путешествие. Не будет преувеличением сказать, что судь-
судьба вашего проекта была в очень большой степени решена работой, которую вы
смогли или не смогли пока сделать. Если вы применяли к вашему проекту этапы
из структурного руководства проектом, то вы будете:
¦ Знать в тончайших деталях цель проекта.
¦ Иметь план - очень детальный на ближайшее будущее, менее детальный на
дальнейшее, но, по крайней мере, показывающий остающиеся важные про-
промежуточные цели.
¦ Иметь ясное представление того, кто будет реально руководить [проектом].
¦ Видеть распределение членов вашей команды по задачам в списке задач.
¦ Точно знать, что каждый понимает полную картину и как его отдельная часть
вписывается в общую картину.
¦ Знать, чего ожидает каждый, и иметь некоторое место для маневра между
этими ожиданиями и тем, что вы планируете сделать.
Теперь вы можете начинать путешествие, защищенные знанием, что вы стар-
стартуете с надежной базы и что вы на этой стадии сделали столько, сколько могли,
чтобы подготовиться ко встрече с неожиданностями. Если вы сделали не все или
вообще ничего из всех указанных вещей, вас ждет потрясающее количество
очень плохих новостей, и лучше я начну их пересказывать. Если у вас остались

Часть 2. Контроль и осуществление плана; достижение цели 91
слезы, готовьтесь пролить их сейчас. Ваш проект может и не потерпеть неудачу.
В конце концов, жизнь полна неожиданностей - это одна из тех вещей, которые
делают ее столь веселой.
Если ваш проект не потерпит неудачу, то вы вытащите главный приз. Вы вы-
выиграете несмотря на то, что все шансы против вас. Готов держать пари, это было
не очень приятно и были времена, когда это было просто ужасно, так что вряд
ли кто-нибудь радовался всему этому. Но если вы сделали это, что я могу ска-
сказать, честь вам и хвала. Я только удивляюсь, зачем вы решили протащить себя
и свою команду через такой опыт. И я удивляюсь, почему вы выбрали такой
способ выполнять проекты, поскольку вам не становится легче продвигаться от
данной цели до следующей при постоянном незнании, будет ли это работать или
нет. В любом случае, это ваш выбор и удачи вам в будущем проекте.
Это были хорошие новости. Плохие новости состоят в том, что я уверен -
ваш проект обречен на катастрофу, двигаясь к ней с возрастающей скоростью
так же, как "Титаник" к своему столкновению с айсбергом. Ваш проект будет
катастрофой, и вы, как руководитель проекта, будете иметь на руках капиталь-
капитальный бардак, который заставит пожалеть, что вы когда-то связались с ним. Что
бы вы ни надеялись извлечь из него (деньги, продвижение по службе, престиж,
мощный послужной список в резюме, славу, признание, что бы то ни было), все
будет погребено в ужасных руинах, которые ждут впереди. Я могу предложить
вам только два возможных совета. Либо сделайте надлежащий план, либо вый-
выйдите из игры, пока вы еще не запятнаны.
Если вы сделали надлежащий план, со всеми подробностями, которые мы так
настойчиво подчеркивали, это означает, что вы выделили один возможный путь,
по которому может разворачиваться проект. Что мы теперь собираемся сделать
на Этапах 6-10, так это преобразовать план в самореализующийся прогноз. Мы
будем пробовать заставлять действительность твердо придерживаться пла-
плана. И хотя это звучит так, как будто вам надо обладать качествами бога, чтобы
добиться такого, забудьте, ничего сверхъестественного вам не потребуется.
План говорит, что определенные наборы задач должны "откусываться" каж-
каждый месяц, каждую неделю и, в конечном счете, каждый день. Если задачи "съе-
"съедаются" точно так, как определено в нашем плане - другими словами, если мы
достигаем ежемесячных, еженедельных и ежедневных целей, которые определя-
определяет наш план, - тогда проект останется в графике. Кроме того, мы можем исполь-
использовать взаимодействие наших четырех параметров:
¦ функциональность,
¦ дата поставки,

92 Ф. О'Коннэл. Как успешно руководить проектами
¦ трудозатраты (стоимость),
¦ качество,
чтобы пытаться обеспечить выполнение задуманного. Таким образом, например,
если определенный промежуточный этап должен быть достигнут в заданный
день, мы можем, скажем, добавить людей (увеличение трудозатрат) или умень-
уменьшить функциональность, чтобы добиться этого. Если мы делаем это для каждого
промежуточного этапа, большого и маленького, в течение всего процесса вы-
выполнения проекта, то проект останется в графике и наш план действительно
превратится в самореализующийся прогноз. Реальность на самом деле будет
придерживаться плана. Эти комментарии полностью применимы также к стои-
стоимости или бюджету.
Это то, что представляют собой этапы 6-10, так же как и материалы части 3
об одновременном выполнении нескольких проектов.
Здесь на прилавок выкладывается еще одна вещь. В какой-то момент я хотел на-
назвать эту книгу "Ленивый руководитель проекта" ("The Lazy Project Manager"), но
Вики, мой редактор, не оценила эту идею. Слово "ленивый" (lazy) обычно использу-
используется в отрицательном смысле, но в настоящем контексте я намереваюсь сделать его
достаточно хвалебным. У ленивого руководителя проекта не просто успешные про-
проекты. Он имеет их, делая наименьшее количество возможной работы.
Видите ли, Десять этапов не просто гарантируют успешный проект. Они
представляют собой тот минимум, который вы должны сделать для успеха про-
проекта. Математики описали бы их как "необходимое и достаточное условие" для
успешного проекта. Необходимое, потому что вам придется делать эти вещи;
достаточное, потому что их достаточно, как только вы их сделали, больше ни-
ничего вам делать не нужно.
Десять этапов избавляют вас от мучительных мыслей о том, достаточно ли
сделано для руководства проектом. Они избавляют вас от пробуждения в сере-
середине ночи в холодном поту, задающим себе вопрос, не пропустили ли вы что-
нибудь. Они говорят вам, когда сделано достаточно, когда ваша работа выпол-
выполнена на том уровне, на каком это возможно.
В главах 6-10 и в части 3 я покажу вам, как стать ленивым руководителем
проекта.
Наконец, есть еще одно последнее заслуживающее внимания применение Де-
Десяти этапов. Когда я начинал руководить проектами и когда принял или запус-
запустил новый проект, первым делом я "вчитывался". Это включало прохождение
через мои руки каждого документа, который я считал связанным с проектом,
всего связанного с технологией, используемой проектом, и любой другой общей

Часть 2. Контроль и осуществление плана; достижение цели 93
информации, которая выглядела хотя бы в отдаленной степени относящейся
к проекту. Затем я садился читать и предавался этому занятию с настоящим ув-
увлечением. Часто материалов не существовало или они были устаревшими, и то-
тогда я получал неполную или искаженную картину проекта.
С появлением Десяти Этапов вчитыванию пришел конец. Первые пять этапов
точно говорят вам, какие вещи вам надо знать:
¦ Где я могу найти описание цели проекта и подтверждение, что детали этой
цели будут разрабатываться (спецификации, проектные исследования и т. д.)?
¦ Есть ли план? (Если есть, то вы можете использовать материал части 4, чтобы
проанализировать его.) Кто руководит проектом, если это не вы сами?
¦ Все ли задачи распределены по людям? Были ли приняты во внимание другие
их занятия? Где потенциальные слабости в распределении работ?
¦ Учтены ли неожиданные обстоятельства и есть ли запасная позиция? Какие
ожидаемые результаты были определены? Как цель, запасная позиция и ожи-
ожидания связаны между собой?
ИСПОЛЬЗОВАНИЕ В РАЗРАБОТКЕ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
На этой стадии вы должны иметь следующее:
¦ детальное описание цели проекта (из этапа 1);
¦ список задач, полный для первого промежуточного этапа и детализирован-
детализированный в меру возможностей на последующие этапы, но с включенными основ-
основными промежуточными задачами (из этапа 2);
¦ руководителя проекта (из этапа 3);
¦ распределение вашей команды по задачам в списке задач, такое, что все зада-
задачи охвачены (из этапа 4);
¦ какие-то планы на случай непредвиденных обстоятельств (из этапа 5), если
дела пойдут не так, как надо.
Другими словами, вы имеете все, что должно быть в хорошем проектном
плане, и готовы отправиться в великое неизведанное. Только напоследок ссыл-
ссылки, в которых представлено оглавление проектного плана, где вы можете струк-
структурировать всю информацию, собранную с применением этапов с 1 по 5.

94
Разделы плана
0. Связанные
проекта
[с проектом]
документы
Ф.
О
'Коннэл.
Как
успешно руководить проектами
Информация из этапов
1. Введение 1
2. Описание проекта
2.1. Формулировка работы 1/2
2.1.1. Технические требования
2.1.2. Разработка верхних уровней
2.1.3. Разработка нижних уровней
2.1.4. Реализация
2.1.5. Альфа-тестирование
2.1.6. Бета-тестирование
2.2. Поставка 1
2.2.1. Программное обеспечение
2.2.2. Документация
2.2.3. Услуги
2.2.4. Критерии приемки
2.3. Критерии завершения (как мы узнаем, когда проект будет 1
закончен?)
_
План разработки
3.1. Структура разбиения работ (WBS)
3.1.1.
3.1.2.
3.1.3.
3.1.4.
3.1.5.
3.1.6.
Технические требования
Разработка верхних уровней
Разработка нижних уровней
Реализация
Альфа-тестирование
Бета-тестирование
3.2. Рабочий план
3.3. Трудозатраты 2
3.4. График 2
3.5. Промежуточные этапы 2
3.6. Загрузка ресурсов / накачка проекта [ресурсами] 2,3,4
3.7. Бюджет 2,3,4
3.8. Критические пункты 5
3.9. Организация проекта 3
4. Требуемые ресурсы
4.1. Люди 3,4
4.2. Оборудование 2,5
4.3. Обучение 2,3,4,5
4.4. Прочие 2-5

Часть 2. Контроль и осуществление плана; достижение пели
Разделы плана проекта
5. Прогнозы
6. Нерешенные проблемы
95
Информация из этапов
1-5
1-5
Приложение А. Получение оценок 2,4,5
П.1. Трудозатраты и кадры
П.2. График
П.З. Допуск на ошибки 5
Вообще говоря, программные проекты терпят неудачу по множеству причин,
однако часто они терпят неудачу только потому, что:
¦ некоторые вещи длятся дольше, чем ожидалось;
¦ требования постоянно изменяются неконтролируемым образом;
¦ возникает что-то, чего никто не предполагал;
¦ никто не оценил - хотя бы из соображений минимального здравого смысла, -
как долго данная вещь будет делаться или сколько она будет стоить;
¦ технические проблемы, которых никто не предвидел, вызвали задержки.
Признаем, некоторые из этих утверждений справедливы. Однако они часто
используются для того, чтобы замаскировать отсутствие базового планирования
и предусмотрительности. Выполните этапы 1-5 структурного руководства про-
проектом в вашем проекте, и вы дадите себе некоторый шанс для драки. Если вы
наследуете проект, настаивайте, чтобы вам позволили выполнить эти этапы, и не
удивляйтесь, если ваше начальство будет обеспокоено результатами.
Однако вам самому беспокоиться не надо. Структурное руководство проектом
гарантирует истинность ваших утверждений, и в любом случае в этой точке про-
проекта ваша позиция морально безупречна. Держите себя в руках, и если проект
достаточно важен, они позволят вам сделать все правильно. Это также справедли-
справедливо, если вы имеете дело с субподрядчиком. Проверьте, что по самому минимуму его
предложение содержит уже намеченные элементы, и выбросьте его, если этого нет.
Вы осуществили все планирование, и проект тронулся в путь. Следующие
пять глав обсуждают, что вы должны делать в течение путешествия к вашему
месту назначения.
ЗНАЧЕНИЕ ЭТАПОВ 1-5 ДЛЯ PSI В ЭТОЙ ТОЧКЕ
Здесь должны быть отмечены два момента. Во-первых, вы должны заметить,
что 70 % PSI приходится на этапы 1-5, этапы планирования. Если это так, а все
собранные нами до настоящего момента свидетельства показывают, что это так,

96 Ф. О'Коннэл. Как успешно руководить проектами
то подтверждается ранее сказанное нами о решении судьбы вашего проекта на
стадии планирования.
Во-вторых, проекты, которые мы анализировали до настоящего момента, по-
показывают, что 40 баллов - это пороговое значение для этих этапов планирова-
планирования. Что я имею в виду? Когда проект запускается, в течение самых первых мо-
моментов его жизни такие вещи, как цель (этап 1), список задач (этап 2) и т. д., да-
дают очень малый, если не нулевой вклад в начисляемые баллы. Например, у вас
может быть чуть больше двух строк описания цели проекта, что даст, если пове-
повезет, 1 или 2 балла из 20. Аналогично и для других четырех этапов.
Порог в 40 баллов говорит, что первое, что вы должны сделать в проекте,
причем абсолютно первое, вплоть до исключения всех других дел, - вы должны
пройти через процессы:
¦ Определения цели с нарастающими уровнями детализации. (Если вы задумае-
задумаетесь, то первые несколько стадий цикла жизни любого проекта - сбор требова-
требований, проектирование и так далее - относятся именно к этому процессу.) (Этап 1.)
¦ Уточнения плана по мере большей определенности и детализации цели.
(Этап 2.)
¦ Обеспечения единоличного управления проектом путем создания организа-
организационной структуры проекта и введения процессов и процедур, которые будут
работать повсеместно до конца проекта. (Этап 3.)
¦ Заполучения людей для работы (реальных теплых существ) и распределения
задач между ними. (Этап 4.)
¦ Структурирования вашего плана таким образом, чтобы обеспечить запасную
позицию и допуск на ошибки. (Этап 5а.)
¦ Определения правильных ожиданий. (Этап 5Ь.)
При выполнении этих задач вы постепенно поднимаете ваш PSI, пока он не
достигнет критического уровня в 40 баллов. Пока вы не добьетесь 40, вы долж-
должны стараться тратить на проект столь мало труда, сколь это возможно, посколь-
поскольку вы не можете быть уверенными ни в чем, пока не преодолеете порог в 40 бал-
баллов. Таким образом, делая что-либо отличное от вышеперечисленного, вы тра-
тратите впустую время, труд, ресурсы, деньги и энергию.

ГЛАВА б
Этап 6: ИСПОЛЬЗУЙТЕ ПОДХОДЯЩИЙ СТИЛЬ
РУКОВОДСТВА
ВВЕДЕНИЕ
Ваша команда продвигается вперед; это смешанный набор индивидуалов, как
мы уже обсуждали. Некоторые кажутся мегазвездами, некоторые - хорошие на-
надежные работники, некоторые определенно выглядят слишком хитрыми. В ко-
команде может быть всего несколько человек, так что она похожа на семью, а мо-
может быть и тысячи. Каждый человек - индивидуум со своими собственными же-
желаниями, страхами, надеждами, предубеждениями, навыками, опытом, отноше-
отношениями, проблемами, амбициями. Как же хотя бы начать руководство таким
сложным организмом? Как распределить работу? Знать, как идут дела? Как под-
поддерживать рабочую атмосферу? Как ее вообще оценить?
"Это выше моего понимания!" - является, вероятно, наиболее точным отве-
ответом на эти вопросы. Это - невероятно трудная вещь. Несложно предположить,
что в любое конкретное время у некоторых из людей в вашей группе будут ка-
какие-то личные проблемы. Равно как несложно предположить, что в любое кон-
конкретное время некоторые из людей будут вести себя таким образом, что от них
не будет никакой отдачи или они даже будут тормозить ваш проект.
Лучшее, что здесь может сделать любой из нас, это на полную катушку экс-
эксплуатировать свои управленческие способности. Здесь нет никаких правил,
только самые общие рекомендации; и я представляю свой опыт под общим заго-
заголовком: используйте подходящий стиль руководства.
Каждая задача в вашем списке будет выполняться человеком. Это делает
комбинацию задачи и человека уникальной, то есть та же самая задача была бы
сделана по-другому другими людьми. Это означает, что в вашем проекте будут
сотни или, возможно, тысячи уникальных человеко-задач и всеми вам придется
управлять. Сумма того, как вы управляетесь со всем этим, и представляет ваш
стиль руководства.
Каждый из нас имеет некий основной стиль - авторитарный, демократиче-
демократический, мягкий, жесткий и т. д., - но нам придется изменять этот наш стиль в зави-
зависимости от той человеко-задачи, с которой мы имеем дело. Означает ли это, что
мы должны иметь сотни различных стилей? А если нет, как мы узнаем, какие
4 - 2224

98 Часть 2. Контроль и осуществление плана; достижение цели
стили существуют и когда их использовать? Есть пути, как это сделать. В гла-
главе 4 мы обсуждали пять ситуаций, которые могли возникать в отношениях чело-
человека и задачи. Это были:
1) может выполнить данную работу и хочет делать ее;
2) может выполнить данную работу и подготовлен, чтобы делать ее;
3) может выполнить данную работу, но не подготовлен, чтобы делать ее;
4) может быть обучен/проинструктирован, как выполнить данную работу;
5) не может выполнить данную работу.
Есть другая концепция, которую мы должны здесь представить. Это - идея
доверия к тому, кто выполняет задачу. Введем следующее определение. Если,
когда вы обращаетесь к кому-то с просьбой выполнить задание, вы можете счи-
считать это задание уже выполненным, мы будем говорить, что вы доверяете этому
человеку. Очевидно, если бы это было справедливо для всех людей и всех задач
в вашем проекте, тогда вы вряд ли были бы нужны вообще, все бы шло гладко
и завершилось согласно плану. Вы именно потому и нужны, что обычно не до-
доверяете некоторым или всем людям в вашем проекте.
Что заставит вас доверять кому-то так, как мы определили это выше? Вы
могли бы доверять им, потому что работали с ними прежде и знали, что на них
можно положиться при выполнении любого задания. Или, возможно, другие
люди, которым вы доверяете, могли бы дать о них хвалебные отзывы. Или вы
уже попробовали их в вашем проекте: объяснили, чего вы ожидаете от членов
группы - когда человеку дают задание, то всегда можно считать, что оно будет
сделано, - и проверили их на двух-трех задачах. Если они выполнили эти зада-
задачи, то вы начинаете выстраивать свое доверие к ним. Хорошим тестом будет
спросить себя, будете ли вы чувствовать себя уверенно, вручая вашу репутацию
их решениям и исполнительности. Другая проверка состоит в том, что вы нахо-
находите некое надежное доказательство того, что им можно доверять.
Если они не пройдут эти испытания, то вы не доверяете им. Проще простого.
В процессе работы над проектом вы можете изменить свое мнение и начать до-
доверять им. Это другая проблема. Также вы можете некоторые задания доверять
им, а другие нет. Я повторяю тест - если вы не чувствуете, что с ними можно
пойти в разведку, или не имеете никаких надежных свидетельств на этот счет, то
в рамках данного обсуждения вы не доверяете им.
В таблице 6.1 показано десять возможных сценариев и стилей руководства,
которые я предлагаю принимать вам в каждом случае. Когда в таблице говорит-
говорится: "Перевести в B) или E)", это значит, что методы, позволяющие это сделать,
будут обсуждаться в главе 15.

Глава 6. Используйте подходящий стиль
Таблица 6.1
ВАРИАНТ
1. Может делать это/любит дела! ь это
2. Может делать это/подготовлен, чтобы
сделать это
3. Может делать это/но не хочет
4. Может делать это после обучения
5. Не может сделать это
руководства
ДОВЕРЯЮ
(А)
(А)
Ситуация такая, как в (Е)
(С)
(Е)
99
НЕ ДОВЕРЯЮ
(В)
(В)
Перевести в B) или E)
(D)
Перевести в B) или E)
А
Вы уверены, что данный человек выполнит задание. Возможно, он делал это
или что-то аналогичное прежде. Ему нравится это делать, или, в худшем случае,
он настроен сделать его. Короче говоря, он профессионал и может принимать
все решения внутри своей задачи. Оставьте задачу ему. Не тратьте на него свое
время, за исключением постановки галочки в списке в день, когда работа долж-
должна быть завершена по графику. Даже если что-то пойдет не так, мы перехватим
это благодаря концепции "Без сюрпризов", как будет описано в следующей главе.
В
Они делают это, душа у них, вероятно, лежит к этому, но вы не уверены на
все сто процентов, что оци сделают это правильно или уложатся в срок. Вам
придется контролировать их: вы отвечаете головой. Нет необходимости жестко
пинать их - несколько легких движений руки сделают свое дело. Если необхо-
необходимо принимать решения, то вам придется работать с ними, чтобы достигнуть
правильного результата.
С
Они делали другие вещи хорошо в прошлом, а теперь вы пробуете их на чем-
то новом. Пока они хорошо справлялись со всем, но это - новая игра. Еще один
вариант ненавязчивого наблюдения, как в случае В. Помните, что ваша голова
зависит от этого. У вас могут быть приличные отношения с ними в любом слу-
случае - из которых возникает доверие, - и вы знаете, какой уровень контроля нужно
применить. Решения можно принимать демократическим путем, как в случае В.
D
Они никогда не делали этого прежде, и у вас нет веских причин полагать, что
они могут или будут делать это. Назад в школу, парни. Крепко держать за руку.
Медленное продвижение с подробным разъяснением мини-целей. Непрерывный
контроль на предмет появления признаков неприятностей.

100
Часть 2. Контроль и осуществление плана; достижение цели
Здесь у нас проблема. Фактически даже две проблемы. Сначала проблема,
что делать с задачей, которую, как предполагалось, должен делать этот человек.
Эта задача не будет выполнена: нам придется поручить ее другому. Тогда есть
проблема человека. По крайней мере, одну из задач нашего проекта этот человек
не сделает. Это потенциально означает, что это же происходит или произойдет
с другими задачами. Мы должны определить, что мы будем делать с этим чело-
человеком. Но как для руководителя проекта, особенно как для "ленивого руководи-
руководителя проекта" наш главный приоритет - задача. Сначала мы должны решить
с ней. А затем, во вторую очередь, мы можем позаботиться о человеке.
Вы можете использовать форму 2 из главы 4, которая воспроизведена здесь
(рис. 6.1), чтобы понять, какой стиль управления использовать в каждой ситуа-
ситуации человеко-задачи.
Работник
Задача
Категория
Надежность
Да
Нет
Рис. 6.1. Форма 2: распределение работ
Ленивый руководитель проекта
Давайте быстро оценим эти пять различных стилей по шкале, показанной на
рис. 6.2. Вертикальная ось - мера того, сколько усилий и времени на управление
вы затрачиваете на определенную задачу. Это - мера того, сколько микроуправ-
микроуправления вы производите, сколько времени видите лица ваших людей, насколько
суете свой нос в их дела. Мы оценим по этой шкале каждый из наших пяти сти-
стилей А - Е.

Глава 6. Используйте подходящий стиль руководства
101
Высокие
Управленческие
усилия
Низкие
I
Тип человека
Рис. 6.2. Различные стили управления
Возрастающий пунктир показывает нарастание управленческих усилий при
движении от стиля руководства А до стиля Е. Мне же кажется, что для живых,
теплых и любящих существ естественная тенденция состоит в том, чтобы рас-
распределять наши время и усилия таким образом, как представлено сплошной нис-
нисходящей линией.
Мне нравится тратить время и усилия в области спектра А - В, как показано
на рис. 6.3. Здесь счастливые земли, где мирно живут все хорошие люди. Здесь
компетентные, активные люди. Промежуточные цели достигаются и обязатель-
обязательства выполняются; здесь хорошие новости, рабочая атмосфера, прямой про-
прогресс; все те прекрасные вещи, о которых мы мечтаем для нашего проекта. Мы
проводили бы здесь счастливые дни и возвращались вечером домой, думая, что
мир прекрасен.

102
Часть 2. Контроль и осуществление плана; достижение пели
Высокие
Управленческие
усилия
Низкие
Тип человека
Рис. б.З. Где руководитель проекта должен тратить наименьшее количество времени
На конце спектра в D и особенно в Е, с другой стороны, находится сумереч-
сумеречная зона руководства проектом. Это земля перманентных плохих новостей, не-
разберих, провалов, SNAFU1 s; необходимость сообщать плохие новости началь-
начальству и заказчикам; проглатывать обиды; давать отрицательные отзывы о работе
персонала или не повышать зарплаты; необходимость увольнять людей; долго и
занудно уговаривать людей что-то сделать; конфликтовать, раздражать, спорить
и вообще тратить огромное количество эмоциональной энергии, пытаясь дер-
держать все в рамках. Здесь есть чувство, что тебе обязательно подложат свинью.
Короче говоря, нам хочется находиться здесь не более, чем в преисподней!
Итак (я не знаю, есть ли на вас такая вина, но я грешен), мы проводим наше вре-
время на стороне А - В и тянем резину, откладываем и, по большей части, избегаем
делать то, что нужно, на стороне D - Е. Мы занимаемся действительно интересны-
1 SNAFU - Situation Normal - All Fouled Up - беспорядок, неразбериха, дословно: "Все в поряд-
порядке - полный бардак" - Прим. переводчика.

Глава 6. Используйте подходящий стиль руководства
103
ми разговорами с хорошими парнями и тратим впустую наше и их время; и мы из-
избегаем иметь дело с проблемами, которые копятся внутри нашего проекта.
У "ленивого руководителя проекта" нет времени на такие глупости. Он знает,
что расход времени в затененной зоне (рис. 6.2) может быть и приятен, но не
имеет никакого значения вообще для продвижения проекта.
Действительно, если вы проводите большое количество времени, пытаясь
управлять людьми, с которыми на самом деле надо обращаться в стиле А - В,
это не только трата времени и сил, это может фактически стать контр-
контрпродуктивным. Эти люди начинают чувствовать, что вы не доверяете им, их
опыту и решениям, и они могут стать крайне демотивированы избытком того,
что они воспринимают как вмешательство в их компетенцию.
Вместо этого "ленивый руководитель проекта" концентрирует усилия там,
где они нужны: в затененной зоне рис. 6.4. Здесь каждая унция времени управ-
управления и сил непосредственно способствует прогрессу проекта.
Высокие
Управленческие
усилия
Низкие
BCD
Тип человека
Рис. 6.4. Где руководитель проекта должен проводить большую часть времени

104
Часть 2. Контроль и осушествление плана; достижение пели
"Ленивый руководитель проекта" становится объектом сильного недоумения
и раздражения своих коллег, потому что он, кажется, имеет сверхъестественный
дар знания, кого можно не трогать и как выявить проблемы. Короче говоря,
у "ленивого руководителя" не только всегда успешные проекты, но и сам про-
процесс выполнения выглядит у него, как конфетка.
Использование в разработке программного обеспечения
Здесь мы заполняем форму 2. Мы уже заполнили форму, распределяя группу
людей по категориям в соответствии со схемой, представленной в главе 4. Судя
по форме, мы находимся на разумном пути. Есть некоторая потребность в обу-
обучении в силу наличия 4-й категории; однако сейчас нас больше всего интересу-
интересуют два крайних правых столбца. Данная форма точно показывает, куда руково-
руководитель проекта должен направить управленческие усилия, и подсказывает стиль
управления, который будет правильным в любой конкретной ситуации.
На рис. 6.5 мы видим, что каждый попал в столбец отсутствия доверия; причина
может быть в том, что это совершенно новая команда, с которой руководитель про-
проекта прежде не работал, и каждый был помещен либо в категорию В, либо в катего-
категорию D. Эта группа будет требовать интенсивного контроля со стороны руководите-
руководителя проекта. Нет ни одной части проекта, в которую он может не совать свой нос.
Если же после некоторого периода времени он найдет, что созрел для того, чтобы
полагаться на некоторых людей из проекта, и что они регулярно выполняют все за-
задания, он может счесть необходимым пересмотреть свою оценку и переместить их
в столбец "доверяю". Однако до этого времени он должен сохранять осторожный
взгляд на вещи, чтобы гарантировать, что никто не уронит мяч.
Работник
Белоснежка
Ворчун
Чихун
Растяпа
Соня
Счастливчик
Скромняга
Мудрец
Руководитель проекта
Пользовательский интерфейс
Новые функции
Программист
Программист
Разработчик
Специалист по БД
Тестирование
Категория
1
4
4
1+
1+
1
4
4
Надех
Да
<ность
Нет
В
D
D
В
В
В
D
D
Рис. 6.5. Использование формы 2

Глава 6. Используйте подходящий стиль руководства 105
ВКЛАД В PSI
Если ваш стиль имеет тенденцию к статичности - либо перманентный кон-
контроль, либо перманентное невмешательство, выставьте себе низкий балл. Если
вы изменяете свой стиль сообразно с обстоятельствами, дайте себе высокую
оценку. Максимальный вклад в PSI - 10.
СТРУКТУРНОЕ УПРАВЛЕНИЕ ПРОЕКТОМ
Планирование проекта
1. НАГЛЯДНО ПРЕДСТАВЬТЕ СЕБЕ ЦЕЛЬ; НАЦЕЛЬТЕСЬ НА ПРИЗ.
2. СДЕЛАЙТЕ СПИСОК ЗАДАЧ, ПОДЛЕЖАЩИХ ВЫПОЛНЕНИЮ.
3. ДОЛЖЕН БЫТЬ ОДИН РУКОВОДИТЕЛЬ.
4. РАСПРЕДЕЛЕНИЕ ЗАДАЧ ПО ЛЮДЯМ.
5. УПРАВЛЕНИЕ ОЖИДАНИЯМИ, ЗАДАНИЕ ДОПУСКА НА ОШИБКИ,
ОБЕСПЕЧЕНИЕ ЗАПАСНОЙ ПОЗИЦИИ.
Реализация плана; достижение цели
6. ИСПОЛЬЗУЙТЕ ПОДХОДЯЩИЙ СТИЛЬ РУКОВОДСТВА.

ГЛАВА 7
Этап 7: ЗНАЙТЕ, ЧТО ПРОИСХОДИТ
ВВЕДЕНИЕ
В этой главе мы говорим о трех вещах:
1. Использование вашего плана как пульта управления проектом. Здесь мы
опишем, как "ленивый руководитель проекта" проводит свой день.
2. Положительные и отрицательные признаки в проекте.
3. Доктрина "без сюрпризов".
ИСПОЛЬЗОВАНИЕ ВАШЕГО ПЛАНА КАК ПУЛЬТА
УПРАВЛЕНИЯ /ДЕНЬ "ЛЕНИВОГО РУКОВОДИТЕЛЯ
ПРОЕКТА"
Мы все знакомы с пультами управления. В автомобиле, например, мы имеем
ряд индикаторов, циферблатов и других устройств отображения, которые дают
нам количественные данные о том, что происходит в мире. Затем мы предпри-
предпринимаем действия, основанные на этой информации.
Мы можем использовать наш план точно таким же способом, чтобы получать
информацию о том, что происходит в нашем проекте. Тогда мы сможем делать
осмысленные решения и предпринимать соответствующие шаги, чтобы управлять
продвижением нашего проекта к цели. В книгах по руководству проектами, более
научных, чем наша, этот процесс называют "мониторинг и менеджмент проекта".
Именно в этом процессе весь тяжкий труд этапов 1-5, и особенно этапа 2, на-
начинает приносить свои плоды. Заметим также, что план, разработанный нами
в течение этапов планирования, имеет несколько применений:
¦ план, который мы разрабатывали на этапах с 1 по 5 а, позволяет нам оцени-
оценивать проект;
¦ применение этапа 5Ь к этому плану позволило нам сгенерировать его версии,
из которых наше начальство и/или заказчики могли выбирать;
¦ теперь мы собираемся использовать выбранную версию снова как пульт
управления для ведения проекта.

Глава 7. Знайте, что происходит 107
Множество вариантов применения нашего плана является еще одной причи-
причиной, почему стоит тратить время и усилия на создание качественного плана.
И мы снова видим центральную задачу планирования в получении успешного
результата для нашего проекта.
Вы можете использовать ваш план как пульт управления, хранится ли он
в бумажном виде или в компьютеризованной системе планирования на основе ПК.
Все, что я собираюсь сказать здесь, применимо в любом случае. Преимущество
использования компьютеризованной системы состоит в том, что вы будете по-
получать результаты быстрее и ваша работа не будет содержать ошибок, которые
почти неминуемо появляются при работе вручную и записи на бумаге. Я соби-
собираюсь здесь все иллюстрировать, ссылаясь на компьютеризованную систему,
однако повторяю: все, что я говорю здесь, также может быть сделано вручную.
Давайте предположим, что у вас есть план и вы ввели его в компьютерную
систему планирования, такую как MS Project. Каждое утро, когда "ленивый ру-
руководитель проекта" приходит на работу, он запускает свой компьютер и выво-
выводит план на экран. Теперь в плане может быть очень много задач. Для тех уров-
уровней детализации, которые, как мы говорили, надо создать, от четырех до пяти
сотен строк не будет редкостью.
Но вспомните формат нашего плана. Он содержит все основные промежу-
промежуточные этапы, и, кроме того, он сильно детализирован до ближайшего промежу-
промежуточного этапа. Так что, когда мы смотрим на наш экран, а смотрим мы на те за-
задачи, которые сгруппированы вокруг сегодняшнего числа, вероятно, мы будем
видеть не больше пары дюжин строк, что соответствует интервалу, скажем, в не-
неделю в обе стороны от сегодняшнего дня. Когда же мы обратимся к правой час-
части экрана, мы увидим другие задачи, которые являются частью больших проме-
промежуточных этапов в будущем.
Далее "ленивый руководитель проекта" должен сделать две вещи, прежде чем он
в буквальном смысле закончит руководство проектом в течение дня. Эти две вещи:
1) проверить текущее состояние проекта и
2) заглянуть в будущее и попытаться добавить детали для будущих промежу-
промежуточных этапов.
Мы обсудим каждую из них по очереди.
Проверка текучки
Несколько дюжин заданий, сгруппированных вокруг сегодняшнего дня, дают
"ленивому руководителю проекта" список работы на день.

108 Часть 2. Контроль и осуществление плана; достижение иели
Сначала есть завершающиеся задачи. Это задачи, которые, как гласит план,
должны закончиться. Есть такие? Проверьте. Есть выходные результаты, кото-
которые можно пощупать руками? Если да, то задачи выполнены. Если они не вы-
выполнены, то вы модифицируете свой план, чтобы отразить этот факт. Это изме-
изменение вызывает возмущение в остальной части проекта. Мы обсудим это воз-
возмущение более подробно чуть позже.
Затем есть запускаемые задачи. Он должны начать выполняться. И снова, так
ли это? Есть люди, возящиеся с ними, делая в точности то, что указано в плане?
Если так, прекрасно. Если нет, то что они делают? Надо ли модифицировать
план? Или надо по новой привлечь их внимание к этим пунктам?
Наконец, есть задачи, которые находятся в работе. В зависимости от стиля ру-
руководства, который вы принимаете в конкретных ситуациях (см. главу 6), вы мо-
можете захотеть пойти и проверить некоторые из них. С другой стороны, вы можете
с большим удовольствием избавить соответствующих людей от своего визита.
Обратите внимание, что это снова работа "ленивого руководителя проекта".
Все эти пункты могут генерировать дополнительные вспомогательные меро-
мероприятия и операции (встречи, записки, электронная почта, факсы, телефонные
контакты и так далее), которые вам придется делать. Это - ваши задачи руковод-
руководства проектом в течение дня.
Откройте пакеты с сюрпризами
С каждым прошедшим днем вы приобретаете больше информации о проекте.
Почти как следователь, собирающий улики, вы получаете все больше и больше
информации о вещах, которые лежат в будущем и до сих пор были неясными
или прогнозируемыми, или предполагаемыми, а то и просто неизвестными.
Проверив текущее состояние, вы теперь просматриваете материал, который
лежит в будущем, и пытаетесь добавить к нему любые дополнительные детали,
которые сможете обнаружить. Вспомните, что вам надо добиваться уровня дета-
детализации человек-день во всем плане так, чтобы вы могли сказать, что каждый
человек в вашем проекте делает каждый день на протяжении любого заданного
периода времени. Как только вы добавили все доступные подробности, работа
закончена.
Выполнение этих двух только что описанных операций может иметь ряд воз-
возможных последствий для рабочего графика. Это:
¦ изменений нет;
¦ сбой, который можно поправить;
¦ сбой, который невозможно поправить.

Глава 7. Знайте, что происходит 109
Давайте посмотрим на них последовательно. Первое тривиально. Оно означа-
означает, что вы сумели удержать проект в графике еще один день. Большего желать
нельзя. Идите домой - вы сделали сегодняшнюю работу по руководству проектом.
Во втором случае изменения в графике создают сбой. Однако, используя план
как пульт управления, мы можем принять такие меры, как переброска людей,
организация сверхурочной работы, исключение из спецификаций какой-нибудь
сомнительной функциональности или что-то еще в этом роде, чтобы вернуть
проект в график. Обратите внимание, что те же четыре параметра Апокалипсиса:
¦ функциональность,
¦ срок сдачи,
¦ трудозатраты (стоимость),
¦ качество.
показывают нам возможности нашего выбора. Заметьте также, как наша модель,
в которую мы вложили столько труда, снова хорошо служит нам. Наша модель
сообщает нам, что возможно, а что нет. Это удерживает нас от дурацких пред-
предположений типа того, что мы можем всегда поправить любой срыв, просто за-
затратив больше труда - избитое прибежище практиков программирования. Как
сказал Цезарь, "люди обычно охотно верят в то, чего они желают".
Третий вариант состоит в том, что у нас срыв графика и мы не можем попра-
поправить его, как бы ни играли с нашими четырьмя параметрами. Вот теперь у нас
проблема. Это означает, что мы натолкнулись на непредвиденное обстоятельст-
обстоятельство. Единственная вещь, которая может помочь нам теперь, - счастливый случай,
и мы могли бы действительно позволить событиям идти своим чередом в тече-
течение нескольких дней, недели, пары недель, чтобы увидеть, не появится ли он.
Помните, что наша модель - все еще только прогноз, так что когда-нибудь боги
улыбнутся нам и что-то потребует меньше времени и трудозатрат, чем мы ожи-
ожидали. Когда-нибудь! Может быть, мы и получим такой прорыв, который расста-
расставит все по правильным местам.
Однако, если на этой стадии положение не улучшается - учтите, метод, кото-
который я здесь описываю, используется некоторыми людьми, включая меня самого,
для решения проблем с превышением кредита! - вам придется покаяться перед
начальством.
Будет ли это приятно? Почти определенно, нет. Унижение редко бывает при-
приятным. Но вам придется. Альтернатива немыслима. Вы можете попасть в зону
маленького взрыва теперь или термоядерного позже.

110 Часть 2. Контроль и осуществление плана; достижение цели
Продолжим. Идите и сообщите новости вашему начальству и/или заказчику. Ка-
Какая бы из вышеперечисленных ситуаций с графиком ни произошла, после того как
вы сделали все дела, которые мы только что наметили - управление проектом, кон-
контроль и манипуляции с ним, четкое представление текущей ситуации, - ваша работа
на сегодня завершена. Вы можете больше ничего не делать. Вы уже сделали все, что
надо было сделать. Можно идти домой и отдыхать, зная, что все под контролем.
Даже если события пошли вкривь и вкось, вы перехватили проблему на самой ран-
ранней возможной стадии. Вот теперь вы профессиональный руководитель проекта!
ПОЛОЖИТЕЛЬНЫЕ ЗНАКИ
Указанные ниже события - индикаторы, которые должны быть расценены
как положительные тенденции в проекте.
Люди получают удовольствие
Доклад Роланда Хантфорда (Roland Huntford, 1993) о возвращении Амундсе-
Амундсена является увлекательным чтением. Амундсен знает, что он победил, все, что
ему осталось сделать теперь, это вернуться со своей группой в безопасное место
и объявить о своем достижении миру. У него много продовольствия и топлива,
а последние 200 миль сигнальные флаги, которые он выставил во время движе-
движения к полюсу, делают возвращение скорее похожим на спортивный лыжный ма-
марафон. Делая по 20-30 миль в день (в три-четыре раза больше, чем Скотт), его
люди влетели в Фрамхейм, их базу, 26 января 1912 года. Это - хороший при-
признак, если ваш проект доходит до точки, где:
¦ Люди ходят слегка самодовольно.
¦ Их доверие высокое.
¦ Самочувствие великолепно и в значительной степени не зависит от условий
работы в проекте.
¦ Они чувствуют, что худшее осталось позади.
¦ Их вера в собственные способности и способности группы усилилась.
¦ Меньше напряжения и раздражительности.
¦ Стало больше розыгрышей и подшучивания
¦ Людям нравится находиться в окружении команды; короче говоря, они до-
довольны.
¦ Промежуточные этапы выполняются.

Глава 7. Знайте, что происходит 111
Амундсен сформулировал свой план с условием выполнения ежедневных
промежуточных этапов, которые могла понять вся его группа: каждый день они
должны были проходить 20 миль, четверть градуса широты, и останавливаться.
Таким образом, каждые четыре дня они были на градус ближе к полюсу. Кроме
того, как только они делали свои 20 миль, можно было останавливаться. Завер-
Завершение промежуточных этапов и их зачеркивание - хороший признак продвиже-
продвижения, вдобавок это является существенным моральным стимулом, поскольку под-
подразумевает, что оценки, сделанные перед началом проекта, кажется, оказывают-
оказываются правильными.
Независимые отклики
Вы можете получить ранние указания на то, что проект работает, от источника,
независимого от проектной группы. "Независимый" здесь является ключевым
словом. Это иногда называют "дать поковыряться в ранах". В случае проекта по
разработке [программного] продукта это может означать демонстрационную вер-
версию, прототип, раннюю редакцию или частично работающую систему. Был пери-
период в операции "Буря в пустыне", когда широкая публика на Западе получала край-
крайне мало или вообще не получала независимой информации от союзной группи-
группировки, так что в итоге нам было совершенно неясно, как этот проект продвигается.
{Примечание (прежде чем вы обрушите на меня поток возражений!): я сначала
написал черновик этой главы книги, в середине февраля 1991 года. В то время су-
сухопутные операции еще не начались, и было неясно, что в точности происходит.)
Люди оставляют команду в покое
Это по большей части с точки зрения проектной группы. Если проект идет
хорошо, создается впечатление, что уменьшается количество внешних вмеша-
вмешательств, людей, сующих свои носы в проект, совещаний и так далее.
Жизнь после проекта
Снова больше с точки зрения группы: люди затевают разговоры о жизни по-
после завершения проекта. Они так долго были прикованы к этой работе, но теперь
начинают видеть свет в конце туннеля.
Общее видение
Цель стабилизирована; есть полное согласие, и никакого замешательства от-
относительно того, что является окончательной целью.

112 Часть 2. Контроль и осуществление плана; достижение цели
Мало кризисных ситуаций
Кажется, ничего не забыто, очень мало пожарных ситуаций; все спокойно
и эффективно.
ОТРИЦАТЕЛЬНЫЕ ПРИЗНАКИ
Ниже приведены индикаторы, любой из которых должен чрезвычайно насто-
насторожить руководителя проекта.
Промежуточные этапы не выполняются
Вещи не делаются по плану. Оценки, похоже, оказались ненадежными. Про-
Промежуточные этапы, о которых докладывалось как о сделанных, как-то оказались
невыполненными. Один и тот же промежуточный этап перепланируется не-
несколько раз.
"Все под контролем"
Это - отрицательный признак, если кто-то, особенно руководитель проекта,
использует эту фразу!
Плохое настроение
Высокая текучесть кадров или уровень заболеваний. Люди смотрят уныло
или много жалуются. Очевидное отсутствие того, что можно было бы назвать
командным духом. Никто, кажется, не рад ничему. Потеря доверия в группе.
Столкновения индивидуальностей
Они должны особенно настораживать, если происходят в верхних эшелонах
управления проектом.
Никто не радуется
Действительно яркий образец этого признака - возвращение Скотта с полюса,
ужасно читать об этом: его ослабленным и деморализованным людям требуются
колоссальные усилия для перемещения того, что стало теперь легкой поклажей,
на несколько миль. Нервы напряжены, поскольку запасы пищи тают, а склады
трудно найти. Один из группы, Эванс (P.O. Evans), умирает. Оутис (Oates), конюх,
страдает от старой раны ноги, полученной в бурской войне. Он также умирает:
выходит из палатки, и его больше никто не видит. Наконец за 14 миль до склада
продовольствия Скотт и два оставшихся его товарища, застигнутые снежной бу-
бурей, разбивают лагерь. Они больше никогда не двинулись вперед.

Глава 7. Знайте, что происходит 113
Затягивание времени
Вы несколько раз спрашиваете об определенных задачах, и каждый раз находит-
находится оправдание, почему данная задача не была выполнена. Интересный историче-
исторический пример такой ситуации - командование генералом Джорджем Б. Макклелла-
ном (George В. McClellan) Потомакской армией в начальный период Гражданской
войны в США, когда Линкольн постоянно просил его выдвинуться к армии конфе-
конфедератов, а Макклеллан постоянно находил причины не делать этого (за это Макк-
леллан заработал прозвище "Вирджинский Плющ"). См. Cotton A960,1961,1963).
Стойки ворот продолжают сдвигаться
Цель никак не стабилизируется. Каждый раз, когда вы думаете, что иденти-
идентифицировали ее, она как-то изменяется или расширяется. Обратите внимание, что
это может случиться благодаря процессу "расползания элегантности": добавле-
добавление к цели большого количества мелких модификаций. Каждая из них сама по
себе мала и, вероятно, могла бы быть введена без особых трудностей. Однако
сумма всех изменений представляет драматическое изменение цели.
Совершаются ошибки
Кажется, было забыто об очень многих вещах; ошибки становятся более час-
частыми; наблюдается множество небрежностей.
Куча кризисов
Ощущение, что кризисы возникают через день. Панические совещания стали
обычной практикой. "Тушение пожаров" - в порядке вещей.
Нет независимой информации
Все, что у вас есть, - заверения руководителя проекта, что все под контролем.
Нет ничего такого, что вы можете сами увидеть и почувствовать.
Трясина уныния
Чувство, или в группе, или у заказчика, что не видно никакого конца. Хорошим
историческим примером этого является сражение при Пасшендаеле, длившееся
с июня по ноябрь 1917 года во Фландрии (Macdonald, 1978; Terraine, 1977). В на-
народной памяти оно стало классическим сражением Первой мировой войны. Лето
1917 было одно из самых плохих по погодным условиям, и дождь превратил низ-
низменную Фландрию в море грязи, в которой люди буквально тонули.

114 Часть 2. Контроль и осуществление плана; достижение цели
Сражение у Пасшендаеле на деле состояло из ряда небольших боев, и резуль-
результатом с точки зрения пехотинца было то, что время от времени ему приказывали
пересечь взбаламученное болото под губительным огнем пулеметов и артилле-
артиллерии, чтобы штурмовать немецкие окопы, защищенные многочисленными ряда-
рядами колючей проволоки. Те, кто выживал в одном бою, вскоре бросались
в следующий, так что в итоге люди потеряли надежду. Война будет идти всегда.
Они все равно умрут, вопрос только когда - и лучше сделать это раньше, чем
позже, и избежать ужасного страдания, жизни и борьбы в болоте. Если ваш про-
проект доходит до точки, когда людей регулярно просят работать сверхурочно,
приложить еще одно последнее усилие, выходить на работу в выходные, и если
они чувствуют, что никакого реального прогресса не наблюдается, то проект
находится в опасности.
Машина слухов
Нормальная система обмена информацией, существующая в любой организа-
организации, внезапно заменяется машиной слухов, и эта машина, кажется, изрыгает все
более и более дикие слухи день ото дня.
Все идет не так, как ожидалось
При планировании своего проекта вы проходили через процесс наглядного
представления каждого этапа путешествия. В результате вы ожидаете, что все
будет происходить заданным путем, что будут присутствовать некие знаки, ко-
которых вы ждете и рассчитываете увидеть. Если вы не видите их или видите не те
знаки, которых ожидали, это должно стать причиной для беспокойства. Истори-
Исторический пример - сражение при Сомме. Одной из целей артиллерийского обстре-
обстрела (которая была обсуждена в главе 5) был прорыв вражеских проволочных за-
заграждений. Было с уверенностью предсказано, что они будут разбиты при
стрельбе шрапнелью. Однако накануне наступления пехоты разведывательные
отряды сообщили о больших участках неповрежденных проволочных загражде-
заграждений. Эти сообщения были проигнорированы главным штабом, будучи списан-
списанными на нервное напряжение, что и привело к уже описанной нами катастрофе.
"Без сюрпризов"
Выполняйте ваш проект "без сюрпризов". Это означает, что должно сущест-
существовать только одно настоящее преступление: знать о некоторой надвигающейся
проблеме в проекте и не предупредить об этом всех. Это относится к любому
лицу, связанному с проектом: руководителю, члену команды или заказчику.

Глава 7. Знайте, что происходит 115
Ошибки могут быть и будут делаться, и это вполне допустимо, но прятать по
какой бы то ни было причине бомбу замедленного действия означает навлечь на
проект крупные неприятности и подвести других людей, включенных в него.
ИСПОЛЬЗОВАНИЕ В РАЗРАБОТКЕ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Как вы узнаете, что происходит? В большом программном проекте могут
быть сотни людей, работающих дистанционно над компонентами системы. Чис-
Число этих компонентов может доходить до многих тысяч, причем все они должны
состыковываться сложным и безошибочным образом. Как вы определите, на-
насколько хорошо соберется система, насколько она завершена и сколько еще надо
затрат на ее завершение?
Помимо всех описанных нами качественных признаков существует пара ко-
количественных методов, позволяющих вам отслеживать продвижение проекта.
Наиболее очевидный из них, если предположить, что ваш план заложен в ма-
машинную систему планирования проекта, состоит в том, что вы можете отслежи-
отслеживать продвижение, отмечая выполненные задачи, добавляя новые задачи и изме-
изменяя существующие. Преимущество машинных средств в том, что они неумоли-
неумолимы. Если есть сбой, они показывают его вам занудным клиническим образом.
Одновременно они также показывают критический путь - путь восстановления
сбоев, - если восстановление возможно.
Весь план можно представлять с таким количеством деталей, большим или
малым, которое интересно вам в данный момент или требуется для проведения
анализа. Как я уже говорил ранее, тот, кто ведет проект любого вида и размера
без использования одного из этих компьютеризованных средств планирования, -
балбес. Еще более тонкий способ отслеживания движения проекта, особенно
в больших проектах, заключается в концепции освоенной стоимости (earned
value). Вы найдете хорошее описание ее в книге "Software Engineering
Economics" (Boehm, 1981). Кроме того, конкретное машинное средство планиро-
планирования проекта, используемое вами, объяснит, как в нем реализована эта концеп-
концепция и какие отчеты и аналитические функции, базирующиеся на освоенной
стоимости, доступны пользователю.
В основном освоенная стоимость позволяет определять, пропорциональны ли
затраты, понесенные в проекте до настоящего времени, его текущему уровню
завершения. Другими словами, система сообщает, если вы тратите больше, чем
планировали потратить на данную работу, которая была закончена на данный
момент. Это также дает возможность предсказать, сколько будет стоить проект

116 Часть 2. Контроль и осуществление плана; достижение цели
(или любая задача в пределах него) при завершении, если текущая тенденция
сохранится. Помните, однако, что концепция освоенной стоимости - не панацея.
Многие другие вещи, помимо освоенной стоимости, полезны, эффективны
и дают вам прекрасный шанс держать руку на пульсе проекта. Однако, если ба-
базовые, простые вещи, которые мы описываем в остальной части этой книги, не
выполняются, все освоенные стоимости или причудливые системы финансовой
отчетности в мире не спасут вас.
ВКЛАД В PSI
Этап 7 дает до 10 баллов в PSI. Если вы делаете то, что было сказано, и дер-
держите руку на пульсе проекта, то вы получаете здесь высокий балл. В противном
случае, если изо дня в день вы не соприкасаетесь с тем, что происходит [в про-
проекте], балл будет низким.
СТРУКТУРНОЕ УПРАВЛЕНИЕ ПРОЕКТОМ
Планирование проекта
1. НАГЛЯДНО ПРЕДСТАВЬТЕ СЕБЕ ЦЕЛЬ; НАЦЕЛЬТЕСЬ НА ПРИЗ.
2. СДЕЛАЙТЕ СПИСОК ЗАДАЧ, ПОДЛЕЖАЩИХ ВЫПОЛНЕНИЮ.
3. ДОЛЖЕН БЫТЬ ОДИН РУКОВОДИТЕЛЬ.
4. РАСПРЕДЕЛЕНИЕ ЗАДАЧ ПО ЛЮДЯМ.
5. УПРАВЛЕНИЕ ОЖИДАНИЯМИ, ЗАДАНИЕ ДОПУСКА НА ОШИБКИ,
ОБЕСПЕЧЕНИЕ ЗАПАСНОЙ ПОЗИЦИИ.
Реализация плана; достижение цели
6. ИСПОЛЬЗУЙТЕ ПОДХОДЯЩИЙ СТИЛЬ РУКОВОДСТВА.
7. ЗНАЙТЕ, ЧТО ПРОИСХОДИТ.

ГЛАВА 8
Этап 8: СООБЩАЙТЕ ЛЮДЯМ, ЧТО ПРОИСХОДИТ
ВВЕДЕНИЕ
В этой главе мы поговорим об отчетах о состоянии работ, и я покажу вам, как
"ленивый руководитель проекта" проводит свою неделю.
Нам говорят, что знание рассеивает страхи. Амундсен и Скотт показали два
противоположных примера того, как работать с распространением информации
внутри проекта. Амундсен объяснил цель и свой план ее достижения. План объ-
объяснялся, обсуждался и вывешивался в кают-компании для ознакомления с ним
каждого. Как мы видели, этот план позволял людям наглядно видеть прогресс
и устанавливать конечный предел ежедневного объема работ.
План Скотта, напротив, оставался неясным, даже когда он уже существенно
продвинулся в направлении полюса. Какой бы план в конце концов ни был раз-
разработан, он не делился им ни с кем до того самого момента, пока людям не
пришлось его узнать. В самый последний момент Скотт изменил один из крае-
краеугольных камней плана: число людей, которые должны были идти с ним к по-
полюсу. Даже его резервный план, такой, какой он был, пришлось поспешно со-
состыковывать с основным, и в результате, когда Скотт столкнулся с серьезными
трудностями, все надежды на спасение были разрушены плохо разработанными
и беспорядочными планами, которые он давал своим подчиненным.
Я утверждаю здесь, что люди - это мыслящие создания. Каждый может вне-
внести свой вклад, у каждого есть элементы творческого потенциала, и каждый
ощущает себя более ценным, если все знают то, что происходит. Люди будут
работать лучше всего, если они знают, какова большая картина в целом и какое
место их вклады, как бы тривиальны они ни были, занимают в общей картине.
Считается, что это особенно верно на фронте, когда вы просите людей пожерт-
пожертвовать для вас очень многим и даже жизнью.
Так что этап 8 называется "Сообщайте людям, что происходит". Сказав это,
я теперь попытаюсь возразить данному утверждению. Существует концепция
руководителя, действующего как фильтр. Представьте себе это, как крепость
с командой проекта внутри и руководителем, выступающим в роли часового
у ворот. Внешний мир находится в постоянном процессе изменения. В течение
жизни проекта некоторые из этих изменений будут оказывать влияние на проект
и на команду. Руководитель должен решить, какую часть этих изменений про-
пропустить к команде.

Т18 Часть 2. Контроль и осуществление плана; достижение цели
Некоторые изменения нужно пропустить. Часть из них носит здоровый ха-
характер и, как я уже сказал, самооценка команды будет выше, если она будет
знать, что с ними обращаются как с умными людьми. Однако бывают измене-
изменения, которые могут или обязательно приведут к крупным проблемам в продви-
продвижении проекта, если команда их заметит. Эти изменения вы должны либо:
¦ блокировать,
¦ либо, если вы не в состоянии это сделать, подвергнуть цензуре так, чтобы их
угроза уменьшилась,
¦ либо, если и это не получается, передать группе таким способом, чтобы ми-
минимизировать их воздействие.
причем вы должны сделать все это, не скрывая от них истинные факты. Трудная
задача? Будьте уверенны! Все вышесказанное одинаково справедливо и для вы-
выходящей информации. В проекте будут подъемы и спады, и внешний мир дол-
должен быть информирован о его продвижении. Однако в проекте могут происхо-
происходить вещи, для которых вы обязательно должны:
¦ остановить движение информации наружу,
¦ или, если это нельзя сделать, разбавить ее так, чтобы, когда информация
выйдет наружу, ее истинный эффект был ослаблен,
¦ или, если и это невозможно, передайте информацию таким образом, чтобы
минимизировать эффект ее воздействия на внешний мир.
и все это без того, чтобы скрывать истинные факты. Это все очень сложная за-
задача. Данная книга пытается снабдить вас пригоршней методов и идей, которые
можно применять именно в таких обстоятельствах. В главе 15 есть целая куча
идей, которые Вы можете использовать. В любой конкретной ситуации вы мо-
можете применить не одну из них с различными результатами. Вашей задачей бу-
будет выбрать ту, которая наилучшим образом подходит вам и ситуации.
Можно провести аналогию с плотницким ящиком для инструментов. В нем
много всего: молоток, ручка отвертки, широкая сторона угольника - что может
забить гвоздь в кусок дерева, однако некоторые из инструментов для этого под-
подходят лучше, чем другие. Так же обстоит дело со средствами, предлагаемыми
в этой книге. Некоторые из них позволяют достичь результата. Но только вы
можете судить, какой результат является лучшим для вас.

Глава 8. Сообшайте людям, что происходит 119
ОТЧЕТЫ О СОСТОЯНИИ РАБОТ
Забавно, но, кажется, есть вещи, одинаковые во множестве различных куль-
культур, и одна из них, как я открыл, это то, что в школе многие люди писали сочи-
сочинение с заголовком "Мой день у моря".
Возможно, вы тоже писали его, и если так, то, вероятно, помните, как это бы-
было. Вся человеческая жизнь была там: погода, люди, события, эмоциональные
взлеты и падения, взаимодействие характеров - и в конце всего этого мы добре-
добредали до постели с песком между пальцев ног, сильно обгоревшие, намазанные
кремом от солнечных ожогов, утомленные, но счастливые после огромного дня.
Я вспомнил об этом, потому что большинство отчетов о состоянии работ, ка-
кажется, имеют поразительное сходство с сочинениями на тему дня у моря. Они
могли бы называться "Вот все ужасно интересные вещи, которые случились
в проекте на прошлой неделе". По мере прочтения мы взволнованно выясняем
все мелочи, которые произошли в проекте, причем неизменно в отчете есть сча-
счастливый конец - почти так же, как в нашем сочинении - приподнятое заключе-
заключение, которое говорит, что все хорошо, весь мир в порядке.
Но двигается ли проект к цели? Эй, я не знаю. И вы, конечно, не найдете
в чтении о дне у моря отчет о состоянии работ. Если вы хотите остаться с посто-
постоянным теплым чувством, день у моря - это для вас. Но если вы хотите получить
некую полезную информацию, надо искать в другом месте.
Отчет о состоянии работ, который я предлагаю, создается сверху вниз, от са-
самого верхнего уровня до максимально детального рассмотрения. Он говорит
в однозначных терминах, каково состояние проекта; и вы, возможно, поймете,
почему люди могут не захотеть писать такие отчеты - они совершенно неумо-
неумолимы и клиничны в рамках того, что они отображают.
Вот структура, которой вы могли бы придерживаться при написании отчета
о состоянии работ.
Уровень I
Проект в графике? Да или нет? В вашем шаблоне отчета о состоянии работ
может быть два поля, в одном из которых вы ставите галочку. Если проект идет
по графику, люди могут и не захотеть знать больше.
Уровень II
На этом уровне вы представляете некоторую информацию верхнего уровня
по состоянию наших четыре;; параметров: функциональность, дата поставки,
трудозатраты и качество.

120 Часть 2. Контроль и осуществление плана; достижение пели
Функциональность
Пара предложений, относящихся к верхнему уровню:
¦ с чего началась функциональность,
¦ любые главные изменения, которые произошли,
и ссылки на журнал регистрации изменений (см. главу 1), где можно найти дета-
детали изменений и их историю.
Дата поставки
Здесь - какая она была первоначально mm/dd/yy (мес/день/год)
Здесь - какая она теперь mm/dd/yy
Здесь - насколько изменилась пппп (дней)
№ Изменения
1
2
п
Дата
mm/dd/yy
mm/dd/yy
...
mm/dd/yy
Причина для изменения
ххххххххххххххххх
ххххххххххххххххх
ххххххххххххххххх
Новая дата поставки
mm/dd/yy
mm/dd/yy
...
mm/dd/yy
Трудозатраты
Здесь то, что было первоначально пппп человеко-дней
Здесь то, что теперь пппп человеко-дней
Здесь разница пппп
№ Изменения
1
2
п
Дата
mm/dd/yy
mm/dd/yy
...
mm/dd/yy
Причина для изменения
ххххххххххххххххх
ххххххххххххххххх
ххххххххххххххххх
Новый объем работ
(в человеко-днях)
пппп
пппп
...
пппп
Качество
Если вы измеряете качество чем-то типа средней наработки на отказ (MTTD),
можно приводить данные об этом параметре аналогично данным по дате постав-
поставки или трудозатратам, как показано выше. Если это вам интересно, хорошее об-
обсуждение параметра MTTD можно найти в Puttnam и Myers A992).
Наконец, на втором уровне вы должны дать некоторое общее заключение
о состоянии здоровья проекта. Даже если он в графике, могут вырисовываться
некоторые неприятности. Здесь вы можете сказать в нескольких предложениях,
какие крупные вопросы, известные риски и проблемы находятся вне вашего
контроля и что вы делаете/хотели бы сделать с ними.

Глава 8. Сообщайте людям, что происходит 121
Уровень III
На третьем уровне, если вы слегка ощущаете себя несостоявшимся писате-
писателем, поскольку в свое время не смогли описать день у моря, у вас есть шанс от-
отвести душу. Если хотите, можете записать вещи, которые происходят в настоя-
настоящее время. Это соответствовало бы "текучке", о которой мы говорили в главе 7.
Сделать это можно на персональной основе, так что каждый получит что-то,
сказанное о нем, и почувствует, что его любят и что он нужен.
Уровень IV
Наконец, на этом уровне вы можете вывалить все и даже мусорное ведро.
Сюда можно включить копию текущего плана - диаграмму Гантта, - показы-
показывающую все подробности в мире.
И последний вопрос: кому мы вручаем этот великий опус? Ну, в духе того,
что мы сказали во введении к этой главе, мне кажется, что мы должны вручить
его как можно большему числу людей. Ясно, что могут быть вещи, которые мы
не хотим показывать команде или начальству, или заказчику, но нам ничто не
мешает сделать своего рода "основной" отчет для общего потребления с не-
небольшим приложением, в котором указаны вещи, которые мы хотим сообщить
определенной аудитории.
Давая этот отчет команде, мы даем каждому человеку возможность видеть
полную картину и то, как его часть вписывается в нее. Другие люди могут заме-
заметить вещи, на которые мы не обратили внимание. Чем больше проблем будет
обнаружено сейчас, тем меньше их у нас будет потом.
Аналогично, давая отчет о состоянии работ начальству и заказчикам, мы из-
избегаем проекта, становящегося черной дырой, в которую вливают деньги, а ко-
когда-нибудь, может, что-то и получится. Мы не только делаем хорошую работу,
все видят, что мы делаем хорошую работу.
Как пример того, что я здесь подразумеваю (и это - по большей части иллюст-
иллюстрация, а не правило), в проекте, который я делал для клиента, я подготовил две
версии отчета о состоянии работ. Один распространялся в группе и был послан
моему начальнику, то есть моему клиенту. Другой был предназначен для клиента
моего клиента, то есть для моего заказчика. Было два различия между версиями:
1. Все ссылки на информацию о том, кто над чем работает, из версии заказчика
были удалены, так как учитывалось, что это дело моего клиента, а не заказчика.
2. Любые мрачные или зловещие сообщения были убраны из уровней II и III
версии заказчика. Это, однако, было потому, что проект в целом шел хорошо.
Будь это иначе, мы передали бы эти сообщения заказчику. Если бы нам при-

122 Часть 2. Контроль и осуществление плана; достижение иели
шлось сделать это, то помимо всего прочего, мы бы готовили заказчика
к плохим новостям. И делая это, мы бы следовали принципу "без сюрпризов",
который обсуждался в этапе 7. Если бы нам все же пришлось сообщить за-
заказчику плохие новости, то он бы видел, что профессиональное руководство
проектом обеспечивалось всегда и в любой ситуации.
НЕДЕЛЯ "ЛЕНИВОГО РУКОВОДИТЕЛЯ ПРОЕКТА"
Неделя "ленивого руководителя проекта" проходит следующим образом.
Понедельник
Понедельник, или первый послепраздничный день, - длинный день для "ле-
"ленивого руководителя проекта". В понедельник ему надо сделать три вещи.
Установить цели
Первая состоит в установке целей на данную неделю. Делайте это как можно
раньше в первый день новой недели. Это не только дает группе максимум воз-
возможного времени, чтобы достигнуть заданных целей, но также морально воз-
возвращает людей к труду, то есть возвращает их головы из выходного. (Мы пред-
предполагаем, что тела уже вернулись!)
Используйте ваш план, ваш пульт управления, чтобы сделать это. Работайте
в персональных встречах тет-а-тет, или на встрече группы, или комбинируя эти
два подхода, как удобнее. Каждый из этих подходов имеет преимущества и не-
недостатки. Тет-а-тет означает, что каждый тратит наименьшее количество време-
времени с вами; но совещания синергичны - вы охватываете те аспекты, в которых
существуют зависимости между людьми. Используйте ваш здравый смысл. За-
Затем пусть каждый с полученным возвращается к работе.
Текучка
Как мы говорили в предыдущей главе, понедельник ничем не отличается от
любого другого дня, так что вам придется выполнять ежедневные задачи "лени-
"ленивого руководителя проекта".
Любые другие дела
Многие организации имеют свои собственные плановые мероприятия, кото-
которые приходятся на понедельник: заполнение табелей рабочего времени, регу-
регулярные совещания по различным темам, стандартные административные проце-
процедуры, которые нужно выполнять. Это составляет третий элемент рабочего дня
"ленивого руководителя проекта" в понедельник.

Глава 8. Сообщайте людям, что происходит 123
Вторник-четверг
Эти три дня весьма спокойны для "ленивого руководителя проекта". Все, что
ему надо сделать, - это текучка (см. раздел "День Ленивого Руководителя про-
проекта" в главе 7), а затем с работой покончено.
Пятница
Пятница более насыщена, чем предшествующие три дня, но не столь нагруже-
нагружена, как понедельник. Сначала есть текучка, которую надо сделать, как и прежде.
Затем, как можно позже, т. е. как можно ближе к концу делового дня, прой-
пройдитесь по группе, посмотрите, что произошло, и напишите отчет о состоянии
работ. Эти результаты должны также быть занесены в столбцы "Actual Schedule"
("Рабочий график") и "Effort" ("Трудозатраты") диаграммы Гантта проекта или
в карту контроля оценок ESC (см. приложение 5). Здесь мы регистрируем, были
ли достигнуты установленные в понедельник цели или нет. Те, кто не достиг
своих заданных целей, имеют возможность сделать это за два выходных дня.
Отметим здесь пару обстоятельств. Первое - хирургически точное использова-
использование сверхурочного времени. Многие программистские организации делают неог-
неограниченное сверхурочное время чуть ли не основной характеристикой работы.
Если на собеседовании о вашем приеме на работу говорится примерно следую-
следующее: "Мы упорно трудимся, у нас не прохлаждаются" или "у нас очень интенсив-
интенсивные графики работ", можете безошибочно предположить, что они ожидают, что
жизни вне работы для вас не будет. У "ленивого руководителя проекта" нет вре-
времени на такие глупости, однако равным образом он признает, что в реальном мире
сверхурочная работа иногда необходима. Использование сверхурочного времени
компаниями "упорного труда", "жестких рабочих графиков" производится с лов-
ловкостью рабочего с циркулярной пилой. "Ленивый руководитель проекта" исполь-
использует сверхурочное время подобно хирургу со скальпелем, который делает тонкий
надрез для получения потрясающих результатов.
Другая вещь, которую надо отметить, состоит в том, что использование
сверхурочного времени фактически добавляет в наш проект учтенные непредви-
непредвиденные обстоятельства. Таким образом, учет непредвиденных обстоятельств -
это не только то, что вы однажды закладываете в проект, но и небольшой резер-
резервуар, который Вы можете доливать неоднократно. Это можно себе представить
как в старой арифметической задачке, где резервуар имеет отверстие, через ко-
которое вода выливается, а также трубу, через которую вода доливается. Если вы
сможете постоянно сохранять некоторый запас воды в резервуаре, то никогда не
выйдете за пределы заложенных непредвиденных обстоятельств и вам никогда
не придется обращаться к начальству для пересмотра обязательств.

124 Часть 2. Контроль и осуществление плана; достижение иели
РАЗНОВИДНОСТЬ НЕДЕЛИ "ЛЕНИВОГО
РУКОВОДИТЕЛЯ ПРОЕКТА"
Ди Карри (Dee Carri), мой друг, изобрела следующий вариант недели "лени-
"ленивого руководителя проекта".
Понедельник
Делая все в понедельник, почему бы, помимо прочего, не писать отчет о со-
состоянии работ также в понедельник? Мне это рассказала Ди. Она пишет отчет
и пришпиливает его на стену. Как она говорит: "Это - то, что я хочу услышать
в пятницу, а после того, как я написала отчет, я не люблю его изменять. Можешь
быть уверен, я скорее переверну небо и землю, чем вернусь к этому отчету, что-
чтобы его переписывать".
Вторник-пятница
Если вы пишете отчет в понедельник, в остальные четыре дня остается толь-
только придерживаться программы обычного дня "ленивого руководителя проекта".
Некоторые люди любят ставить цели и оглашать отчет о состоянии работ на
одном совещании, но я не думаю, что это хорошая идея. Это приводит к размы-
размыванию различия между целью и достижением. Люди говорят что-то вроде:
"У меня это еще не доделано, но не беспокойтесь, все будет готово через не-
несколько часов". Обратите внимание, что в этой ситуации у вас уже срыв [графи-
[графика]. Разделение этих двух вещей исключает сомнение, туманность или смущение
в вопросе о том, что было и что не было достигнуто.
ИСПОЛЬЗОВАНИЕ В РАЗРАБОТКЕ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Добавить нечего, просто делайте это!
ВКЛАД В PSI
Максимальный вклад в PSI для этапа 8-10 баллов. Вознаградите себя высо-
высокой оценкой, если вы позволяете всем заинтересованным лицам знать, что про-
происходит в проекте. Поместите ваш проект в стеклянную витрину - и балл высок.
Спрячьте его у себя на груди - и балл низок: помните, что случилось с капита-
капитаном Скоттом!

Глава 8. Сообщайте людям, что происходит 125
СТРУКТУРНОЕ УПРАВЛЕНИЕ ПРОЕКТОМ
Планирование проекта
1. НАГЛЯДНО ПРЕДСТАВЬТЕ СЕБЕ ЦЕЛЬ; НАЦЕЛЬТЕСЬ НА ПРИЗ.
2. СДЕЛАЙТЕ СПИСОК ЗАДАЧ, ПОДЛЕЖАЩИХ ВЫПОЛНЕНИЮ.
3. ДОЛЖЕН БЫТЬ ОДИН РУКОВОДИТЕЛЬ.
4. РАСПРЕДЕЛЕНИЕ ЗАДАЧ ПО ЛЮДЯМ.
5. УПРАВЛЕНИЕ ОЖИДАНИЯМИ, ЗАДАНИЕ ДОПУСКА НА ОШИБКИ,
ОБЕСПЕЧЕНИЕ ЗАПАСНОЙ ПОЗИЦИИ.
Реализация плана; достижение цели
6. ИСПОЛЬЗУЙТЕ ПОДХОДЯЩИЙ СТИЛЬ РУКОВОДСТВА.
7. ЗНАЙТЕ, ЧТО ПРОИСХОДИТ.
8. СООБЩАЙТЕ ЛЮДЯМ, ЧТО ПРОИСХОДИТ.

ГЛАВА 9
Этап 9: ПОВТОРЯЙТЕ ЭТАПЫ 1-8
ДО НАСТУПЛЕНИЯ ЭТАПА 10
ВВЕДЕНИЕ
Ваша работа как руководителя проекта включает повторение первых восьми
этапов структурного руководства проектом до тех пор, пока он не будет завершен.
Как часто вы делаете это? Каждый месяц? Каждый день? Каждый час? В главе 12
я буду говорить о том, как распределить ваше время по нескольким проектам, од-
однако основной ответ здесь — да! Каждый месяц, каждый день, каждый час - так
часто, как требуется, чтобы работа была сделана. Это означает, что:
¦ Каждый постоянно сосредоточен на цели. Члены группы слышали вашу меч-
мечту, ваше представление цели так часто, что любой из них мог бы повторить
вашу речь во всех подробностях!
¦ Вы используете список задач, план как компас, указывающий направление
к каждому новому горизонту. Это означает, что вы постоянно просматривае-
просматриваете план, добавляете новые задачи, когда возникает что-то непредвиденное,
изменяете характер задач, по мере того как более подробная информация
о них становится доступной, вычеркиваете задачи (или ставите против них
галочку), как только они завершаются, исключаете работы, если находите,
что они теперь не нужны, и перемещаете людей туда, где они наиболее эф-
эффективны. И всегда вы используете стиль [руководства], наиболее соответст-
соответствующий ситуации.
¦ Вы обеспечиваете единоличное руководство проектом.
¦ Вы постоянно помните об определенных вами ожидаемых результатах и рас-
рассматриваете запасные позиции. У каждой задачи есть связанные с ней ожи-
ожидания и запасная позиция, и в ряде задач можно будет отступить назад, не за-
затронув весь проект в целом.
¦ Вы в авангарде, высматривая опасности на горизонте, спрашивая себя, что
может идти не так. Вы знаете, как продвигается команда за вами, и сообщаете
им о новых опасностях, препятствиях, вызовах впереди.

Глава 9. Повторяйте этапы 1-8 до наступления этапа 10 \Т7
КОГДА МЫ ДОЛЖНЫ МОДИФИЦИРОВАТЬ ПЛАН?
Вот вопрос, который задавался почти в каждой мастерской руководства про-
проектом, где я руководил, и мне кажется, что это результат ряда различных про-
проблем, смешиваемых вместе и плохо понимаемых.
Есть три различных ответа на вопрос, в зависимости от того, что имел в виду
спрашивающий.
Постоянно
Как мы уже видели, план постоянно модифицируется по ежедневному графи-
графику "ленивого руководителя проекта".
Еженедельно
В настоящее время я бы никогда не взялся за выполнение проекта без приме-
применения машинных средств планирования. Возможно, вы знаете, что при исполь-
использовании одного из этих средств план (диаграмма Гантта) сохраняется в файле;
и, например, в пакете MS Project этот файл имеет расширение .МРР. Именно
в этот файл я постоянно вношу изменения, как было описано выше.
Вообще Говоря, полезно сохранять копии предыдущих версий плана, чтобы
иметь возможность оглядываться назад и видеть, как разворачивались события.
Я делаю это еженедельно. При этом я руководствуюсь следующим правилом:
последнее, что я делаю в пятницу, это копирование текущего плана (текущего
МРР-файла) в новый файл. Этот файл становится тем планом, который я исполь-
использую на следующей неделе.
Я переименовываю файлы, используя понедельник соответствующей недели.
Таким образом, ХХ042301.МРР является файлом, действующим в течение неде-
недели с понедельника 23 апреля1 ('XX' - код проекта), а в пятницу этой же недели
я создам новый файл ХХ043001.МРР, с которым буду работать на следующей
неделе, с понедельника 30 апреля.
Только при наличии срыва графика
В начале проекта мы пишем план и согласовываем его со всеми вместе и
с каждым по отдельности, каждый получает копию, и план становится нашим
контрактом с начальством. Этот документ никогда не должен изменяться, за ис-
1 Как читатель, вероятно, знает, в ряде западных стран принят формат даты "месяц-день-год". -
Прим. переводчика.

128 Часть 2. Контроль и осуществление плана; достижение цели
ключением случаев, когда происходит срыв графика, который нельзя ликвиди-
ликвидировать (см. главу 7).
Если таких срывов нет вообще, то данный конкретный документ никогда не
модифицируется. Отчеты о состоянии работ благодаря их рассылке держат каж-
каждое заинтересованное лицо в курсе событий проекта, сообщают им о том, как мы
прогрессируем по отношению к исходному документу.
Если есть неликвидируемый срыв графика, это означает, что мы находимся
в позиции, где мы должны заново обсудить наш контракт. Тогда вырабатывается
новая версия документа плана, скажем версия 2.0, и она становится новым дого-
договорным основанием проекта.
ИСПОЛЬЗОВАНИЕ В РАЗРАБОТКЕ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Программные проекты имеют известную репутацию за свою тенденцию вы-
выходить из-под контроля. Мы упомянули в главе 1 проект по созданию штурмо-
штурмовика А-12 для ВВС США. (Между прочим, пока писалось первое издание этой
книги, проект А-12 был закрыт!) Одним из элементов, упоминаемых в связи
с превышением сметы расходов проекта А-12, было программное обеспечение;
и по мере того как программное обеспечение вторгается во все большее число
областей нашей жизни и мы используем компьютерные программы для выпол-
выполнения все более и более сложных (не говоря уже об угрожающих жизни!) задач,
мы все чаще обнаруживаем, что программные проекты терпят крах.
Это не столь уж удивительно. Разработка программного обеспечения как ин-
инженерная дисциплина существует менее 50 лет. Если сравнить ее с чем-то типа
строительства зданий, которое существует уже несколько тысяч лет, то, кажется,
следует ожидать, что разработка ПО должна все еще иметь статус строительства
коттеджей, почти кустарного ремесла. Это одна из немногих оставшихся трудо-
затратных отраслей промышленности, и, при всех благих намерениях и целях,
каждый элемент программного продукта все еще производится вручную. (Даже
препроцессоры или генераторы программного кода требуют ручной работы!)
Нельзя сказать, что не прилагалось никаких усилий для продвижения этой дис-
дисциплины. Куча методов появилась в 1970-х и 1980-х, и в результате было реше-
решено, что разработка ПО наконец достигла состояния инженерной дисциплины.

Глава 9. Повторяйте этапы 1-8 до наступления этапа 10 129
Отсюда термин "software engineering. Обратите внимание, что в этом процессе
развития множество фразеологических оборотов из других дисциплин, напри-
например, "sub-assemblies" ("подсистемы") (из производства), "architecture" f'apxu-
тектура"), "build" ("построение") (из строительной промышленности), перешли
в словарь по разработке программного обеспечения.
Мы говорили в главе 2 о создании списка задач для перемещения к следую-
следующему горизонту (промежуточному этапу). Развитие программирования уже оп-
определило основные горизонты для вас. Есть концепция цикла жизни разработки
продукта (product development life cycle - PDLC), и горизонты соответствуют
фазам в PDLC. Любой, кто когда-либо работал над программным проектом, зна-
знаком с PDLC. В больших организациях PDLC - вещь в себе, и для ее поддержки
существуют целые отделы. В рамках этой главы мы будем считать, что цикл
жизни разработки ПО состоит из шести стадий. Эти шесть стадий таковы:
1. Стадия планирования и выработки требований.
2. Разработка верхнего уровня. Она включает начальную разработку пользова-
пользовательской документации и планирование тестов.
3. Разработка нижнего уровня.
4. Стадия реализации. Она включает написание программных кодов, тестирова-
тестирование модулей, сборку, тестирование собранного продукта, а также завершение
планирования тестов и пользовательской документации.
5. Альфа-тестирование - тестирование системы, предпочтительно независимой
группой с использованием плана тестирования.
6. Бета-тестирование - тестирование в реальных условиях, проводимое ото-
отобранной группой конечных пользователей системы.
Примечание: не беспокойтесь, если ваш цикл жизни разработки ПО неточно со-
соответствует тому, который мы используем здесь. Как только вы увидите то, что
мы делаем, вы поймете, что это легко применить к любому стандарту цикла
жизни, который используется вашей организацией. Остальная часть этой главы
показывает структурное руководство проектом для работы над проектом в це-
целом и для каждой из стадий.
Правильно это надо переводить как прикладное программирование или инженерное програм-
программирование. Однако, учитывая природную российскую нелюбовь к прикладным вещам, этот
термин не очень прижился у нас. -Прим. переводчика.
5 - 2224

130 Часть 2. Контроль и осушествление плана; достижение цели
Планирование и выработка требований
Наглядное представление цели; нацельтесь на приз
Первым шагом во всех программных проектах является (или должна яв-
являться) формулировка требований к системе, называемых в наших PDLC тех-
техническими требованиями - ТТ (RS - requirement specification1). TT - требова-
требования, которым должна удовлетворять подлежащая разработке программная сис-
система. Поэтому она описывает:
¦ что система будет делать,
¦ как она взаимодействует с внешней средой,
¦ уровни производительности, ожидаемые от нее.
Должным образом оформленные письменно ТТ представляют собой форму-
формулировку приза. Есть различные пути, которыми вы можете записать ТТ.
¦ На базовом уровне три вышеперечисленных элемента составляют перечень
контрольных вопросов для ТТ.
¦ В литературе существует множество перечней контрольных вопросов, так же
как и все возрастающее количество методологий для определения, докумен-
документирования и отслеживания технических требований. Все эти хитрые средства
имеют право на жизнь и могут оказаться полезными, особенно в работе с об-
обширным объемом информации, получаемой в процессе разработки системы.
¦ Моя компания, ЕТР, предлагает службу консультирования, названную AAD
(accelerated analysis and design - ускоренный анализ и проектирование), которая
обычно представляет собой 5-10-дневный сеанс мозгового штурма, в котором
могут быть разработаны все технические требования и часть проекта системы,
при условии что задействованы все лица, принимающие решения в проекте.
Также, независимо от перечня контрольных вопросов или средств, которые
вы можете использовать, все еще обязательно пройти этап наглядного представ-
представления цели, описанный в главе 1.
Сделайте список задач, которые должны быть выполнены
Рассмотрение ТТ как первого ориентира (горизонта) позволяет нам очень бы-
быстро идентифицировать задачи, которые необходимо выполнить, чтобы добрать-
добраться до него. Это совершенно простой список и, вероятно, представляет собой не-
нечто вроде:
Так в оригинале: RS - requirement specification. - Прим. переводчика.

Глава 9. Повторяйте этапы 1-8 до наступления этапа 10 131
¦ изложить ТТ в письменном виде,
¦ один или более уровней (внутреннего/внешнего) анализа,
¦ один или более уровней модификации,
¦ подписание (утверждение документа).
Наглядное представление приза позволяет нам до некоторой степени видеть
дальше первого горизонта и формировать наш список задач. Мы знаем, каковы
следующие большие горизонты, потому что наша PDLC дает их нам. Также впол-
вполне очевидны последние несколько задач, которые надо будет сделать (запись про-
программного обеспечения на диск, отправка его, установка у пользователя и т. д.).
Кусок в середине проекта будет бессмысленным расточительством почти поляр-
полярных масштабов, и все, что можно сделать на этой стадии, так это сделать его
[приблизительную] оценку. Оценивание подробно обсуждается в главе 14.
Должен быть один руководитель
Здесь нечего добавить сверх того, что уже сказано в главе 3.
Проектирование верхнего уровня
Мы достигли первого горизонта: ТТ написаны и, что более важно, мы можем
изобразить цель с отчетливо прописанными деталями. Однако наш непосредст-
непосредственный интерес теперь сосредотачивается на выполнении разработки верхнего
уровня (РВУ1). Если ТТ описывают, что система будет делать, как она выглядит
снаружи, РВУ описывает, на что похожи системные внутренности - сердце, лег-
легкие, печень и так далее.
Наглядное представление цели; нацельтесь на приз
РВУ может быть изображена как блок-схема, показывающая главные компо-
компоненты вашей системы. В конечном итоге эта блок-схема будет разбита на мно-
множество более мелких, вплоть до уровня программы или модуля, но в данный
момент она содержит только большие блоки.
Сделайте список задач, которые должны быть выполнены
Цикл, подобный тому, что выполнялся для ТТ, то есть: запись, анализ, пере-
переделка, утверждение - вероятно, это все, что здесь потребуется.
Разработка нижнего уровня
Второй горизонт достигнут. Мы должны теперь разложить РВУ до такого
уровня детализации, чтобы можно было писать программный код системы.
1 В оригинале HLD - High Level Design. - Прим. переводчика.

132 Часть 2. Контроль и осуществление плана; достижение цели
Наглядное представление цели; нацельтесь на приз
В нашей PDLC мы сделали разработку в два уровня, РВУ и РНУ1 (разработка
нижнего уровня). Вне зависимости от того, сколько уровней вы используете,
чтобы добраться сюда, и как их называете, вы должны закончить с полной кар-
картиной вашей системы. Эта картина представляет собой блок-схему, показываю-
показывающую все компоненты системы, которые необходимо создать, вплоть до мельчай-
мельчайших. Для больших систем блок-схема может занимать множество страниц и иметь
свою собственную внутреннюю иерархию. Она теперь и становится призом.
Сделайте список задач, которые должны быть выполнены
Знакомый цикл записи, анализа, переделки, утверждения - то, что вам нужно.
Я пытаюсь сделать правилом никогда не брать обязательств по поставке заказ-
заказчику, пока не закончено РНУ. Большинство заказчиков вполне удовлетворяются
этим, а если они настаивают на выдаче абсолютно гарантированной, отлитой в
бетоне стоимости до этого момента, вы популярно объясняете им, что в этом
случае им придется платить сильно завышенную цену, поскольку вам придется
заложить в нее свой риск (мы будем обсуждать эту проблему снова в приложе-
приложении 1, в разделе "Учет непредвиденных обстоятельств"). Ваш список задач бу-
будет живым существом, постоянно изменяющимся для адаптации к обстоятельст-
обстоятельствам. Будут появляться новые задачи, задачи будут завершаться, обнаружатся
ненужные задачи и задачи, завершающиеся иначе, чем это предполагалось пер-
первоначально. (Это является еще одной причиной, почему очень полезна компью-
компьютеризированная система планирования проектов.) Все эти изменения - нормаль-
нормальное рутинное дело. Ваш список будет сильно детализирован для ближнего гори-
горизонта и в меньшей мере для более дальнего.
Сообщайте людям, что происходит
Единственный новый пункт, который надо сделать здесь: если в течение про-
процесса разработки появляется что-то значительно изменяющее ожидания, то это
необходимо обнародовать. Приятные сюрпризы можно продолжать хранить
в тайне до того момента, который вы сочтете лучшим для вас и ваших целей.
Плохие, к сожалению, должны быть обнародованы так, чтобы внешний мир мог
адаптироваться к новой ситуации.
Реализация
Разработка закончена, так что мы переходим к написанию программных ко-
кодов и тестированию.
В оригинале LLD - Low Level Design. - Прим. переводчика.

Глава 9. Повторяйте этапы 1-8 до наступления этапа 10 133
Наглядное представление цели; нацельтесь на приз
Целью теперь является работающая система. Если вы формируете вашу сис-
систему последовательным наращиванием, причем у каждого из новых вариантов
больше функциональных возможностей, чем у предыдущего - это всегда хоро-
хороший способ работы, поскольку он допускает отступление на запасные пози-
позиции, - то эта стадия будет состоять из ряда мини-стадий, каждая из которых
представит собой горизонт (ориентир) движения.
Альфа-тестирование
Ваша система закончена и, к удовлетворению разработчика, функционирует.
Теперь необходимо провести запланированное тестирование системы, предпоч-
предпочтительно кем-то другим, а не разработчиками.
Наглядное представление цели; нацельтесь на приз
Цель - работа системы или продукта без ошибок (в той мере, насколько это
в человеческих силах).
Бета-тестирование
Ваша система или продукт поставлены ограниченному числу пользовате-
пользователей/заказчиков. Она/он действует в рабочих условиях, и разработчики вносят
исправления/расширения системы или продукта.
Наглядное представление цели; нацельтесь на приз
Цель состоит в том, для чего вы трудились все это время: система или продукт,
который нравится пользователям и/или который продается тысячными тиражами.
ВКЛАД В PSI
Этап 9 дает вклад 0 баллов, поскольку все уже содержится в этапах 1-8.

134 Часть 2. Контроль и осуществление плана; достижение иели
СТРУКТУРНОЕ УПРАВЛЕНИЕ ПРОЕКТОМ
Планирование проекта
1. НАГЛЯДНО ПРЕДСТАВЬТЕ СЕБЕ ЦЕЛЬ; НАЦЕЛЬТЕСЬ НА ПРИЗ.
2. СДЕЛАЙТЕ СПИСОК ЗАДАЧ, ПОДЛЕЖАЩИХ ВЫПОЛНЕНИЮ.
3. ДОЛЖЕН БЫТЬ ОДИН РУКОВОДИТЕЛЬ.
4. РАСПРЕДЕЛЕНИЕ ЗАДАЧ ПО ЛЮДЯМ.
5. УПРАВЛЕНИЕ ОЖИДАНИЯМИ, ЗАДАНИЕ ДОПУСКА НА ОШИБКИ,
ОБЕСПЕЧЕНИЕ ЗАПАСНОЙ ПОЗИЦИИ.
Реализация плана; достижение цели
6. ИСПОЛЬЗУЙТЕ ПОДХОДЯЩИЙ СТИЛЬ РУКОВОДСТВА.
7. ЗНАЙТЕ, ЧТО ПРОИСХОДИТ.
8. СООБЩАЙТЕ ЛЮДЯМ, ЧТО ПРОИСХОДИТ.
9. ПОВТОРЯЙТЕ ЭТАПЫ 1-8 ДО НАСТУПЛЕНИЯ ЭТАПА 10.

ГЛАВА 10
Этап 10: ПРИЗ
" Что теперь достигнуто,
было когда-то только
воображаемым".
Уильям Блей к
ПРИЗ
Наконец наступает день вашей мечты, день, который был в центре вашего
ведения, день, когда проект закончен. Амундсен и его товарищи достигли Юж-
Южного полюса в 3:00 дня в пятницу 15 декабря 1911 г. В своих дневниках они вы-
выразили различные чувства. Бьяланд (Bjaaland), чемпион по лыжам, наслаждался
тем, что оказался там раньше Скотта, и отпраздновал это событие большим пи-
пиром. Хансен (Hanssen), погонщик собак, был просто доволен, что ветер больше
не будет дуть ему в лицо, а только в спину.
Тревор Гриффите (Trevor Griffiths) в своем сценарии для телевизионного се-
сериала "The Last Place on Earth" (Griffiths, 1986) о Скотте и Амундсене помещает
следующие слова в уста Амундсена, когда его товарищи просят сказать неболь-
небольшую речь:
"Я благодарю вас. От всей души. За вашу работу. За ваше согласие. За ваше
умение и ваше товарищество. У меня... нет никаких сильных эмоций, никаких
глубоких мыслей, чтобы поделиться с вами, я должен признать это. Я испыты-
испытываю волнение, конечно... Но прежде всего я чувствую... не больше или глубже,
а только: насколько это хорошо. Быть живым".
ПОДВЕДЕНИЕ ИТОГОВ
Человеческая память коротка, и ничто не забывается легче, нежели опыт,
приобретенный в работе над проектом. Если это был неудачный проект, мы хо-
хотим стереть из памяти эти мрачные воспоминания, если же он был удачным, мы
пребываем в эйфории и только мечтаем о чем-то все большем и большем. Оста-
Остановитесь только на мгновенье. Оглянитесь назад на проект и задайте себе при-
примерно такие вопросы:
¦ Вы завершили работу точно там, где вы заявили, или достигнутая цель от-
отлична от предсказанной?

136 Часть 2. Контроль и осуществление плана; достижение цели
¦ Где она изменилась?
¦ Знали ли вы, что она изменяется?
Задокументируйте, как ваши оценки соотносятся с тем, что произошло в дей-
действительности:
¦ Что было сделано правильно, а что нет, в особенности в отношении людей?
Какие ошибки вы совершили? Были ли вещи, которые можно было сделать
лучше? Если бы вы начинали сначала, что бы вы сделали по-другому?
¦ С каким сюрпризами вы столкнулись? Что вы не предвидели?
¦ Пришлось ли вам тратить свой резерв на ошибки? Были ли проблемы с ожи-
ожиданиями людей? Пришлось ли вам действительно отходить на запасную по-
позицию? Какие уроки из этого можно почерпнуть на будущее?
Запишите ответы на эти и аналогичные вопросы и имейте их перед собой, ко-
когда вы будете писать план для следующего проекта.
ПОРОГИ PSI
С тех пор как появилось первое издание этой книги, мы обнаружили три су-
существенных вещи в PSI, которые обсуждаются в следующих трех разделах.
Порог для этапов 1-5
Число 40, полученное на этапах 1-5, кажется, должно быть пороговым. Пер-
Первоначально, когда проект только запущен, в PSI будет добавляться немного, ес-
если вообще что-нибудь. Мы ожидаем, что это будет именно так.
Вашими приоритетами в проекте тогда должны быть утверждение цели, ко-
которая должна быть достигнута (этап 1), и план ее реализации (этапы 2-5). Вы
делаете это, проходя обычные ранние стадии проекта: определение требований,
анализ, разработка различных уровней. Если они сделаны должным образом, то
это приведет к увеличению баллов для этапа 1, что, в свою очередь, даст возмож-
возможность увеличить баллы для других четырех этапов. Общий балл должен в конеч-
конечном счете приближаться к 40, когда эти различные стадии будут завершены.
Если вы не можете зафиксировать балл выше 40, это означает, что цель не-
недостаточно хорошо проработана и согласована. Если вы не предпримете шаги,
чтобы подкрепить цель таким большим количеством подробностей, какое
только возможно, вы не должны двигаться дальше в работе над проектом.
И, определенно, не должны начинать действия типа реализации. Ваги проект не
будет успешным!

Глава 10. Приз 137
Порог для этапов 1-10
Число 60, полученное на этапах 1-10, по-видимому, является порогом. Пер-
Первоначально, когда проект только запущен, в PSI будет добавляться немного,
если вообще что-нибудь. Мы ожидаем, что это будет именно так.
Отныне маленький балл будет всегда указывать вам на наиболее важные за-
задачи. Если вы относитесь к категории людей, испытывающих сложности в рас-
ставлении приоритетов, то низкие баллы на каждом этапе будут с абсолютной
точностью показывать вам, каковы наиболее важные задачи. Если в любой мо-
момент вы сосредотачиваетесь на них, вы делаете в точности то, что надо.
Второй закон руководства проектом
Brooks A987) сформулировал закон: "Если проект не укладывается в сроки, то
добавление рабочей силы задержит его еще больше". Обратите внимание, что этот
закон включает два из наших четырех параметров: дату поставки и трудозатраты.
Относительное равновесие двух порогов PSI, описанных выше, подразумева-
подразумевает, что существует гораздо более общая формулировка этого закона. Я назвал
его "вторым законом руководства проектом". Он работает примерно так:
¦ Если вы получили очень высокий балл на Этапах 6-10, скажем 9 баллов из
десяти на каждом этапе, что дает суммарно 27, это означает экстраординар-
экстраординарный уровень восприятия при работе с персоналом (Этап 6), мониторинге
и контроле (этап 7) и информировании [людей] (этап 8).
¦ Далее, если вы набрали низкий балл на этапах 1-5, ниже порогового значения
в 40, тогда великолепный балл этапов 6-10, суммируясь с низким баллом эта-
этапов 1-5, не будет достаточен, чтобы перевести вас через 60-балльный порог.
Или, говоря попросту:
чтобы вы ни делали с плохо спланированным проектом, лучше не станет.
Второй закон руководства проектом включает все четыре наших параметра
и является, я верю, более общим законом, частным случаем или следствием ко-
которого является Закон Брукса.
ИСПОЛЬЗОВАНИЕ В РАЗРАБОТКЕ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Последнее действие драмы - достижение конечного горизонта: приза. Когда
это приходит, все кажется таким знакомым, и так и должно быть, потому что это
мечта, в которой вы жили с тех пор, как впервые встали на путь. Это ваше время
для того праздника, который вы планировали. При удачном стечении обстоя-
обстоятельств они дадут вам время для независимой экспертизы. (Настаивайте на этом,

138 Часть 2. Контроль и осуществление плана; достижение цели
даже если они не дают!) После этого они, вероятно, поручат вам новый проект -
еще более спорный, еще более захватывающий, с еще более жесткими кон-
контрольными сроками и датами поставки. Но это - завтра. Сегодня вы можете
греться в лучах вашей славы и поражаться, как легко выглядит то, что сделано.
ВКЛАД В PSI
Этап 10-0 баллов. Это чистый академизм - вы закончили.
СТРУКТУРНОЕ УПРАВЛЕНИЕ ПРОЕКТОМ
Планирование проекта
1. НАГЛЯДНО ПРЕДСТАВЬТЕ СЕБЕ ЦЕЛЬ; НАЦЕЛЬТЕСЬ НА ПРИЗ.
2. СДЕЛАЙТЕ СПИСОК ЗАДАЧ, ПОДЛЕЖАЩИХ ВЫПОЛНЕНИЮ.
3. ДОЛЖЕН БЫТЬ ОДИН РУКОВОДИТЕЛЬ.
4. РАСПРЕДЕЛЕНИЕ ЗАДАЧ ПО ЛЮДЯМ.
5. УПРАВЛЕНИЕ ОЖИДАНИЯМИ, ЗАДАНИЕ ДОПУСКА НА ОШИБКИ,
ОБЕСПЕЧЕНИЕ ЗАПАСНОЙ ПОЗИЦИИ.
Реализация плана; достижение цели
6. ИСПОЛЬЗУЙТЕ ПОДХОДЯЩИЙ СТИЛЬ РУКОВОДСТВА.
7. ЗНАЙТЕ, ЧТО ПРОИСХОДИТ.
8. СООБЩАЙТЕ ЛЮДЯМ, ЧТО ПРОИСХОДИТ.
9. ПОВТОРЯЙТЕ ЭТАПЫ 1-8 ДО НАСТУПЛЕНИЯ ЭТАПА 10.
10. ПРИЗ.

ЧАСТЬ 3
ОДНОВРЕМЕННОЕ ВЕДЕНИЕ
НЕСКОЛЬКИХ ПРОЕКТОВ
ГЛАВА 11
ЕЖЕМЕСЯЧНАЯ ПРОГРАММА "ЛЕНИВОГО
РУКОВОДИТЕЛЯ ПРОЕКТА"
ВВЕДЕНИЕ
Во введении к части 2 мы выдвигаем (довольно очевидный) аргумент, что
если мы сможем "откусывать" то количество проекта, которое требует выпол-
выполнить наш план каждый день, каждую неделю и каждый месяц, то наш проект
не сойдет с рельсов. То же самое относится к бюджету проекта. Ясно, что это
же утверждение можно приложить к нескольким ведущимся одновременно
проектам. Если руководитель проекта может преуспеть в последовательном
выполнении в каждом из своих проектов ежемесячных, еженедельных и, в ко-
конечном счете, ежедневных финансовых и временных промежуточных этапов,
то проекты не выйдут из графика.
Процедуры, описанные в этой и двух последующих главах, дают возмож-
возможность руководителю проекта делать именно это.
Эти три процедуры обязательно должны использоваться совместно описанным
здесь образом. Любая из процедур не может быть использована изолированно.
ЕЖЕМЕСЯЧНАЯ ПРОГРАММА РУКОВОДИТЕЛЯ ПРОЕКТА
Если руководитель проекта спланировал все свои проекты, используя "десять
этапов", то каждый проект будет состоять из плана, который сильно детализиро-
детализирован до очередного промежуточного этапа, вероятно, не больше, чем на четыре-

140 Часть 3. Одновременное ведение нескольких проектов
шесть недель вперед, и детализирован по мере возможности на оставшийся ин-
интервал времени.
Ежемесячная программа руководителя проекта включает процедуру выделе-
выделения месячной порции каждого проекта и последующую попытку организации
своего времени таким образом, чтобы все задачи в этой месячной порции были
выполнены.
Чтобы сделать это, выполняйте следующие шаги или в начале нового месяца,
или в конце предшествующего:
1. Определить для каждого проекта, на какой стадии он должен быть к концу
месяца.
2. Определить, каковы ваши личные (но не вашей команды) трудозатраты в каждом
из этих проектов. Включите в подсчеты время, которое будет потрачено на:
¦ поездки,
¦ запланированные встречи,
¦ обучение,
¦ ежегодный отпуск,
¦ выходные и праздничные дни,
¦ личные задачи,
¦ проблемы качества,
¦ техническую поддержку,
¦ разные задачи, например работа с входящими [документами], прерывания,
общие административные обязанности, которые не могут быть привязаны
ни к какому специфическому проекту.
Все, что вы делаете на своем рабочем месте, должно быть отражено в этом
расчете.
3. Сложить все трудозатраты на все проекты и другие работы и преобразовать
полученное число в человеко-дни.
4. Сравнить результат с числом доступных рабочих дней.
5. Если C) меньше или равно D), перейти к шагу F). В противном случае надо
определить, как компенсировать нехватку. В основном есть четыре доступ-
доступных вам способа:
¦ делайте меньше - поручите это кому-нибудь,
¦ делайте меньше - бросьте это,
¦ работайте большее количество часов,
¦ задерживайте события и отодвигайте сроки.

Глава 11. Ежемесячная программа ленивого руководителя проекта 141
Обратите внимание, что последнее может иметь эффект задержки проектов.
Прежде чем вы можете продолжать, потребность, полученная на шаге C),
должна быть не больше, чем ресурс, рассчитанный на шаге D). Как только
это получилось, можно переходить к F).
6. Теперь занесите все в персональную диаграмму Гантта, как показано на
рис. 11.1. Это можно сделать и на бумаге, но электронная таблица для этого
очень удобна и делать изменения ежемесячно намного проще.
7. Теперь, когда в течение месяца происходят изменения или появляются новые
требования/потребности во времени руководителя проекта, он может заложить
их в свой ежемесячный график, используя варианты, описанные выше в E),
вместо того чтобы давать неблагоразумные или невыполнимые обязательства.
Август
Новая система
Процесс установки
Сборка
Совещание
Планирование
Выбор поставщика
Администрирование базы данных
Установка обновления клиента
Текущие работы
Административная работа
Управление
Общее администрирование
Помощь
Прерывания
ВСЕГО:
1-5
0,5
2
0,5
0,5
0,5
0,5
0,5
5
8-12
3
0,5
2
0,5
0,5
6,5
15-19
0,5
1,5
0,5
0,5
0,5
3,5
22-26
3
0,5
0,5
0,5
0,5
5
29-31
2
0,5
0,5
0,5
0,5
4
Количество дней
общее
21
3
0,5
2
2
2
2,5
4
2
2,5
2,5
24
действительное
21
4
2
4
4
0
0,75
1,5
3
8
2
25,75
Рис. 11.1. Персональная диаграмма Гантта

ГЛАВА 12
ЕЖЕНЕДЕЛЬНАЯ ПРОГРАММА РУКОВОДИТЕЛЯ
ПРОЕКТА
ВВЕДЕНИЕ
Ежемесячное представление показывает, какие работы должны выполняться
каждую неделю для того, чтобы проекты руководителя оставались в графике.
Еженедельная программа включает последовательность работ на неделю, извле-
извлеченную из ежемесячного представления. Это должно проделываться в конце не-
недели или в самом начале следующей.
Чтобы сформировать еженедельный график, руководитель проекта читает из
месячного представления содержание следующей недели и распределяет его на
последующие дни недели (шесть или семь, но идеально - на пять). Давайте про-
проиллюстрируем это, взяв неделю из примера на рис. 11.1.
Неделя 1-5 августа
Руководитель проекта потратит около половины недели на текущую работу,
но есть одна большая задача - план сборки, - которая потребует полной занято-
занятости этой работой в течение двух дней. Если дело обстоит так, то руководитель
проекта мог бы зарезервировать для этого два определенных дня, например
вторник и четверг. В эти дни он заявит, что никакой текучкой заниматься не бу-
будет, и любой, кому это нужно, должен будет ждать. Таким образом, его неделя
будет выглядеть примерно так:
Понедельник:
Вторник:
Среда:
Четверг:
Пятница:
текущая работа
начало работы над планом сборки
текущая работа
конец работы над планом сборки
текущая работа
Снова, если на неделе происходят изменения или возникают новые приорите-
приоритеты, руководитель проекта может пересмотреть недельный график, а в случае не-
необходимости перенести что-то на следующие недели, используя ежемесячное
представление как полный контекст, в котором принимаются решения.

Глава 12. Ежемесячная программа руководителя проекта 143
СПЕЦИАЛЬНЫЕ ЕЖЕНЕДЕЛЬНЫЕ РАБОТЫ
Есть две специальных задачи, которые должны занимать часть каждой неде-
недели руководителя проекта. Это - утренние планерки для проектов по понедель-
понедельникам и создание отчета о состоянии работ проекта как последнее мероприятие
в пятницу. Они были описаны подробно в главах 7 и 8 соответственно. Здесь мы
снова скажем о них.
Утро понедельника: планерка
Планерки надо проводить как можно ближе к началу недели. Их цель состоит
в согласовании той доли проектного графика, которую должен выполнить каж-
каждый человек на этой неделе. На этом совещании можно решать проблемы с за-
задержками, отсутствием людей и другими непредвиденными вещами, произо-
произошедшими в проектах. Руководитель проекта может использовать компьютерную
модель проекта для принятия разумных решений, как реагировать на неожидан-
неожиданные события.
Пятничный отчет о состоянии работ проекта
Создание отчета о состоянии работ должно быть последней работой в пятни-
пятницу, а сам отчет или его версии рассылаются заказчику, начальству и проектной
группе. Если понедельничная планерка устанавливает цели, то пятничный отчет
о состоянии работ констатирует результаты.
Эти результаты должны также быть зарегистрированы в столбцах "Actual
Schedule" ("Рабочий график") и "Effort" ("Трудозатраты") диаграммы Гантта
проекта или в карте контроля оценок ESC (см. приложение 5).

ГЛАВА 13
ДНЕВНАЯ ПРОГРАММА РУКОВОДИТЕЛЯ
ПРОЕКТА
ВВЕДЕНИЕ
В конечном счете, будут ли проекты оставаться в графике или нет, определя-
определяется тем, что руководитель проекта делает или не делает в течение рабочего дня.
Ежедневная программа помогает добиваться, чтобы те задачи, которые являются
ключевыми для успеха каждого проекта, были выполнены. Такая программа
включает выборку тех работ, которые должны делаться ежедневно. Это должно
быть первым делом с утра или последним в предшествующий день.
1. Составление списка всех задач (работ), претендующих на выполнение в дан-
данный день. Для этого обращаются к следующим источникам:
¦ В проектах выделяются задачи посредством уже описанных ежемесячных
и еженедельных программ.
¦ В проектах выделяются задачи при ежедневном анализе, который прово-
проводит руководитель проекта для каждого проекта, находящегося в его веде-
ведении, чтобы определить, какие задачи требуют принятия неких мер.
¦ В проектах выделяются задачи, когда руководитель проекта пытается соз-
создавать более детальные списки задач для тех частей проекта, которые все
еще лежат в будущем и не были проработаны до уровня человек-день.
¦ Существуют другие работы - входящие документы, совещания, факсы,
электронная почта, почта, стакеры*, напоминания, звонки, которые надо
сделать.
¦ Возможно также наличие личных дел.
2. После составления списка производится их классификация согласно следую-
следующей схеме:
A. Надо сделать это сегодня.
B. Хорошо бы сделать это сегодня.
Так у нас уже привыкли именовать специальные разноцветные наклейки-памятки. - Прим.
редактора.

Глава 1 3. Дневная программа руководителя проекта 145
C. Сегодня не буду делать.
D. Поручу эту работу другому.
3. Далее выполняются все задачи, попавшие в категории D и А. Все остальное
можно перенести на другие дни недели или месяца.
Примечание: обратите внимание, что данный подход работает только в том слу-
случае, если сначала выполняется анализ ежемесячных и еженедельных планов. Ес-
Если не сделать этого, то единственным результатом будет скопление большого
числа невыполненных задач позднее на неделе или в течение месяца.
Как описано выше, если возникают изменения в течение дня или появляются
новые приоритеты, руководитель проекта может изменить свою программу,
просто пересмотрев классификацию дневных работ и выполняя все работы кате-
категорий DnA, как и ранее. Если работа категории А оказывается в конце концов
несделанной, то по определению она не могла относиться к категории А (надо
сделать).

ЧАСТЬ 4
КАК ОЦЕНИВАТЬ ПЛАНЫ
ПРОЕКТОВ
ГЛАВА 14
ОЦЕНКА ПЛАНОВ ПРОЕКТОВ
ВВЕДЕНИЕ
Вы уже понимаете теперь, какова наша точка зрения: если вы планируете
что-то правильно, сделать это будет просто. Ключевой мерой того, насколько
хорошо был спланирован проект, является качество созданного плана проекта.
В этой главе я покажу вам, как оценивать такие планы - свои собственные или
других людей. Зная, как сделать это, вы предотвратите превращение потенци-
потенциальных бедствий в реальные.
Вы также догадываетесь теперь, что я очень хочу сделать вас не просто ус-
успешным руководителем проекта, но и "ленивым руководителем". Метод, кото-
который я покажу в этой главе, будет главным оружием в вашем арсенале "ленивого
руководителя проекта". Если план слаб, вы выясните это за несколько минут.
Далее, только если план хорош, вы будете тратить время, анализируя его более
тщательно. Тесты, содержащиеся в описанном методе, выловят всех блох с ми-
минимальным количеством усилий с вашей стороны.
Как можно было ожидать, тесты в этом методе непосредственно выведены из
"десяти этапов".
На самом верху лежат четыре вещи, которые необходимо проверить для
оценки проектного плана. Это:
1. Что в проекте видна четко определенная цель.
2. Что есть план достижения этой цели.
3. Что у проекта есть [реальный] руководитель.
4. Что существует некий резервный план или место для маневра.

Глава 14. Оценка планов проектов 147
Все проверки, которые я описываю, должны будут определить существова-
существование или отсутствие этих пунктов.
Для вас может оказаться удобным не проводить все описанные проверки
в каждом плане, с которым вы сталкиваетесь. В частности, может оказаться по-
полезным использовать первую батарею проверок, которые должен пройти план,
и только если он их проходит, вы выполняете дальнейший анализ. В идеале ко-
количество работы, затрачиваемой на выполнение этой первой серии проверок, не
должно быть слишком велико.
Это и есть тот самый способ, которым я организовал проверки в рамках дан-
данного метода. Всего имеется девять проверок, и они перечислены в следующей
таблице. Напротив каждой проверки приведена оценка количества работы - ма-
малое, среднее, большое - требуемой для выполнения проверки.
Пять из них требуют относительно небольших объемов работы. Я предлагаю
вам использовать их в качестве первого уровня анализа. Эти пять проверок, ве-
вероятно, можно выполнить менее чем за 30 минут.
Другие три проверки могут быть сделаны при скромнейших затратах труда.
Выполнение их всех может потребовать пары часов вашего времени. Однако,
как я уже говорил, вы будете проводить их только при условии, что тестируе-
тестируемый план уже прошел 30-минутный тест.
Остающаяся проверка в зависимости от масштаба плана может потребовать
действительно много времени. Будете ли вы проводить такую проверку или нет,
конечно, полностью зависит от вас. Если вы решили не проводить ее лично, все-
таки важно, чтобы ее провел кто-то другой - а это, скорее всего, будет руководи-
руководитель проекта. Проверки, которые мы рассматриваем, приведены ниже в таблице:
ПРОВЕРКА ТРЕБУЕМЫЕ ТРУДОЗАТРАТЫ
Проверки первого уровня
Содержание
WBS1
Диаграмма Гантта - первичный анализ
Проверки ресурсов 1 и 2
PSI
Малые
Малые
Малые
Малые
Малые
1 WBS - Work Breakdown Structure (структура распределения работ). Подробно обсуждается
ниже. - Прим. переводчика.

148
ПРОВЕРКА
Проверки второго уровня
График и трудозатраты
Диаграмма Гантта - критический путь
Проверки загрузки ресурсов 3 и 4
Проверки третьего уровня
Диаграмма Гантта - все задачи
Часть 4. Как оценивать планы проектов
ТРЕБУЕМЫЕ ТРУДОЗАТРАТЫ
Средние
Средние
Средние
Большие
ПРОВЕРКИ ПЕРВОГО УРОВНЯ
План проекта: анализ содержания
Первая быстрая и очень простая проверка, которую можно выполнить для пла-
плана проекта, состоит в анализе его оглавления. (Если такового нет, возвращайте
документ!) Это, вероятно, займет не более 5-10 минут и может сказать вам, стоит
ли этот план того, чтобы вы продолжали тратить время на его оценивание.
Названия могут быть разными, однако оглавление обязательно должно со-
содержать следующие элементы:
1. Резюме руководства. Некоторый вид краткого обзора или резюме.
2. Формулировка того, что должно быть сделано. Цель проекта.
3. Поставляемые результаты проекта. Также представляют части цели. Они
могут стоять под рядом заголовков:
a. Программное обеспечение.
b. Оборудование.
c. Документация.
d. Услуги.
4. Критерии завершения. Как мы узнаем, когда проект закончен? (Ключевая
часть цели.)
5. Критерий приемки. Как наш заказчик решает, что проект закончен?
(Также ключевая часть цели.)
Все из следующих восьми элементов являются частью основного и резервно-
резервного планов:

Глава 14. Оценка планов проектов 149
6. Структура распределения работ (WBS). Список всех задач, которые должны
быть выполнены для завершения проекта, вместе с оценками трудозатрат на
них и любыми сделанными предположениями.
7. Диаграмма Гантта. Показывает развертку WBS во времени и содержит
формулировки любых сделанных предположений.
8. Промежуточные этапы. Список ключевых дат, извлеченных из диаграммы
Гантта.
9. Требуемые ресурсы. Персонал и любые другие.
10. Загрузка ресурсов. Как ресурсы распределяются по времени.
И.Бюджет проекта (необязательно). Выводится из трудозатрат в WBS F)
и ресурсов (9 и 10).
12. Схема организационной структуры проекта (необязательно). Среди прочего
она служит для идентификации руководителя проекта.
13. Резервный план/допуск на ошибки. Иногда называют анализом рисков.
План проекта представляет собой предсказание того, как различные вещи,
относящиеся к данному проекту, пойдут в будущем. Цель данного раздела в том,
чтобы показать, что автор плана задумывался о том, что он будет делать, если
в действительности случится нечто отличное от плана проекта.
Соотнесите эти 13 элементов с оглавлением плана, который вы оцениваете.
Без тщательного вникания в план это даст вам первый показатель того, насколь-
насколько хорошо собран план.
План проекта: анализ структуры распределения работ
Следующее, что вам нужно, это посмотреть, полон ли план в том смысле, что
он содержит все различные элементы работ, которые определяют проект. Кон-
Контрольный перечень, показанный в примере 1, позволяет вам сделать это. Исполь-
Используйте его как путеводитель, чтобы выявить отсутствующие элементы проектного
плана. Перечень контрольных операций представлен в форме WBS, структуры,
которая распределяет все элементы проекта от верхнего к детальному уровню.
WBS пытается сделать наиболее общее из возможных предположение о цик-
цикле жизни, которому следует проект. Цикл жизни может быть описан следующим
образом.
1. Разрабатываются требования для системы.
2. На основании этих требований разрабатывается общая архитектура системы.
В этой архитектуре видны главные блоки системы.

150 Часть 4. Как оценивать планы проектов
3. Система программируется C.1) и создается ее рабочая (собранная) версия C.2).
4. Планируется D.1) и выполняется D.2) тестирование. 4.2 часто называют аль-
альфа-тестом.
5,6. Как в процессе разработки системы, так и после ее выпуска, приемки и на-
начала эксплуатации с системой работают элементы 5 и 6 (управление проек-
проектом и управление конфигурациями).
7. Разрабатывается документация (руководства).
8. Система выпускается, устанавливается и принимается.
9. Проводится обучение, сначала персонала группы проекта, а затем и пользо-
пользователей системы.
10. Принятая система ставится на сопровождение.
11-13. Некоторые другие элементы, которые, скорее всего, встретятся почти
в любом проекте.
WBS представлена таким способом, что вы можете добавлять в ваши собст-
собственные контрольные перечни WBS элементы, полученные на основе собствен-
собственного опыта по мере его накопления.
ПРИМЕР 1: СТРУКТУРА РАСПРЕДЕЛЕНИЯ РАБОТ
1. Анализ требований.
1.0. Анализ.
1.1. Документ(ы) требований.
1.2. Запрос коммерческих предложений [потенциальным поставщикам].
2. Разработка продукта.
2.0. Аналитика.
2.1. Разработка верхнего уровня (основная архитектура).
2.2. Разработка нижнего уровня (детальное проектирование/программные спецификации).
2.3. Возможное создание прототипов.
3. Программирование.
3.0. Общая проработка кода.
3.1. Тестирование кодов и модулей.
3.1.1. Написание кодового элемента.
3.1.2. Чистовая компиляция кодовых элементов.
3.1.3. Модульное тестирование кодовых элементов (включая план тестирования элементов).
3.1.4. Документирование кодовых элементов.
3.2. Сборка.
3.3. Разработка среды тестирования.
3.4. Техническая поддержка разработки.

Глава 14. Оценка планов проектов 151
3.4.1. Администрирование баз данных.
. 3.4.2. Среда разработки.
3.4.3. Системная компоновка.
4. Тестирование.
4.0. Анализ.
4.1. Написание планов тестирования.
4.2. Альфа-тестирование (системный тест).
4.3. Бета-тестирование (приемочный тест).
5. Руководство проектом.
5.0. Анализ.
5.1. Выработка начального плана проекта, текущий мониторинг и контроль проекта.
5.2. Работа с субподрядчиками.
6. Управление конфигурациями
6.0. Анализ.
6.1. Текущее управление конфигурациями.
6.2. Выпуск.
7. Документация.
7.0. Анализ.
7.1. Пользовательская (различные типы).
7.2. Администраторская.
7.3. Примечания к выпуску.
7.4. Технические руководства, то есть руководства, описывающие, как работает программное
обеспечение.
7.5. Тексты справок.
8. Реализация.
8.0. Анализ.
8.1. Установка.
8.1.1. Планы.
8.1.2. Операции.
8.1.3. Тестирование.
8.2. Преобразование, конвертация.
8.2.1. Планирование.
8.2.2. Операции.
8.2.3. Тестирование.
9. Обучение.
9.0. Анализ.
9.1. Ознакомление проектного персонала.
9.2. Обучение проектного персонала.
9.3. Обучение пользователей.
10. Сопровождение.
11. Укомплектование персоналом.
11.1. Набор кадров.
11.2.Обучение персонала.

152 Часть 4. Как оценивать планы проектов
12. Качество.
12.1. Контроль качества.
12.2. Планы по контролю качества.
13. Административная деятельность.
13.1. Праздники и выходные дни.
13.2. Ежегодный отпуск.
13.3. Болезни.
13.4. Совещания.
Соотнесите с этими элементами WBS аналогичные в оцениваемом вами пла-
плане. Это покажет вам, что было в нем упущено.
План проекта: анализ диаграммы Гантта, обзор верхнего уровня
Диаграмма Гантта - основа вашего плана проекта. Если ее нет в плане, кото-
который вы оцениваете, то возвращайте его назад, так как нет никакого смысла дви-
двигаться дальше.
Диаграмма Гантта может быть оценена на различных уровнях, причем каж-
каждый все более детализован, нежели предыдущий. Чем более детальна оценка,
тем более вероятно, что вы выловите потенциальные недостатки в плане. Одна-
Однако для выполнения такого детального анализа потребуется большее количество
работы с вашей стороны.
Вот три уровня, которые мы рассмотрим, спускаясь от самого верхнего до
самого нижнего:
1. Обзор верхнего уровня.
2. Критический путь.
3. Все задачи.
На данном этапе, однако, мы будем заниматься только обзором верхнего
уровня.
План должен представлять всеобъемлющий обзор верхнего уровня проекта.
Другими словами, план должен показывать:
¦ каковы основные стадии проекта,
¦ сколько длятся эти стадии,
¦ как они связаны друг с другом,
¦ трудозатраты на каждой стадии.
Для проверки этого не потребуется много времени, и есть ряд преимуществ
в проведении именно такой проверки.

Глава 14. Оценка планов проектов
153
Во-первых, этот обзор дает вам ориентиры1 (промежуточные этапы, кон-
контрольные точки) - точки во времени, в которых проект должен будет находиться
в определенном состоянии. Если в момент наступления времени данного ориен-
ориентира проект не находится на ожидаемой стадии, то это раннее предупреждение,
что что-то неправильно.
Наличие обзора верхнего уровня также подразумевает ясность видения со
стороны руководителя проекта. Он указывает, что руководитель проекта четко
продумал, по крайней мере на верхнем уровне, что ему поручено сделать.
Пример плана, у которого есть именно такой вид обзора, показан на рис. 14.1.
На рис. 14.2 показан план, который является почти полной противоположностью
того, что мы подразумеваем. Оба плана основаны на реальной жизни.
ID
1
2
3
4
5
6
—~
8
9
10
11
12
13
Task Name
Пример Проекта №1
0. Начало
1. Выполнение
1.1 Проектирование и подготовк
1.2. Кодирование и тестирована
1.3. Сборка
1.4. Альфа-тестирование
1.5. Поддержка и разное
1.6. Дополнительные работы
1.7. Завершение документации
2. Системные испытания у заказчика
3. Руководство проектом
4. Завершение всего
Work
1 574 days
Odays
1 416 days
275 days
500 days
146 days
312 days
127 days
41 days
15 days
60 days
98 days
Odays
2000
Qlr 1 | Qtr 2 | Qtr 3 | Qtr 4
2001 |
Qtrl JjQtriQ Qtr3 1
tz ¦
i I i
' 1 j
! 1 '
i I
1
4
1
i i
d
\ 1
| 27.12
Рис. 14.1. Анализ верхнего уровня плана
В оригинале "milestones" - верстовые столбы - Прим. переводчика.

154
Часть 4. Как оценивать планы проектов
ID
39
40
41
42
43
44
45
46
47
48
49
Task Name
Изменения бсмы данных
Спецификации
Внесение изменений в существующую
базу данных
Настройка
Многопользовательский режим
Система отчетов
Исследование отчетов
Спецификации
Реализация
Решения по документированию
Решения по оборудованию
Duration
40 days
5 days
9 days
15 days
40 days
30 day»
14 days
lday
15 days
Odays
Odays
Start
Tue 04.01.00
Tue 04.01.00
Tue 11.01.00
Mon 31 01 00
Tue 04 01 00
Tue 04.01.00
Tue 04 01.00
Mon 24.01.00
Tue 250100
Fn 14 01 00
Fn 14 01 00
Finish
Mon 2S.02.00
Mon 10.01.00
Fri 21.01.00
Fn 18 02 00
Mon 28 02.00
Mon 14.02.00
Fri 21.01 00
Mon 24.01 00
Mon 14 02 00
Fri 1401 00
Fri 1401 00
Рис. 14.2. План без соответствующего анализа
Еще один аспект для наблюдения на этом уровне - это количество операций,
которые выполняются параллельно. Иногда, если проект имеет очень сжатые сро-
сроки или крайний срок был установлен до составления плана, метод, которым люди
пытаются решить поставленную задачу, состоит в параллельном выполнении не-
нескольких операций. В этом нет изначального просчета, если только некоторые
операции, запланированные для параллельного выполнения, на деле не могут
быть таковыми. Например, ряд потенциальных поставщиков для системы нельзя
реально оценить до тех пор, пока не будет составлен запрос коммерческих пред-
предложений (RFP). (RFP — Request For Proposal - документ, рассылаемый компанией,
приглашающей другие компании на тендер по предложению неких продуктов или
услуг.) Возможно, некоторые работы по оцениванию, например сбор информации
о конкретных продуктах, или системах, или поставщиках, могут быть выполнены,
пока RFP все еще составляется, однако определенно невозможно завершить в од-
одно и то же время и RFP, и оценку поставщика!
План проекта: анализ ресурсов
Две быстрые проверки, которые должны быть сделаны в проекте, связаны
с исследованием его обеспечения ресурсами. В простейшем виде это означает,
что планирование персонала в проекте учитывает некоторые основные реалии.
Первая из этих реалий (проверка 1) в том, что распределение людей по зада-
задачам учитывает тот факт, что люди могут работать только пять дней в неделю
и что есть определенные периоды (выходные, праздники, отпуска), когда они не
работают. Таким образом, вы должны проверить, что учтено влияние:
¦ ежегодных отпусков (особенно для проектов, идущих летом),

Глава 14. Оиенка планов проектов 155
¦ праздников,
¦ длинных выходных,
¦ сезонных отпусков (Рождество, ПасхаI.
Также следует смотреть с некоторым подозрением на проекты или этапы
проектов, которые заканчиваются в субботы и воскресенья. Они могут подразу-
подразумевать, что некоторые основные вещи не были продуманы.
Проверка 2 состоит в контроле того, что против каждой задачи в плане про-
проекта стоит (см. главу 4). Если дело обстоит не так, это не обязательно проблема,
при условии что где-то в плане заложены такие работы, как, например, вербовка
и найм персонала, внутренние переходы, согласование субподрядных договоров
и так далее - предоставляющие имена этих людей.
План проекта: анализ PSI
Если вы прочли главы 1 - 10, то знаете, что такое PSI. Если нет, быстро за-
загляните в приложение 3, это даст вам общее представление о нем.
PSI рассчитывается быстро (можно использовать рис. 14.3 для облегчения
работы) и не только покажет, в какой форме находится проект, но и позволит по
низким значениям понять в вашем анализе плана, куда руководитель проекта
должен направить свою энергию.
ПРОВЕРКИ ВТОРОГО УРОВНЯ
План проекта: анализ рабочего графика и трудозатрат
Очень эффективный путь выяснения того, что проект был запланирован и про-
продуман должным образом, состоит в проверке распределения трудозатрат и рабо-
рабочего графика по времени жизни проекта. Сравнивая это распределение с анало-
аналогичными параметрами предыдущих законченных проектов, вы можете почувство-
почувствовать точность, или ее отсутствие, в оценках в рассматриваемом плане.
Очевидно, проекты сильно различаются в разных организациях и даже в пределах
одной организации. В силу этого распределения трудозатрат и рабочего графика по
жизни проекта также будут различаться. Однако обнаружение того, что распределе-
распределение в оцениваемом проекте грубо сопоставимо с распределением в ранее завершен-
завершенном успешном проекте, добавит вашего доверия к оцениваемому плану. И наоборот,
обнаружение сильных расхождений между соответствующими распределениями по-
побудит вас задать вопросы о различных оценках и методах их получения.
1 Хотя формально таких отпусков в России нет, начало января и начало мая отличаются от них
разве что еще более печальным влиянием на рабочую обстановку. - Пргш. переводчика.

156
Часть 4. Как оценивать планы проектов
Десять Этапов
Планирование проекта
1. Наглядное представление цели; установка на приз
2. Создание списка задач, подлежащих выполнению
3. Наличие одного руководителя
4. Распределение задач по людям
5. Управление ожиданиями/ задание допуска на ошибки! обеспечение запасной позиции
Реализация плана; достижение цели
°< Применение подходящего стиля руководства
7. Знание происходящего
8. Информирование людей о происходящем
9. Повторение этапов 1-8 до наступления этапа 10
Ю. Приз
Всего
Текущие проекты
Вес
20
20
10
10
10
10
10
10
10
100
1-5 5-10
Рис. 14.3. Расчет PSI проекта

Глава 14. Оценка планов проектов
157
Понятно, что этот анализ можно провести только в том случае, если вы уже
имеете какие-то цифры по таким распределениям, чтобы использовать их как ос-
основание для сравнения. К сожалению, в области ИТ-технологий все еще крайне
редко можно найти такие данные, не говоря уже об их точности. Таким образом,
чтобы этот тест давал наибольший эффект, вам нужно начинать собирать данные
по этим распределениям в своих завершенных проектах. Форма, которая облегча-
облегчает эту работу, называется картой контроля оценок (ESC - Estimating Score Card),
она описана в приложении 5.
При отсутствии своих собственных данных вы можете все же применять этот
анализ, используя данные, отраженные в карте ESC, показанной на рис. 14.4.
Карта контроля оценок
Проект
Автор
№ редакции
Дата
Стадия
Тех. требования
и разработка A,2)
Прогр. и тест {За}
Сборка (ЗЬ)
Системный тест D)
Управление
проектом (9)
Документация,
поддержка,
конфигурация
(<*. 7, 9)
8,10
Пример анализа графика
и трудозатрат
График
(мес.)
%
Трудозатраты
(чел-мес.)
%
График
(мес.)
X
27
37
18
18
—
-
Трудозатраты
(чел-мес.)
X
18
36
9
20
6
11
-
График
(мес.)
X
Трудозатраты
(чел-мес.)
X
Рис. 14.4.

158 Часть 4. Как оценивать планы проектов
Сравнение будет не слишком аккуратным, поскольку эти данные, в силу воз-
возникшей необходимости, представляют собой некую обобщенную по многим раз-
различным проектам информацию. Однако они дадут вам возможность начать приме-
применять этот анализ, их можно будет использовать, пока не станут доступными ваши
собственные данные. Пункты, на которые необходимо обратить внимание:
¦ ESC охватывает все, кроме двух стадий жизненного цикла, описанных в раз-
разделе по анализу WBS (стр. 149). Это стадии 8 "Установка и сдача" и 10 "Со-
"Сопровождение".
¦ Первый столбец с заголовком "%" показывает, какая доля прошедшего вре-
времени исполнения проекта должна приходиться на каждую из стадий. Так, на-
например, 26 % от прошедшего времени проекта должны быть затрачены на
стадии выработки требований и разработки.
¦ Второй столбец с заголовком "%" показывает, какая доля трудозатрат должна
приходиться на каждую из стадий.
Примечание: снова повторяю - это обобщенные данные, и поэтому они должны
использоваться осторожно. Цифры оцениваемого проекта могут значительно
отличаться от них и все еще оставаться правильными в силу специфического
характера конкретного проекта.
Теперь давайте посмотрим пример анализа. Предположим, что план оценивае-
оцениваемого проекта имеет распределение трудозатрат и графика, показанный на рис. 14.5.
Если автор плана не представил такое распределение, есть два варианта: или
отошлите план назад с предписанием представить распределение графика и тру-
трудозатрат, или проработайте его сами, получив оценки трудозатрат и графика из
структуры распределения работ (WBS) и диаграммы Гантта плана.
Рис. 14.6 показывает распределение плана проекта в сравнении с нашими
обобщенными данными. Существенные различия между двумя наборами цифр
обсуждаются ниже.
1. Время или трудозатраты, отведенные в проекте на сбор требований и разра-
разработку, кажется, недостаточны.
2. Слишком большая часть времени и трудозатрат в проекте отводится на непо-
непосредственное написание программ.
3. Сборка не предусмотрена вообще.

Глава 14. Оценка планов проектов
159
4. Показатели для теста системы выглядят завышенными. Не обусловлено ли
это тем, что стадия разработки усечена и ожидается появление большого ко-
количества проблем?
Это вопросы, на которые вам надо будет получить ответы прежде, чем вы
сможете дать добро этому проекту.
Карта контроля оценок
Проект
Автор
№ редакции
Дата
Пример анализа графика и трудозатрат
Стадия
Тех.требования
и разработка A,2)
Прогр. и тест (За)
Сборка (ЗЬ)
Системный тест D)
Управление
проектом (9)
Документация,
поддержка,
конфигурация
F, 7, 9)
График
(мес.]
%
17
55
0
28
—
-
Трудозатраты
(чел-мес.)
%
7
52
0
35
6
График
(мес.]
%
Трудозатраты
(чел-мес.)
%
График
(мес.)
%
Трудозатраты
(чел-мес.)
%
Рис. 14.5

160
Часть 4. Как оценивать планы проектов
Карта контроля оценок
Проект
Автор
№ редакции
Пример анализа графика и трудозатрат
Дата
Стадия
Тех. требования
и разработка A,2)
Прогр. и тест (За)
Сборка Cd)
Системный тест D)
Управление
проектом (9)
Документация,
поддержка,
конфигурация
F, 7, 9)
График
(мес.)
%
17
55
0
28
Трудозатраты
(чел-мес.)
%
7
52
0
35
6
График
(мес.)
А
В
С
D
Е
%
26
36
18
18
Трудозатраты
(чел-мес.)
%
18
36
9
20
17
График
(мес.)
%
Трудозатраты
(чел-мес.)
%
Рис. 14.6
План проекта: анализ диаграммы Гантта, критический путь
Как мы упоминали ранее, диаграмма Гантта может быть оценена на различ-
различных уровнях, причем каждый более детализован, чем предыдущий. Чем более
подробна оценка, тем больше вероятности обнаружения потенциальных прорех
в плане. Однако для более детального анализа вам потребуется большее количе-
количество работы. Уровень, который мы рассмотрим в этой проверке, это уровень
критического пути.
Критический путь представляет собой самый короткий путь в проекте: дру-
другими словами, это самое короткое время, за которое проект может завершиться.
Если выполнение любой из задач на критическом пути задерживается, то и весь
проект будет задержан.
Если вы хотите копнуть проект поглубже без фактического прохождения от
задачи к задаче, критический путь является и удобным, и точным индикатором
как раз для такой работы.

Глава 14. Оценка планов проектов 161
Чтобы сделать это, в оцениваемом плане должно быть ясно показано, каков
критический путь. Компьютерные средства планирования проекта делают это
автоматически. Если диаграмма Гантта строилась без помощи таких средств, то
автор плана должен определить критический путь вручную. Если в плане не по-
показан критический путь, то вы можете со спокойной душой вернуть его, по-
поскольку, скорее всего, это означает, что руководитель проекта недостаточно
продумал его.
Основываясь на предположении, что диаграмма Гантта показывает критиче-
критический путь, для каждой задачи на критическом пути вы должны проверить все
следующее:
¦ Выглядят ли трудозатраты, связанные с конкретной задачей, обоснованными?
¦ Имеют ли смысл календарные дни, в которые должна выполняться задача?
Например, не были ли запланированы работы в праздничные или выходные
дни и не сделаны ли нереалистичные предположения о том, что будет сдела-
сделано в праздничные периоды, типа рождественских каникул?
¦ Приписана ли каждая задача на критическом пути к какому-либо исполните-
исполнителю - не к организации, а к конкретному человеку, который ответственен за
эту задачу?
Комментарии, сделанные ранее о распараллеливании задач, применимы
и здесь. Не запланировано ли параллельное выполнение задач, которые на самом
деле связаны между собой?
Результаты всех этих тестов, применяемых к каждой задаче на критическом
пути, составят аналитические комментарии плана.
И наконец, при желании вы можете сделать простой анализ рисков, исполь-
используя четыре параметра из "первого закона руководства проектом":
¦ функциональность - что должно быть сделано,
¦ дата поставки (или время, которое должно пройти) - когда задача должна
быть выполнена,
¦ трудозатраты - какой объем работ включен,
¦ качество - как хорошо сделана работа.
Вы можете это сделать, задавая себе вопросы, подобные следующим:
¦ Делается ли в данной задаче что-то критическое для проекта? Если нет, не
может ли она быть передвинута на более поздний срок? (Функциональные
возможности.)
¦ Что случится, если задача не уложится в срок? (Прошедшее время.)
¦ Можно ли ускорить выполнение данной задачи? (Прошедшее время.)
6 - 2224

162 Часть 4. Как оценивать планы проектов
¦ Что случится, если объем работ окажется больше, чем мы оцениваем? (Тру-
(Трудозатраты.)
¦ Каким будет эффект от добавления людей? (Трудозатраты.)
¦ Что случится, если эта задача не будет сделана качественно? (Качество.)
План проекта: анализ ресурсов
Существует еще две проверки, которые показывают, правильно ли распреде-
распределены ресурсы и принимает ли проект во внимание некоторые основные реалии.
Проверка 3 состоит в выявлении того, что люди не будут загружены более,
чем на 100 %, то есть они не должны быть запланированы для одновременного
присутствия в двух местах или для работы более пяти дней в неделю.
Проверка 4 исследует, учитываются ли в количестве трудозатрат персонала,
запланированного в данном проекте, другие их обязанности. Таким образом,
если запланировано, что данный человек будет работать над проектом пять дней
в неделю, то это означает, что он не будет делать абсолютно ничего иного
в течение всего времени работы над проектом. Часто у людей несколько обязан-
обязанностей, и это следует учесть.
Нужно снова сказать, что использование руководителем проекта компьютер-
компьютерных средств делает проверку всех этих вещей очень простой. В частности, ком-
компьютерные средства могут выводить диаграммы загрузки ресурсов, показываю-
показывающие, сколько работы намечено для каждого человека и когда.
ПРОВЕРКИ ТРЕТЬЕГО УРОВНЯ
План проекта: анализ диаграммы Гантта, все задания
Как мы упомянули ранее, диаграмма Гантта может быть оценена на ряде раз-
различных уровней. Уровень, на который мы посмотрим в этой проверке, это уро-
уровень всех задач в плане.
Анализ диаграммы Гантта может применяться для всех задач в проекте. Это
работа, которая потребует весьма много времени. Если можно ожидать, что ру-
руководитель проекта ее сделал, то вам, вероятно, не надо делать этого в оцени-
оцениваемом плане. Что вы, однако, могли бы сделать, так это выполнить выбороч-
выборочную проверку по определенным задачам. Например, можно сделать проверку:
¦ особенно больших задач,
¦ задач, которые должны выполняться внешним подрядчиком,
¦ задач, которые должны выполняться каким-то новым сотрудником,
¦ задач, о которых известно, что они являются технически сложными,

Глава 14. Оценка планов проектов 163
¦ новых задач, то есть таких, которые прежде не выполнялись в данной органи-
организации,
¦ и так далее.
Вне зависимости от того, что вы собрались сделать, здесь снова существуют
определенные этапы. Проверьте:
¦ Выглядят ли трудозатраты, связанные с конкретной задачей, обоснованными?
¦ Имеют ли смысл календарные дни, в которые должна выполняться задача?
Например, не были ли запланированы работы в праздничные или выходные
дни и не сделаны ли нереалистичные предположения о том, что будет сдела-
сделано в праздничные периоды, типа рождественских каникул?
¦ Приписана ли каждая задача к какому-либо исполнителю - не к организации,
а к конкретному человеку, который ответственен за эту задачу?
Комментарии, сделанные ранее о распараллеливании задач, применимы и здесь.
Не запланировано ли параллельное выполнение задач, которые на самом деле свя-
связаны между собой?
Результаты всех этих тестов, применяемых к каждой задаче, составят анали-
аналитические комментарии плана.
И наконец, при желании вы можете сделать простой анализ рисков, исполь-
используя четыре параметра из "первого закона руководства проектом":
¦ функциональность - что должно быть сделано,
¦ дата поставки (или время, которое должно пройти) - когда задача должна
быть выполнена,
¦ трудозатраты - какой объем работ включен,
¦ качество - как хорошо сделана работа.
Вы можете это сделать, задавая себе вопросы, подобные следующим:
¦ Что случится, если задача не уложится в срок? (Прошедшее время.)
¦ Можно ли ускорить выполнение данной задачи? (Прошедшее время.)
¦ Что случится, если объем работ окажется больше, чем мы оцениваем? (Тру-
(Трудозатраты.)
¦ Каким будет эффект от добавления людей? (Трудозатраты.)
¦ Делается ли в данной задаче что-то критическое для проекта? Если нет, не
может ли она быть передвинута на более поздний срок? (Функциональные
возможности.)
¦ Что случится, если эта задача не будет сделана качественно? (Качество.)

164 Часть 4. Как оценивать планы проектов
ПРИМЕРЮ
Сценарий
Вы получаете план проекта для анализа. Это документ объемом приблизи-
приблизительно 15 страниц. Страницы не нумерованы и нет оглавления. Просматривая
план, вы обнаруживаете, что у него три раздела со следующими заголовками:
¦ Введение.
¦ Технические требования.
¦ Нарисованная вручную диаграмма Гантта.
Раздел, названный "Технические требования", достаточно детализирован. По
мере его чтения вы начинаете понимать, что план предусматривает внедрение
системы, которая будет взаимодействовать с некоторыми другими системами ор-
организации. Система будет приобретена при условии модификации ее поставщи-
поставщиком под нужды организации. Некоторый объем разработок потребуется также
и со стороны организации. Новая система заменит существующую систему. План
показывает, что проект начинается 12 декабря 2000 г. и будет считаться претво-
претворенным в жизнь 28 июня 2001 г.
Раздел "Технические требования" описывает:
¦ систему, которая будет передана пользователям;
¦ программное обеспечение, документацию, обучение и поддержку, которые
составляют часть проекта;
¦ период параллельной работы [старой и новой систем] и условия, которые долж-
должны быть выполнены, прежде чем [новая] система может быть объявлена рабо-
работающей;
¦ аппаратное и программное обеспечение, в которых система будет разрабаты-
разрабатываться и работать.
Этот раздел также имеет сильный уклон в сторону пользователей, вовлекаемых
во все этапы выработки технических требований, проектирования и разработки.
Диаграмма Гантта частично показана на рис. 14.7. Горизонтальные полоски
показывают детальное разбиение каждой из задач верхнего уровня. Разбиение
очень детализировано в декабре и январе, меньше в последующее время, однако
диаграмма Гантта производит впечатление богатства деталей. При оценке ее
с помощью анализа WBS (структуры распределения работ) кажется, что упуще-
упущено немного или вообще ничего.

Глава 14. Оиенка планов проектов
165
НАЧАЛО
1. Написание запроса на
коммерческие предложения
• написание документов АВ, CD
• анализ документов EF, GH, IJ
• утверждение EF, GH, IJ
• посылка поставщикам АВ
2. Выбор поставщика
3. Разработка поставщика
4. Разработка компании
5. Интеграция (сборка)
6. Тестирование
7. Документация
8. Установка
9. Обучение
10. Параллельная работа
11. Промышленная эксплуатация
КОНЕЦ
2000
Декабрь
12.12
2001
Январь Февраль Март Апрель Май Июнь Июль
28.06
Рис. 14.7
Каждая задача в WBS имеет инициалы против названия работы, показываю-
показывающие, кто будет выполнять ее. Для каждой задачи также показан объем трудоза-
трудозатрат. Примечания к диаграмме Гантта объясняют, как эти оценки были получе-
получены, а также объясняют, какой статус имеет каждый работник, включенный
в проект, - полная занятость, два дня в неделю, требуется только для дачи за-
заключений и т. д.
Какова была бы ваша оценка этого плана?

166 Часть 4. Как оценивать планы проектов
Анализ
Проверки первого уровня
Анализ оглавления
План содержит три раздела, в то время как предложенное нами идеальное
оглавление содержало тринадцать! Это уже не похоже на многообещающее на-
начало, но мы решаем проявить немного настойчивости и посмотреть, что еще мы
сможем найти.
1. Формулировка того, что должно быть сделано. Это оказалось адекватно ос-
освещено в технических требованиях.
2. Поставляемые результаты. Отражено в технических требованиях.
3. Критерий завершения. Отражено в технических требованиях.
4. Критерий приемки. Отражено в технических требованиях.
5. Структура распределения работ. Идущие вниз задачи в левой стороне диа-
диаграммы Гантта.
6. Диаграмма Гантта. Присутствует.
7. Промежуточные этапы. Могут быть выведены из диаграммы Гантта.
8. Требуемые ресурсы. Кадровые ресурсы представлены в пояснениях к диаграм-
диаграмме Гантта. Другие ресурсы (компьютеры, программное обеспечение и т. д.) от-
отражены в технических требованиях.
9. Загрузка ресурсов. Явно не сформулирована, однако может быть получена из
предыдущего раздела.
10. Бюджет проекта. Не определен.
11. Схема организационной структуры проекта. Не определена. Из плана под-
подразумевается, что автор является руководителем проекта.
12. Резервный план/допуск на ошибки. Если 28 июня система не будет готова, то
их существующая ручная система может продолжать работать, как прежде.
Это, может быть, не очень элегантный резервный план, но он будет работать!
WBS-анализ
См. пункт 5 выше. Похоже, все нормально.

Глава 14. Оценка планов проектов 167
Анализ диаграммы Гантта; краткий анализ верхнего уровня
На диаграмме Гантта представлен в точности тот вид краткого анализа верх-
верхнего уровня, который мы искали. Мы можем видеть:
¦ основные стадии проекта и точное начало и завершение каждой стадии,
¦ какие стадии зависят друг от друга и какие могут выполняться параллельно,
¦ объем работ на каждой стадии.
Анализ ресурсов
Быстрый взгляд на диаграмму Гантта показывает, что проект должен начаться
за неделю до Рождества, а интенсивная работа запланирована с этой даты и до
конца года. Культуры различаются, как и организации. Однако в Европе было бы
маловероятно выдержать такой график, так что эту часть графика, по всей види-
видимости, надо поправить. Этот может иметь серьезные последствия для срока за-
завершения проекта - 28 июня. Анализ критического пути на диаграмме Гантта оп-
определил бы: а) так это или нет и б) что могло быть сделано с этим. Что касается
проверки 2, то все задачи расписаны по людям.
Анализ PSI
Наконец, давайте вычислим PSI проекта.
1. Цель ясно определена. Да, но детали надо дорабатывать. Это будет сделано
в процессе написания запроса на коммерческие предложения и в конечном
счете в процессе разработки. Балл будет, скажем, 6 из 20. Вспомните, низкий
балл может отражать либо а) проблемные места, либо б) в какой временной
точке жизни проекта вы находитесь. В данном случае - последнее.
2. Список работ. Есть, но список неизбежно неполон, учитывая ту точку во вре-
времени жизни проекта, где мы сейчас находимся. Снова даем 6 баллов из 20.
3. Один руководитель. Да, полагая, что автор плана действует, как тот тип ру-
руководителя, который мы требуем, т. е. командир, прокладывающий путь.
10 баллов, максимальное значение.
4. Люди распределены по задачам. Да, хотя поскольку список задач неполон
(см. п. 2 выше), то это условно. 3 балла из 10 на этой стадии проекта.
5. Резервный план/допуск на ошибки. Да, несмотря на неэлегантный способ.
Балл, скажем, 7 из 10.
Общий балл стадии планирования - 32. Как мы уже отметили, 40 - порог для
успешного проекта, так что мы его еще не достигли. Однако, как только проект

168 Часть 4. Как оценивать планы проектов
пройдет стадию написания запроса на коммерческие предложения, мы должны
оказаться в хорошей форме, чтобы продолжать.
Таким образом, на основании нашей начальной быстрой оценки, несмотря на
малообещающее оформление и некоторые недочеты, этот план, кажется, в хо-
хорошей форме. Главная проблема с ним в настоящее время -это та самая пробле-
проблема с Рождеством.
Мы можем теперь провести:
¦ анализ рабочего графика и трудозатрат,
¦ анализ критического пути по диаграмме Гантта,
¦ анализ ресурсов (проверки 3 и 4).
И среди других вещей это позволит определиться с проблемой Рождества.
Наконец, при желании мы можем провести анализ диаграммы Гантта всего
проекта.
ПРИМЕР 11
Сценарий
Вы получаете план проекта для анализа. Его объем примерно 30 страниц.
План предназначен для проекта по разработке программного продукта, поставки
его пользователю, установки и загрузки пользовательских данных к 31 марта
2000 г.
Проверяя содержание, вы находите, что в нем есть разделы, соответствующие
всем пунктам в нашем контрольном перечне оглавления. Каждый из этих разде-
разделов выглядит довольно существенным и содержит те вещи, о которых мы гово-
говорили. В частности, назван руководитель проекта.
Диаграмма Гантта для этого проекта, которая содержит WBS (структуру рас-
распределения задач) в столбце "Name", показана на рис. 14.8.
Какова ваша оценка этого плана?
Анализ
Проверки первого уровня
Анализ оглавления
Как описано в сценарии, кажется, здесь все в порядке.
Анализ WBS
Похоже, в этой WBS отсутствует следующее:

Глава 14. Оиенка планов проектов
169
¦ какой-либо анализ требований или их описание;
¦ любой вариант разработки верхнего уровня;
¦ сборка программ;
¦ разработка тестов (в противоположность проведению тестов);
¦ управление проектом;
¦ управление конфигурациями и другие действия по поддержке проекта;
¦ создание документации;
¦ что-либо существенное на этапе инсталляции или обучения.
Анализ диаграммы Гантта: краткий обзор верхнего уровня
Не существует.
Анализ ресурсов
Проблема с периодом рождественских праздников, кажется, тоже задевает
этот проект (проверка 1). Все задачи расписаны по исполнителям (проверка 2).
ID
37
38
39
40
41
42
43
44
45
46
. 47
0
шз
ЕЭ
ЕЗ
ЕЭ
ЕЗ
[_Task Name I
Реализация ;
Архивирование
Изменение базы данных
Спецификация
Внесение изменений в существующую баз)
Обработка
Многопользовательский режим
: Система отчетов
Исследование отчетов
Спецификации
i Реализация
Duration |
7 days
19 days
203 days
130 days
9 days
15 days
39 days
29 days
14 days
Iday .
15 days
Start
Fri 14.01.00
Tue 04.01.00
Tue 04.01.00
Mon 03.04.00
Mon 02 10.00
Mon 31 01 00
Tue 04.01.00
Tue 04.01.00
Tue 04.01.00
Fri 21 01 00
Mon 24.01.00
L Rnish
Mon 24.01.00
Fri 28.01.00
Thu 12.10.00
Fri 29.09.00
Thu 12.10.00
Fri 18 02.00
Fri 25.02 00
Fri 11.02.00
Fri 21 01.00
Fri 21 01.00
Fri 11.02.00
Рис. 14.8
Анализ PSI
1. Цель ясно определена. Цель проекта на самом деле не может быть ясно опре-
определена, если нет никаких действий (анализ требований или разработка верх-
верхнего уровня) для ее определения! Предполагая существование некого описа-
описания требований в тексте документа, мы дадим им 10 баллов из 20.
2. Список задач. Список задач, WBS, является, как бы это сказать помягче, не
очень хорошим. Даем 10 баллов из 20.

170 Часть 4. Как оценивать планы проектов
3. Один руководитель. План говорит, что он есть, так что давайте примем это.
10 баллов из 201.
4. Задачи распределены по людям. Да, распределены. Но поскольку список за-
задач беспорядочен, это распределение также будет подпорчено. Дадим поло-
половину, как для пункта 2 выше, т. е. 5 баллов из 10.
5. Резервный план/допуск на ошибки. Не выглядит хорошим. В плане указаны
операции по поставке системы и загрузке данных (задача 56), намеченные на
31 марта 2000 г. Если не все пойдет точно по графику, то 31 марта на стороне
пользователя ничего не произойдет2. Балл -15 (т. е. вычесть пятнадцать) при
максимальном балле 10.
Общая сумма здесь составляет 20 баллов. При 40 баллах порога и без задач
в плане, которые могли бы увеличить балл для определения цели и списка задач,
этот проект выглядит, как имеющий сильно угнетающие перспективы.
ПРИМЕР 12
Сценарий
Вы получаете план проекта для анализа. Его объем примерно 30 страниц.
План предназначен для проекта разработки и выпуска системы. Из документа
ясно, что план очень напряженный, проект начинается 1 мая и должен закон-
закончиться самое позднее 31 августа. План основан на документе, содержащем тех-
технические требования, который уже утвержден.
Проверяя содержание, вы находите, что в нем есть разделы, соответствующие
всем пунктам в нашем контрольном перечне оглавления. Каждый из этих разде-
разделов выглядит довольно существенным и содержит те вещи, о которых мы гово-
говорили. Руководитель проекта назван.
При проверке WBS вы находите, что есть многие упущения и неточности,
и помечаете их для себя.
Вы ищете диаграмму Гантта для обзора верхнего уровня и находите ее (вос-
(воспроизведена на рис. 14.9). Она нарисована вручную, но тем не менее, кажется,
содержит все главные блоки. Более детальная диаграмма Гантта (не показанная
здесь, но содержащая все, что мы ожидаем) дополняет обзор верхнего уровня.
' Видимо, здесь автор ошибся, говоря о максимальном балле, равном 20. Везде в книге он ука-
указывает 10 баллов. - Прим. редактора.
2 Шутка, принятая в "музейных" городках Дикого Запада, восстановленных для туристов.
На некоторых домах можно видеть таблички "На этой стороне улицы 25 июля 1865 г. ничего
не произошло". -Прим. переводчика.

Глава 14. Оценка планов проектов
171
Анализ рабочего графика и трудозатрат, гистограмма анализа ресурсов пока-
показывают, что каждый исполнитель задействован на 100 % или меньше и все пред-
предположения по наличию и доступности персонала содержатся на страницах
плана. Есть также примечание в плане на предмет того, что летние отпуска всех
членов проектной группы учтены в оценках и графиках.
Какова ваша оценка этого плана?
Май Июнь Июль Август Сентябрь
одулеи
Тестир
>вание ь
Сборк! i
Тестир* >вание с истемы
Рис. 14.9
Анализ
Проверки первого уровня
Анализ оглавления
Как описано в сценарии, кажется, здесь все в порядке.
Анализ WBS
Результаты анализа WBS (структуры распределения работ) уже отмечены
в сценарии.
Анализ диаграммы Гантта: краткий обзор верхнего уровня
Здесь определенно есть обзор верхнего уровня с более детальной диаграммой
Гантта, поддерживающей его. Однако в этом обзоре верхнего уровня есть глав-
главный порок: четыре операции в нем в высшей степени подозрительно наклады-
накладываются друг на друга.

172 Часть 4. Как оценивать планы проектов
¦ Программное обеспечение пишется в то время, как разрабатывается система.
Это всегда опасно делать.
¦ Сборка программного обеспечения начинается прежде, чем вся программа
будет написана. Хотя это может указывать на хорошее опережающее плани-
планирование со стороны руководителя проекта, иногда это может указывать, что
кто-то просто пытается ужать все задачи в заданное время. Это заслуживает
дальнейшего исследования на уровне большей детализации - уровне крити-
критического пути.
¦ Тестирование системы представлено не так всеобъемлюще, как это кажется.
Тестирование системы должно делать в точности следующее: проверять всю
систему. В этом же плане тестирование системы начинается прежде, чем сис-
система полностью доступна. Снова это могло бы подразумевать большое пред-
предвидение со стороны руководителя проекта. К сожалению, более часто это
подразумевает присутствие Закона Паркинсона - "Работа расширяется (или
сжимается!), чтобы заполнить все выделенное время".
Анализ ресурсов
Как мы отметили в сценарии, летний сезон отпусков учтен (проверка 1). Так-
Также информация, кто что делает, содержится в более детальной диаграмме Гантта
(проверка 2).
Анализ PSI
1. Цель ясно определена. При запараллеливании разработки и программирова-
программирования есть большой шанс, что цель проекта никогда не будет ясной; что то, что
напишут программисты, будет не тем, что хотели разработчики. Даем, ска-
скажем, 12 баллов из 20.
2. Список задач. Список задач, WBS, как сказано в сценарии, не очень хорош.
Даем снова 12 из 20.
3. Один руководитель. План говорит, что он есть, так что примем это. Даем все
10 баллов.
4. Люди распределены по задачам. Если список задач с существенными изъяна-
изъянами, этот пункт также будет иметь существенные изъяны. Счет в той пропор-
пропорции, что и для п. 2 (выше), 6 из 10.
5. Резервный план/допуск на ошибки. Не выглядит хорошим. План демонстри-
демонстрирует все признаки планирования по Паркинсону. В нем, вероятно, не только
нет допуска на ошибки, но и план в том виде, как он представлен, скорее все-
всего, слабо привязан к реальности. Балл -15 (то есть вычитается пятнадцать)
при максимальном балле 10.

Глава 14. Оценка планов проектов 173
Общая сумма здесь составляет 25 баллов. При 40 баллах порога и без задач
в плане, которые могли бы увеличить балл для определения цели и списка задач,
этот проект выглядит, как имеющий сильно угнетающие перспективы.
Как мы видели во всех этих трех примерах, вы часто - но не всегда - можете
выяснить все, что нужно знать о плане, используя пять небольших проверок,
о которых мы говорили ранее, то есть те, которые занимают 30 минут или около
того. Исключительно для напоминания, это:
Проверка
Оглавление
WBS
Краткий обзор диаграммы Гантта
Анализ ресурсов
PSI
Трудозатраты
Малые
Малые
Малые
Малые
Малые
Проверки второго уровня
Для примера 12, исключительно ради интереса, мы посмотрим, что мы мо-
можем еще выяснить, применив один из тестов второго уровня. Из трех тестов это-
этого уровня мы применим анализ графика и трудозатрат.
Проверка
Анализ графика и трудозатрат
Диаграмма Гантта - критический путь
Анализ ресурсов, 3 и 4
Затрачиваемые усилия
Средние
Средние
Средние
Анализ графика и трудозатрат
Анализ графика и трудозатрат, приведенных в плане, показан на рис. 14.10.
Добавление наших цифр для сравнения показано на рис. 14.11. Интерпретация
различий между этими двумя наборами данных следующая.
1. Трудозатраты на разработку выглядят слишком низкими. В совокупности
с запараллеливанием разработки, программирования и тестирования модулей
это дополнительное свидетельство очень тревожного положения дел.
2. 75 % трудозатрат на программирование и тестирование модулей граничит
с безумием!
3. То же относится к 3 % на сборку.
4. И к 10 % на тестирование системы.
Эта проверка только добавляет вес, если бы это потребовалось, доказательст-
доказательству, которое мы уже имеем.

174
Часть 4. Как оценивать планы проектов
Карта контроля оценок
Проект
Автор
№ редакции
Дата
Стадия
Разработка
Прогр. и тест (За)
Сборка (ЗЬ)
Системный тест D)
Пример 12
График
(мое.)
%
25
41
17
17
Трудозатраты
(чел-мес.)
%
12
75
3
10
График
(мес.)
X
Трудозатраты
(чел-мес.)
X
График
(мес.)
%
Трудозатраты
(чел-мес.)
%
Рис. 14.10
Карта контроля оценок
Проект
Автор
№ редакции
Дата
Стадия
Разработка
Прогр. и тест (За)
Сборка (ЗЬ)
Системный тест D)
Пример 12
График
(мес.)
X
25
41
17
17
Трудозатраты
(чел-мес.)
X
12
75
3
10
График
(мес.)
А
В
С
D
%
27
37
18
18
Трудозатраты
(чел-мес.)
X
18
36
9
20
График
(мес.)
X
Трудозатраты
(чел-мес.)
%
Рис. 14.11

Глава 14. Оценка планов проектов 175
РЕКОМЕНДАЦИИ ПО НАПИСАНИЮ ПЛАНОВ ПРОЕКТОВ
Если вам поручено написать план проекта, тогда следующие пункты должны
помочь вам сделать наилучшее в такой работе. (Это альтернатива тому, что при-
приведено во введении в части 2.) Ваш план должен содержать следующие элементы:
1. Оглавление.
2. Сводка по управлению проектом.
3. Формулировка того, что должно быть сделано (цель проекта).
4. Комплект поставки (также часть цели). Они могут иметь ряд заголовков:
¦ Программное обеспечение.
¦ Оборудование.
¦ Документация.
¦ Услуги.
5. Критерий завершения. Как мы узнаем, когда проект закончен? (Ключевая
часть цели.)
6. Критерий приемки. Как наш заказчик решает, что проект завершен? (Также
ключевая часть цели.)
Следующие девять пунктов все являются частью плана и резервного плана:
7. Структура распределения работ (WBS). Список всех задач, которые должны
быть выполнены для завершения проекта, вместе с оценками трудозатрат на
них и любыми сделанными предположениями.
8. Диаграмма Гантта. Показывает WBS во времени и фиксирует любые сделан-
сделанные предположения. Диаграмма Гантта должна также ясно показывать кри-
критический путь проекта.
9. Распределение трудозатрат и рабочего графика по стадиям проекта.
10. Контрольные точки (промежуточные этапы). Список ключевых дат, извле-
извлеченный из диаграммы Гантта.
11. Требуемые ресурсы. Персонал и иные.
12. Распределение ресурсов. Как ресурсы распределены по времени и как рас-
рассчитывалась доступность персонала по времени.

176 Часть 4. Как оценивать планы проектов
13. Бюджет проекта (необязательно). Выводится из трудозатрат в WBS и раздела
по ресурсам.
14. Схема организационной структуры проекта. Среди прочего, она служит для
идентификации руководителя проекта.
15. Резервный план/допуск на ошибки. Иногда его называют анализом рисков.
План проекта представляет собой предсказание того, как события будут разви-
развиваться в будущем в отношении этого проекта. Цель данного раздела в том,
чтобы показать, что автор плана уделил некоторое внимание тому, что он бу-
будет делать, если в действительности случится нечто отличное от плана проекта.

ЧАСТЬ 5
ОСТАЛЬНЫЕ СРЕДСТВА
ГЛАВА 15
РАЗРЕШЕНИЕ ВОПРОСОВ: УСТРАНЕНИЕ
ПРОБЛЕМ И ПРИНЯТИЕ РЕШЕНИЙ
ВВЕДЕНИЕ
В частях 1 и 2 этой книги я представил общий метод ведения проекта. Мы го-
говорили о том, как планировать его, какие вещи делать в течение выполнения пла-
плана и как привести проект к успешному завершению. Представленный метод был
концептуально очень прост и в значительной степени основан на здравом смысле.
Однако жизнь никогда не бывает простой. Бесчисленные вопросы - большие
и маленькие - возникнут в течение жизни вашего проекта. Не будет и дня, когда
не будет проблем, требующих своего решения; каждый день вы будете прини-
принимать решения, которые повлияют на результаты проекта.
Эта часть книги представляет общий метод и набор техник, которые вы мо-
можете использовать для облегчения разрешения этих вопросов, решения проблем
и принятия правильных решений. Со своим здравым смыслом в одной руке
и методом решения проблем в другой вы будете в состоянии справиться с любой
проблемой, которая возникает перед вами.
В настоящей главе я перечислил эти техники решения проблем и, где это бы-
было полезно, дал примеры их использования. Нет правильных или неправильных
ситуаций, для которых должна применяться та или иная методика. Как мы виде-
видели, проекты - это сложные организмы, и любая проблема, скорее всего, будет
комплексной с многочисленными факторами, которые необходимо сбалансиро-
сбалансировать. Для решения данной конкретной проблемы может применяться несколько
из изложенных техник. Только вы можете оценить, какое решение является пра-
правильным для вашего проекта. Если бы эта глава имела подзаголовок, он бы зву-
звучал как "Есть больше одного способа освежевать кота".

178 Часть 5. Остальные средства
МЕТОД РЕШЕНИЯ ПРОБЛЕМ
Общий метод решения проблем, который мы будем использовать, содержит
следующие четыре этапа:
1. В чем проблема?
2. Каково идеальное решение?
3. Определение диапазона решений.
4. Реализация одного или более из найденных решений.
• Теперь рассмотрим способы выполнения каждого из этих этапов.
В чем проблема?
Первая вещь, которую вам надо сделать, это определить, в чем состоит про-
проблема. Иногда вы можете начать пробовать решить проблему прежде, чем вы дей-
действительно поняли ее. Поэтому всегда следует помнить, что может случиться одна
из следующих вещей:
1. Иногда заявленная проблема не является реальной проблемой.
2. Иногда проблема определяется формулировкой ее решения.
3. Иногда, даже если проблема сформулирована правильно, надо отойти назад
и посмотреть на более общую картину событий, чтобы принять решение.
Часто хороший способ идентифицировать проблему состоит в том, чтобы ее
сформулировать. Простая формулировка проблемы - при записи ее на бумаге
или в разговоре - может выкристаллизовать ее, а иногда и подсказать, как дви-
двигаться дальше.
Каково идеальное решение?
Вы никогда не сможете достигнуть его, но знание его неоценимо. Что было
бы наилучшим результатом? Это связано с нашим старинным древнейшим во-
вопросом, что бы вы хотели сделать? Каково идеальное решение? Если бы не было
никаких ограничений или границ, что бы вы сделали? Вы удивитесь, узнав, как
часто находится решение проблемы, не слишком далекое от идеального.
Определение диапазона решений
Следующие пункты предназначены для помощи вам в определении возмож-
возможных решений вашей проблемы или вопроса.
Шахматы
Нам говорят, что шахматисты мирового класса могут видеть игру на много
ходов вперед. Они знают, что, если они сделают некоторый ход, их противник,
вероятно, сделает ход А, тогда они сделают ход В, их противник сделает ход С

Глава 15. Разрешение вопросов: устранение проблем и принятие решении 179
и так далее. Часто вы можете решить что-то, только исследуя ваш возможный
выбор, продумывая вещи и анализируя, что,' вероятно, случится.
Если вы пойдете по одному пути, то вот альтернативы, а в зависимости от то-
того, что произойдет здесь, появятся дальнейшие альтернативы. Я регулярно вы-
вычерчиваю на доске диаграммы, показывающие решение, которое надо принять,
выбор, возникающий в результате решения, и последующие сценарии, которые
стали возможными. Они могут в конце напоминать большое дерево зимой, су-
существует так много ветвей, но это дает вам очень ясную картину того, с чем вы
имеете дело. Два других пункта, на которые надо обратить внимание:
¦ Если один конкретный путь более выгоден для вас, вы можете увидеть его
очень быстро и начать двигать все по этому пути, заставляя прочие пути вы-
выглядеть менее привлекательными для других людей.
¦ Вы можете сэкономить для себя много времени, потому что ходы могут стать
лишними, то есть вне зависимости от того, что случается в результате сле-
следующего решения(й), вы все равно попадете в нужное место.
Игра в баллы1
Баллы отражают ваш рейтинг популярности среди других людей. Каждый
человек, связанный с проектом, дает вам баллы либо сознательно, либо подсоз-
подсознательно. В любое заданное время некоторые оценки будут высокими, а некото-
некоторые - не очень. Игра в баллы гласит, что вы должны разрешать проблему таким
образом, чтобы максимизировать ваш рейтинг у одного или нескольких людей.
Незадолго до начала войны в Персидском заливе Саддам Хуссейн повысил
денежное довольствие всем своим солдатам. Мы не знаем, была ли у него про-
проблема моральной поддержки, но если он решал именно эту проблему, то выбрал
ее решение с помощью игры в баллы.
Люди, выслуживающиеся перед своим начальством, постоянно играют с ним
в игру в баллы. У меня как-то был босс, который сказал мне на моей аттестации,
что он повысил мне зарплату на 10 процентов. "Ни один из твоих коллег не по-
получил такое огромное повышение, - сказал он мне. - Только ты, благодаря своей
работе сверх всяких должностных обязанностей". Как оказалось, по крайней ме-
мере двое из моих коллег также получили повышение на 10 процентов. Мой на-
начальник играл в игру в баллы.
Особенностью игры в баллы является то, что она может часто давать хоро-
хорошие результаты звездного масштаба. Другой особенностью является то, что эти
результаты могут быть очень краткосрочными и в долгосрочном плане иметь
отрицательный эффект.
Здесь подразумеваются баллы, которые начисляют скаутам за добрые дела. - Прим. переводчика.

180 Часть 5. Остальные средства
Мозговой штурм
Мозговой штурм - замечательная методика. Идея состоит в том, чтобы со-
собрать кучку людей вместе, а затем записывать все возможные пути решения
проблемы.
Есть две стадии. На первой стадии все идеи, независимо от того, насколько
они фантастичны, приемлемы. Ничего не исключается. Любая идея, которая,
кажется, решает проблему, добавляется к списку. Обратите внимание, что вы
можете использовать все техники в этом разделе, чтобы получить идеи. На второй
стадии вы просматриваете список и пробуете извлечь лучшую идею или ряд идей.
Не делайте ничего
Когда мы думаем о проектах, мы думаем о бешеном темпе работы, чтобы за-
завершить проект. Что, если бы проблему можно было решить, ничего не делая?
Соблазнительно? Держу пари, что это так. Хотя это может показаться странным,
но я нашел пять вариантов техники ничегонеделания. Это:
1. Буквально не делать ничего. Полагаете ли вы искренне, что проблема уйдет
сама, или только хотели бы этого, не важно; вы решаете не предпринимать
никаких действий.
2. Вернуться позже. Вы решаете не делать ничего и вернуться к проблеме сно-
снова через некоторое время. При этом следующем рассмотрении вы можете
решить принять какие-то меры или, если вещи, кажется, идут тем путем, ко-
которого вы хотели, снова отложить проблему и вернуться к ней позже.
3. Отражатели. Отражатели - это ленты из алюминия, сбрасываемые военны-
военными самолетами, чтобы создать на экране вражеского радара впечатление
большого количества самолетов противника. В нашем контексте это подра-
подразумевает, что вы создаете впечатление выполнения чего-либо по данной про-
проблеме, когда фактически вы не делаете ничего. Например, вы можете иметь
внутреннюю информацию, что проблема, которая причиняет вашей команде
главные неприятности, может быть вот-вот решена. Вы не хотите, чтобы лю-
люди видели вас бездействующим, потому что это еще больше будет нервиро-
нервировать группу, но в то же самое время вы не хотите тратить впустую время на
проблему, потому что вы знаете, что решение уже в пути. Поэтому вы посы-
посылаете сигналы, демонстрирующие вашу активную деятельность по данному
вопросу, в то время как фактически вы не делаете абсолютно ничего. Это -
отражатели.

Глава 15. Разрешение вопросов: устранение проблем и принятие решений 181
4. Обследование (рекогносцировка). Вам надо получить большее количество ин-
информации. Пока вы собираете эту информацию, вы ничего не делаете по самой
проблеме.
5. Каменная стена. Это когда вы решаете не делать ничего и хотите, чтобы об
этом знали. Классический случай - это когда кто-то просит у вас повышения
зарплаты, а вы решили, что он его не получит. Каменная стена в основном
предполагает дачу отрицательного ответа до тех пор, пока он не уйдет!
Таблицы истинности
Таблицы истинности - это техника, позаимствованная из информатики
и очень полезная при анализе проблемы. Вот несколько надуманный пример.
Я хотел бы бросить свою работу и стать экологическим фермером - производить
экологически чистые продукты. Есть ли путь сделать это без существенного па-
падения моего уровня жизни? Проблема здесь состоит из двух факторов (стать эко-
экологическим фермером и не получить падения доходов), однако можно рассматри-
рассматривать любое число факторов; только таблица истинности становится больше. Каж-
Каждый фактор имеет две возможности: или это случается (да, Y), или это не случает-
случается (нет, N). Тогда таблица истинности выглядит следующим образом:
Выбор:
Стать экологическим фермером
Получить падение доходов
1
Y
Y
2
Y
N
3
N
Y
4
N
N
У меня теперь есть четыре варианта.
¦ Вариант 1 означает, что я стал экологическим фермером, но получил сниже-
снижение доходов. Не решает проблемы.
¦ Вариант 2 означает, что я стал экологическим фермером и не получил сниже-
снижения дохода: идеальное решение.
¦ Вариант 3 - это, не став экологическим фермером, получить снижение дохо-
доходов. Это - явно худший сценарий, поскольку отбрасывает меня еще дальше
от моей поставленной цели стать экологическим фермером и не потерять
в доходах.
¦ Вариант 4 показывает, где я сейчас нахожусь: я не экологический фермер,
но мой доход приемлем.
Этот анализ сообщает мне, что в рамках поставленной цели я не достиг ее, но
я и не удалился от нее. Как я сказал, это несколько искусственный пример, но
тем не менее разобраться в нем интересно.

182 Часть 5. Остальные средства
Метод Рональда Рейгана
Иногда в ваших проектах возникает проблема, и вам не очень важно, как она
будет решена, главное, чтобы было принято какое-то решение. Например, воз-
возможно, что пока некоторое решение не будет принято, ваш проект задерживает-
задерживается. Несколько лет назад циркулировали истории о том, что Рональд Рейган при-
принимал все свои решения, крупные или мелкие, следующим образом.
Ему вручался один лист бумаги; проблема была описана кратко, в простых
предложениях, короткими словами. Решение, которое будет принято, формули-
формулировалось внизу и на листе было нарисовано два квадратика, один помеченный
"ДА", а второй - "НЕТ". Подпись под ними гласила: "Пожалуйста, поставьте
одну галочку". Слово "одну" было подчеркнуто.
Я часто использовал этот метод квадратиков на совещаниях. Это полезно в слу-
случаях, когда совещание застревает на данной проблеме, а вы хотите подтолкнуть его.
Сформулируйте решения, которые надо принять, и заставьте людей выбрать.
Постепенный разогрев проблемы
Это очень эффективная методика, и она действительно доказывает правду
пословицы о том, что есть больше одного способа освежевать кота. Большинст-
Большинство рассмотренных до сих пор методов имели одну общую тенденцию: они пы-
пытаются решать проблему здесь и сейчас. Постепенный разогрев решает пробле-
проблему за больший временной интервал.
У вас есть проблема, вы знаете, что это щекотливая проблема, и вы совер-
совершенно уверены, что, если идти напролом, вас пристрелят. Первое, что надо сде-
сделать в этом случае, отложить ее решение. Вы, возможно, говорите: "Я не хочу
говорить об этом сегодня, но я хотел бы вернуться к этому через некоторое вре-
время". Это заставляет другую сторону задуматься. Затем вы сдвигаетесь на шаг
вперед: возможно, вы неформально обсуждаете ее за ленчем или кофе. Далее,
может быть, вы оформляете письменное предложение и смотрите, как оно прой-
пройдет. Этот процесс продолжается до тех пор, пока вы не получаете то, что хотите.
Если на любой стадии вы находите, что проблема не решается тем путем, кото-
который вам нужен, вы притормаживаете, выжидаете, а затем снова постепенно про-
продвигаетесь вперед.
Я использовал этот метод на коротких A-2 недели) и длинных A год) перио-
периодах. Это высокоэффективный метод.

Глава 15. Разрешение вопросов: устранение проблем и принятие решении 183
"Что бы вы сделали на моем месте?"
Если ничто другое не помогает, эта техника дает вам еще один вариант реше-
решения проблемы. Обратите внимание, что это другой путь выяснения, каково иде-
идеальное решение для другого человека.
Поместите себя в положение другого человека
Смотрите на вещи с точки зрения другого человека. Любой хороший прода-
продавец скажет вам, что если вы можете делать это - видеть точку зрения вашего
клиента, его проблемы, заботы, страхи, цель, побуждения, - тогда вы действи-
действительно на пути к успешному заключению сделки.
Обращайтесь с проблемой, как с проектом
Примените структурное руководство проектом!
Деловой обмен
"Я сделаю это, если вы сделаете то". "Вот то, что я сделаю для вас, теперь,
что Вы сделаете для меня? "
Выйти из себя
Часто может привести к катастрофе, но иногда может быть высокоэффектив-
высокоэффективным, особенно если вы подобный мне человек, не часто выходящий из себя. Не-
Несколько раз мне приходилось притворяться, что я выхожу из себя, и я подумы-
подумываю, не выбрать ли карьеру актера!
Заряжающая беседа
Иногда все, что нужно человеку - это немного поднять настроение. Заря-
Заряжающая беседа - это то, что в перерыве между таймами дает тренер команде.
Обычно совершенно очевидно, если кто-то применяет такую зарядку к вам, то,
в зависимости от вашего настроения, этого может быть достаточно. Это очень
упрощенный подход, и вы должны убедиться, что он сработал, потому что, если
нет, вы не решили проблему.
Продажа чего-то неприятного
Для частного случая, когда вам надо продать что-то неприятное ко-
кому-нибудь - неприятное или скучное поручение например, - можно использо-
использовать технику, используемую при продажах. Это идея, состоящая в том, что вы не
предлагаете вашему клиенту выбор, покупать или нет, вы предлагаете ему вы-
выбор способа покупки. Таким образом, вы можете предлагать человеку ряд раз-
различных способов, которыми он может выполнить данное поручение.

184 Часть 5. Остальные средства
Заискивание
Это может оказаться трудно проглотить, но бывают времена, особенно если вы
где-то напортачили, когда извинение - единственный путь. У многих людей есть
проблемы с извинениями перед подчиненными, и извиняться нелегко даже в луч-
лучшие из времен. Иногда, к сожалению, это лучший путь.
На закуску я приберег для вас два совершенно фантастических метода опре-
определения возможных решений. Они очень сложны, опасны тем, что могут обер-
обернуться против вас, но приносят много удовольствия, если вы сможете протащить
их. Вы можете использовать их ради куража, чтобы проверить себя или проде-
продемонстрировать свою силу другим людям - коллегам, персоналу, оппозиции. Не
применяйте их слишком часто, сберегите их как деликатес для себя.
Притворное отступление
Притворное отступление, как можно сообразить, является военным термином.
Классический пример его использования - сражение при Гастингсе (Hastings)
в 1066 г. (Macdonald, 1984). Это - пример того, что Клаузевиц (Clausewitz) A984)
назвал хитростью. Это означает, что вашими действиями вы вводите в заблужде-
заблуждение другую сторону, заставляя ее считать, что вы собираетесь делать нечто отлич-
отличное от того, что вы на самом деле планируете совершить.
Притворное отступление красиво, когда оно срабатывает, как в следующем
примере. (Некоторые из деталей были изменены, чтобы гарантировать аноним-
анонимность, но суть вы поймете).
Я как-то работал в одной компании, и мое подразделение боролось за большой
проект от другой компании. Мы очень сильно хотели тот проект. Эта другая ком-
компания долго суетилась вокруг него - они собирались реализовать его сами, они
собирались заключить субконтракт на него в другом месте. Наше предложение
было совершенно неприемлемо: они не могли поверить, что это потребует так
много времени, как мы сказали, или что на это потребуется так много народу.
Было организовано последнее решающее совещание. Оно началось с той же са-
самой старой песни - им надо иметь это изделие скорее, они легко могут сделать его
сами, не могли бы мы предложить что-нибудь новенькое? Да, сказали мы, парни,
забирайте-ка его себе, мы его не хотим. Мы можем, если хотите, помочь вам, ска-
скажем продать вам немного консалтинга. И мы проделали большую работу, оценивая
этот проект, так что сможем немного помочь вам здесь, поскольку думаем, что не-
некоторые из ваших оценок слегка неверны (они были дико неверными!). Так почему
бы вам, парни, не уйти и обратиться к нам, когда мы сможем помочь. Это все мы
выложили в наиболее цивилизованных тонах. Внутри мы корчились; если мы поте-
потеряем эту работу, у нас будут большие проблемы. Однако мы не показывали вида.
После поспешного совещания они возвратились и предоставили нам контракт.

Глава 15. Разрешение вопросов: устранение проблем и принятие решений 185
Вот другой пример того, что может случиться, когда вы пробуете выполнить
притворное отступление. В военных ситуациях притворное отступление рас-
рассматривается, как очень трудно выполняемый маневр. Это потому, что притвор-
притворное отступление иногда слишком быстро может стать реальным.
Парень, которого я знал - давайте называть его Альбертом, - был важной фи-
фигурой в организации в течение долгого времени. Его начальник был неудачни-
неудачником, и Альберт в значительной степени делал, что хотел. Затем прибыл новый
начальник, и все стало меняться; многое из находящегося во власти Альберта
начало разрушаться его новым начальником. Альберт был очень обозлен и вы-
выбрал следующий курс поведения. Он знал, что он был незаменимым на своем
месте, и в этом он был весьма прав: он был наиболее технически квалифициро-
квалифицированным человеком, и его чрезвычайно трудно было заменить. Он получил дру-
другое предложение работы и затем предпринял попытку притворного отступления
перед своим начальником, которого звали, скажем, Берт.
Зарезервировав новое место работы, Альберт отправился на встречу с на-
начальником. "Мне действительно нравится работать здесь, Берт, и мне нравится
работать с Вами, но меня не устраивают некоторые вещи, и я хотел бы обсудить,
что мы можем делать с этим". Альберт перечислил различные вещи - обязанно-
обязанности, свою позицию по отношению к коллегам, аттестации, заработки. Берт по
большей части стоял как стена, несколько незначительных уступок, но ничего
существенного.
Альберт повторил свою позицию - на сей раз с большим нажимом - говоря
о том, что ему очень многое здесь так нравится, но если его совершенно разум-
разумные требования будут проигнорированы, он будет вынужден уволиться, а он не
хотел бы этого. Берт продолжал стоять стеной. "Хорошо", - сказал Альберт, он
не хотел делать этого, но Берт не оставляет ему выбора.
Альберт объяснил, что он нашел другую работу - намного больше ответст-
ответственности, лучший заработок, больше перспектив — и что он будет вынужден со-
согласиться на нее, если он и Берт не смогут уладить свои разногласия. Берт под-
поднялся, протянул руку через стол и сказал: "Ну, Альберт, поздравляю. Вы знаете,
что мы будем сожалеть о потере, но это звучит как замечательная возможность,
которая действительно продвинет вашу карьеру". Альберт ушел. Он никогда не
хотел этого, и в конечном итоге ему пришлось перебираться с семейством за
3000 миль.
Двойной обхват (клещи)
Двойной обхват включает обход противника с обеих сторон, чтобы окружить
его; слово "клещи" описывает это графически. Снова это военный термин,
и классический пример - битва при Каннах в 216 г. до н. 3.(Macdonald, 1984),

186 Часть 5. Остальные средства
когда Ганнибал победил римскую армию в Италии. Более подходящий пример
из нашего времени это - серия маневров, выполненных союзниками, которые
привели войну в Персидском заливе к завершению.
При применении метода клещей вы задумываете попробовать справиться
с проблемой, найдя ряд решений, а затем применив одновременно два или
большее количество из них. Идея здесь в том, что по крайней мере одна из ва-
ваших атак должна сработать, а если они сработают все, это обеспечит великолеп-
великолепную демонстрацию вашей силы. Обратная сторона медали состоит в том, что
если ни одна из них не срабатывает, вы остаетесь в общем-то голым и безоруж-
безоружным, то есть вы исчерпываете все ваши боезапасы.
Вы можете применить клещи, взяв свой основной и резервный планы и при-
применяя их одновременно. Неприятность при этом состоит в том, что у вас в таком
случае не остается резервного плана. Вы можете прожить всю жизнь и никогда
не использовать клещи и все равно оставаться крайне удачливым в решении
проблем. Я упоминаю здесь клещи главным образом потому, что это большая
забава и хорошее испытание вашего искусства.
Реализация одного или большего количества решений
Вот три метода, помогающих выбирать решение из группы найденных.
Запись"за"и"против"
Возьмите лист бумаги, запишите проблему, запишите действия, которые вы
намереваетесь предпринять. Затем нарисуйте посреди страницы вертикальную
линию и запишите преимущества на одной стороне и недостатки - на другой.
Пари
Целью этой книги не является превращение вас в азартного игрока, но я на-
нашел, что пари является очень полезной техникой, когда имеешь дело с пробле-
проблемами. Можно держать пари на что угодно - возможность выполнения этапа
в срок, успешное завершение проекта, уход из проекта ключевого человека - вы
называете предмет и можете держать на него пари. Обычно лучше всего, если
ставки небольшие (меньше 5 долларов) и на короткий срок - чтобы разрешаться
в течение нескольких недель. Необходимость держать пари делает три вещи:
¦ она заставляет обе стороны очень серьезно думать о любой ситуации и об
учете шансов для той вещи, на которую сделана ставка;
¦ если эта вещь в пределах нашего контроля, это заставляет вас прилагать значи-
значительные усилия, чтобы гарантировать, что она идет так, как нам хочется;
¦ это задает степень уверенности в данной проблеме.

Глава 15. Разрешение вопросов: устранение проблем и принятие решений 187
Сделайте себе подарок
Обещайте себе небольшой подарок, если выбранное решение(я) сработает та-
таким образом, как вы хотели.
И наконец, вот еще несколько эмпирических правил, которые надо также
иметь в виду при решении проблем.
Не наезжайте на других, пока они не наедут на вас
Если один из методов, который вы выделили, чтобы решить проблему, за-
заставляет грубо давить на другого человека, не выбирайте этот метод, если толь-
только он перед этим не давил на вас тем же образом. (Мировые государственные
деятели должны взять себе на заметку.) Таким образом, вопрос остается в циви-
цивилизованных рамках, если только другая сторона не открывает военные действия.
Выберите правильный момент: синхронизация - это все
Один из моих клиентов может быть весьма сварливым, возвращаясь к работе
после выходных. Я никогда не звоню ему в понедельник утром!
Переложите ношу на другие плечи
Какой бы способ решения проблемы вы ни выбирали, хорошо, если вы найдете
решение, в котором данная проблема уже не ваша проблема. Это то, что называ-
называется переложить ношу на другие плечи. При прочих равных условиях метод, ко-
который снимает с вас ответственность, - это метод, который стоит выбрать.
Если один метод не работает, попробуйте другой
Любая проблема может быть решена. Если вы обнаружили, что это ружье не
стреляет, попробуйте другое.
Утро вечера мудренее
Предположим, вы собираетесь кого-то увольнять или устроить крупное раз-
разбирательство с кем-то, или сделать что-нибудь такое, что может привести вас
к большим неприятностям. Вне зависимости от конкретики, если это имеет
серьезные отрицательные последствия, обдумайте это, пока едете домой. Засни-
Засните с этим. Затем утром, если вы все еще считаете, что лучше ничего не придума-
придумаешь, сделайте это.
Не позволяйте проблемам преследовать вас
Не позволяйте проблемам преследовать вас. Во что бы то ни стало ждите
и выберите правильный момент, но не затягивайте и не позволяйте вещам выхо-
выходить из-под контроля. Шансы только ухудшатся. Решайте проблему столь быст-
быстро, сколь это практично.

ГЛАВА 16
СНЯТИЕ НАПРЯЖЕНИЯ
ВВЕДЕНИЕ
Стресс, или напряжение, наступает, когда вы не контролируете ситуацию,
когда внешние события ведут вас, вместо того чтобы вы управляли событиями.
Пока большая часть этой книги была посвящена попыткам зафиксировать
ситуацию, когда вы управляете; когда неопределенность и догадки, окружаю-
окружающие ваш проект, сводятся к минимуму и когда вы знаете, что в любой заданный
момент времени вы сделали все, что могло быть сделано. В главе 15 мы рас-
рассмотрели пути преодоления проблем и трудностей, которые могли бы вызывать
у вас стресс. Все методы, представленные в этой главе, должны обеспечить су-
существенное сокращение уровней ваших стрессов.
Однако даже храбрейший из нас склонен к беспокойству, переживаниям,
стрессам, и эта глава говорит также о некоторых других вещах, которые вы мо-
можете сделать. Вообще говоря, эти вещи не будут ликвидировать причины стрес-
стрессов - последнее остается за другими частями этой книги. Методы в этой главе
помогут вам изменить ваше отношение к конкретной проблеме и, надеюсь,
уменьшить ваше беспокойство о ней. Вот - цитата, чтобы задать тон этой главе.
Вы можете размышлять о ваших проблемах или вы можете переживать за них, и есть ог-
огромное различие между этими двумя понятиями. Переживание - это размышление, пре-
превратившееся в яд. Это - раздражающая мелодия, которая повторяется снова и снова
и никогда не приходит к кульминации или завершению. Размышление прокладывает
путь через проблемы к заключениям и решениям; переживание оставляет вас в состоя-
состоянии напряженного оживления. Когда вы переживаете, вы бесконечно движетесь по од-
одной и той же территории и выходите в том же месте, с которого вы начали. Размышле-
Размышление заставляет вас продвигаться из одного места в другое; переживание оставляет ста-
статичным. Задача жизни состоит в замене переживания на размышление, а беспокойства
на созидательную деятельность.
Гарольд Б. Уолкер
(Harold В. Walker)
С этой идеей в заднем кармане в данной главе рассматривается двенадцать
способов снижения стрессов и управления ими.

Глава 16. Снятие напряжения 189
СПОСОБЫ СНИЖЕНИЯ НАПРЯЖЕНИЯ
У кого мяч?
Если вы зациклились на проекте, надо определить вещь, которая вызывает
напряжение. После ее нахождения есть только два варианта: либо вы можете
что-то сделать, либо нет. Если можете, тогда мяч у вас и вы бежите с ним. Обра-
Обратите внимание, что это может включать запуск другого проекта.
Если вы ничего не можете сделать с проблемой - а это подразумевает, что вы
испробовали все методы решения проблем, изложенные в главе 15, - если вы
действительно не можете сделать ничего, значит, мяч у кого-то другого. Опре-
Определив, кто это, причем заметьте, что это может быть Судьба (или Бог, если вам
угодно), и если вы все еще не видите, что можно сделать, чтобы повлиять на ре-
результат, то нет ничего, что вы можете сделать. И под "ничего" я имею в виду
ни-че-го. Главное, не переживайте. Найдите событие(я), которое заставит мяч
возвратиться к вам. Ждите, пока оно не настанет, поскольку рано или поздно это
произойдет, и тогда вы вновь сделаете рывок с мячом.
Сохраняйте чувство соразмерности, или Всегда есть кто-то,
кому хуже, чем вам1
Прежде чем я закончу эту главу, в мире умрут тысячи невинных людей. Они
умрут от голода, болезней, пыток, казней, пренебрежения, насилия, одиночест-
одиночества. Важно сохранять чувство соразмерности. Вообще говоря, если вы не вовле-
вовлечены в определенные типы проектов, например военные, медицинские, вы почти
наверняка не будете заниматься вещами, угрожающими жизни.
Многие из вещей, с которыми вы сталкиваетесь в ваших проектах, ничего не
добавляют к куче бобов (как сказал Хэмфри Богарт (Humphrey Bogart)) в кон-
контексте некоторых реальных проблем в этом мире. В следующий раз вы почувст-
почувствуете себя подавленным, покупая газету и читая мировые новости. С другой
стороны, вы можете обратиться (как было обещано) к Винни Пуху. Снова наш
друг Иа-Иа в беседе с Кристофером Робином.
Привет, Иа, - сказал Кристофер Робин, открывая дверь и выходя наружу. -
Как ты? - Все еще идет снег, - сказал Иа уныло.
- Это точно.
- И подмораживает'.
См. отечественный рекламный слоган: "А кому сейчас легко!" - Прим. переводчика.

190 Часть 5. Остальные средства
- Неужели?
- Да, - сказал Иа. - Однако, - сказал он, немного просветлев, - у нас еще нет
землетрясения.
Попытайтесь смотреть на это как на игру
Если вы подавлены, это означает, что вы чувствуете угрозу для чего-то, что
вы считаете для себя дорогим.
Это может быть ваша жизнь, работа, брак, карьера, репутация, дом, семья.
Один способ поведения состоит в том, чтобы попробовать рассматривать это как
игру. Предположим, что ставки были не столь высоки. Предположим, что это
была только игра и через пару часов она закончится и возвратится реальность.
Теперь, с этой другой точки зрения, получаете ли вы какие-то новые перспекти-
перспективы для движения вперед?
Физические упражнения
Я об этом еще не думал. Врачи рекомендуют физические упражнения, осо-
особенно связанные с вентиляцией легких - плавание, езду на велосипеде, бег,
греблю и так далее, - очень ритмичные упражнения, как средство для снятия
напряжения. Йога и любой вид медитации также очень хороши.
Загляните на год вперед
Возьмите вещь, которая вас угнетает, и представьте, как она будет выглядеть
через неделю, месяц, год от данного момента. Будет ли она выглядеть столь же
важной? Вы думаете, что вы действительно будете в состоянии помнить об
этом? Представьте себе некоторое время в будущем и посмотрите, как выглядит
картина.
Достигнут ли нижний предел?
В математике берут точку на кривой и сравнивают ее с близко лежащей точ-
точкой той же кривой. Так можно определять, является ли кривая возрастающей
или убывающей. (Я обычно спотыкаюсь на объяснении математики всего этого!)
Вы можете использовать эту идею, анализируя каждый прошедший день и опре-
определяя, улучшается ли ваша ситуация или нет.
Сравните ситуацию сегодня и вчера. Если даже ситуация кажется лучше на
бесконечно малую величину, то, возможно, она достигла твердого дна и теперь
начнет улучшаться. Этот метод особенно хорош для долгов! А если кривая идет
неправильно, попробуйте другой метод.

Глава 16. Снятие напряжения 191
Закройте ворота к вашему дому
У моей усадьбы есть ворота и короткая аллея к ним. Часто, когда я прихожу
домой вечером и закрываю ворота, я чувствую, что я закрываюсь от проблем
внешнего мира. Завтра, когда я пройду через ворота, проблемы все еще будут
там, но сегодня вечером я жив, у меня есть семья. У меня есть небольшой оазис
в пустыне. Завтра существует, но оно в будущем, где-то там, далеко. Тем време-
временем я могу наслаждаться тем, что у меня есть.
Марафонец
Я бегал на марафонские дистанции. Так как мысль о беге на 26 миль слишком
возмутительна, есть одна идея пробега марафона, состоящая в том, что вы забывае-
забываете о том, как велика дистанция, и просто сосредотачиваетесь на следующем дереве
или доме, или телеграфном столбе. Несомненно, остаток дистанции все равно надо
пробежать, однако, сосредоточившись на очень близком горизонте и блокируя все
прочее в будущем, вы можете чрезвычайно уменьшить давление на себя.
Запишите, в чем проблема
Несколько похоже на формулирование вопроса в главе 18. Запишите пробле-
проблему, изучите ее и посмотрите, не будет ли сам этот процесс лечением и не даст ли
он вам новый взгляд на вещи.
Мир закрыт на выходные
Многие из учреждений, которые вызывают у нас стресс - конторы, прави-
правительство - закрываются на выходные. Во многих странах почтовые отправления,
которые могли бы принести дополнительный стресс, перестают доставляться
где-то в полдень пятницы. Это означает, что у вас есть отсрочка в целых два дня
с кусочком, прежде чем вам придется вновь ввязываться в драку.
Поговорите с кем-нибудь
Как гласит старая пословица, "поделиться проблемой значит поделить ее по-
пополам".
Ведите дневник
Некий писатель - хоть убейте, я не могу вспомнить кто, даже ссылку найти
(если кто-то может помочь, буду очень благодарен), - сказал: "Я пишу, чтобы
видеть то, что я думаю" (или что-то в этом роде). Пишите или, более конкретно,
ведите дневник, чтобы видеть то, что вы думаете. Используйте его для анализа,
комментария, понимания, поиска путей. Возможно, такой дневник вам поможет.

ГЛАВА 17
ВЫБОР ПРАВИЛЬНЫХЛЮДЕЙ
ВВЕДЕНИЕ
Для многих проектов вам надо будет подбирать людей, и вопрос, который мы
обсуждаем здесь, состоит в том, как выбрать правильно. Эта книга говорит
о приобретении проектно-ориентированного стиля работы. Некоторые люди де-
делают это инстинктивно. Я полагаю, что большую часть остальных можно нау-
научить этому без особых усилий. На самом деле именно этого и добивается данная
книга от читателя. В этой главе я буду говорить о собеседовании, но вы должны
думать об этом с точки зрения поиска людей для вашего проекта в противопо-
противоположность простому найму людей на работу.
МЕТОД СОБЕСЕДОВАНИЯ
На моей последней постоянной работе я был генеральным директором аме-
американского многонационального Европейского центра развития и поддержки
программирования. Там мы использовали двухэтапный подход в собеседованиях
с людьми. На первой стадии я производил предварительный отбор всех резюме
и проводил предварительные беседы. (Учитывая, что нас было более 60 человек
и что мы были очень разборчивы при подборе персонала, вы можете видеть, что
это составляло огромное количество бесед с соискателями в течение года. Это
имело смысл потому, что я был лидером проекта и мне нужно было иметь ре-
решающее мнение о тех, кто будет работать в моем проекте.)
Все компании говорят, что люди являются наиболее важным их ресурсом, но
сколько же их видит процесс найма и проблемы, связанные с людьми, как дело
отдела кадров или отдела людских ресурсов? Люди определяют, как мы сделаем
наши проекты. Именно поэтому они наш наиболее важный ресурс.
Беседы были обычно короткими (полчаса), и в них на самом деле задавалось
только три вопроса:
¦ Что вы сделали?
¦ Что вы хотите делать?
¦ Что вам нравится?

Глава 1 7. Выбор правильных людей 193
В результате того что все предварительное отсеивание выполнял один и тот
же человек, после некоторого периода времени такой процесс отбора гарантиро-
гарантировал получение определенного типа или типов людей, попадающих на второе со-
собеседование. Правда, это может привести и к отсеву правильных людей. Но
с другой стороны, если вы нашли тип или типы, которые работают на вас, зачем
что-то менять?
На втором собеседовании, которое могло длиться 3 или 4 часа, соискателю
надо было встречаться с как можно большим числом людей из команды: колле-
коллегами, подчиненными, менеджерами. Мы поощряли соискателя походить и по-
пообщаться с людьми, особенно с работниками, делающими работу, аналогичную
его будущей работе. Соискатель делал это без всякой цензуры, то есть он мог
заговорить с любым попавшимся ему сотрудником, а последний мог отвечать
ему все что взбредет в голову. Не было никаких репетиций или линии партии.
Мы утвердили такую точку зрения, что нам нечего скрывать, что люди должны
увидеть нас без прикрас. Мы хотели, чтобы люди почувствовали, как будет вы-
выглядеть работа в нашей команде, и именно поэтому интервью продолжалось столь
долго, и кандидат видел так много людей: это было минимальное расстояние,
с которого он мог разглядеть нас, прежде чем принять решение о работе здесь.
ВОПРОСЫ СОБЕСЕДОВАНИЯ
Вот как подходить к получению ответов на три наших основных вопроса.
Что вы сделали?
Именно на этом этапе вы выясняете, какой опыт и квалификация есть у чело-
человека. Для любой высокотехнологичной области существуют определенные про-
профессиональные умения и навыки, которые важны. Мы ищем людей, которые
описывают свою карьеру в терминах этапов или достижений и, собственно, яв-
являются проектно-ориентированными людьми. Типичные вопросы здесь:
¦ Каков величайший момент в вашей жизни?
¦ Расскажите мне о трех вещах, которые вам больше всего нравилось делать
в вашей жизни.
¦ Что было вашей самой большой неудачей?
На что надо обратить внимание:
7 - 2224

194 Часть 5. Остальные средства
¦ Резкие ответы - человек отвечает вам, дает то, что вы спрашивали, и замол-
замолкает. Несвязные ответы меня очень настораживают, поскольку они, как мне
кажется, указывают на суетливый или неорганизованный тип мышления.
¦ Чувство, что человек преодолел трудности, чтобы сделать свою работу.
Что вы хотите делать?
Ключевой вопрос. Мы уже говорили об использовании личных целей человека
в интересах выполнения нашего проекта. Если человек не знает, что он хочет, то я
почти никогда не возьму его. Если он не знает, что хочет, то как вы можете ис-
использовать его в вашем проекте - это ведь может оказаться не тем, что ему надо?
Понятно, что я не задаю вопрос в лоб, и, если человек не отвечает, выбрасы-
выбрасываю его за дверь. Я готов к исследованию и провожу его при необходимости са-
самым тщательнейшим образом. Однако в конце дня вам все равно надо извлечь
из кандидата правильную информацию. Невероятно, но иногда это может быть
первый раз, когда они поняли, что они хотят делать. Мы задаем вопросы типа:
¦ Что вы определенно не хотите?
¦ Если бы вы могли выбирать абсолютно любую работу, что бы это было?
¦ Вас устраивает, как идет ваша карьера?
¦ Что вами движет?
¦ Вы считаете себя человеком, ориентирующимся на задачу или ориентирую-
ориентирующимся на людей?
¦ Что вы делаете на досуге?
¦ Что мог бы сказать о вас кто-то другой - прежний начальник, ваша подруга?
Почти не имеет значения, кто это будет, однако, если человек спотыкается на
этом вопросе, вы должны получить ответ.
¦ Насколько сильно вы хотите работать?
Вам надо знать, каков будет этот человек, когда он появится в вашей коман-
команде. Вы знаете то, что вы хотите сделать с вашим проектом и какую роль вы хо-
хотите поручить этому человеку. Вопрос состоит в том, что сам этот товарищ хо-
хочет делать?

Глава 17. Выбор правильных людей 195
Что вы любите?
Наконец, вы должны получить представление об индивидуальности человека.
Вы чувствуете, что он будет соответствовать общему духу вашей группы?
¦ Опишите вашу личность.
¦ Вы тот тип человека, для которого, если я прошу сделать какую-то работу, то
могу расценивать ее как сделанную?
¦ Какие у вас сильные и слабые стороны?
¦ Расскажите о себе что-нибудь отрицательное.
¦ Что вы любите читать?

ГЛАВА 18
ПЕРЕГОВОРЫ
ВВЕДЕНИЕ
Каждому из нас, во всех аспектах нашей жизни, приходится вести переговоры.
Мы делаем это по поводу повышения оклада, когда мы покупаем вещи, в нашей
личной жизни, как часть нашей работы; и мы видим то же в международных де-
делах, где ставки временами могут быть пугающе высокими. Мы знакомы с тем,
что происходит на переговорах: мы излагаем позицию, другая сторона свою,
а затем обе стороны спорят, пока не будет достигнут компромисс.
Есть замечательная небольшая книга под названием "Getting to Yes" ("Приход
к Да") (Fisher and Ury, 1981), основанная на работе, сделанной в Гарварде. Эта
короткая книга представляет метод, называемый принципиальными переговора-
переговорами или переговорами о достоинствах. Этот метод имеет в качестве цели выра-
выработку мудрого соглашения. Мудрое соглашение определяется как "то, которое
в максимально возможной степени учитывает законные интересы каждой сторо-
стороны, справедливо разрешает конфликтующие интересы, является долговечным
и принимает в расчет интересы общества".
ПРИНЦИПИАЛЬНЫЕ ПЕРЕГОВОРЫ
Метод принципиальных переговоров имеет четыре стадии:
1. Отделить людей от проблемы.
2. Сосредоточиться на интересах, а не на позициях.
3. Выработать разнообразие возможностей, прежде чем решать, что делать.
4. Настоять, чтобы результат основывался на некотором объективном стандарте.
Давайте рассмотрим их поочередно.
Отделить людей от проблемы
Часто переговоры могут заканчиваться личными стычками между участни-
участниками, в которых сильные эмоции и индивидуальности людей заслоняют реаль-
реальные проблемы. Принципиальные переговоры рекомендуют нам распутать узел
людей и проблем и двигаться от конфронтационной ситуации до такой, в кото-

Глава 1 8. Переговоры 197
рой участники работают вместе, борясь с проблемой, а не друг с другом. Неко-
Некоторые из методов, изложенные в главе 15, могут быть полезны и здесь, особенно
следующие:
¦ В чем, собственно, состоит проблема?
¦ Сформулировать проблему.
¦ Таблицы истинности.
¦ Каково идеальное решение (очень полезно)?
¦ "Что бы вы сделали на моем месте?".
¦ Поставить себя в положение другого человека.
¦ Обращаться как с проектом. Применить этап 1 из структурного руководства
проектом - наглядно представить цель; сосредоточиться на призе.
Сосредоточиться на интересах, а не на позициях
Чаще всего мы занимаем переговорные позиции, основанные на ряде факто-
факторов (интересов), которые важны для нас. В обычных переговорах такая позиция
может быстро привести к упущению из вида интересов. Принципиальные пере-
переговоры рекомендуют сосредотачиваться на интересах, а не на позициях. И снова
здесь могут помочь техники, перечисленные выше.
Выработать разнообразие возможностей, прежде чем
решать, что делать
Другими словами, мозговой штурм.
Настаивать, чтобы результат основывался на некотором
объективном стандарте
В обычных переговорах результаты часто достигаются сдачей позиции одной
стороны или бескомпромиссностью другой. Другой путь состоит в том, чтобы
заранее согласовать объективный стандарт или набор критериев, в соответствии
с которыми будет оцениваться результат. Как только это сделано, никому не на-
надо сдаваться - обе стороны могут использовать стандарт как определяющую
точку отсчета. Примеры объективных стандартов - рыночная стоимость, преце-
прецедент, равноправие или мнение эксперта.
В этой главе я пытаюсь создать у вас общее представление о методе принци-
принципиальных переговоров. Подобно многим другим вещам в этой книге он тоже
исходит из обычного здравого смысла. Вместо беспорядочных препирательств

198 Часть 5. Остальные средства
по какому-либо вопросу мы говорим: "Смотрите, у нас есть вот эта проблема,
как мы можем решить ее к нашему взаимному удовлетворению?" Это путь, ко-
который, как мы инстинктивно знаем:
¦ более эффективен,
¦ чаще будет успешным,
¦ чаще будет вырабатывать лучшее решение,
¦ гораздо более симпатичен,
чем традиционные переговоры. Прочтение книги "Getting to Yes" (Fisher and Ury,
1981) не займет у вас много времени, ее объем - приблизительно половина этой
книги. Я настойчиво советую вам достать экземпляр.

ГЛАВА 19
СОВЕЩАНИЯ
ВВЕДЕНИЕ
Совещания могут быть невероятно полезной вещью в проекте. На хорошо ор-
организованном совещании вы можете пробиться через препятствия, разрешить
проблемы и принять решения и закончить с чувством, что вы действительно про-
продвинули проект и что, заплатив вам зарплату за этот день, ваш наниматель не зря
потратил свои деньги. Сколько из нас, однако, участвуют в совещаниях, которые:
¦ плавают вокруг да около;
¦ по-видимому, не имеют никакой цели;
¦ не имеют повестки дня, так что вы понятия не имеете, продвинетесь ли вы
куда-нибудь, сидя здесь, или лучше было не приходить сюда вообще;
¦ похоже, не имеют к вам никакого отношения.
Эта глава содержит быстрый способ выяснить, будет ли совещание, на кото-
которое вас приглашают, одним из таких совещаний, и некоторые подсказки на
предмет того, как надо проводить совещания, чтобы они были столь же эффек-
эффективными, как описано в первом абзаце.
ТРЕВОЖНЫЕ СИГНАЛЫ В СОВЕЩАНИИ
Если кто-то приглашает вас на совещание, вы должны выяснить:
¦ Какова цель?
¦ Какая требуется подготовка?
¦ Почему вы должны идти? (Первые два вопроса должны сделать это ясным.
Если вам придется задавать себе этот вопрос, это само по себе признак опас-
опасности.)
¦ Как долго оно будет длиться?
¦ Кто ведет совещание?
Если вы не можете получить прямые, ясные ответы на эти вопросы, тогда я
полагаю, что совещание, скорее всего, будет пустой тратой времени и вам стоит

200 Часть 5. Остальные средства
отказаться от него. (Ясно, что вам придется решить, не требует ли внутренняя
политика, чтобы вы пришли на данное совещание в любом случае!)
ОРГАНИЗАЦИЯ И ВЕДЕНИЕ СОВЕЩАНИЙ
Вот девять шагов к улучшению качества совещаний.
1. Определите цель(и) совещания.
2. Определите участников, в которых вы нуждаетесь, и председателя1.
3. Исходя из A) и B), разработайте повестку дня.
4. Установите временной регламент на каждый пункт повестки дня и на сове-
совещание в целом.
5. Раздайте материалы с указанием цели(ей), повесткой дня, регламентом вре-
времени и укажите каждому участнику, какая требуется подготовка.
6. Проведите совещание.
7. Председатель ведет совещание к цели(ям).
8. Подготовьте список действий, вытекающих из обсуждения на совещании.
9. Закройте совещание, когда цель(и) будет достигнута и повестка дня исчерпана.
Т. е. лицо, ведущее совещание. В отечественной практике это не всегда так. - Прим. переводчика.

ГЛАВА 20
ПРЕЗЕНТАЦИИ
ВВЕДЕНИЕ
Ваши проекты будут неизменно требовать, чтобы вы проводили презентации
для вашего клиента, команды проекта, ваших коллег и руководства.
Некоторые люди рождены для проведения презентаций, их можно назвать
почти актерами. Мы все видели их. Они являются абсолютными авторитетами
в своем предмете. Они становятся остроумными, драматическими, слегка не-
неформальными, раскованными, честными, внимательными, беззаветно верящими
в то, что они говорят. Они рассказывают свою историю в острой, эффективной
манере, которая никогда не утомляет, а наоборот, захватывает и удерживает наш
интерес. Они постоянно заглядывают в глаза слушателей и часто используют
аудиовизуальные средства и реквизит.
Другие менее убедительны. Возможно, они самодовольны, имеют покрови-
покровительственный тон, чрезмерно агрессивны, слишком многословны и затягивают
свой рассказ, действуют слишком заученно, скучны, слишком небрежны, нече-
нечестны или просто не уверены в своем предмете. Есть люди, которые считают пре-
презентации наиболее ужасающими из испытаний, которые можно вообразить; ино-
иногда это становится очевидным в ту минуту, когда они встают и открывают рот.
В цели этой главы не входит обучение искусству презентации, т. е. как пода-
подавать ваш материал. Сегодня существует достаточное количество компаний, ко-
которые занимаются такими вещами и могут дать ценный совет относительно то-
того, как улучшить вашу эффективность в общении с аудиторией.
Цель здесь состоит в том, чтобы рассмотреть, как лучше всего структуриро-
структурировать ваш материал (который мы представляем) для презентации. Любой, незави-
независимо от того, хороший он или плохой оратор, может сделать то, что мы реко-
рекомендуем здесь; и описанный подход компенсирует недостатки многих доклад-
докладчиков. Все, что выше этого - удел пиаровских компаний, превращающих всех
нас в Лоуренсов Оливье. Вероятно, наилучшим заветом для всех проводящих
презентации являются следующие пункты:
¦ расскажите им то, что вы собирались рассказать,
¦ рассказывайте им,
¦ рассказывайте им, что вы рассказали.

202 Часть 5. Остальные средства
В то время как трудно совершенствоваться в этом для самой презентации,
есть много вещей, которые можно сделать посредством предварительной подго-
подготовки. Вот некоторые руководящие принципы, которые я использую:
¦ Выделите главные тезисы, которые вы хотите донести до аудитории. Их
должно быть немного, и они должны быть кристально ясны. Вы также долж-
должны понимать, является ли вашей задачей просто объяснить и описать нечто
или необходимо убедить вашу аудиторию в чем-то.
¦ Неприятность с кристально ясными тезисами состоит в том, что они также
грубы и прямолинейны. Вы можете немного смягчить их, прикрывая, как
я это называю, оттенками. Под последним я подразумеваю добавление не-
некоторых красок в черно-белые тезисы, чтобы они выглядели счастливы-
счастливыми/грустными, оптимистическими/пессимистическими, началом чего-то
большого/предвестником беды, угрожающими/доброжелательными, безза-
беззаботными/серьезными, с пустячными проблемами/с большими проблемами
или любыми другими из миллиона разных оттенков. Прямолинейные тезисы
и есть прямолинейные тезисы. Оттенки означают, что вы учитываете настрое-
настроение вашей аудитории и доносите свои тезисы с максимальным эффектом.
¦ Если у вас есть некоторые материалы для раздачи, структурируйте их вокруг
тезисов и их оттенков.
¦ Отрепетируйте ваш доклад с человеком или людьми не из предполагаемой
аудитории. Изложите тезисы и оттенки, которые вы пробуете донести, и по-
посмотрите, достигает ли ваша презентация эффекта. Сделайте это несколько
раз, если необходимо.
¦ Определите возможные вопросы, как полагаясь на собственную интуицию,
так и с помощью репетиции, и подготовьте ответы, которые подкрепляют
ваши тезисы и оттенки.
¦ Вопросы могут часто уводить вас туда, куда вы не собирались идти, и такой
уход в сторону может заставить вас случайно выдать тезисы и оттенки, кото-
которые не предназначались для презентации. Пробуйте определить эти потенци-
потенциальные отходы в сторону на репетиции и выработайте, как использовать их,
чтобы подкрепить ваши тезисы и оттенки.
¦ Проводите презентацию, руководствуясь приведенным выше заветом:
- изложите план вашей презентации;
- ведите презентацию, постоянно обращаясь к плану, так, чтобы аудитория
могла следовать за вами; и сообщите ваши тезисы вместе с их оттенками;
- резюмируйте тезисы и оттенки, которые вы сообщили.

ГЛАВА 21
СОКРАЩЕНИЕ СРОКОВ ПРОЕКТОВ С ПОМОЩЬЮ
УСКОРЕННОГО АНАЛИЗА И РАЗРАБОТКИ
ВВЕДЕНИЕ
В 1970-х годах наблюдался большой интерес к идее, согласно которой боль-
большее количество времени, потраченное на выработку требований и разработку,
должно дать:
¦ меньшее время, потраченное на кодирование (программирование) и тестирова-
тестирование;
¦ меньшее количество ошибок;
¦ продукт, лучший во всех отношениях.
В то же самое время начали появляться инструментальные средства, которые
автоматизировали некоторые части процесса программирования и тестирования.
Таким образом, казалось, что мы имеем лучший из миров - вкладывайте время
и трудозатраты в приятную часть работы (требования и разработка) и автомати-
автоматизируйте, насколько возможно, работу, поглощающую много времени и трудоза-
трудозатрат. Результатом всего этого стала нынешняя расхожая мудрость, что невоз-
невозможно сократить время стадий выработки требований и проектирования проекта
без серьезного ухудшения качества конечного продукта.
Я полагаю, что эта мудрость фундаментально неверна; и остальная часть дан-
данной главы показывает путь значительного ускорения выполнения проекта и, по-
помимо прочего, улучшения качества продукта. Следующий раздел рассказывает
о том, что действительно поглощает уйму времени на стадиях выработки требова-
требований и разработки в проекте. Идущий за ним раздел описывает, как проводить сес-
сессию ускоренного анализа и разработки (УАР) (Accelerated Analysis and Design -
AAD). Четвертый раздел говорит о вовлеченных рисках и как работать с ними.
Пятый раздел говорит о некоторых практических соображениях, связанных с про-
проведением УАР.
НА ЧТО ТРАТИТСЯ ВРЕМЯ?
Стадии выработки требований и проектирования несколько напоминают
адюльтер. Они обычно состоят из приступов интенсивной деятельности, переме-
перемежающихся периодами с весьма низким уровнем активности. Это не интенсивная

204 Часть 5. Остальные средства
деятельность определяет столь большую длительность традиционных стадий вы-
выработки требований и разработки. На самом деле ее обуславливают вещи вроде
следующих:
¦ Большие объемы документации, которую надо создать; большая часть этих
объемов обусловлена технологическим циклом "написание - рецензирова-
рецензирование - переработка документа", принятым в традиционных подходах к стади-
стадиям выработки требований и разработки.
¦ Потеря непрерывности из-за традиционного подхода "положить в ящик ис-
исполнителя - взять из ящика исполнителя".
¦ Задержки в получении ответов и/или решений.
¦ Иногда падает боевой дух команды, что является либо причиной несколько
несфокусированных усилий, либо их результатом.
¦ Трудность в получении нужных людей в нужное время.
¦ Прерывания.
¦ Люди, имеющие другие обязанности ("Эй, мне надо делать мою собственную
работу!").
¦ Большие периоды времени между рецензированием, механической выверкой
[документов] или совещаниями означает, что некоторые вещи подолгу идут
неправильно, прежде чем это обнаруживается.
¦ Естественные непроизводительные издержки в традиционных методах и струк-
структурах руководства проектом.
¦ Совещания (и трудности координирования ежедневных графиков работников).
¦ Процедуры получения (решений, документов), поданных на рассмотрение
и одобрение.
¦ Переделки и уточнения (документов, идей и т. д.).
КАК ВЫПОЛНЯТЬ УАР
УАР подходит к этим проблемам следующим образом. Устраивается одно-
двухнедельная встреча - сессия УАР. В идеале ее надо проводить вне фирмы. На
встречу приглашаются все лица, принимающие решения в проекте, будь то
пользователи и сотрудники информационных служб и подразделений информа-
информационных технологий в случае внутренней разработки на фирме или разработчи-

Глава 21. Сокращение сроков проектов с помошью ускоренного анализа и разработки 205
ки и маркетологи в случае разработки коммерческого продукта. Присутствовать
должны все люди, которым есть что сказать.
До процесса УАР полезно провести своего рода мини-семинар, целью кото-
которого является определение ожиданий как команды УАР, так и высшего руковод-
руководства. Этот семинар должен объяснить, что представляет собой процесс [УАР]
и каких результатов можно от него ожидать. После проведения мини-семинара
каждый из членов команды УАР должен подготовиться к сессии. Каждый уча-
участник должен независимо записать:
¦ название системы/изделия, которое необходимо построить/разработать,
¦ описание в одно предложение того, что система/изделие будет делать,
¦ три-четыре преимущества системы/изделия или же три-четыре проблемы,
которые оно решит.
Помимо участников (а между прочим, восемь - это практически максималь-
максимальное число участников, которое полезно иметь на УАР) требуются еще два чело-
человека. Сеанс УАР нуждается в лидере, а также требуется тот, кого мы называем
техническим секретарем. Лидер работает с "восьми и допоздна"; технический
секретарь работает, начиная после обеда и допоздна. Вот что они делают.
В первый день лидер начинает сессию УАР с группой. Секретарь может быть
или не быть там, это, вообще говоря, не имеет значения. Группа начинает соби-
собирать главные требования для системы или продукта. Обычно это делается на
доске, на пластиковых лекционных планшетах или (если ваш бюджет позволяет)
на фотокопировальном планшете - одном из наиболее замечательных изобрете-
изобретений, известных человеку. После выработки главных требований они последова-
последовательно детализируются, и этот процесс продолжается до тех пор, пока не будет
достигнут требуемый уровень детализации.
Я предполагаю здесь, что вы выполняете ваши требования и проекты в доку-
документах на английском языке, поскольку это обычно минимальный общий при-
признак для всех организаций по разработке программного обеспечения. Таким об-
образом, в процессе УАР вы просто берете оглавление или шаблон документа тех-
технических требований или разработки и заполняете пустые места. Если вы уже
ушли от этого и используете одну из структурированных методологий или
CASE1-технологии, то УАР даже более эффективен при использовании с этими
подходами.
1 CASE - computer-aided software engineering - автоматизированное проектирование и создание
программ. - Прим. переводчика.

206 Часть 5. Остальные средства
Продолжим с нашим УАР. Технический секретарь показывается после обеда.
Как правило, это человек уровня старшего разработчика. Сеанс УАР кончается,
скажем, в 5 часов пополудни, и секретарь с лидером группы собирают все мате-
материалы, накопленные за день, и записывают все, что было выработано в техниче-
технических требованиях. Этот документ затем оказывается на рабочем столе каждого
члена группы, когда они приходят на следующее утро.
Процесс начинается снова, при этом новый документ используется как от-
отправная точка. Обычно можно надеяться на получение 95 % требований к концу
второго дня, однако может потребоваться и намного более длинный срок. Сес-
Сессии УАР полностью управляются временем, так что вы планируете делать
столько, сколько вы можете в отведенное время, в противоположность фиксиро-
фиксированному количеству работы, которую надо сделать, и переменному количеству
времени на ее выполнение.
Дни продолжают идти таким же образом, с обновлением документации каждый
вечер и с использованием ее в качестве отправной точки на следующее утро. Ре-
Результаты варьируются, однако в конце двухнедельной сессии УАР можно ожидать
получения спецификаций технических требований, правильных почти на 100 %
(только незначительные пункты детализации могут вызывать сомнения, если вооб-
вообще вызовут), и некоторой части разработки системы/продукта на месте.
РИСКИ ПРИ ПРОВЕДЕНИИ УАР
В этом разделе мы поговорим о рисках, существующих при проведении УАР,
и что можно, если можно, сделать, чтобы минимизировать их. Ниже перечисля-
перечисляются риски, а затем указываются возможные действия по их минимизации.
¦ Вы получили не тех людей. Скажем, для примера, на сессии будет отсутство-
отсутствовать старший из принимающих решения. Вероятно, это наиболее серьезная
вещь, которая может случиться. Если это действительно произошло, вы
должны прекратить сессию УАР немедленно. Тщательная подготовка должна
уменьшить риск получения такой ситуации.
¦ Группа думает коллективно. Это происходит, когда группа становится на-
настолько вовлеченной в УАР, что идеи, которые не очень хороши или даже со-
совершенно неправильны, принимаются и используются. Старайтесь выбрать
участников, чьи индивидуальности таковы, что это, скорее всего, не произойдет.
¦ Испортятся ранее хорошие отношения с пользователями или маркетологами,
если УАР не даст нужного результата. Решения нет!

Глава 21. Сокращение сроков проектов с помошью ускоренного анализа и разработки 207
¦ Риск для собственной карьеры, если У АР не даст нужного результата. Реше-
Решения нет! Удачи!
¦ В УАР недостаточно времени для срабатывания интуиции. Иногда нам лучше
всего работается вне офиса, и в таких случаях мы часто приходим к высоко-
высокоэффективным творческим решениям. УАР действительно не предоставляет
нам эту роскошь. Этот риск компенсируется до некоторой степени синерге-
тическим эффектом УАР.
¦ Ожидания не удовлетворены, особенно ожидания верхнего звена управления.
Ясно, что эти ожидания должны были быть правильно установлены. Это тот
случай, когда очень полезна идея мини-семинара.
¦ Подразделения стандартизации, гарантии качества или по контролю качества
смотрят на процедуру с подозрением и тормозят ее, упорно утверждая, что
весь их материал по стандартам должен быть сделан в дополнение к резуль-
результатам УАР.
¦ Некоторые стандарты (например, утверждения документов) существуют в силу
предположения традиционных циклов жизни требований и разработки. Можно
сказать, многие из них основаны на подходе "положить в ящик исполнителя -
взять из ящика исполнителя". Для УАР-подхода стандарты, вероятно, следует
пересмотреть и изменить, чтобы они отражали методику работы УАР.
¦ Корпоративная или национальная культура. Часы работы и/или эмоциональ-
эмоциональная интенсивность, сопутствующие УАР, могут оказаться подходящими не
для каждой компании. Решения нет!
¦ После проведения части сессии УАР обнаруживается, что проект слишком
велик, и поэтому ожидаемые результаты не могут быть достигнуты за отве-
отведенное время. Произведите меньший объем поставки или возьмите одну
часть системы и доведите ее до обещанного уровня детализации.
¦ Не достигается консенсус. Проблема. Лучше ставить на то, что этот эффект
можно нейтрализовать чувством людей, работающих вместе на общую цель.
¦ В УАР нет времени для тактичности. Да, его нет!
¦ Спад/расслабленность после завершения УАР. Создайте список работ на пе-
период, следующий за сессией УАР, таким образом, чтобы он был ее естест-
естественным продолжением.
¦ Требования не выработаны. Да, но этот риск также существует и при тради-
традиционном подходе.

208 Часть 5. Остальные средства
ПРАКТИЧЕСКИЕ СООБРАЖЕНИЯ
В этом разделе говорится о некоторых практических соображениях, исполь-
используемых при проведении УАР. Они объединены в два подраздела со следующими
заголовками:
¦ Кто должен участвовать.
¦ Что вам потребуется.
Кто должен участвовать
Лидер: должен быть не из проекта, а лучше из другой организации.
До четырех аналитиков/разработчиков: они должны быть из отделения инфор-
информационного обслуживания/информационных технологий или из компании по
разработке программного обеспечения, в зависимости от потребности.
До четырех клиентов: вообще можно было бы ожидать большее их количество,
чем аналитиков/проектировщиков. Для разработки информационной систе-
системы/продукта в идеале они должны представлять различные уровни потенциаль-
потенциальных пользователей от эксплуатационного персонала до управленцев. Для разра-
разработки коммерческого продукта, вероятно, имела бы смысл смесь маркетинга,
сбыта и потенциальных клиентов.
Руководитель проекта: если он уже не включен в группу аналитиков/проекти-
аналитиков/проектировщиков или клиентов.
Технический секретарь: человек с хорошим знанием анализа и разработки. Он
также должен быть способен использовать текстовый процессор!
В чем вы будете нуждаться
Помещение
¦ В идеале вне офиса.
¦ Окна - действительно важно.
¦ Стены, чтобы втыкать кнопки или прилеплять что-либо.
¦ 24-часовая доступность.
¦ Никаких телефонов.
¦ Большие столы для работы.

Глава 21. Сокращение сроков проектов с помошью ускоренного анализа и разработки 209
¦ Удобные стулья.
¦ Перекусы. Вероятно, лучше подальше от рабочего места, легкие закуски и
никакого вина.
Оборудование
¦ Белая или черная доски. Фотокопирующий планшет в идеале.
¦ Два - три пластиковых лекционных планшета, множество фломастеров.
¦ Диапроектор и экран.
¦ Фотокопировальное устройство.
¦ Персональный компьютер.
¦ Лазерный принтер.
¦ Текстовый процессор.
¦ Электронные таблицы.
¦ Компьютерные средства планирования проекта.
¦ Программное обеспечение для создания слайдов/диапозитивов для просмотра
через проектор.
¦ Факс (при необходимости).
Разное
¦ Степлер.
¦ Маркеры.
¦ Скрепки.
¦ Ножницы.
¦ Дырокол.
¦ Отрывные блокноты и ручки/карандаши.
¦ Диапозитивная пленка.

ПОСЛЕСЛОВИЕ
ДЕЛЕГИРОВАНИЕ (ИЛИ РЕАЛЬНАЯ РАДОСТЬ
УПРАВЛЕНИЯ)
Мы только однажды проходим через этот мир и ограничены в том, что мы
можем сделать, в доступные нам часы бодрствования. Мы, как менеджеры про-
проектов, находимся в уникальном и привилегированном положении: мы можем
использовать время других людей, чтобы выполнить то, что мы хотим, и таким
образом, всемерно увеличиваем количество доступного нам времени, а в конеч-
конечном результате целей, которых мы можем достигнуть.
Подумайте об этом. От каждого человека из нашей команды мы имеем время
этого человека, чтобы использовать его в наших целях. Это как возможность
увеличить продолжительность свой жизни или прожить ее много раз. Мы смо-
сможем правильно и эффективно использовать эту силу, только если мы делегируем
свои полномочия, передавая столько материала, сколько можем, нашим членам
команды.
¦ Используйте руководящие принципы, изложенные в главе 17, чтобы окру-
окружить себя правильными людьми.
¦ Делегируйте им столько материала, сколько можете, следуя руководящим
принципам, изложенным в главе 7.
Делайте это тогда, когда вы можете доверять это людям. Если вы будете де-
делать обе эти вещи, вы обнаружите, что ваши дни содержат достаточно времени,
которое вы можете использовать для всех тех новых вещей, которыми вам все-
всегда хотелось заняться. Тогда, и только тогда, вы будете испытывать реальную
радость руководства.

ПРИЛОЖЕНИЯ
ПРИЛОЖЕНИЕ 1
ПРОЦЕДУРА ОЦЕНКИ ISO 9000
ВВЕДЕНИЕ
Этот документ описывает процедуру оценки, основанную на этапах 1-5 из
"десяти этапов", которая может использоваться всем персоналом, а не только
менеджерами проектов, для получения оценок. Эта процедура может входить
в ряд процедур управления проектами, которые, в свою очередь, могли бы войти
в руководство по управлению качеством организации - разработчика программ-
программного обеспечения. Процедура состоит из семи разделов.
Раздел 1 показывает, как создать структуру распределения работ (WBS) и ис-
использовать ее для получения оценки трудозатрат. Это - сторона "спроса" урав-
уравнения проекта.
Раздел 2 показывает, как вычислить сторону "предложения", то есть наличие
ресурсов.
Раздел 3 показывает, как согласовать спрос и предложение, описывая, таким
образом, модель того, как проект мог бы разворачиваться.
Раздел 4 показывает, как встроить в план учет непредвиденных обстоя-
обстоятельств.
Раздел 5 показывает, как использовать эту модель, чтобы идентифицировать
варианты и принимать разумные решения о том, что может и что не может быть
достигнуто.
Раздел б показывает, что делать, после того как выбран предпочтительный
вариант.
Раздел 7 содержит образец WBS.

212 Ф. О'Коннэл. Как успешно руководить проектами
СТРУКТУРА РАСПРЕДЕЛЕНИЯ РАБОТ, ТРУДОЗАТРАТЫ,
ЗАВИСИМОСТИ ЗАДАЧ
Создание WBS для проекта
Это, в сущности, структурированный список всех работ (задач), которые
должны быть выполнены, чтобы завершить проект. Список должен иметь фор-
формат "раскладываемой карты", то есть:
¦ Демонстрировать все наиболее важные промежуточные этапы (контрольные
точки) - вы можете получить их непосредственно из этапа 1 в следующем
разделе.
¦ Отображать максимально возможное количество деталей (то есть до уровня
детализации человек-день) для наступающей стадии (фазы) проекта.
¦ Быть детализованным, насколько это возможно, для последующих стадий.
Делайте WBS исчерпывающе детализированной, используя все доступные
источники информации для получения любых заслуживающих внимания под-
подробностей.
Чтобы помочь вам сделать это, в разделе 7 настоящего приложения приво-
приводится образец WBS. Эта WBS соответствует жизненному циклу проекта по раз-
разработке программного обеспечения общего назначения. WBS представлена та-
таким образом, чтобы вы могли добавлять в нее ваши собственные элементы жиз-
жизненного цикла и элементы контрольного списка WBS, получаемые с течением
времени на основании вашего собственного опыта.
Шаги, которые необходимо предпринять...
1. Записать все задачи в вашем проекте и для каждой задачи выделить:
- от каких задач данная задача зависит;
- какие задачи зависят от нее.
2. Представить этот список в нисходящем порядке, при этом он должен иметь:
- четко определенные точки начала и конца;
- обзорное представление задач верхнего уровня, то есть те ответственные
задачи (в пределах дюжины), которые должны быть обязательно выполне-
выполнены, чтобы завершить проект;
- контрольные точки (промежуточные этапы), связанные с этими задачами;

Приложение 1. Процедура опенки ISO 9000 213
- разбиение этих задач всюду, где это возможно, до максимального уровня
детализации (то есть до уровня человек-день);
- в течение следующих четырех-шести недель только задачи длиной не бо-
более пяти человеко-дней.
Вы можете сделать это любыми подручными средствами для записи в бу-
бумажном виде, или же - что гораздо лучше - с помощью компьютерных
средств планирования проектов.
3. Спрогнозируйте и документируйте трудозатраты (также иногда называемые
объемами работ) для каждой задачи. Обратите внимание, что мы хотим полу-
получить здесь именно трудозатраты, а не общее затраченное время. Это и не ко-
количество времени, называемое продолжительностью, которое так любят
отображать компьютерные средства планирования проекта. Для каждого
элемента запишите основание вашего прогноза, например, в документе
12 разделов, отводим 1 час на раздел, отсюда 1,5 человеко-дня; или: "Обычно
столько это занимает у меня" и т. д. Если доступны какие-либо данные из
предыдущих проектов, используйте их.
Если вы чувствуете, что вы просто не можете спрогнозировать некоторые ра-
работы, поскольку они неясны или неизвестны, попробуйте сначала разбить их
на более мелкие.
Когда вы в конце концов почувствуете, что не можете двигаться дальше в этом
процессе, а о некоторых задачах все еще слишком мало известно, какими они
будут, сделайте и задокументируйте предположения о них. В конце концов,
привлеките людей, которые смогут выполнить оценку подобных задач. В таких
случаях привлекайте любого, кто, по вашему мнению, может иметь более или
менее надежные данные.
Введите прогнозы трудозатрат для каждой задачи в списке. Документируйте,
как был получен каждый прогноз. Обратите внимание, что это включает до-
документирование всех сделанных вами предположений.
При получении оценок для отдельного работника должен использоваться
нормальный рабочий день индивидуума: не надо пользоваться какими-либо
показателями производительности. Если неизвестно, кто будет выполнять
определенную задачу, следует использовать коэффициент производительно-
производительности в 20 %. Таким образом, задача на 10 человеко-дней фактически превра-
превращается в задачу на 12 человеко-дней.

214 Ф. О'Коннэл. Как успешно руководить проектами
4. Сложите трудозатраты для всех задач. Это дает общие трудозатраты в проек-
проекте. Применение нормативов оплаты дает также бюджет проекта, если он вам
нужен. Это - сторона "спроса" для вашего проекта. Все это должно быть за-
зарегистрировано в плане проекта.
НАЛИЧИЕ РЕСУРСОВ
План укомплектования персоналом
Выработайте план укомплектования персоналом, показывающий:
¦ требуемые типы работников;
¦ количество работников каждого требуемого типа;
¦ когда какие работники потребуются.
Расчет трудовых ресурсов, требуемых в проекте
Как правило, кроме вашего проекта члены вашей команды будут тратить свое
время во множестве других областей:
¦ Известные другие проекты, в которых они участвуют.
¦ С трудом отслеживаемые обязанности по поддержке/обслуживанию /качеству/другим
заявкам, которые занимают определенный отрезок времени каждую неделю.
¦ Ежегодный отпуск, праздничные дни.
¦ Непредсказуемые вещи, которые невозможно предусмотреть. По этой статье
проходит отпуск по болезни.
Три первых пункта поддаются количественной оценке, а о последнем пункте
можно сделать некоторое предположение, так что он тоже будет иметь количе-
количественную оценку.
Шаги, которые необходимо предпринять...
1. Проработать для каждого человека, какая часть его времени (измеряемая
в днях в неделю, часах в день или в любых других единицах, которые вас
устраивают) будет потрачена на эту деятельность и отсюда как много време-
времени (измеренного в тех же самых единицах) доступно для вашего проекта.
2. Задокументируйте доступность каждого человека в вашем плане проекта и в ва-
вашем компьютеризованном средстве планирования проекта, если вы его ис-
используете.

Приложение 1. Процедура оиенки ISO 9000 215
МОДЕЛЬ ПРОЕКТА
Используйте WBS и наличие трудовых ресурсов
для построения модели проекта
Шаги, которые необходимо предпринять...
Теперь свяжите людей с задачами. Везде, где это возможно, попытайтесь
сделать так, чтобы для какой-либо конкретной задачи существовал только один
ресурс. Обеспечьте, насколько это возможно, чтобы против каждой задачи стоя-
стояло имя конкретного человека - в противоположность названию организации или
сокращениям типа "TBD" или "ANO", стоящим против нее.
¦ Обеспечьте, насколько возможно, использование в точности всего времени,
доступного для каждого человека в проекте, - не больше и не меньше.
¦ Если вы применяете компьютерную программу планирования, используйте
ее, чтобы закрепить задачи за людьми. Программа затем нарисует диаграмму
Гантта для вашего проекта. Среди дюжин, если не сотен полезных вещей,
программа покажет его критический путь.
¦ Если вы это не сделаете, вам придется рисовать диаграмму Гантта самому
вручную. Если вы уже делаете это, предупреждаю, ручной подход почти все-
всегда дает ошибки. Диаграмма Гантта - модель того, как ваш проект может
разворачиваться во времени.
УЧЕТ НЕПРЕДВИДЕННЫХ ОБСТОЯТЕЛЬСТВ
Используйте "первый закон руководства проектом",
чтобы заложить допуск на ошибки
Вы построили модель вашего проекта, или на вашем ПК, или на бумаге, и эта
модель говорит вам о вашей вере в то, как будет двигаться ваш проект после то-
того, как он "встанет на рельсы".
На этом месте вам может показаться, что вы знаете такие вещи, как дата
окончания, требуемое число людей, бюджет и так далее. На самом деле это не
так. Модель, которую вы создали - это всего лишь модель. Это - прогноз того,
что может произойти в будущем.
Прежде чем вы начнете брать на себя обязательства, основываясь на этой мо-
модели, необходимо задать себе один жизненно важный вопрос: "Что я буду де-
делать, если модель неправильна - что я буду делать, если она не сработает так,
как я думал?"

216 Ф. О'Коннэл. Как успешно руководить проектами
Допуск на ошибки можно получить, рассматривая четыре параметра, на ко-
которых основывается "первый закон руководства проектом".
На всякий случай еще раз напомним их:
¦ Функциональность - что должно быть поставлено.
¦ Дата поставки - когда это должно быть поставлено.
¦ Трудозатраты - количество работы, требуемое для поставки.
¦ Качество - качество того, что поставлено.
"Первый закон руководства проектом" гласит, что есть функция, которая свя-
связывает эти четыре переменные, и что эта функция является константой, то есть
Функция (функциональность, дата поставки, трудозатраты, качество) = const
Таким образом, если одна из этих переменных изменяется, другие изменяют-
изменяются таким образом, что значение всего выражения не изменяется.
Мы знакомы с этим эффектом. Сократите дату поставки, например, и а) при-
придется уменьшить функциональность, б) придется увеличить трудозатраты или в)
придется пожертвовать качеством.
Шаги, которые необходимо предпринять...
1. Чтобы определить допуск на ошибки и запасной вариант работы, исследуйте
ваш проект, используя эти четыре параметра как основу. Вы можете исследо-
исследовать ваш проект на трех различных уровнях, причем каждый последующий
требует от вас все больших трудозатрат. Этими уровнями являются:
- общий (то есть рассмотрение всего проекта как одной большой задачи),
- задачи критического пути,
- все задачи.
На каждом уровне вы исследуете соответствующую задачу(и) и задаете себе
следующие вопросы:
- Что случится, если задача не будет выполнена в планируемые сроки? (затра-
(затраченное время)?
- Можно ли сократить сроки для этой задачи? (затраченное время).
- Что случится, если задача окажется большей, чем оценили? (трудозатраты)
- Каков будет эффект от добавления большего количества людей? (трудоза-
(трудозатраты).

Приложение 1. Процедура оценки ISO 9000 217
- В этой задаче выполняется то, что критично для проекта? Если нет, нельзя
ли ее перенести на более поздний срок? (функциональность).
- Что случится, если эта задача будет сделана некачественно? (качество).
На основании этих ответов вы должны изменить оценки трудозатрат и/или
времени выполнения для некоторых или всех работ.
2. В качестве альтернативы вы можете добавлять к выведенной ранее цифре,
скажем, 15 % для закладки непредвиденных обстоятельств. Добавьте это зна-
значение ко всем оценкам трудозатрат, и это автоматически отразится в сдвиге
крайних сроков и дат поставки.
ИДЕНТИФИКАЦИЯ ВАРИАНТОВ
Идентифицируйте ряд различных путей, которыми можно
реализовать проект
В этом пункте весьма вероятно, что дата завершения и/или требуемые ресур-
ресурсы и функциональность, которые достижимы в соответствии с вашей моделью
проекта, не соответствуют тем, которые требуют руководство или заказчики.
Если это так, то вы можете использовать модель, чтобы выяснить, что дости-
достижимо, а что нет.
1. Идентифицируйте набор вариантов, используя те же четыре параметра, упо-
упомянутые в разделе 4:
- что должно быть поставлено (функциональность),
- когда это должно быть поставлено (дата поставки),
- количество работ, требуемое для поставки (трудозатраты),
- качество того, что поставлено (качество).
Анализ модели даст ответы на вопросы, подобные следующим:
- Можно ли сократить сроки для этой задачи? (затраченное время).
- Каков будет эффект от добавления большего количества людей? (трудоза-
(трудозатраты).
- В этой задаче выполняется то, что критично для проекта? Если нет, нельзя
ли ее перенести на более поздний срок? (функциональность).
- Что случится, если эта задача будет сделана некачественно? (качество).

218 Ф. О'Коннэл. Как успешно руководить проектами
- Делающие возможным творческий подход и получение вариантов наилуч-
наилучшего продвижения проекта.
2. И снова компьютерная модель вашего проекта позволяет очень быстро сде-
сделать анализ типа "что если", описанный выше. На основании того, что вы об-
обнаружите, задокументируйте различные варианты вашей модели проекта.
Аналогичным образом, если вы делаете это вручную, измените вашу доку-
документацию для выработки различных вариантов.
РАБОТА С ВЫБРАННЫМ ВАРИАНТОМ
Введение
Процесс достижения предпочтительного варианта должен быть документиро-
документирован и формально одобрен. Как только это сделано, следует выполнить ряд про-
простых процедур. Цель их состоит в том, чтобы обеспечить использование модели
проекта в качестве "инструмента", с помощью которого будет вестись проект.
Зафиксируйте выбранный вариант модели проекта
В целом это означает создание моментального снимка вашей модели проекта.
Тогда происходящее в действительности будет записываться против этого сним-
снимка, так, что можно будет определять, насколько точна модель, и далее можно
будет произвести более точную настройку в тех местах, где это потребуется.
Все компьютеризованные средства обеспечивают такую возможность. В про-
противном случае вы можете просто организовать свой план следующим образом:
¦ две колонки для оценочных значений графика и трудозатрат - они будут за-
заполнены сразу,
¦ две колонки для фактических значений графика и трудозатрат - они будут
заполняться по мере выполнения проекта.
Выделите главные контрольные точки
(промежуточные этапы)
Главные контрольные точки могут быть извлечены из модели проекта и явно
описаны в плане проекта. Они будут служить в качестве:
¦ полезных промежуточных целей, которые должны быть достигнуты;
¦ ранней системы предупреждения, если контрольные точки не достигаются.

Приложение 1. Процедура оценки ISO 9000 219
ОБРАЗЕЦ WBS
1. Стадия выработки требований к продукту
1.1. Создание документа требований к продукту
¦ Исследование.
¦ Создание документа.
¦ Рассылка.
¦ Индивидуальные отзывы (рецензии).
¦ Совещание по результатам рецензирования.
¦ Обновления/изменения документа.
¦ Повторная рассылка.
¦ Повторное рецензирование.
¦ Утверждение.
1.2. Завершение этапа выработки требований к продукту
2. Стадия выработки требований к программному
обеспечению
2.1. Создание документа требований к ПО
¦ Исследование.
¦ Создание документа.
¦ Рассылка.
¦ Индивидуальные отзывы (рецензии).
¦ Совещание по результатам рецензирования.
¦ Обновления/изменения документа.
¦ Повторная рассылка.
¦ Повторное рецензирование.
¦ Утверждение.
2.2. План теста приемки программного обеспечения
¦ Исследование.
¦ Создание документа.
¦ Рассылка.

220 Ф. О'Коннэл. Как успешно руководить проектами
¦ Индивидуальные отзывы (рецензии).
¦ Совещание по результатам рецензирования.
¦ Обновления/изменения документа.
¦ Повторная рассылка.
¦ Повторное рецензирование.
¦ Утверждение.
2.3. Завершение этапа выработки требований к программному обеспечению
3. Стадия проектирования архитектуры
3.1. Создание документа по архитектуре системы
¦ Исследование.
¦ Создание документа.
¦ Рассылка.
¦ Индивидуальные отзывы (рецензии).
¦ Совещание по результатам рецензирования.
¦ Обновления/изменения документа.
¦ Повторная рассылка.
¦ Повторное рецензирование.
¦ Утверждение.
3.2. План тестирования продукта в целом
¦ Исследование.
¦ Создание документа.
¦ Рассылка.
¦ Индивидуальные отзывы (рецензии).
¦ Совещание по результатам рецензирования.
¦ Обновления/изменения документа.
¦ Повторная рассылка.
¦ Повторное рецензирование.
¦ Утверждение.

Приложение 1. Процедура оиенки ISO 9000 221
3.3. Завершение этапа проектирования архитектуры
4. Стадия разработки деталей
4.1. Создание документа по разработке деталей
¦ Исследование.
¦ Создание документа.
¦ Рассылка.
¦ Индивидуальные отзывы (рецензии).
¦ Совещание по результатам рецензирования.
¦ Обновления/изменения документа.
¦ Повторная рассылка.
¦ Повторное рецензирование.
¦ Утверждение.
4.2. План тестирования программных модулей
¦ Исследование.
¦ Создание документа.
¦ Рассылка.
¦ Индивидуальные отзывы (рецензии).
¦ Совещание по результатам рецензирования.
¦ Обновления/изменения документа.
¦ Повторная рассылка.
¦ Повторное рецензирование.
¦ Утверждение.
4.3. Завершение этапа разработки деталей
Примечания
1. В течение первых четырех стадий цикл (рассылка, индивидуальное рецензиро-
рецензирование, совещание по результатам рецензирования, обновления/изменения до-
документа) может повторяться более одного раза. Вы должны задать в своих рас-
расчетах, сколько повторений этого цикла предполагается.

222 Ф. О'Коинэл. Как успешно руководить проектами
2. Исследования могут быть существенной частью проекта со своими собствен-
собственными этапами, требующими дальнейшей детализации.
5. Стадия программирования (кодирования)
5.1. Создание программного компонента
¦ Написание программного компонента.
¦ Чистовая компиляция программного компонента.
¦ Компоновка программного компонента.
¦ Прогон программного компонента:
- подготовка к прогону,
- выполнение прогона,
- обновления/изменения программного компонента,
- утверждение прогона.
¦ Документирование программного компонента.
5.2. Завершение этапа программирования
6. Стадия тестирования модулей
6.1. Программирование тестов модулей
¦ Подготовка плана тестирования и набора тестов.
¦ Тестирование модуля.
¦ Внесение исправлений в программу.
¦ Повторное тестирование модуля.
¦ Подготовка документа по результатам тестирования модуля.
6.2. Завершение стадии тестирования
Примечание
Цикл (тестирование программы, внесение исправлений) может повторяться
более одного раза. Вы должны задать в своих расчетах, сколько повторений это-
этого цикла предполагается.

Приложение 1. Процедура оценки ISO 9000 223
7. Стадия тестирования продукта в целом
7.1. Тестирование программного обеспечения в целом
¦ Любая остающаяся подготовка плана тестирования и набора тестов, не охва-
охваченная планом тестирования системы в целом.
¦ Тестирование ПО.
¦ Внесение исправлений в ПО.
¦ Повторное тестирование ПО.
¦ Подготовка документа по результатам тестирования ПО в целом.
7.2. Завершение стадии тестирования ПО в целом
Примечания
1. Цикл (тестирование программы, внесение исправлений) может повторяться
более одного раза. Вы должны задать в своих расчетах, сколько повторений
этого цикла предполагается.
2. Как "Тестирование ПО", так и задача "Внесение исправлений в ПО" могут
быть существенными частями проекта со своими собственными этапами,
требующими дальнейшей детализации.
8. Стадия тестирования системы
8.1. Выполнение плана тестирования для внутренней приемки программ-
программного обеспечения
8.2. Завершение стадии тестирования системы
9. Стадия выпуска
9.1. Установка
¦ Планы
¦ Действия
¦ Тестирование
¦ Запись результатов.
9.2. Преобразование данных
¦ Планы.
¦ Действия.

224 Ф. О'Коннэл. Как успешно руководить проектами
¦ Тестирование.
¦ Запись результатов.
9.3. Анализ
9.4. Выпуск программного обеспечения
9.5. Завершение стадии выпуска
10. Стадия запуска в эксплуатацию и сопровождения
10.1. Оценка
10.2. Рецензирование разработки
10.3. Поддержка и сопровождение
10.4. Независимая экспертиза
10.5. Завершение стадии запуска в эксплуатацию и сопровождения
11. Другие возможные элементы WBS в жизненном цикле
11.1. Обучение
¦ Ознакомление персонала проекта.
¦ Обучение персонала проекта.
¦ Обучение пользователей.
11.2. Набор персонала
11.3. Разработка тестовой среды
Накладные расходы.
11.4. Техническая поддержка разработки
¦ Администрирование баз данных.
¦ Среда разработки.
¦ Построение системы.
11.5. Руководство проектом
См. главу 4 для полного распределения задач. Выделите 6-8 процентов от
полного объема работ по проекту, как описано в главе 4.

Приложение 1. Процедура оценки ISO 9000 225
11.6. Управление конфигурациями
¦ Анализ.
¦ Текущее управление конфигурациями.
11.7. Документация
¦ Отзывы (рецензии).
¦ Пользовательская (различные типы).
¦ Администратора.
¦ Дополнительная информация по выпуску.
¦ Технические руководства, то есть руководства, описывающие, как работает
программное обеспечение.
¦ Тексты, справки.
¦ Накладные расходы при работе со штатом разработчиков программного
обеспечения.
11.8. Управление качеством/планирование качества
8-2224

ПРИЛОЖЕНИЕ 2
СТРУКТУРНОЕ РУКОВОДСТВО ПРОЕКТОМ
("ДЕСЯТЬ ЭТАПОВ") И ДРУГИЕ МЕТОДИКИ
ВВЕДЕНИЕ
Если вы в своем руководстве проектами не применяете никакой методики,
если все, что вы используете - ваша природная хитрость и навыки выживания,
то через какое-то время, вполне возможно, вы обнаружите, что делаете некото-
некоторые из вещей, обеспечивающих успех проектов. (Я говорю, что это возможно,
потому что этого может и не случиться. Много людей - особенно в области про-
программирования - проживают целую жизнь руководителями проектов и никогда
не усваивают, что работало и что не работало для них в прошлом. В результате,
когда они начинают новый проект, то никогда не знают, действительно ли пре-
преуспеют. Они проводят свою жизнь в постоянной неопределенности, тревогах
и волнениях. Иногда проекты удаются, иногда - нет.)
Если вы перейдете от этой первой ситуации к использованию некоторой ме-
методики, то, вероятно, заметите улучшение ситуации. Надеюсь, эта методика
подвигнет вас делать некоторые из вещей, обеспечивающих успех проектов.
Однако, в конечном счете, только применяя "десять этапов", вы будете делать
все то, что делает проекты успешными. "Десять этапов" - "наилучший" путь ве-
ведения проекта. Таким образом, "десять этапов" могут служить в качестве этало-
эталона, с которыми можно сравнивать другие подходы.
Я упоминаю все это, чтобы объяснить, как методики вписываются в схему
работы. Методики заставляют вас выполнять некоторые из вещей, которые де-
делают проекты успешными. Хорошая методика может заставить вас сделать мно-
многие из них. Из тех методик, которые я знаю, ни одна не гарантирует успех на все
100 процентов. "Десять этапов" делают это исключительно потому, что они бы-
были получены из наблюдений за тем, что делает другие проекты успешными.
Если вы уже используете некую методику, было бы полезно и интересно сде-
сделать сравнение вашей методики с "десятью этапами". Возьмите каждый из эле-
элементов вашей методики и посмотрите, имеет ли этот элемент аналог в "десяти
этапах". Например, ваша методология может описывать некий способ делать
оценки. Десять Этапов также описывают способ оценивания (он в главе 2). Если

Приложение 2. Структурное руководство проектом и другие методики 227
вы проделаете это для всех элементов вашей методики, то для каждого из них
возникают три возможности:
¦ он есть и в вашей методике, и в "десяти этапах";
¦ он есть в вашей методике, но отсутствует в "десяти этапах";
¦ это есть в "десяти этапах", но отсутствует в вашей методике.
Он есть и в вашей методике, и в "десяти этапах"
Это идеальная ситуация. Этот конкретный элемент существенен для плани-
планирования и выполнения ваших проектов.
Он есть в вашей методике, но отсутствует в "десяти этапах"
Я могу поспорить, что вы не нуждаетесь в этом элементе. Это - оформление
витрины. Ваши проекты могут обойтись и без него.
Это есть в "десяти этапах", но отсутствует в вашей
методике
Это брешь в вашей методике. Судя по моему опыту, некоторые из моментов,
которые обычно здесь возникают, что происходит почти всегда, это:
¦ эта методика не останавливает вас от взятия на себя невыполнимых обяза-
обязательств;
¦ эта методика не требует от вас закладывания в план непредвиденных обстоя-
обстоятельств;
¦ эта методика не проясняет, как вы должны управлять субподрядчиками или
внешними поставщиками.
Вы можете ознакомиться с полным примером сравнения "десяти этапов" и ти-
типичной методики в книге O'Connell A999).

ПРИЛОЖЕНИЕ 3
ИНДИКАТОР ВЕРОЯТНОСТИ УСПЕХА
ВВЕДЕНИЕ
Мы описывали текущее состояние индикатора вероятности успеха (PSI) и наши
изыскания по нему в главах 1-10. Хотя в выставлении баллов все еще много субъ-
субъективности, наше доверие к нему значительно укрепилось после трехлетнего ис-
использования в нашей работе.
Первая работа по PSI была описана в главе 20 первого издания этой книги.
Для тех, кому интересно проследить его эволюцию, я привожу этот материал
в данном приложении.
ВЫЧИСЛЕНИЕ PSI ПРОЕКТА
PSI - число, лежащее в диапазоне 0-100, которое присваивается проектам
с помощью схемы подсчета, приведенной в следующем разделе. PSI может быть
рассчитан в любой точке жизни проекта и определяет вероятность того, что про-
проект завершится успешно. PSI может быть рассчитан различными способами. От-
Отдельный человек (например, организатор проекта или внешний консультант)
может произвести оценку проекта и вычислить PSI, применяя приведенные ни-
ниже правила. Альтернативно можно опросить ряд лиц, участвующих в проекте
(руководитель проекта, члены группы, управленческое звено, заказчики), для
получения их мнений (скажем, используя анкетный опрос), а затем усреднить
полученные результаты.
Кто вычисляет PSI, кто дает исходные данные и как эти исходные данные со-
собираются - анкетным опросом, в беседах, подсчетом поднятых рук(!) - это все
факторы, которые могут рассматриваться, если вы собираетесь использовать
PSI. Здесь я выбрал самый быстрый и самый простой путь, то есть один человек
(я!) проводит анализ данного проекта.
КАК ВЫЧИСЛЯТЬ PSI
PSI рассчитывается путем присвоения баллов каждому из "десяти этапов",
привязанных к определенному проекту. Максимально возможное количество
баллов для каждого этапа:

Приложение 3. Индикатор вероятности успеха 229
ЭТАП
МАКСИМАЛЬНЫЙ
итого
БАЛЛ
1
20
2
20
3
10
4
10
5
10
70
б
10
7
10
8
10
9
0
10
0
30
Общая сумма:
100
Между прочим, обратите внимание, как критична стадия планирования.
Я твердо убежден, что успех или неудача проектов определяются в первые 10 %
времени их жизни. Ладно, вернемся к PSI. Далее мы изложим, как определять
каждый балл.
1. Цель{20}
Запишите:
¦ Описание проекта в одно предложение [8].
¦ Три или четыре пункта о том, что составляет завершенный проект [6].
¦ Две-три страницы в рекламном стиле, которые пытаются ответить на вопро-
вопросы из вопросника по наглядному представлению цели (см. стр. 11) [6].
Сделав это, подсчитайте балл, используя числа в квадратных скобках.
2.Список задач{20}
¦ Список задач не устарел? [4]
¦ Он полон? Он, по крайней мере, покрывает все пункты в контрольном списке
на стр. 19? [4]
¦ Все контрольные точки (промежуточные этапы) обозначены и хорошо опре-
определены? [6]
¦ Список исчерпывающе детализирован до первой контрольной точки (проме-
(промежуточного этапа)? [6]
Подсчитайте балл, используя числа в квадратных скобках.
3. Один руководитель {10}
Вопросы, подобные следующим, помогут вам выкурить его из норы:
¦ Назовите руководителя проекта.
¦ Есть ли человек с "огнем в груди" для завершения проекта1?
¦ Сколько других проектов он или она ведут?
Присвоение баллов осуществляется следующим образом:
- 1 лидер —* 10,
1 По-видимому, о "сердце Данко" автор не слышал. Данко, кстати, тоже руководитель проекта. -
Прим. переводчика.

230 Ф. О'Коннэл. Как успешно руководить проектами
- 2 лидера —> 4,
- О или больше 2 —> 1.
4. Распределение людей {10}
Используйте форму 2 из примера 5 (глава 4) и список задач из п. 2 выше для
подсчета всех человеко-задач в списке задач. Сложите все результаты и раздели-
разделите это число на число задаче-человек1. Тогда в зависимости от того, какая полу-
получится цифра, балл будет отличаться от максимального значения в 10 следующим
образом:
- 1,00-1,25 -» 10
- 1,25-4,49 ->4
- 4,50 - 5,00 -> 1
Вы можете проделать это в двух разрезах, сначала на уровне человека (разде-
(разделить на число людей), затем на уровне человек-задача.
5. Допуск на ошибки {10}
Следующие задачи помогут вам оценить допуск на ошибки:
¦ Запишите главные риски.
¦ Опишите запасную позицию.
¦ Объясните, как при отходе от конечной цели эта запасная позиция создает
для вас допуск на ошибки.
Вы можете сделать это на ряде уровней:
¦ на уровне проекта,
¦ для контрольных точек (промежуточных этапов),
¦ для элементов критического пути,
¦ для каждой человеко-задачи.
Вычитайте 15 баллов из общей суммы, если у вас нет допуска на ошибки.
6. Стиль руководства {10}
Выполните анализ, требуемый формой 2 из примера 5 (глава 4). Сравните
с тем, что случается на самом деле. Максимальный балл - 10.
1 В оригинале именно так: people-jobs и job-persons. Остается только догадываться, что именно
имел в виду автор. - Прим. переводчика

Приложение 3. Индикатор вероятности успеха 231
7. Знать то, что происходит {10}
Проанализируйте используемые отчетные и мониторинговые механизмы
и присвойте балл при максимуме, равном 10. Теряете баллы при отсутствии кон-
контроля и мониторинга плана.
8. Сообщать людям, что происходит {10}
Проанализируйте механизмы распространения информации, например, каж-
каждый ли имеет последнюю обновленную копию плана; получают ли они ее каж-
каждый раз, когда план изменяется? Вычтите баллы за отсутствие совещаний по те-
текущему состоянию проекта и отчетов о достигнутых результатах.
9. Повтор этапов с 1 до 8 {нет баллов}
10.Приз; признание{нет баллов}
ПРИМЕРЫ
Давайте посмотрим на некоторые примеры. Два примера, которые мы уже
хорошо знаем, это экспедиции Скотта и Амундсена на Южный полюс. Давайте
подсчитаем баллы для них в качестве наших двух первых примеров.
Скотт
1. Цель четко определена? Не очень. Только после того, как он направился
к полюсу, это действительно стало целью. Половинный счет. A0)
2. Такой список работ, чтобы каждый знал свою часть. Нет. Совсем тяжело.
Роли людей были перепутаны и подвергались изменениям. F)
3. Один руководитель. Здесь нет проблем. A0)
4. Распределение людей по задачам. Как упоминалось ранее, была проблема
с ролями участников и тем, что ожидалось от них. D)
5. Запасная позиция. История доказывает, что ее не было. (-15)
6. Соответствующий стиль руководства? Скотт имел один (авторитарный)
стиль, который он использовал с каждым. Я бы дал низкую оценку. D)
7. Знать, что происходит. Учитывая, что большая часть плана была в голове
у Скотта, он должен был иметь разумное представление о том, что происхо-
происходило. Где он допускал промахи, так это в понимании скрытых настроений
и морального духа. F)
8. Сообщать людям, что происходит? Едва ли. B)
Это дает профиль, показанный в табл. АЛ:

232
Таблица A.I
ЭТАП
1
2
3
4
5
б
7
8
9
10
Общий балл:
ДОПУСТИМО
20
20
10
10
10
10
10
10
0
0
Ф. О'Коннэл. Как
ФАКТИЧЕСКИ
10
б
10
4
-15
4
б
2
0
0
успешно руководить проектами
ВСЕГО
15
12
27
Амундсен
1. Цель ясно определена? Абсолютно. B0)
2. Такой список работ, чтобы каждый знал свою часть. Полностью. Но, ска-
скажем, он мог сделать это немного получше. A8)
3. Один лидер. Здесь нет проблем. A0)
4. Распределение людей по задачам. Да. См. главу 4 (а еще лучше прочтите
Huntford A993), если сомневаетесь). (9)
5. Запасная позиция. Да - они набирают вес, помните? A0)
6. Соответствующий стиль руководства? Да, Амундсен был очень чуток
к своим людям. (9)
7. Знать, что происходит. Абсолютно. (8)
8. Сообщать людям, что происходит? Да. (8)
Это дает профиль, показанный в табл. А.2:
Таблица А.2
ЭТАП
1
2
3
4
ДОПУСТИМО
20
20
10
10
ФАКТИЧЕСКИ
20
18
10
9
ВСЕГО

Приложение 3. Индикатор вероятности успеха 233
ЭТАП
5
6
7
8
9
10
Общий балл:
ДОПУСТИМО
10
10
10
10
0
0
ФАКТИЧЕСКИ
10
9
8
8
0
0
ВСЕГО
67
25
92
Проект XI
Это - проект, над которым я работал около десяти лет назад. Это тот проект,
о котором я упоминал в главе 3 (пример 4) и в котором было два лидера.
1. Цель ясно определена? Вроде бы. Не было никаких реальных спецификаций,
но были люди в проекте, хорошо знавшие, какую систему пытаются поста-
поставить. Дадим грубо половину от максимума. (9)
2. Такой список работ, чтобы каждый знал свою часть. Мы знали, что надо
делать изо дня в день; но знали ли мы, как это вписывалось в общую картину,
и продвигаемся ли мы? Определенно нет. F)
3. Один руководитель. Нет, их было два. A )
4. Распределение людей по задачам. Люди были, конечно, распределены по ра-
работам. Однако, учитывая, что список работ, возможно, был неполон (см. вы-
выше), нам придется отметить этот пункт низким баллом. D)
5. Запасная позиция. Ну, я предполагаю, что она была, потому что, когда что-то
органическое попало в вентиляционное устройство, руководство смогло пе-
перекроить проект, чтобы осуществить поставку с уменьшенной функциональ-
функциональностью. D)
6. Соответствующий стиль руководства! Было два лидера, один авторитар-
авторитарный и самоуверенный, другой нирыбанимясо и слегка ноющий. D)
7. Знать, что происходит. См. комментарии выше относительно списка задач
и распределения людей. D)
8. Сообщать людям, что происходит? Отчасти. D)
Это дает профиль, показанный в табл. А.З:
Кстати, выше автор предлагал данный случай оценивать четырьмя баллами. Таким образом,
общий балл должен был равняться 39 баллам. - Прим. редактора.

234
Таблица А.З
ЭТАП
1
2
3
4
5
б
7
8
9
10
Общий балл:
ДОПУСТИМО
20
20
10
10
10
10
10
10
0
0
Ф. О Коннэл. Как
ФАКТИЧЕСКИ
9
б
1
4
4
4
4
4
0
0
успешно руководить проектами
ВСЕГО
24
12
36
Сражение при Сомме
Об этом мы упоминали ранее в тексте, начало сражения при Сомме в Первой
мировой войне.
1. Цель ясно определена? Да, без сомнения. B0)
2. Такой список работ, чтобы каждый знал свою часть. Да, сбросим им пару
баллов на том основании, что они могли бы сделать это немного лучше. A8)
3. Один лидер. Да. A0)
4. Распределение людей по задачам. Да, сделано очень хорошо. (8)
5. Запасная позиция. Нет. (-15)
6. Соответствующий стиль руководства? Руководство в Первой мировой вой-
войне было предметом горячих споров и литературных изысканий. Преобла-
Преобладающий стиль у военных того времени был: "Не рассуждать - только выпол-
выполнять, что сказано". Я дам им 5 баллов, основываясь на том, что большее ко-
количество ответственности и инициативы должно было быть передано ниж-
нижним звеньям. E)
7. Знать то, что происходит. Технология того времени делала связь на поле
битвы очень и очень трудной. Половинный балл. E)
8. Сообщать людям, что происходит? См. более ранние комментарии относи-
относительно "выполнять, что сказано ". Половинный балл. E)
Это дает профиль, показанный в табл. А.4:

Приложение 3. Индикатор вероятности успеха 235
Таблица А.4
ЭТАП
1
2
3
4
5
б
7
8
9
10
Общая сумма:
ДОПУСТИМО
20
20
10
10
10
10
10
10
0
0
ФАКТИЧЕСКИ
20
18
10
8
-15
5
5
5
0
0
ВСЕГО
41
15
56
Проект Х2
Вот еще один проект, над которым я когда-то работал.
1. Цель ясно определена? Да, весьма неплохо. Мы имели подробные специфи-
спецификации и описания функциональных возможностей, которые должны быть
обеспечены в каждой версии. A6)
2. Такой список работ, чтобы каждый знал свою часть. Нет, мы так и не суме-
сумели реально стабилизировать наши списки. Мы получали списки в письмен-
письменном виде, а вскоре нам сообщали, что "все изменилось", и списки теряли свое
значение.A0)
3. Один руководитель. Нет. Мы имели страшные проблемы - слишком много-
многочисленные, чтобы перечислять, - с руководителями. Позвольте мне дать 1
балл на том основании, нто мы были в категории "ноль или больше двух ру-
руководителей".
4. Распределение людей по задачам. Ну, поскольку списки задач были в состоя-
состоянии непрерывного изменения, таким же было и распределение людей. C)
5. Запасная позиция. Да, мы это делали. Когда продвижение стало очень тяже-
тяжелым, мы были в состоянии переместить функциональность с первой версии
на последующие, стандартный трюк разработчиков ПО. G)
6. Соответствующий стиль руководства? Из-за проблем, описанных ранее,
мне в конце концов пришлось взять этот проект под свой контроль и довести
его до ума. Позвольте мне (скромно!) оценить себя в 7 баллов. G)

236 Ф. О'Коннэл. Как успешно руководить проектами
7. Знать, что происходит. Вообще говоря, да, мы знали. F)
8. Сообщать людям, что происходит? Мы пытались. F)
Это дает профиль, показанный в табл. А.5:
Таблица А.5
ЭТАП
1
1
2
3
4
5
б
7
8
9
10
Общая сумма:
ДОПУСТИМО
20
20
20
10
10
10
10
10
10
0
0
ФАКТИЧЕСКИ
9
16
10
1
3
7
7
б
б
0
0
ВСЕГО
37
19
56
ПроектХЗ
Еще один программный проект, над которым я работал. Руководитель проек-
проекта - один из лучших, кого я знаю.
1. Цель ясно определена? Да. A8)
2. Список работ такой, что каждый знал свою часть. Да. A8)
3. Один руководитель. Да. A0)
(Лирическое отступление: какое само по себе удовольствие вспоминать о хо-
хорошо сделанном проекте. Во мне до сих пор все теплеет, когда я вспоминаю
о нем.)
4. Распределение людей по задачам. Да. (8)
5. Запасная позиция. Да, даже при том, что она не потребовалась. (8)
6. Соответствующий стиль руководства? Да. (8)
7. Знать, что происходит. Да. (8)
8. Сообщать людям, что происходит! Да. (8)

Приложение 3. Индикатор вероятности успеха 237
Это дает профиль, показанный в табл. А.6:
Таблица А. 6
ЭТАП
1
2
3
4
5
б
7
8
9
10
Общая о/мма:
ДОПУСТИМО
20
20
10
10
10
10
10
10
0
0
ФАКТИЧЕСКИ
18
18
10
8
8
8
8
8
0
0
ВСЕГО
•
62
24
86
Операция "Буря в пустыне"
Ясно, я не принимал участия в планировании операции "Буря в Пустыне".
Однако вот человек с уличной оценкой этого проекта.
1. Цель ясно определена? Да, с клинической точностью. B0)
2. Такой список работ, чтобы каждый знал свою часть. Похоже. A8)
3. Один руководитель. Да, г-н Шварцкопф. A0)
4. Распределение людей по задачам. Кажется, здесь все было сделано хорошо. G)
5. Запасная позиция. Мое предположение, что она была - хотя не могу знать
наверняка. G)
6. Соответствующий стиль руководства? Кажется, невозможно желать луч-
лучшего. (9)
7. Знать, что происходит. Мы не знали, но скорее всего, власти знали. (8)
8. Сообщать людям, что происходит? Снова нам не сообщали, но я думаю, что
участников все же информировали. (8)
Это дает профиль, показанный в табл. А.7:

238
Таблица А. 7
ЭТАП
1
2
3
4
5
6
7
8
9
10
Общий балл:
ДОПУСТИМО
20
20
10
10
10
10
10
10
0
0
Ф. О'Коннэл. Как
ФАКТИЧЕСКИ
20
18
10
7
7
9
8
8
0
0
успешно руководить проектами
ВСЕГО
62
25
87
Анализ
Тенденции
Проекты, которые я только что описал, показаны в табличной форме на
рис. А.9. Из ограниченного количества примеров, представленных здесь и/или
изученных нами, несколько вещей становятся очевидными:
¦ Любой проект со значением ниже примерно 40 баллов на стадии планирова-
планирования выглядит сомнительно.
¦ Любой проект с общим баллом ниже примерно 60 выглядит сомнительно.
¦ Если вы получаете низкий балл за стадию планирования, то, мягко выража-
выражаясь, вы имеете ограниченный диапазон возможностей последующего улуч-
улучшения ситуации. Говоря менее мягко, если вы выходите из стадии планиро-
планирования с низким баллом, то, по всей видимости, вы можете делать что хотите,
но это не будет иметь почти никакого значения для конечного результата.
Это последнее наблюдение восходит к моему дополнению известного Закона
Брукса (Brooks, 1975), который гласит: "Если проект не укладывается в сроки, то
добавление рабочей силы задержит его еще больше". Мое дополнение гласит:
"Проекты успешно выполняются или терпят неудачу в первые 10 % своего вре-
времени жизни".

Приложение 3. Индикатор вероятности успеха 239
Применение
То, что мы описали здесь, представляет собой очень простой анализ рисков.
Он может быть проведен в любой точке жизни проекта. Это очень похоже на
"веришь - не веришь", если вы говорите, что это неправда, вам говорят неправду
в ответ.
Ограничения
В настоящее время ограничения "принятия PSI вызова" (если я могу так это
назвать) включают следующее:
¦ он базируется на очень маленькой выборке,
¦ подсчет несколько груб,
¦ подсчет несколько субъективен,
¦ он имеет ограниченное применение в реальной жизни,
¦ и шкалу, и процесс подсчета необходимо подстраивать и уточнять, обращаясь
к множеству других проектов.
Несмотря на вышесказанное, мы теперь используем PSI в консалтинге и на
курсах обучения. Все проекты, которые мы изучили до настоящего времени,
подтвердили точность нашей схемы подсчета PSI. Мы планируем провести до-
дополнительную работу в этой области.
ИНДИКАТОР ВЕРОЯТНОСТИ
1.
2.
3.
4.
5.
б.
7.
8.
9.
10.
Цель
Список задач
Один лидер
Распределение людей
Запасная позиция
Стиль руководства
Знать, что происходит
Сообщать, что происходит
Повтор этапов с 1 по 8
. Приз; признание
Общий итог:
УСПЕХА: ТАБЛИЦА АНАЛИЗА
Допустимые
значения
20
20
10
10
10 G0)
10
10
10
0
0C0)
100
Скотт
10
6
10
4
-15A5)
4
6
2
-
-12
27
XI
9
б
1
4
4B4)
4
4
4
-
-12
36
Сомма
20
18
10
8
-15D1)
5
5
5
-
-15
56
Х2
16
10
1
3
7C7)
-7
б
б
-
-19
56
ХЗ
18
18-
10
8
8F2)
8
8
8
-
-24
86
Буря в
пустыне
20
18
10
7
7F2)
9
8
8
-
-25
87
Амундсен
20
18
10
9
10F7)
9
8
8
1
-25
92
Рис. А.9. Таблица анализа PSI

240 Ф. О'Коннэл. Как успешно руководить проектами
Комментарии
¦ Скотт. Самые худший проект, который мы имеем; почти нуль в нашем мас-
масштабе.
¦ XI. Счет очень плохой, как и можно было ожидать.
¦ Сомма. Иллюстрирует то, что в некоторых обстоятельствах допуск на ошиб-
ошибки может быть разрушительным.
¦ Х2. Плохой профиль после планирования, едва спасенный сильной реализа-
реализацией.
¦ ХЗ. Профиль аналогичен проекту Амундсена; сильный план, сильная реали-
реализация.
¦ Буря в пустыне. Почти столь же хорош, как проект Амундсена, лучший про-
проект, который мы имеем.
Эмпирические правила
Все, выходящее из стадии планирования с баллом меньше 40, очень риско-
рискованно. Неудачи ждут при общем балле ниже 60.

ПРИЛОЖЕНИЕ 4
ОСНОВНЫЕ ПРИНЦИПЫ И ГЛОССАРИЙ
ТЕРМИНОВ
ВВЕДЕНИЕ
Глава 19 первого издания этой книги содержала некоторую базовую инфор-
информацию, которую, я думаю, стоит воспроизвести и здесь.
Хотя оно и считается столь сложным, руководство проектом в действитель-
действительности не требует большого объема специальной терминологии. Есть четыре ре-
реальных вещи, о которых вы должны знать:
¦ трудозатраты, также иногда называемые объемом работ или работой;
¦ график, также иногда называемый затраченным временем;
¦ критический путь;
¦ контрольные точки (промежуточные этапы).
Кроме того, есть целая куча дополнительных терминов, которые обсуждают-
обсуждаются время от времени, и они представлены в глоссарии терминов в конце этого
приложения.
БОЛЬШАЯ ЧЕТВЕРКА
Давайте рассмотрим четыре основных понятия.
Трудозатраты (объем работ, работа)
Трудозатраты вполне просто представляют собой количество труда в опреде-
определенных единицах. Трудозатраты измеряются в таких единицах, как человеко-дни,
человеко-недели или человеко-годы. Если человек роет яму и ему требуется для
этого 5 дней, тогда количество труда - 5 человеко-дней. Если 5 человек роют яму
и им требуется для этого 1 день, то объем работ также равен 5 человеко-дней.
График (затраченное время)
График - это затраченное или календарное время, за которое что-то должно
быть выполнено. График измеряется в обычных календарных единицах времени:
час, день, месяц, год. В предыдущем примере рытья ямы график в первом случае
был равен 5 дням; во втором он был равен 1 дню.

242 Ф. О'Коннэл. Как успешно руководить проектами
Критический путь
Критический путь - во многом неправильно понимаемый термин. Критиче-
Критический путь представляет собой самое короткое время (то есть самый короткий
график или затраченное время), за которое что-то может быть завершено.
В примерах, которые последуют, вы увидите важность критического пути.
Контрольные точки (промежуточные этапы1)
Milestones, первоначально размещавшиеся вдоль дорог, показывали путеше-
путешественнику, как далеко он от начала или конца своего путешествия. Промежу-
Промежуточные этапы в проектах делают точно то же самое. Они - "вехи" проекта в спе-
специфических точках во времени. Они показывают, какая часть проекта была за-
закончена и сколько он еще должен длиться.
СОКРАЩЕНИЯ И ЭМПИРИЧЕСКИЕ ПРАВИЛА
Вы можете также сталкиваться с применением следующих единиц и соотно-
соотношений:
¦ 8 человеко-часов (МН) = 1 человеко-дню (MD).
¦ 5 человеко-дней = 1 человеко-неделе (MW).
¦ Технически в человеко-неделе будет 4,3 человеко-дня2, но со значением 5
легче работать.
¦ 19 человеко-дней = 1 человеко-месяцу (ММ).
¦ 12 человеко-месяцев = 1 человеко-году (MY).
¦ 220 человеко-дней = 1 человеко-году.
Технически 1 человеко-год равен 228 человеко-дням, и я думаю, что это мо-
может быть правильно в США. Конечно, в Европе он ближе к 220.
ПРИМЕР 1
Беременность - часто используемый пример проекта. Для этого примера на-
наши четыре величины, указанные выше, будут равны:
Трудозатраты 9 женщино-месяцев
График Приблизительно 9 месяцев
1 В оригинале термин, используемый и в MS Project, - milestone - мильный камень, т. е. версто-
верстовой столб по-русски.
2 В рабочей неделе в Европе и Северной Америке обычно 35 часов. - Прим. переводчика

Приложение 4. Основные принципы и глоссарий терминов 243
Критический путь 9 месяцев (то есть добавление большего количества женщин не сократит
продолжительность проекта)
Промежуточные этапы Врачи могут идентифицировать специфические важные точки в процессе
роста ребенка от зачатия до родов
ПРИМЕР 2
Вот другой проект. Он содержит шесть задач в следующем порядке:
¦ Написание документа.
¦ Рассылка документа.
¦ Рецензирование документа (отзывы).
¦ Пересмотр и обновление документа.
¦ Повторная рассылка документа.
¦ Утверждение документа.
Проект кончается, когда этот конкретный документ утверждается соответст-
соответствующими сторонами.
Давайте также примем, что следующие оценки, то есть сделанные нами
предположения, применимы к этим шести задачам. Каждая оценка дается в виде
трех чисел: трудозатраты в человеко-днях (MD), график в затраченном времени1,
число занятых людей.
Написание документа
Рассылка документа
Рецензирование документа
Пересмотр и обновление документа
Повторная рассылка документа
Просмотр и утверждение документа
15,0 MD
0,5 MD
5,0 MD
4,0 MD
0,5 MD
2,5 МО
Продолжительность=7,5
Продолжительность = 0,5
Продолжительность = 5,0
Продолжительность = 2,0
Продолжительность = 0,5
Продолжительность = 5,0
2 человека
1 человек
5 человек
2 человека
1 человек
5 человек
Как всегда, мы документируем основание для этих оценок:
1. Написание документа - для двух человек, работающих полный рабочий день,
требуется полторы недели времени.
2. Рассылка документа - один человек, делающий фотокопирование, отправ-
отправляющий факсы и почту в течение половины дня.
1 Так в оригинале. По-видимому, график дан все же в днях, как видно из последующего изложе-
изложения. - Прим. переводчика.

244 Ф. О'Коннэл. Как успешно руководить проектами
3. Рецензирование - пять человек, каждый из которых тратит день на рассмот-
рассмотрение документа, и мы даем им неделю, чтобы сделать это.
4. Пересмотр - это два человека на полный рабочий день, на сей раз в течение
двух дней.
5. Повторная рассылка - то же самое, что и рассылка.
6. Просмотр - те же самые пять человек, работающие половину дня каждый,
чтобы просмотреть и подписать документ, и мы даем им еще неделю, чтобы
сделать это.
Таким образом:
Трудозатраты 27,5 MD
График Продолжительность=20,5
Критический путь Продолжительность=20,5 (потому что задачи должны следовать друг за другом
последовательно. Это не всегда так. Итак, каждое действие находится на
критическом пути.)
Промежуточные Завершение каждой из этих шести задач представляет один возможный набор
этапы промежуточных этапов в проекте. (Начало каждой задачи - альтернативный
набор.)
КРИТИЧЕСКИЙ ПУТЬ
Критический путь важен по ряду причин.
¦ Он показывает вам самое короткое возможное время, за которое проект мо-
может завершиться.
¦ Он идентифицирует те задачи, которые, будучи не выполненными в срок,
приведут к задержке или срыву проекта в целом.
¦ Он идентифицирует те задачи, которые обязательно должны быть сокраще-
сокращены, если время выполнения проекта должно быть сокращено.
¦ Если в вашем проекте происходит срыв графика, критический путь иденти-
идентифицирует работы, которые должны быть выполнены в том случае, если про-
проект должен быть возвращен в график.
¦ Критический путь - причина, почему добавление большего количества людей
к проекту может не дать тех изменений, которых мы ожидали. Чтобы проил-
проиллюстрировать это, давайте посмотрим, что случается, если мы добавляем не-
некоторое количество людей к нашему вышеописанному проекту.

Приложение 4. Основные принципы и глоссарий терминов 245
Почти 70 % из объема работ в этом проекте занято двумя задачами: написа-
написание документа и пересмотр документа. Если бы нам пришлось добавить одного
или даже двух человек на эти задачи, нашей естественной реакцией было бы
ожидание существенного улучшения в графике.
На практике ничто не может быть дальше от правды. Добавление одного че-
человека (то есть увеличение команды на 50 %) уменьшает график до:
5 + 0,5 + 5 +1,5 + 0,5 + 5 = 17,5, экономия 15 % от начального значения;
При добавлении еще одного человека и увеличении команды на 100 % дает
уменьшение графика на следующую величину:
4 + 0,5 + 5+1 + 0,5 + 5 =16,0, экономия только 21 % от начального значения;
И заметьте, что при добавлении людей предполагается, что они могут сразу
включиться в работу без предварительного знакомства с данной конкретной за-
задачей и быть столь же производительными, как люди, которые уже работают
над ней. Такое предположение редко оправдывается в ИТ.
Действительно, есть довод, гласящий, что в определенных обстоятельствах
добавление людей к проекту фактически не будет сокращать график вообще.
Этот довод сжато сформулирован в Законе Брукса (Brooks, 1975).
Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще
больше.
ГЛОССАРИЙ ОБЩИХ ТЕРМИНОВ РУКОВОДСТВА
ПРОЕКТОМ
PERT. Техника оценки и анализа проекта. Сетевая диаграмма задач, на которой
показаны их зависимости.
WBS. Структура распределения (разбиения) работ. Иерархическая организация
задач с применением определенной кодификации.
Анализ рисков. Попытка предсказать, что может пойти в проекте неправильно, и
закладывание места для маневра.
Бюджет (проекта). Стоимость всего или части проекта.
Гантт. Диаграмма, показывающая задачи проекта как полосы на шкале времени.
Детализированная задача. Задача, которая не имеет никаких вложенных внутри
себя задач.

246 Ф. О'Коннэл. Как успешно руководить проектами
Диаграмма PERT. Сетевой график, узлы которого представляют собой задачи проек-
проекта и их продолжительности, а ребра отражают отношения между парами работ.
Зависимость. Временные соотношения между двумя задачами, определяющие
необходимую последовательность событий.
Задача. Деятельность, имеющая определенное начало и конец и производящая
определимый результат.
Запас ресурсов. Это - общее количество всех ресурсов в проекте. Запас ресурсов
для проекта может обслуживаться внутри проекта, или же обслуживание может
быть вынесено в отдельный проект и, таким образом, совместно использоваться
несколькими проектами.
Затраченное время. Как долго работа будет выполняться.
Зафиксированный график. Запись дат, продолжительности, трудозатрат и стоимо-
стоимости задач, заложенных изначально.
Калькуляция (проекта). Обсчет стоимости проекта.
Контрольная точка (промежуточный этап). Дата существенного события, обычно
создаваемого как задача с нулевой продолжительностью.
Критический путь. Последовательность задач, каждая из которых должна быть
закончена вовремя, чтобы обеспечить зафиксированные даты завершения задач
и/или дату конца проекта в целом.
Мониторинг проекта. Проверка, как проект выполняется по сравнению с планом
проекта.
Отчеты. Отчеты используются в основном в течение стадии выполнения проекта.
Они позволяют пользователю вычислять суммарные значения и сводить их в
перекрестную таблицу задач и ресурсов.
Оценивание. Предположение. Попытка предсказать будущее. Его выполнение
основано на некотором предыдущем знании или опыте.
Переменные издержки. Стоимость, определенная как цена на единицу времени.
План проекта. Ваш прогноз того, как, по вашему мнению, будет развиваться про-
проект. Это также формальное соглашение между
- членами команды,
- командой и руководителем проекта,

Приложение 4. Основные принципы и глоссарий терминов 247
- командой проекта и ее заказчиком.
Описывает все аспекты проекта, идентифицированные в процессе планирования.
Поставки. Что-то сделанное, написанное, произведенное или созданное в резуль-
результате работы.
Предельный срок, к которому работа должна быть выполнена обязательно.
Предшественник. Более ранняя задача в отношениях зависимости между двумя
задачами.
Преемник. Более поздняя задача в отношениях зависимости между двумя задачами.
Проект. Любое приложение усилий может рассматриваться как проект. В нашей
терминологии проект к работа синонимы.
Промежуточная цель. Думайте о проекте как о путешествии; промежуточная
цель - это один из пунктов, который вы должны пройти на пути к вашей точке
назначения. Другими словами, каждая работа имеет промежуточную цель.
Работа. Тот же самое, что и проект, или его стадия, или действие, или задача.
Распределение ресурсов. Распределение людей (или других ресурсов) по задачам.
Резерв времени. Количество времени, на которое может быть отсрочена задача
без сдвига контрольной точки или даты окончания всего проекта.
Ресурс. Люди, оборудование и комплектующие, используемые для выполнения
задач в проекте.
Руководитель проекта. Каждый проект должен иметь одного и только одного ру-
руководителя проекта, который полностью контролирует проект. Этот человек от-
отвечает за проект и получает честь и хвалу при успешном завершении проекта
или отсечение головы, если проект потерпит неудачу. На больших проектах мо-
может быть множество руководителей, и каждый из них отвечает за определенную
часть проекта. Каждый такой руководитель должен быть в состоянии идентифи-
идентифицировать границы своего проекта и факторы успеха, связанные с ним.
Составная задача. Задача, которая является перечнем задач, вложенных в нее при
представлении в виде дерева (структуры). Также известна как укрупненная задача.
Стадия (фаза), действие, задача. Все это термины, применяемые для описания
субкомпонент, на которые может быть разбит проект. В некоторых организаци-
организациях в них вкладываются специальные значения и отношения друг к другу. Чтобы

248 Ф. О'Коннэл. Как успешно руководить проектами
избежать какого-либо конфликта, здесь мы используем термин работа как си-
синоним любого из этих трех терминов.
Трудозатраты. Какое количество работы требуется для выполнения задачи.
Управление (проектом). Попытка держать то, что происходит в проекте в реаль-
реальности, в соответствии с планом проекта.
Управление изменениями. Процесс, посредством которого план проекта модифи-
модифицируется в ходе его выполнения.
Факторы успеха. Что есть успешный проект?
¦ в пределах согласованного времени,
¦ в пределах согласованного бюджета,
¦ предоставляет требуемую функциональность,
¦ обеспечивает требуемое качество.
Фильтры. Фильтры используются для уменьшения количества данных, выводи-
выводимых на экран из базы данных. Фильтр действует на поток данных, выходящий из
базы данных. Он не затрагивает данных в самой базе.
Цель. Думайте о проекте как о путешествии; цель - ваша точка назначения. Каж-
Каждый индивидуум, работающий над проектом, руководитель проекта и спонсор
проекта обязан уметь кратко сформулировать цель проекта. Только тогда каж-
каждый будет работать в команде. Кроме того, должна быть только одна цель.

ПРИЛОЖЕНИЕ 5
ДОПОЛНИТЕЛЬНЫЕ ФОРМЫ
КАРТА КОНТРОЛЯ ОЦЕНОК
Карта контроля оценок
Проект
Автор
№ редакции
Дата
Стадия
Оценки
График
(мес.)
%
Трудозатраты
(чел-мес.)
%
Действительные значения
График
(мес.)
%
Трудозатраты
(чел-мес.)
%
Разница
График
(мес.]
%
Трудозатраты
(чел-мес.)
%
ЖУРНАЛ РЕГИСТРАЦИИ ЗАПРОСОВ ИЗМЕНЕНИЯ
Per. Номер
Дата получения
Дата решения
Отвергнуто (Да/Нет)

250
Ф. О'Коннэл. Как успешно руководить проектами
ФОРМА ЗАПРОСА ИЗМЕНЕНИЯ
Форма запроса изменения
Название проекта
Номер проекта
Номер запроса на изменение
Кем инициировано
Описание запроса изменения
Причины и ожидаемые выгоды
Приоритет: Существенно для успеха проекта
Требуется для реализации Г~
Может подождать
Затрагиваемые задачи/поставляемые компоненты
Оценка стоимости и времени
Да
Одобрено | 1 Отвергнуто | |
Руководитель проекта
Команда проекта ознакомлена
Дата
Дата
Дата
Нет ?

ПРИЛОЖЕНИЕ 6
ИЗУЧЕНИЕ MS PROJECT
ВВЕДЕНИЕ
Цель этого приложения состоит в том, чтобы показать минимальные функ-
функциональные возможности MS Project, нужные руководителю проекта для облег-
облегчения управления им. Оно базируется на учебном курсе моей фирмы ЕТР, в ко-
котором MS Project применяется для создания плана и графика [работ] для учебно-
учебного проекта: строительства площадки для игры в гольф.
Изложение следует стандартным этапам, требуемым при планировании и вы-
выполнении проекта:
¦ Создание задач
¦ Редактирование и перемещение задач в плане
¦ Установка продолжительности задач
¦ Установка зависимостей между задачами
¦ Форматирование и презентация плана
¦ Назначение ресурсов задачам
¦ Сохранение базового содержания.
Предполагается, что читатель этого материала обладает базовыми навыками
работы в операционной системе MS Windows.
МОДУЛЬ 1: ОСНОВЫ РУКОВОДСТВА ПРОЕКТОМ
Краткий обзор
Модуль основ руководства проектом повторяет этапы 1 и 3 методологии
структурного руководства проектом фирмы ЕТР. В нем также кратко обсужда-
обсуждаются ключевые темы руководства проектом.
Цели
Учащемуся надо уяснить, что проект должен иметь:
¦ Ясную цель.
¦ Только одного установленного лидера (руководителя).

252 Ф. О'Коннэл. Как успешно руководить проектами
Подготовка
Изучите содержание модуля. Ознакомьтесь с терминами в приложении 4
и будьте в состоянии объяснить значение каждого термина и как он использует-
используется в управлении проектами.
Введение
MS Project - инструмент, который вы можете использовать для облегчения
применения методологии структурного руководства проектом.
Упражнение
Если учащиеся не выполняли это упражнение ранее, в курсе "Структурное
руководство проектом", пусть они выполнят следующее:
УПРАЖНЕНИЯ 1.1. УРОВЕНЬ: БАЗОВЫЙ
В своем блокноте:
¦ Запишите название вашего проекта.
¦ Запишите цель вашего проекта.
¦ Запишите руководителя проекта.
¦ Перечислите факторы успеха.
Обсуждение
Напомните участникам об этапе 1, необходимости наглядного представления
цели. Вспомните о четырех параметрах проекта из "первого закона руководства
проектом" (отметьте факторы успеха, которые определяют успешный проект).
Также напомните им об этапе 3, о обязательности единоличного руководства
проектом. Руководитель проекта сам отвечает за подготовку или контроль за
подготовкой плана в MS Project. Руководитель проекта должен понимать все
элементы плана в MS Project, чтобы вносить в него изменения, обеспечивающие
продвижение проекта.
Наконец, объясните учащимся, что пакет MS Project разработан с применени-
применением определенных терминов, которые представляют различные виды информа-
информации в базе данных, используемой в каждом файле проекта MS Project. Отошлите
их к приложению 4, чтобы они могли объяснить, как каждый термин представ-
представлен в MS Project (то есть нарисовать то, на что он похож, показать и рассказать).

Приложение 6. Изучение MS Project 253
МОДУЛЬ 2: НАЧИНАЯ РАБОТУ С MS PROJECT 2000
Краткий обзор
Модуль "Начиная работу с MS Project 2000" знакомит с главными функцио-
функциональными возможностями продукта MS Project.
Цели
Учащийся должен:
¦ Понять различные компоненты, составляющие MS Project 2000.
¦ Знать набор панелей инструментов.
¦ Уметь работать с отображениями на экране.
Подготовка
Ознакомьтесь с содержанием модуля, выясните, как называется каждая па-
панель инструментов и какие компоненты представлены в ней.
Введение
Ознакомьтесь с панелями инструментов вместе с учащимися.
Упражнение
Учащиеся на экране отслеживают объясняемые панели инструментов.
Обсуждение
Объясните, что MS Project представляет собой мощное расчетное средство
и должен использоваться для облегчения управления проектом. Обратите вни-
внимание, что он не может оперировать с проектом без получения информации от
человека, который понимает результаты манипуляций с данными. MS Project не
управляет проектом за вас.
Если вы - плохой руководитель проекта, то использование MS Project, скорее
всего, это усугубит. Если вы хороший руководитель проекта, то применение MS
Project обеспечит вам больший контроль над вашим проектом и усилит ваши
возможности по отслеживанию состояния проекта.
Напомните участникам, что, как и другие продукты Microsoft, MS Project
имеет множество вариантов выполнения одной и той же задачи. Некоторые та-
такие варианты будут им показаны в этом курсе. Другой аспект MS Project, на ко-
который надо обратить их внимание, это то, что пакет был разработан для обслу-
обслуживания всех возможных типов проектов и всех возможных стилей руководства

254 Ф. О'Коннэл. Как успешно руководить проектами
проектами. Он не заставляет вас действовать по его сценарию. Вы можете раз-
разработать и применить ваш собственный стиль, и MS Project будет соответство-
соответствовать вашему стилю управления проектами. Обратной стороной этого, однако,
является то, что MS Project может сначала показаться весьма усложненным. Лю-
Любые вещи в MS Project можно сделать как минимум двумя способами, а иногда
шестью или семью. В настоящем курсе мы будем использовать ряд различных
путей, и в ваших собственных проектах вы сможете выбирать, какой из них
лучше подходит вам.
Проведите учащихся через каждую из панелей инструментов и т. п., выводи-
выводимых в верхней части экрана их компьютеров. Некоторые классы оборудованы
проекторами для отображения на экране содержимого дисплея преподавателя
для всеобщего обзора. В этом случае привлеките внимание учащихся к экрану.
В противном случае расскажите классу о каждой из панелей инструментов и их
содержимом. Стандартный экран MS Project содержит ряд различных областей:
Строка меню: это стандартное меню приложения Windows. Оно обеспечивает
доступ ко всем основным функциональным возможностям. Меню имеет тот же
самый формат, что и другие офисные программы пакета Microsoft Office.
Панель инструментов "Стандартная" (Standard): это просто ускоренный путь
доступа к часто используемым командам меню. Первые десять кнопок, или
значков, идентичны для всех офисных программ. Доступна также функция
"Подсказки" ("Tooltips"), которая кратко описывает функцию каждой кнопки.
Для ее активации достаточно навести курсор мыши на нужный значок.
Панель инструментов "Форматирование" ("Formatting"): эта панель содержит до-
дополнительные значки, помогающие структурировать ваш проект и форматировать
свой текст. Количество и содержание панелей инструментов можно изменять.
Панель ввода: позволяет редактировать вводимые данные.
Строка состояния: Эта строка отображается в самом низу экрана.
Параметры отображения: вы можете контролировать вывод на экран панелей
инструментов, панели ввода и строки состояния. Это проделывается посредством
команд "Options" ("Опции") или "Customize" ("Настройка") в меню "Tools" ("Инст-
("Инструменты").

Приложение 6. Изучение MS Project 255
МОДУЛЬ 3: МЕНЮ MS PROJECT 2000
Краткий обзор
Модуль "Меню MS Project 2000" знакомит учащихся с главными компонен-
компонентами девяти подменю основного меню MS Project 2000 и командами в каждом.
Цели
Участник должен:
¦ Ознакомиться с девятью меню MS Project 2000.
¦ Знать о командах каждого меню.
¦ Понимать, что если около команды меню показан значок, то этот значок при-
присутствует на какой-то панели инструментов (на кнопке этой панели), и что
такие кнопки представляют собой ускоренный метод вызова той же самой
команды.
Подготовка
Ознакомьтесь с содержанием модуля и будьте готовы объяснить каждое из
девяти (9) меню и команд в каждом из них.
Введение
УПРАЖНЕНИЯ
Ознакомьтесь с меню и командами в них вместе с учащимися.
Обсуждение
Продемонстрируйте каждое из меню в MS Project и обратите внимание на
команды в каждом из них. Объясните также, что, если учащийся видит значок
или рисунок рядом с командой в меню, это означает, что на некоторой панели
инструментов также есть этот значок (на кнопке) и что такие кнопки представ-
представляют собой ускоренный метод вызова той же самой команды.
File (Файл) Это меню обеспечивает сохранение и поиск файлов, а также функции
печати. Оно также обеспечивает средства просмотра свойств проектов
Edit (Редактирование) Это меню обеспечивает функции копирования, вырезания и вставки;
а также средства редактирования задач и ресурсов и определения
зависимостей задачи
Не забудьте объяснить, что виды изменяют изображение информации на экра-
экране, видимое пользователем, и что пользователь может печатать это изображение.

256 Ф. О'Коннэл. Как успешно руководить проектами
View (Вид) Виды представляют собой наиболее мощное средство MS Project. Это
меню предоставляет ряд готовых видов1 плюс возможность определять
новые. Оно также предоставляет ряд готовых таблиц и возможность
определять новые. Оно обеспечивает доступ к набору типовых отчетов
и к различным панелям инструментов.
Различные способы просмотра обеспечивают много путей вывода на
экран данных, лежащим в основе базы данных в MS Project. На экран
могут быть выведены или отдельное представление, или комбинация
(двух) видов. Каждое представление имеет название и может быть
определено пользователем.
Представление данных в виде диаграммы Гантта - заданный по
умолчанию вид, выводимый при запуске MS Project. При необходимости
вид по умолчанию можно изменить.
База данных проекта содержит информацию по трем областям проекта:
• задачи,
• ресурсы,
• назначения ресурсов задачам.
Некоторые из этих данных (например, названия задач и их
продолжительность) вводятся пользователем, а остальная часть этих
данных (например, полная продолжительность проекта) рассчитывается
самим MS Project.
Также обратите внимание, что диаграмма Гантта есть вид, заданный по
умолчанию для MS Project. Диаграмма Гантта на данный момент наиболее зна-
знакома всем учащимся, а она является простейшим способом показа, что должно
быть сделано и когда.
Продолжая с меню...
Insert (Вставка) Это меню обеспечивает возможность вставки новых и повторяющихся
задач. Оно также обеспечивает средства для вставки рисунков или
объектов в файл.
Format (Формат) Предоставляет средства форматирования для текста в файле, а также
позволяет форматировать специфические виды информации. Кроме
того, позволяет создавать стили для текста и полос диаграммы Гантта.
Tools (Инструменты) Предоставляет большое количество различных, но необходимых
функциональных возможностей.
Меню "Project" является новым в MS Project 200 и отсутствует в предыдущих
версиях MS Project.
1 Вообще говоря, для MS Project лучше говорить не о видах, а о представлениях, однако, учиты-
учитывая уже принятый перевод названия этого меню, мы будем и далее говорить о видах. - Прим.
переводчика.

Приложение 6. Изучение MS Project 257
Project (Проект) Это меню позволяет вам видеть суммарную информацию о проекте,
такую, как начальные и конечные даты, освоение бюджета в плане
и ДРУГУЮ информацию для конкретных задач и проектов. Оно также
обеспечивает функции фильтрации и сортировки.
Продемонстрируйте возможность разбиения экрана и укажите, что позже на
этот материал будет дано упражнение.
Window (Окно) Стандартное меню приложений Windows, позволяющее отображать ряд
окон одновременно. Это полезно при одновременной работе над рядом
проектов. Это меню позволяет управлять одновременным отображением
двух видов.
Наконец, объясните, что меню "Help" ("Справка") будет рассмотрено более под-
подробно далее в курсе (см. модуль 7).
Help (Справка) Обеспечивает получение всесторонней справочной информации
с помощью гипертекстовых средств Windows. Оно также обеспечивает
доступ к системе подсказывающих карточек, откуда можно обращаться
к обучающей программе. Отметьте, что можно также использовать
клавишу F1 для получения контекстно-зависимой Справки.
Укажите, что как меню, так и панели инструментов можно изменять для ото-
отображения большего или меньшего объема информации. Подробное описание,
как это делать, имеется в руководстве пользователя (User Guide) MS Project
2000; однако для более подготовленного класса позже в этом приложении есть
упражнения по этим операциям. Содержание некоторых из меню может изме-
изменяться в зависимости от контекста, в котором к ним обращаются. Отметьте так-
также, что можно изменять размещение меню на экране, а также количество и зна-
значение команд в каждом из них.
МОДУЛЬ 4: УСТАНОВКА ХАРАКТЕРИСТИК
ПО УМОЛЧАНИЮ ДЛЯ ВАШЕГО ПРОЕКТА
Краткий обзор
Этот модуль знакомит с установками характеристик по умолчанию для ваше-
вашего текущего проекта и также дл^я всех будущих проектов.
Цели
Учащийся должен:
¦ Изучить, как устанавливаются значения по умолчанию для часто используе-
используемых полей (например, данных, графика, представления).
¦ Знать, где расположены установки параметров по умолчанию.
9 - 2224

258 Ф. О'Коннэл. Как успешно руководить проектами
Подготовка
Ознакомьтесь с содержанием этого модуля и выполните каждое из упражне-
упражнений по крайней мере один раз, чтобы ознакомиться с их логикой и результатами.
Введение
Для каждого упражнения в этом модуле описана его цель, а также подходит
ли уровень этих упражнений для начинающих или опытных пользователей.
УПРАЖНЕНИЯ
4.1. Как устанавливать значения по умолчанию, чтобы отобразить дату при
открытии нового файла Microsoft Project.
УПРАЖНЕНИЕ 4.1. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - УСТАНОВКА ДАТЫ ПО УМОЛЧАНИЮ
¦ В меню "Tools" ("Инструменты") нажать команду "Options" ("Опции").
¦ Выбрать вкладку "View" ("Просмотр").
¦ Выбрать подходящий формат даты - (поле со списком "Date Format").
¦ Щелкнуть по кнопке "ОК".
Обсуждение
Объясните, что значения по умолчанию могут применяться для оформления ин-
информации в виде, нужном пользователю. К настраиваемым параметрам обращаются
командой "Options" ("Опции") меню "Tools" ("Инструменты"). Дополнительные спо-
способы настройки информации можно найти в руководстве пользователя.
УПРАЖНЕНИЯ
4.2. Как устанавливать характеристики по умолчанию для задач (например,
требует ли задача для выполнения фиксированного объема ресурсов,
фиксированного количества времени или фиксированных трудозатрат).
УПРАЖНЕНИЕ 4.2. УРОВЕНЬ: ДЛЯ ОПЫТНЫХ - УСТАНОВКА ХАРАКТЕРИСТИК ГРАФИКА
РАБОТ ПО УМОЛЧАНИЮ
¦ В меню "Tools" ("Инструменты") выполнить команду "Options" ("Опции").
¦ Выбрать вкладку "Schedule" ("График").
¦ "Default task type" ("Тип задачи по умолчанию") = "Fixed Units" ("фиксиро-
("фиксированные ресурсы").

Приложение 6. Изучение MS Project 259
Обсуждение
Объясните формулу, которую Microsoft Project использует, чтобы вычислять
продолжительность [выполнения] задачи.
Формула длительности Задачи могут быть либо с фиксированными ресурсами (fixed units), либо
[задачи] с фиксированными трудозатратами [fixed work], либо с фиксированной
продолжительностью [fixed duration]. Для понимания этого
определения надо проанализировать формулу MS Project которая
используется для вычисления продолжительности [задачи]. В самой
простой форме эта формула выглядит так:
Трудозатраты/Ресурсы - Продолжительность
Мы можем установить одну из этих величин по умолчанию,
вводить/модифицировать другую, а третья будет вычисляться
автоматически.
УПРАЖНЕНИЯ
4.3. Как использовать кнопку контекстно-зависимой справки, чтобы полу-
получить определение устанавливаемых по умолчанию характеристик.
УПРАЖНЕНИЕ 4.3. УРОВЕНЬ: ДЛЯ ОПЫТНЫХ - ДОСТУП К СПРАВОЧНОЙ ИНФОРМАЦИИ
ш Щелкнуть по кнопке контекстно-зависимой справки: (? в верхнем правом
углу диалогового окна).
¦ Курсор изменится на знак вопроса (?).
¦ Навести курсор на интересующее поле, например "Date Format" ("Формат
даты"), и щелкнуть кнопкой мыши.
¦ После прочтения выведенной на экран информации щелкнуть кнопкой
мыши, чтобы удалить ее.
Обсуждение
Объясните, что функция "Help" ("Справка") будет исследоваться далее в от-
отдельном модуле.
МОДУЛЬ 5: СОЗДАНИЕ ЗАДАЧ
Краткий обзор
Модуль создания задач знакомит учащихся с операциями вставки, перемеще-
перемещения и редактирования задач в проекте. Он также демонстрирует, как устанавли-
устанавливать основную информацию для проекта.

260 Ф. О'Коннэл. Как успешно руководить проектами
Цели
Учащийся должен:
¦ Научиться размещать задачи последовательно.
¦ Научиться редактировать названия задач и удалять ненужные задачи.
Подготовка
Ознакомьтесь с содержанием этого модуля и выполните каждое из упражне-
упражнений по крайней мере один раз, чтобы ознакомиться с их логикой и результатами.
Введение
Для каждого упражнения в этом модуле описана его цель, а также подходит
ли уровень этих упражнений для начинающих или опытных пользователей.
УПРАЖНЕНИЯ
5.1. Как установить стартовую дату при открытии нового файла MS Project
2000 и как вводить заголовок и другую информацию, относящуюся
к проекту.
УПРАЖНЕНИЕ 5.1. УРОВЕНЬ: БАЗОВЫЙ - УСТАНОВКА ИСХОДНОЙ ИНФОРМАЦИИ ПРОЕКТА
¦ В меню "Project" ("Проект") выполнить команду "Project Information" ("Ин-
("Информация проекта").
¦ Установить стартовую дату проекта в поле "Start Date" = 2 апреля 2000".
Щелкнуть на кнопке К".
¦ В меню "File" ("Файл") выполнить команду "Properties" ("Свойства").
¦ Выбрать вкладку "Summary" ("Сводная").
¦ Вести заголовок проекта в поле "Title" - "Создание поля для гольфа".
¦ Вести в поле "Manager" ("Руководитель") свое имя.
¦ Вести в поле "Comments" ("Комментарии") - "Этот проект предусматрива-
предусматривает строительство нового поля для гольфа".
¦ Щелкнуть на кнопке "ОК", чтобы подтвердить ввод.
Обсуждение
Объясните, что единственная дата, которая должна быть задана для проекта,
это его начальная дата. MS Project вычислит все другие даты на основании свя-
связей, которые вводятся в файл. Далее мы идентифицируем каждую задачу в про-

Приложение 6. Изучение MS Project 261
екте и время, требующееся для ее завершения, прежде чем задавать какие-либо
связи между задачами.
Первое, что мы желаем сделать, это задать некоторую общую информацию
о проекте. Для этого мы используем вкладку диалогового окна "Summary"
("Сводная информация"). В этом диалоговом окне мы используем клавишу та-
табуляции (TAB) для перемещения между полями. Для движения в обратном по-
порядке используется SHIFT+TAB. Альтернативой перемещению с помощью кла-
клавиатуры служит мышь. В течение этого курса мы будем использовать в качестве
нашего главного объекта упражнений строительство поля для гольфа.
При вводе задачи обратите внимание на следующие моменты:
1. Может ли ваша задача быть расписана или разбита на подзадачи?
2. Заполнили ли вы поле начала проекта?
3. Использовали ли вы сокращения?
4. Понятен ли ваш язык?
5. Указали ли вы интересы третьих сторон?
6. Использовали ли типовые описания?
7. Отметили ли конечную цель вашей задачи/проекта?
УПРАЖНЕНИЯ
5.2. Как вводить название задачи в диаграмме Гантта.
УПРАЖНЕНИЯ 5.2. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ВВОД НАЗВАНИЯ ЗАДАЧИ
С ИСПОЛЬЗОВАНИЕМ ДИАГРАММЫ ГАНТТА
¦ Мышью, клавишами табуляции или управления курсором выбрать ячейку
названия задачи (столбец "Name") в строке 1.
¦ Ввести "Утверждение строительного проекта", нажать клавишу "Enter".
¦ Обратите внимание, что теперь выбирается следующая строка.
¦ Ввести "Расчистка территории", нажать клавишу "Enter".
¦ Ввести "Получение разрешений", нажать клавишу "Enter".
Обсуждение
Объясните, что диаграмма Гантта - один из путей ввода деталей задачи. Это
также единственный метод, который будет демонстрироваться в этом курсе. Об-
Обратите внимание на тот факт, что после ввода задачи в файл MS Project 2000 ав-
автоматически создается ряд данных для этой задачи.

262 Ф. О'Коннэл. Как успешно руководить проектами
Создание задач В MS Project есть много путей для задания деталей задачи. В этом курсе
мы будем обычно использовать диаграмму Гантта как первичный метод
ввода деталей задачи.
Также отметьте, что быстрее и проще сначала ввести перечень задач, а затем
вернуться для изменения продолжительности каждой задачи. Когда задача вво-
вводится и нажимается клавиша "Enter", эта задача принимается программой, ей
назначается продолжительность в один день и подсвечивается ячейка названия
задачи под только что введенной задачей.
Ввод задач Самым быстрым способом ввода задач является использование
диаграммы Гантта с раздельным вводом названия и продолжительности
задачи. Вводите названия задач в столбце "Name" ("Название") и
жмите клавишу "Enter". Когда названия задач введены, повторите этот
процесс для столбца "Duration" ("Продолжительность").
УПРАЖНЕНИЯ
5.3. Как исправлять ошибки, используя функции удаления, очистки и отмены
в MS Project.
УПРАЖНЕНИЕ 5.3. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - УДАЛЕНИЕ, ОЧИСТКА И ОТМЕНА
¦ Щелкнуть в столбце названий задач по задаче 3 "Получение разрешения".
¦ В меню "Edit" ("Редактирование") выполнить команду "Clear All" ("Очи-
("Очистить все").
Таким образом удаляется только название задачи. Мы не хотели делать этого,
поэтому можем отменить то действие, которое мы только что сделали.
¦ В меню "Edit" выполнить команду "Undo Clear" ("Отмена очистки").
¦ В меню "Edit" выполнить команду "Delete task" ("Удалить задачу").
Эта команда удаляет всю задачу. Однако теперь мы сообразили, что эта зада-
задача нам потом все же потребуется.
¦ В меню "Edit" выполнить команду "Undo Delete" ("Отмена удаления").
¦ Нажать клавишу "Del" на клавиатуре.
Это также удаляет всю задачу. Снова мы сообразили, что эта задача нам по-
потом все же потребуется, и поэтому используем команду "Undo" ("Отмена"),
чтобы восстановить ее.

Приложение 6. Изучение MS Project 263
Обсуждение
Объясните, что, как и в других программах Microsoft, здесь есть возможность
отменить или изменить информацию, если сделана ошибка.
Исправление ошибок MS Project имеет мощные средства отмены выполненных операций для
тех случаев, когда вы делаете ошибку и хотите отследить в обратном
порядке, что вы только что сделали.
УПРАЖНЕНИЯ
5.4. Как перемещать задачу либо методом вырезания и вставки, либо мето-
методом перетаскивания.
УПРАЖНЕНИЕ 5.4. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ПЕРЕМЕЩЕНИЕ ЗАДАЧИ
Мы хотим, чтобы задача "Получение разрешений" в списке стала перед зада-
задачей "Очистка территории".
Метод 1
¦ Выбрать всю задачу "Получение разрешений", щелкнув мышью по ее
строке в столбце "ГО". Это столбец, содержащий номера задач.
¦ В меню "Edit" выполнить команду "Cut Task" ("Вырезать задачу").
¦ Щелкнуть мышью по задаче "Очистка территории".
¦ В меню "Edit" выполнить команду "Paste Task" ("Вставка задачи").
Метод 2
¦ Выбрать задачу "Получение разрешений", щелкнув мышью по ее строке
в столбце "ГО".
¦ Нажать кнопку "Cut" ("Вырезать") на панели инструментов.
¦ Щелкнуть на задаче "Утверждение строительного проекта".
¦ Нажать кнопку "Paste" ("Вставка") на панели инструментов.
Метод 3
¦ Выбрать задачу "Получение разрешения", щелкнув на ней мышью в столбце
"ГО".
¦ Установить курсор мыши в ячейку "ГО" выбранной задачи, нажав и удержи-
удерживая кнопку мыши, перетащить всю строку туда, где желаете ее разместить.

264 Ф. О'Коннэл. Как успешно руководить проектами
Обсуждение
Напомните участникам, что при вводе списка задач иногда требуется изме-
изменить порядок задач в этом списке. Переупорядочение задач может быть сделано
или посредством вырезки и вставки, или перетаскиванием информации.
Перемещение задач MS Project не обращает внимания на порядок задач в списке, но иногда
мы хотим переместить задачи, чтобы сделать порядок более
осмысленным для нас. Есть ряд способов сделать это.
УПРАЖНЕНИЯ
5.5. Как редактировать название задачи, используя панель ввода.
УПРАЖНЕНИЕ 5.5. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - РЕДАКТИРОВАНИЕ НАЗВАНИЯ ЗАДАЧИ
¦ Выбрать поле имени задачи "Получение разрешений".
¦ Название задачи появляется в панели ввода.
¦ Щелкнуть мышью между словами "Получение" и "разрешений" в строке
ввода.
¦ Ввести слово "запланированных".
¦ Нажать кнопку с зеленой галочкой на панели ввода или нажать клавишу
Enter.
Обсуждение
Панель ввода позволяет нам изменять ранее введенный текст.
Редактирование Мы можем изменять любой текст, выбирая его, а затем используя панель
введенной ввода, чтобы произвести любое нужное нам редактирование.
информации
МОДУЛЬ б: ВВОД ПРОДОЛЖИТЕЛЬНОСТЕЙ ЗАДАЧ
Краткий обзор
Модуль ввода продолжительностей задач знакомит учащихся с операциями
установки продолжительностей для задач. Продолжительность представляет со-
собой первую оценку затраченного (запланированного) времени, за которое задача
завершается. Это - только первая оценка, потому что продолжительность рас-
рассчитывается корректно, когда с задачей связываются ресурсы и трудозатраты.

Приложение 6. Изучение MS Project 265
Цели
Учащийся должен:
¦ Быть в состоянии определять продолжительности для задач.
¦ Уметь устанавливать временные ориентиры (промежуточные этапы), показы-
показывая контрольные точки продвижения проекта.
Подготовка
Ознакомьтесь с содержанием этого модуля и выполните каждое из упражне-
упражнений по крайней мере один раз, чтобы ознакомиться с их логикой и результатами.
Введение
Для каждого упражнения в этом модуле описана его цель, а также подходит
ли уровень этих упражнений для начинающих или опытных пользователей.
УПРАЖНЕНИЯ
6.1. Как вводить продолжительности для задач, заданных в столбце "Task
Name" ("Название задачи").
УПРАЖНЕНИЕ 6.1. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ВВОД ПРОДОЛЖИТЕЛЬНОСТИ ДЛЯ
ТЕКУЩИХ ЗАДАЧ
¦ Открыть файл проекта.
¦ Выбрать поле "Duration" ("Продолжительность") для задачи "Расчистка
территории".
¦ Ввести в него w" и нажать "Enter".
Обсуждение
Объясните, что поле продолжительности представлено на календарной сто-
стороне диаграммы Гантта полосой и что эта полоса изменяется при изменении
времени, указанного в столбце продолжительности. Продолжительность - это
время, необходимое для завершения задачи. Продолжительность задачи может
быть выражена в минутах (т), часах (h), днях (d) или неделях (w). Если никакой
символ не введен, по умолчанию принимается d. Нерабочие периоды, например
выходные и общегосударственные праздники, не включаются в продолжитель-
продолжительность задачи.

266 Ф. О'Коннэл. Как успешно руководить проектами
УПРАЖНЕНИЯ
6.2. Как использовать команду "Fill Down" ("Заполнить вниз").
УПРАЖНЕНИЕ 6.2. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ИСПОЛЬЗОВАНИЕ ЗАПОЛНЕНИЯ ВНИЗ
¦ Выбрать мышью поле "Duration" для задачи "Очистка территории".
¦ Удерживая кнопку мыши, выбрать следующие пять полей продолжитель-
продолжительности задач.
¦ В меню "Edit" ("Редактирование") выполнить команду "Fill|Down" ("Запол-
("Заполнить вниз").
Обсуждение
Объясните, что можно изменять продолжительность нескольких задач одно-
одновременно, используя команду Fill Down (Заполнить вниз).
УПРАЖНЕНИЯ
6.3. Как устанавливать Milestone (контрольные точки, промежуточные этапы)
в диаграмме Гантта.
УПРАЖНЕНИЕ 6.3. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - УСТАНОВКА ПРОМЕЖУТОЧНЫХ ЭТАПОВ
¦ Выбрать поле "Duration" ("Продолжительность") для задачи "Утверждение
строительного проекта".
¦ Ввести "О" (цифру ноль) и нажать "Enter".
Обсуждение
Объясните, что промежуточный этап, или контрольная точка (Milestone),
отображается черным ромбиком с датой около нее. Все промежуточные этапы
не имеют связанной с ними продолжительности, поскольку они представляют
существенные события, или точки выдачи результатов проекта.
Промежуточный этап Промежуточный этап - важная контрольная точка графика работ.
Вы задаете промежуточный этап, устанавливая нулевую
продолжительность задачи.
УПРАЖНЕНИЯ
6.4. Как открывать окно информации о задаче в файле MS Project 2000.

Приложение 6. Изучение MS Project 267
УПРАЖНЕНИЕ 6.4. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ОБРАЩЕНИЕ К ОКНУ ИНФОРМАЦИИ
О ЗАДАЧЕ
Метод 1
¦ В меню "Project" ("Проект") выполнить команду "Task Information" ("Ин-
("Информация о задаче").
¦ Нажать кнопку "ОК" или "Cancel" ("Отмена"), чтобы закрыть это диалоговое
окно.
Метод 2
¦ Нажать кнопку информации о задаче ("Task Information") на панели инст-
инструментов.
¦ Нажать кнопку "ОК" или "Cancel" ("Отмена"), чтобы закрыть диалоговое
окно.
Метод 3
¦ Дважды щелкнуть мышью по названию задачи.
¦ Нажать кнопку "ОК" или "Cancel" ("Отмена"), чтобы закрыть диалоговое
окно.
Обсуждение
Объясните, что окно информации о задаче - полезный инструмент, который
представляет информацию о каждой задаче. Информация хранится в базе дан-
данных, которая сидит внутри файла MS Project 2000. Для получения дополнитель-
дополнительной информации о содержимом окна информации о задаче, используйте контек-
контекстно-зависимую справку (?), которая доступна в каждом диалоговом окне для
получения более подробных сведений о его содержимом.
УПРАЖНЕНИЯ
6.5. Как использовать окно информации о задаче для одновременной моди-
модификации нескольких задач.
УПРАЖНЕНИЕ 6.5. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ОДНОВРЕМЕННАЯ МОДИФИКАЦИЯ
НЕСКОЛЬКИХ ЗАДАЧ
¦ Выбрать задачи 3, 5 и 6.
¦ Вывести окно информации о задаче.
¦ Установить в поле продолжительности w".
¦ Щелкнуть "ОК".

268 Ф. О'Коннэл. Как успешно руководить проектами
Обсуждение
Объясните, что данные, введенные в окно информации о задаче, будут отра-
отражены в диаграмме Гантта. Таким образом, при внесении изменений в план про-
проекта вы не ограничены применением табличной части диаграммы Гантта.
Чтобы одновременно изменить несколько элементов, выберите элементы
с помощью щелчка и перетаскивания мыши или посредством щелчка мыши при
нажатой клавише "SHIFT". Чтобы выбрать элементы, которые не примыкают
друг к другу, используют щелчок мыши при нажатой клавише Ctrl.
Ускоренный выбор нескольких элементов (например, задач) в среде Windows:
Если элементы находятся рядом, выделить мышью первый элемент и, не от-
отпуская кнопку, переместить курсор мыши к последнему элементу; или щелкнуть
мышью по первому элементу, а затем при нажатой клавише "Shift" щелкнуть по
последнему элементу.
Если элементы не смежны, щелкнуть мышью по каждому выделяемому эле-
элементу при нажатой клавише "Ctrl", все нужные элементы отметятся.
МОДУЛЬ 7: ИСПОЛЬЗОВАНИЕ СПРАВКИ1
Краткий обзор
Модуль использования Справки знакомит слушателей с тем, как наиболее
эффективным способом найти ответы на вопросы2.
Цели
Учащийся должен:
¦ Ознакомиться с функциями справки в MS Project.
¦ Получить представление о всех функциональных возможностях, которые
предлагаются в меню Справка.
К сожалению, этот модуль, по-видимому, описывает работу со справкой более ранних версий
MS Project. - Прим. переводчика.
В зависимости от языка локализации Windows и модели операционной системы (Windows-95,
Windows-98, Windows-ME, Windows-2000) названия вкладок и кнопок в окнах "Справки" мо-
могут различаться. В настоящем приложении рассматривается русифицированная версия
Windows 98. - Прим. переводчика)

Приложение 6. Изучение MS Project 269
Подготовка
Ознакомьтесь с содержанием этого модуля и выполните каждое из упражне-
упражнений по крайней мере один раз, чтобы ознакомиться с их логикой и результатами.
Введение
Для каждого упражнения в этом модуле описана его цель, а также подходит
ли уровень этих упражнений для начинающих или опытных пользователей.
УПРАЖНЕНИЯ
7.1. Как обратиться к контекстно-зависимой справке.
УПРАЖНЕНИЕ 7.1. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ВЫВОД СПРАВКИ ПРИ ВСТАВКЕ ЗАДАЧ
¦ В меню "Help" ("Справка") выполнить команду "Microsoft Project Help".
¦ На экране появится окно разделов "Справки", приглашающее вас ввести за-
запрос.
¦ Набрать в поле запроса "insert a task" ("Вставка задачи").
¦ Нажать кнопку "Search" ("Поиск").
¦ В нижнем поле появится список общих разделов.
¦ Выбрать раздел "Enter a task into a project" ("Ввод задачи в проект") и про-
прочесть необходимую информацию.
¦ После завершения чтения сверните или закройте окно "Справки" или пе-
перейдите к поиску другой информации.
Обсуждение
Объясните, что эта команда называется контекстно-зависимой справкой и ее
можно вызывать различными способами: используя меню "Справка", как было
показано в упражнении, нажимая кнопку со знаком вопроса (?) на панели инст-
инструментов или нажимая клавишу "F1".
Некоторые из справочных окон будут содержать гипертекстовую ссылку под фра-
фразой "See also" ('См. также") или Click for more" ('Щелкните для дополнительной
информации"). Используйте ее, чтобы выяснить больше о той теме, с которой вы зна-
знакомитесь. MS Project использует тип справки, известный как "Офис в Сети". Она
имеет чрезвычайно большой объем сетевой ссылочной информации, к которой мож-
можно обращаться разными способами в зависимости от вашей потребности. Наиболее
общий метод, который вы будете использовать, - обращение к контекстно-зависимой
справке по клавише F1. Эта справка может быть особенно полезной при получении

270 Ф. О'Коннэл. Как успешно руководить проектами
предупреждения или сообщения об ошибке. В большинстве диалоговых окон имеют
кнопку справки. Широко используйте ее.
УПРАЖНЕНИЯ
7.2. Как использовать вкладку "Index" ("Указатель") в окне "Справки" MS
Project 2000.
УПРАЖНЕНИЕ 7.2. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ВЫВОД СПРАВКИ ПО СОЗДАНИЮ ЗА-
ЗАВИСИМОСТЕЙ
¦ Выполнить команду меню "Help" ("Справка") "Contents & Index" ("Содер-
("Содержание и указатель").
¦ Щелкнуть по ярлыку вкладки "Index" ("Указатель").
¦ Набрать "create" ("создание") и нажать клавишу "Enter". Обратить внима-
внимание, что окно списка тем выводит темы, связанные с этим словом.
¦ Найти тему "Create dependencies between tasks in a project" ("Создание за-
зависимостей между задачами").
¦ Прочесть информацию в окне.
¦ Также прочесть разделы, задаваемые гиперссылками, щелкая по ним.
Обсуждение
Объясните, что указатель подобен предметному указателю в конце книги.
Все разделы перечисляются в алфавитном порядке. Обычный путь получения
справки в справочных системах, если известно название предмета, состоит
в том, чтобы вызвать "Справку" из меню, а затем использовать "Index" ("Указа-
("Указатель").
УПРАЖНЕНИЯ
7.3. Как использовать вкладку "Contents" ("Содержание") в справке по MS
Project.
УПРАЖНЕНИЕ 7.3. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ПОИСК ИНФОРМАЦИИ 0 ПРОДОЛ-
ПРОДОЛЖИТЕЛЬНОСТИ ЗАДАЧИ
¦ В меню "Help" выполнить команду "Contents & Index Topics" ("Содержание
и указатель разделов").
¦ Щелкнуть по ярлыку вкладки "Contents" ("Содержимое").
¦ Выбрать главу "Creating a Project" ("Создание проекта") и щелкнуть на
кнопке "Open" ("Открыть").
¦ Выбрать подраздел "Starting a Project" ("Начало проекта") и щелкнуть на
кнопке "Open" ("Открыть").

Приложение 6. Изучение MS Project 271
¦ Выбрать подраздел "Setting the length of a task" ("Установка длины зада-
задачи") и щелкнуть на кнопке "Display" ("Отобразить").
¦ Выбрать поочередно каждый из трех подразделов (по гиперссылкам) и про-
прочитать.
Обсуждение
Объясните, что содержание подобно оглавлению в начале книги. Каждая гла-
глава представлена значком в виде книги и имеет ряд разделов и подразделов. Объ-
Объем указателя очень велик, и иногда трудно найти именно ту тему, которая нуж-
нужна. Другой путь просмотра "Справки" состоит в представлении ее как большого
набора книг. Именно так организована "Справка" при просмотре ее со вкладки
"Content" ("Содержание"). Предложите в качестве примера найти информацию
о продолжительности задач.
УПРАЖНЕНИЯ
7.4. Как перейти в карточку подсказки в Microsoft Project.
УПРАЖНЕНИЕ 7.4. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ИСПОЛЬЗОВАНИЕ КАРТОЧКИ ПОД-
ПОДСКАЗКИ ДЛЯ ВЫЯСНЕНИЯ, КАК ИЗМЕНЯТЬ ПРОДОЛЖИТЕЛЬНОСТЬ ЗАДАЧИ
¦ В меню "Help" ("Справка") выполнить команду "Contents & Index Topics"
("Содержание и указатель тем").
¦ Щелкнуть по ярлыку вкладки "Contents" ("Содержимое").
¦ Выбрать главу "Creating a Project" ("Создание проекта") и щелкнуть на
кнопке "Open" ("Открыть").
¦ Выбрать раздел "Starting a Project" ("Начало Проекта") и щелкнуть на
кнопке "Open" ("Открыть").
¦ Выбрать подраздел "Change a task duration" ("Изменение продолжительно-
продолжительности задач") и щелкнуть на кнопке "Display" ("Отобразить").
¦ Прочитать содержимое и затем нажать на кнопку "»" в конце диалога.
Обсуждение
Объясните, что "Справка" использует оба диалоговых окна и карточки под-
подсказки для помощи пользователю MS Project. В то время как диалоговые окна
объясняют раздел и имеют гипертекстовые ссылки (которые выводятся зеленым
цветом и подчеркнуты) на другой текст, карточки подсказки используют поша-
пошаговый подход, позволяющий пользователю отследить весь процесс выполнения
некоторой операции. Указатель представляет один метод навигации по справоч-
справочной системе. Альтернативный метод навигации - использование карточки под-
подсказки. Карточки подсказки - пошаговая процедура, которой вы можете следо-

272 Ф. О'Коннэл. Как успешно руководить проектами
вать при необходимости выполнить определенную задачу. Карточку подсказки
можно вывести на экран в процессе работы в MS Project, и она остается на экра-
экране, пока вы не свернете или не закроете ее.
УПРАЖНЕНИЯ
7.5. Как перейти к карте проекта MS Project в "Справке".
УПРАЖНЕНИЕ 7.5. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - КАРТА ПРОЕКТА MS PROJECT
¦ В меню "Help" ("Справка") выполнить команду "Getting Started|Microsoft
101: Fundamentals" ("Начало|Основные команды").
¦ Щелкнуть на "Show me a map to Microsoft Project" ("Показать мне карту
Microsoft Project").
¦ Щелкнуть на " 1" и прочитать описание и команды.
¦ Щелкнуть на кнопке "Back" ("Обратно") и повторить последовательность
по мере необходимости.
Обсуждение
Объясните, что карта MS Project показывает шаги, которым надо следовать
при использовании MS Project. Она может использоваться, чтобы напомнить
пользователям, что делать дальше.
УПРАЖНЕНИЯ
7.6. Как перейти на создание вашего собственного проекта в "Справке".
УПРАЖНЕНИЕ 7.6. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ИСПОЛЬЗОВАНИЕ СПРАВКИ ДЛЯ
СОЗДАНИЯ ВАШЕГО СОБСТВЕННОГО ПРОЕКТА
¦ В меню "Help" ("Справка") выполнить команду "Getting Started| Project Map"
(" Начало |Карта проекта").
¦ В главе "Build a Plan" ("Построение проекта") выбрать подраздел "Define
a Project" ("Определение проекта").
¦ Выбрать подраздел "Initiate a project" ("Инициализация проекта").
¦ Пройти по требуемым подразделам, применяя приведенные инструкции
к своему проекту.
Обсуждение
Объясните, что создание вашего собственного проекта - превосходный спо-
способ выяснить, как формировать хороший план проекта в MS Project. Это также

Приложение 6. Изучение MS Project 273
позволяет получить ответы на конкретные вопросы и обеспечивает более слож-
сложные упражнения по управлению проектами.
Обучающая программа Хорошо структурированная обучающая программа, которая охватывает
основы использования MS Project, вызывается командой меню "Help".
Getting Started|Quick Preview
Shift Fl Это - контекстно-зависимый путь входа в систему справки. В любой
точке в приложении вы можете нажать функциональную клавишу "F1",
и будет отображена контекстно-зависимая справочная информация.
Ошибки/Предупреждения Чтобы получить дальнейшую информацию относительно
предупреждений или сообщений об ошибках, необходимо нажать
клавишу "F1" во время отображения этих сообщений.
МОДУЛЬ 8:ПРИМЕНЕНИЕ ВИДОВ
Краткий обзор
В модуле применения видов объясняется, как управлять способами отобра-
отображения данных для наиболее подходящего представления выполняемой работы.
Здесь обсуждается, как MS Project использует виды для обеспечения гибкости
и контроля. В нем также рассматривается применение таблиц и форм.
Цели
Учащийся должен:
¦ Уметь разбивать экран.
¦ Уметь обращаться к подлежащей базе данных.
¦ Быть в состоянии добавлять пользовательские поля в таблицу.
¦ Понимать, как информация отображается в MS Project.
Подготовка
Ознакомьтесь с содержанием этого модуля и выполните каждое из упражне-
упражнений по крайней мере один раз, чтобы ознакомиться с их логикой и результатами.
Введение
Для каждого упражнения в этом модуле описана его цель. Уровень этих уп-
упражнений - для начинающих.
УПРАЖНЕНИЯ
8.1. Как переключиться на другой вид.
10-2224

274 Ф. О'Коннэл. Как успешно руководить проектами
УПРАЖНЕНИЕ 8.1. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ПЕРЕКЛЮЧЕНИЕ НА ДРУГОЙ ВИД
¦ В меню "View" ("Вид") выполнить команду "Calendar" ("Календарь").
¦ В меню "View" ("Вид") выполнить команду "Network Diagram" ("Сетевой
график").
¦ В меню "View" ("Вид") выполнить команду "Gantt Chart" ("Диаграмма Ган-
тта").
Обсуждение
Объясните, что разнообразие способов просмотра только изменяет способ,
которым выводится на экран информация в подлежащей базе данных. Отметьте,
что можно работать в любом из видов и что каждый вид может быть распечатан
в точности так же, как на экране.
Одновременно может отображаться до двух видов, при этом, когда информа-
информация изменяется в одном виде, это отражается в другом виде на экране. Виды -
наиболее мощная функция MS Project. Вид представляет собой средства ввода,
изменения и отображения содержания подлежащей базы данных в MS Project.
Используя набор видов, вы можете посмотреть на ту же самую информацию
о проекте различными способами, в зависимости от организации проекта. Есть
два типа выводов видов на экран: одиночный вид и комбинация видов.
В комбинации видов MS Project связывает вместе данные в двух различных
окнах на экране. При перемещении по строкам в верхнем окне (посредством
клавиш управления курсором или мыши) данные, выводимые в нижнем окне,
отражают эти изменения.
Для переключения с одного вида на другой используется меню "View"
("Вид"). Альтернативно для переключения видов вы можете нажимать кнопки в
левой части экрана.
УПРАЖНЕНИЯ
8.2. Как разбить экран дисплея компьютера, чтобы вывести два вида одно-
одновременно.
8.3. Как вернуться к выводу одного вида, убирая разбиение.
8.4. Как разбить экран дисплея компьютера без использования меню.
УПРАЖНЕНИЕ 8.2. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ПЕРЕХОД К КОМБИНИРОВАННОМУ
ВЫВОДУ, МЕТОД 1
В меню "Window" ("Окно") выполнить команду Split (Разбить).

Приложение 6. Изучение MS Project 275
УПРАЖНЕНИЕ 8.2. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ВОЗВРАТ К ВЫВОДУ ОДНОГО ВИДА
В меню "Window" ("Окно") выполнить команду "Remove Split" ("Снять разбие-
разбиение").
УПРАЖНЕНИЕ 8.4. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ПЕРЕХОД К КОМБИНИРОВАННОМУ
ВЫВОДУ, МЕТОД 2
¦ Переместить курсор на верхнюю границу внутреннего квадратика в пра-
правом нижнем углу экрана (форма курсора изменится на двойную стрелку).
¦ Когда курсор изменит свой вид, нажать кнопку мыши и, не отпуская, пе-
переместить его на нужную позицию вверх по экрану.
Обсуждение
Объясните, что, когда отображается два вида одновременно, можно опреде-
определить, с которым из них вы работаете, по темной синей границе окна на левой
стороне экрана. Есть два способа разбиения и отмены разбиения экрана.
Комбинация Переключение на комбинацию видов производится с помощью меню
Window. Обратите внимание, что только один из видов комбинации
является текущим (активным). Он обозначен синей границей по левой
стороне соответствующего окна. Можно также переключаться на
комбинацию видов путем перетаскивания верхней границы маленького
квадрата в правом нижнем углу окна.
УПРАЖНЕНИЯ
8.5. Как изменять одиночный вид, чтобы видеть больше или меньше разде-
разделов таблицы диаграммы Гантта.
УПРАЖНЕНИЕ 8.5. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ПРОСМОТР ТАБЛИЦЫ ДИАГРАММЫ
ГАНТТА
¦ Переместить курсор в вертикальную строку на левую вертикальную гра-
границу диаграммы Гантта. Форма курсора изменится на двойную стрелку.
¦ Нажмите кнопку мыши и, не отпуская, перетащите курсор вправо.
Обсуждение
Объясните, что, когда курсор изменяет свою форму, это позволяет делать ряд
различных операций, таких как показ большей или меньшей части таблицы, свя-
связанной с диаграммой Гантта. В Microsoft Project существует ряд встроенных
таблиц, однако каждую из них можно модифицировать для приспособления
к нуждам пользователя.
ю*

276 Ф. О'Коннэл. Как успешно руководить проектами
Манипулирование Можно переключиться с комбинации видов на одиночный, изменять
видами отображение с комбинированного до единственного представления,
перемещая линию разбиения окон к нижней границе экрана.
Таблицы Таблицы представляют собой электронные таблицы, используемые
в видах, для вывода информации по задачам или ресурсам. Строки
являются именами задач или ресурсов, а столбцы - полями информации
о задаче или ресурсе. Мы возвратимся к таблицам в последующих
упражнениях (см. модуль 12).
УПРАЖНЕНИЯ
8.6. Как добавить другой вид к списку в меню "View" ("Вид").
УПРАЖНЕНИЕ 8.6. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ПОМЕЩЕНИЕ ВИДА "ЛИСТ ЗАДАЧ"
В МЕНЮ VIEW (ВИД)
¦ В меню "View" ("Вид") выполнить команду "More Views" ("Другие виды").
¦ Выбрать "Task Sheet" ("Лист задач").
¦ Щелкнуть на кнопке "Edit" ("Редактирование").
¦ Выбрать "Show in Menu" ("Показать в меню"). Щелкнуть на кнопке "ОК".
¦ Щелкнуть на кнопке "Close" ("Закрыть").
¦ В меню "View" ("Вид") выполнить команду "Task Sheet" ("Лист задач").
Обсуждение
Объясните, что виды, которые наиболее часто используются пользователем,
могут быть добавлены к списку меню "View" ("Вид"). Это означает, что виды
можно также удалять из меню аналогичным способом.
МОДУЛЬ 9: УСТАНОВКА ЗАВИСИМОСТЕЙ ЗАДАЧИ
Краткий обзор
Этот модуль показывает, как задать связи задач или их зависимости (в MS
Project 2000 их также называют отношениями), используя ряд различных мето-
методов. Пользователь также ознакомится с существующими типами отношений
и лучшими практиками установки зависимостей задач.
Цели
Учащийся должен:
¦ Уметь связывать задачи.

Приложение 6. Изучение MS Project 277
¦ Уметь устанавливать критический путь и форматировать текст для выделения
информации о критическом пути.
Подготовка
Ознакомьтесь с содержанием этого модуля и выполните каждое из упражне*-
ний по крайней мере один раз, чтобы ознакомиться с их логикой и результатами.
ОБСУЖДЕНИЕ
Объясните, что задачи могут связываться несколькими способами и в не-
нескольких видах. MS Project автоматически устанавливает отношения такого ти-
типа, когда одна работа заканчивается прежде, чем другая начнется. Это - наибо-
наиболее обычный тип отношений между задачами, как можно видеть на примере
строительства дома - фундамент должен быть закончен прежде, чем можно
строить стены.
Отношения задач Наиболее обычные отношения между задачами - это когда одна задача
не может начинаться до окончания другой задачи. Очевидный пример
такого типа отношений в процессе строительства дома, когда котлован
под фундамент должен быть вырыт прежде, чем можно лить бетон,
а бетон должен застыть прежде, чем можно строить стены. MS Project
предполагает, что мы хотим именно этот тип отношений, если мы не
сообщаем иное.
Установка отношений Есть два основных способа установки отношений в MS Project 2000:
1. Выбрать задачи в таблице и дать команду MS Project связать их.
2. Использовать вид "Network Diagram" ("Сетевой график") и
соединить блоки с помощью курсора.
Введение
Для каждого упражнения в этом модуле описана его цель, а также подходит
ли уровень этих упражнений для начинающих или опытных пользователей.
УПРАЖНЕНИЯ
9.1. Как подсветить критический путь для файла MS Project.
9.2. Как подсветить текст, связанный с критическим путем в файле MS Project.
УПРАЖНЕНИЕ 9.1. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ИЗМЕНЕНИЕ ДИАГРАММЫ ГАНТТА
ДЛЯ ПОДСВЕТКИ КРИТИЧЕСКОГО ПУТИ
¦ Открыть файл проекта.
¦ Нажать на значок "Мастера диаграммы Гантта" (панель "Стандартная")
и нажать кнопку "Next" ("Далее").

278 Ф. О'Коннэл. Как успешно руководить проектами
¦ Выбрать вариант "Critical path" ("Критический путь") как информацию,
подлежащую отображению.
¦ Щелкнуть на кнопке "Finish" ("Готово") и щелкнуть на кнопке "Format It"
("Отформатировать его").
¦ Выйти из "Мастера".
УПРАЖНЕНИЕ 9.2. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ИЗМЕНЕНИЕ СТИЛЯ ТЕКСТА
¦ В меню "Format" ("Формат") выполнить команду "Text Styles" ("Стили тек-
текста").
¦ Выбрать в поле со списком "Item to change" ("Изменяемый элемент") =
"Critical Tasks" ("Критические Задачи").
¦ Выбрать в поле со списком "Color" ("Цвет") = "red" ("красный").
¦ Щелкнуть на кнопке "ОК".
Обсуждение
Объясните, что полезно иметь информацию о критическом пути, показанную
в плане проекта. MS Project может подсвечивать эту информацию автоматиче-
автоматически и будет изменять подсвеченные задачи при изменениях критического пути
в проекте. Прежде чем мы начинем устанавливать зависимости задач, мы изме-
изменим формат отображения, чтобы показывать критический путь более ясно.
Мастер диаграммы Это - интерактивный помощник по форматированию вида диаграммы
Гантта Гантта в нужное нам представление.
Критический путь Обратите внимание, что некоторые из строк диаграммы Гантта
выводятся синим цветом, а некоторые - красным. Задачи с красными
строками на диаграмме Гантта - это задачи, которые находятся на
критическом пути.
УПРАЖНЕНИЯ
9.3. Как устанавливать зависимости между задачами с помощью меню.
УПРАЖНЕНИЕ 9.3. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ИСПОЛЬЗОВАНИЕ ВИДА "ДИАГРАМ-
"ДИАГРАММА ГАНТТА" И МЕНЮ
¦ Выбрать с помощью курсора задачи 1, 2 и 3.
¦ В меню "Edit" ("Редактирование") выполнить команду "Link Tasks" ("Связать
задачи").

Приложение 6. Изучение MS Project 279
УПРАЖНЕНИЯ
9.4. Как устанавливать зависимости между задачами, используя кнопку свя-
связывания задач.
УПРАЖНЕНИЕ 9.4. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ИСПОЛЬЗОВАНИЕ ВИДА "ДИАГРАМ-
"ДИАГРАММА ГАНТТА" И ПАНЕЛИ ИНСТРУМЕНТОВ
¦ Выбрать с помощью курсора задачи 4, 5 и 6.
¦ Нажать кнопку связывания задач на панели инструментов "Стандартная".
УПРАЖНЕНИЯ
9.5. Как устанавливать зависимости между задачами, используя полосы задач
в диаграмме Гантта.
УПРАЖНЕНИЕ 9.5. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ИСПОЛЬЗОВАНИЕ ВИДА "ДИАГРАММА
ГАНТТА"
¦ Щелкнуть и удерживать нажатой клавишу мыши на центре полоски задачи 7.
¦ Перетащить курсор мыши до центра полоски задачи 6.
УПРАЖНЕНИЯ
9.6. Как показывать большую часть полного графика или большее количест-
количество деталей.
УПРАЖНЕНИЕ 9.6. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ИСПОЛЬЗОВАНИЕ ЗНАЧКОВ ИЗМЕНЕ-
ИЗМЕНЕНИЯ МАСШТАБА ИЗОБРАЖЕНИЯ
Щелкнуть на значке уменьшения масштаба ("Zoom out") на панели инстру-
инструментов, чтобы видеть большую часть графика.
Обсуждение
Объясните, что использование значков изменения масштаба изображения
("Zoom out" и "Zoom in") - один из способов управления изображением, выводи-
выводимым на экран. Есть также команда "Zoom" ("Масштаб") в меню "View" ("Вид").
УПРАЖНЕНИЯ
9.7. Как перейти к текущей дате завершения в файле MS Project.
УПРАЖНЕНИЕ 9.7. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ПОИСК ДАТЫ ОКОНЧАНИЯ ПРОЕКТА
¦ В меню "Project" ("Проект") выполнить команду "Project Information" ("Ин-
("Информация о проекте").

280 Ф. О'Коннэл. Как успешно руководить проектами
¦ Щелкнуть на кнопке "Statistics" ("Статистика").
¦ Найдите текущую дату окончания.
Обсуждение
Объясните, что дата окончания проекта изменяется при изменениях проекта,
и один из способов найти дату окончания проекта представляет собой использо-
использование кнопки статистики в окне информации о проекте.
УПРАЖНЕНИЯ
9.8. Как устанавливать зависимости, используя столбец "Predecessors"
("предшественники") в "Task Sheet" ("Листе задач").
УПРАЖНЕНИЕ 9.8. УРОВЕНЬ: ДЛЯ ОПЫТНЫХ - ИСПОЛЬЗОВАНИЕ ВИДОВ, ЛИСТ ЗАДАЧ
И СЕТЕВОЙ ГРАФИК
¦ В меню "Window" ("Окно") выполнить команду "Split" ("Разбить") для по-
получения комбинации видов.
¦ Выбрать нижнее окно, щелкнув по нему мышью.
¦ В меню "View" ("Вид") выполнить команду "More Views" ("Больше видов").
¦ Выбрать вид "Network Diagram ("Сетевой график").
¦ Выбрать верхнее окно, щелкнув по нему мышью.
¦ В меню "View" ("Вид") выполнить команду "More Views" ("Больше видов").
¦ Выбрать вид "Task Sheet" ("Лист задач").
¦ Выбрать ячейку задачи 4 в столбце "Predecessors".
¦ Ввести 3 в столбец предшественника и нажать "Enter".
¦ Какова текущая дата окончания проекта?
УПРАЖНЕНИЯ
9.9. Как устанавливать зависимости, используя столбец Ш в виде Task Form
(бланк задачи).
УПРАЖНЕНИЕ 9.9. УРОВЕНЬ: ДЛЯ ОПЫТНЫХ - ИСПОЛЬЗОВАНИЕ ВИДОВ, ДИАГРАММА
ГАНТТА И ФОРМА ЗАДАЧ
¦ Выбрать нижнее окно ("Сетевой График").
¦ В меню "View" выполнить команду "More Views".
' На самом деле в MS Project 2000 сетевой график называется PERT Chart, а не Network
Diagram. - Прим. переводчика.

Приложение 6. Изучение MS Project 281
¦ Выбрать вид "Task Form" ("Бланк задачи").
¦ В меню "Format" ("Формат") выполнить команду "Details" ("Детали").
¦ Выбрать "Predecessor & Successors" ("Предшественники и преемники").
¦ Нажатием кнопок "Previous" ("Предыдущая") или "Next" ("Последующая")
в нижнем окне найдите задачу 6.
¦ Ввести " в столбец "ГО" преемника ("Successor").
¦ Щелкнуть на "ОК".
¦ Какова текущая дата окончания проекта?
Обсуждение
Объясните, что пользователь может устанавливать отношения между задача-
задачами, вводя идентификатор (ГО) предшественника задачи в соответствующий
столбец.
УПРАЖНЕНИЯ
9.10. Как устанавливать зависимости, используя сетевой график.
Комментарий
Будет использован наш файл проекта.
УПРАЖНЕНИЕ 9.10. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ИСПОЛЬЗОВАНИЕ ВИДА, СЕТЕВОЙ
ГРАФИК
¦ В меню "Windows" ("Окно") выполнить команду "Remove Split" ("Убрать раз-
разбиение").
¦ В меню "View" ("Вид") выполнить команду "Network Diagram ("Сетевой
график").
¦ Нажать кнопку мыши на блоке задачи 7 и перетащить курсор к блоку за-
задачи 8.
¦ Какова текущая дата окончания проекта?
УПРАЖНЕНИЯ
9.11. Как устанавливать зависимости между задачами, используя диаграмму
Гантта.
Комментарий
Обратите внимание, что мы все еще используем наш файл проекта.
' Как уже отмечалось, на самом деле этот вид называется PERT Chart. - Прим. переводчика.

282 Ф. О'Коннэл. Как успешно руководить проектами
УПРАЖНЕНИЕ 9.11. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ИСПОЛЬЗОВАНИЕ ВИДА, ДИА-
ДИАГРАММА ГАНТТА
¦ В меню "View" ("Вид") выполнить команду "Gantt Chart" ("Диаграмма Ган-
тта").
¦ Выбрать задачу 8.
¦ Щелкнуть по кнопке панели "Стандартная" Go to Selected Task (переход на
выбранную задачу) (это заставит диаграмму Гантта прокрутиться так, что-
чтобы полоса задачи 8 появилась на экране).
¦ Нажать кнопку мыши на полоске задачи 8 и перетащить курсор к полоске
задачи 9.
¦ Какова текущая дата окончания проекта?
УПРАЖНЕНИЯ
9.12. Практическое упражнение по связыванию задач.
УПРАЖНЕНИЕ 9.12. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - УСТАНОВКА ОТНОШЕНИЙ
¦ Ввести отношения для оставшихся задач, используя любой метод, кото-
который вы предпочитаете.
¦ Какие задачи являются не критическими?
Отмена отношений Существует много способов отмены отношений, как и способов их
введения.
9.12. Как удалять зависимости задач, используя меню.
9.13. Как удалять зависимости задачи, используя кнопку для отмены связы-
связывания задач.
9.14. Как удалять зависимости задач в виде СЕТЕВОЙ ГРАФИК.
УПРАЖНЕНИЕ 9.12. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ИСПОЛЬЗОВАНИЕ ДИАГРАММЫ
ГАНТТА И МЕНЮ
¦ Выбрать курсором задачи 1, 2 и 3.
¦ В меню "Edit" ("Редактирование") выполнить команду "Unlink Tasks" ("От-
("Отменить связывание задач").
УПРАЖНЕНИЕ 9.13. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ИСПОЛЬЗОВАНИЕ ДИАГРАММЫ
ГАНТТА И ПАНЕЛИ ИНСТРУМЕНТОВ
¦ Выбрать курсором задачи 4, 5 и 6.
¦ Нажать кнопку "Unlink Tasks" ("Отменить связывание задач") на панели ин-
инструментов.

Приложение 6. Изучение MS Project 283
УПРАЖНЕНИЕ 9.14. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ИСПОЛЬЗОВАНИЕ СЕТЕВОГО ГРА-
ГРАФИКА
¦ В меню "View" ("Вид") выбрать вид "Network Chart" ("Сетевой график").
¦ Дважды щелкнуть по линии, соединяющей задачи 7 и 8.
¦ В появившемся диалоговом окне нажать кнопку "Delete" ("Удалить").
Обсуждение
Объясните, что есть целый ряд различных способов для удаления связей ме-
между задачами.
УПРАЖНЕНИЯ
9.15. Как установить зависимости для всех задач в файле MS Project.
УПРАЖНЕНИЕ 9.15. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - СВЯЗЫВАНИЕ ВСЕХ ЗАДАЧ ОТНО-
ОТНОШЕНИЕ КОНЕЦ-НАЧАЛО
¦ В меню "View" ("Вид") выбрать диаграмму Гантта.
¦ Выделить все задачи, щелкнув мышью по заголовку столбца "Task Name"
("Имя задачи").
¦ Щелкнуть на значке отмены связи задач.
¦ Щелкнуть на значке связывания задач "Link Task" на панели "Стандартная".
Обсуждение
Объясните, что можно установить или отменить связи для всех задач в файле
MS Project, просто выбрав столбец "Task Name" и используя соответствующий
значок или команду.
МОДУЛЬ 10: ПРИМЕНЕНИЕ КАЛЕНДАРЕЙ
ОРГАНИЗАЦИИ И ПРОЕКТА
Краткий обзор
Модуль применения календарей организации и проекта показывает, как ис-
используются календари в MS Project. Главный урок в этом модуле состоит в на-
настройке календаря и связывании его с текущим проектом.
Цели
Учащийся должен:

284 Ф. О'Коннэл. Как успешно руководить проектами
¦ Знать, как модифицировать стандартный календарь.
¦ Знать, как установить стандартный календарь в качестве календаря проекта.
Подготовка
Ознакомьтесь с содержанием этого модуля и выполните каждое из упражне-
упражнений по крайней мере один раз, чтобы ознакомиться с их логикой и результатами.
Введение
Для каждого упражнения в этом модуле описана его цель, а также подходит
ли уровень этих упражнений для начинающих или опытных пользователей.
УПРАЖНЕНИЯ
10.1. Как добавить праздничные дни к стандартному календарю.
УПРАЖНЕНИЯ 10.1. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - МОДИФИЦИРУЕТ СТАНДАРТНЫЙ
КАЛЕНДАРЬ, ЧТОБЫ ВКЛЮЧИТЬ ОБЩЕГОСУДАРСТВЕННЫЕ ПРАЗДНИКИ
¦ В меню "Tools" ("Инструменты") выполнить команду "Change Working time"
("Изменить рабочее время").
¦ Используя вертикальную полосу прокрутки календаря, переместиться до
октября.
¦ Щелкнуть на последнем понедельнике октября.
¦ Под заголовком Set selected date(s) to (установить выбранные даты как) ус-
установить "Non-working Time" ("Нерабочее время").
¦ Повторить процедуру для всех общегосударственных праздников в тече-
течение текущего года1.
- Новый год.
- 15 января..
- 19 февраля.
- 28 мая.
- 4 июля.
- 3 сентября.
- 8 октября.
- 12 ноября.
Похоже, в список праздников включены и ирландские, и американские. -Прим. переводчика.

Приложение 6. Изучение MS Project 285
- 22 ноября.
- Рождество.
Обсуждение
Объясните, что в MS Project установлена 40-часовая рабочая неделя и суббо-
субботы и воскресенья считаются нерабочими днями. Общегосударственные и прочие
праздники в MS Project не введены.
Календари Календари используются планировщиком, чтобы отобразить
продолжительности задач и проекта на множестве реальных дат.
Календарь позволяет задать учет планировщиком:
• общегосударственных праздников,
• праздников компании,
• выходных
• и рабочих часов
MS Project 2000 предоставляет стандартный календарь, который может
быть модифицирован под нужды пользователя. Рекомендуется иметь
в штате организации одного человека, который бы модифицировал
стандартный календарь и обеспечивал им всех менеджеров проекта.
УПРАЖНЕНИЯ
10.2. Как создавать новый календарь проекта, используя стандартный кален-
календарь.
УПРАЖНЕНИЕ 10.1. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - МОДИФИКАЦИЯ КАЛЕНДАРЯ ПРО-
ПРОЕКТА
¦ В меню "Tools" ("Инструменты") выполнить команду "Change Working time"
("Изменить рабочее время").
¦ В верхнем поле со списком выбрать "Standard (Project Calendar) " ("Стан-
("Стандартный (Календарь проекта)").
¦ Щелкнуть на кнопке "New"... ("Новый").
¦ Назвать новый календарь "Golf и нажать "ОК".
¦ Выбрать от "М" до "Th" в строке заголовка дней недели. Это выбирает ка-
каждый понедельник, вторник, среду и четверг в календаре.
¦ Заменить часы окончания работы (Столбец То:) на 9:00".
¦ Щелкнуть на F в строке заголовка дней недели установить ее в "Non-
working Time" ("Нерабочее время").
¦ Щелкнуть на кнопке К".

286 Ф. О'Коннэл. Как успешно руководить проектами
Обсуждение
Объясните, что календари проектов могут использоваться, чтобы отразить
информацию, связанную с конкретным проектом, такую как рабочие часы или
нерабочие дни. Рабочие часы используются планировщиком для определения,
сколько часов работы доступны каждый день для завершения количества рабо-
работы, которое было вычислено для каждой задачи. Для рассматриваемого проекта
мы получаем 4-дневную неделю и 10-часовой рабочий день. Мы устанавливаем
завершение рабочего дня ежедневно с понедельника до четверга в 19:00 и опре-
определяем пятницы нерабочими днями.
УПРАЖНЕНИЯ
10.3. Как проверить, что проект использует соответствующий календарь.
УПРАЖНЕНИЕ 10.3. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - УСТАНОВКА КАЛЕНДАРЯ ПРОЕКТА
¦ В меню "Project" ("Проект") выполнить команду "Project Information" ("Инфор-
("Информация о проекте").
¦ В поле со списком "Calendar" выбрать "Golf".
¦ Щелкнуть на кнопке К".
Обсуждение
Объясните, что, если не установить календарь проекта, проект будет по умол-
умолчанию всегда использовать стандартный календарь. Создав новый календарь, мы
должны теперь задать для проекта использование этого календаря. Какова теку-
текущая дата конца проекта? Мы все еще работаем 40 часов в неделю, так почему она
изменилась?
МОДУЛЬ 11: СТРУКТУРИРОВАНИЕ ЗАДАЧ
Краткий обзор
Модуль структурирования задач вводит концепцию структурирования задач,
позволяющую рассматривать проект на микро- и макроуровнях детальности.
В нем также показывается, как вставлять повторяющуюся задачу.
Цели
Учащийся должен:
¦ Уметь структурировать проект, чтобы включить составные уровни.
¦ Уметь рассматривать проект или на составном уровне, или на уровне подза-
подзадачи (детализованная задача).

Приложение 6. Изучение MS Project 287
Подготовка
Ознакомьтесь с содержанием этого модуля и выполните каждое из упражне-
упражнений по крайней мере один раз, чтобы ознакомиться с их логикой и результатами.
Введение
Для каждого упражнения в этом модуле описана его цель, а также подходит
ли уровень этих упражнений для начинающих или опытных пользователей.
УПРАЖНЕНИЯ
11.1. Как вставлять составные или укрупненные задачи.
УПРАЖНЕНИЕ 11.1. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ВСТАВКА СОСТАВНЫХ ЗАДАЧ
¦ Открыть файл проекта.
¦ Выбрать задачу "Расчистка территории".
¦ В меню "Insert" ("Вставка") выполнить команду "New Task" ("Новая задача").
¦ Набрать имя новой задачи "Этап 1 - Земляные работы".
¦ Выбрать задачу "Расчистка территории".
¦ Щелкнуть на кнопке сдвига вправо ("Indent") на панели инструментов
"Форматирование".
¦ Обратите внимание на изменение в продолжительности задачи Этап 1 - ...
¦ Обратите внимание на изменение полоски этой задачи.
¦ Выбрать задачи 5, 6 и 7 и щелкнуть на кнопке сдвига вправо.
¦ Повторить для этапа 2 до "Рытье траншей".
¦ Повторить для этапа 3 до "Заключительное профилирование".
¦ Удалить последнюю контрольную точку из этапа 3, сдвинув задачу влево.
Обсуждение
Объясните, что составные или укрупненные задачи служат для разбиения
проекта на разделы, которые могут использоваться для доведения до руковод-
руководства информации более высокого уровня. Продолжительность составной задачи
никогда не задается, поскольку продолжительности всех детализованных задач
ниже составной суммируются в ее продолжительность.

288 Ф. О'Коннэл. Как успешно руководить проектами
Составные задачи Мы достигли в нашем планировании стадии, когда мы должны проверить
весь план и информировать по нему наше руководство. В настоящее
время мы имеем только список задач, так что первый шаг состоит
в несколько лучшей их организации.
Мы идентифицируем три этапа в нашем проекте
• этап 1: земляные работы,
• этап 2: дренаж/ирригация,
• этап 3: ландшафтное проектирование.
Затем они вставляются как укрупненные задачи (другое название
состаиных задач) в наш проект. Составная задача не существует как
определенная задача. Это способ обобщения информации о
деталккованных задачах, расположенных ниже ее.
УПРАЖНЕНИЯ
11.2. Как скрыть или показать детализованные задачи.
УПРАЖНЕНИЕ 11.2. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - СКРЫТИЕ И ПОКАЗ ПОДЗАДАЧ
¦ Выделить все задачи.
¦ Щелкнуть на значке скрытия подзадач (-) на панели инструментов "Фор-
"Форматирование".
¦ Выбрать задачу "Этап 1".
¦ Щелкнуть на значке показа подзадач (+) на панели инструментов "Форма-
"Форматирование".
¦ Чтобы показать все, щелкнуть на значке показа всех подзадач (++) на па-
панели инструментов "форматирование".
¦ Чтобы скрыть или показать подзадачи, нажать на квадратик рядом с на-
названием составной задачи.
Обсуждение
Объясните, что пользователь может управлять информацией, выведенной на
экран дисплея компьютера, свертывая некоторые или все подзадачи или детали-
детализованные задачи в пределах итоговых задач. Это делается посредством малень-
маленьких значков рядом с названием составных задач, содержащих (-) или (+) на них.
Создав некие составные задачи, мы можем теперь вывести создать некоторые
полезные представления наших проектных задач.
УПРАЖНЕНИЯ
11.3. Как ввести повторяющуюся задачу.

Приложение 6. Изучение MS Project 289
УПРАЖНЕНИЕ 11.3. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ВВОД ПОВТОРЯЮЩЕЙСЯ ЗАДАЧИ
¦ Выбрать задачу "Очистка территории".
¦ В меню Insert (Вставка) выполнить команду "Recurring Task" ("Повторяю-
("Повторяющаяся задача").
¦ Ввести название новой задачи "Планерка".
¦ Ввести ее продолжительность  hours".
¦ Выбрать в области "Recurrence pattern" ("Шаблон повтора") "Monthly"
("Ежемесячно"), "First" ("Первый") "Monday" ("Понедельник") "of every
month" ("каждого месяца").
¦ Вставить начальную дату ("Start date") и обратить внимание, что число
вхождений равно шести.
¦ Нажать кнопку "ОК".
¦ Обратить внимание на предупреждающее сообщение, которое появляется
на экране, и выбрать соответствующий ответ.
Обсуждение
Объясните, что такие задачи, как совещания (планерки) или подготовка регу-
регулярных отчетов по состоянию дел, происходят в одно и то же время каждую не-
неделю или месяц и могут быть вставлены в план с помощью команды "Recurring
Task" ("Повторяющаяся задача"). Эти задачи могут модифицироваться или от-
отслеживаться так же, как и обычные задачи.
Повторяющиеся задачи Иногда нам надо запланировать задачу, которая должна происходить на
регулярной основе, например совещания о состоянии дел. Мы можем
легко сделать это с помощью MS Project 2000.
УПРАЖНЕНИЯ
11.4. Как показать составную задачу всего проекта.
УПРАЖНЕНИЕ 11.4. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ВЫВОД СОСТАВНОЙ ЗАДАЧИ НА
УРОВНЕ ПРОЕКТА
¦ В меню "Tools" ("Инструменты") выполнить команду "Options" ("Опции").
¦ Выбрать вкладку "View" ("Просмотр").
¦ Установить флажок "Project Summary task" ("Составная задача проекта").
¦ Нажать кнопку "ОК".

290 Ф. О'Коннэл. Как успешно руководить проектами
Обсуждение
Объясните, что вместо сдвигания всех составных задач под составную зада-
задачу, которая будет представлять весь проект, MS Project может сделать это авто-
автоматически. Составная задача проекта может быть скопирована и вставлена
в другой файл с другими проектами.
УПРАЖНЕНИЯ
11.5. Как показать многоуровневую нумерацию задач на плане MS Project.
УПРАЖНЕНИЕ 11.5. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ВЫВОД МНОГОУРОВНЕВОЙ НУМЕ-
НУМЕРАЦИИ ЗАДАЧ
я В меню "Tools" ("Инструменты") выполнить команду "Options" ("Опции").
¦ Выбрать вкладку "View" ("Просмотр").
¦ Установить флажок "Show Outline Number" ("Показать нумерацию строк").
¦ Нажать кнопку К".
Узнаете WBS (структуру распределения работ)?
Обсуждение
Объясните, что иногда удобно показывать многоуровневую нумерацию для
вашего списка задач. В MS Project она может быть вставлена автоматически.
МОДУЛЬ 12: ПРЕДСТАВЛЕНИЯ ДЛЯ ПЕЧАТИ
Краткий обзор
Модуль представлений для печати показывает, как форматировать диаграмму
Гантта, чтобы включать определенную информацию, которая будет напечатана
на ней. Этот модуль также показывает создание новой таблицы, которая может
распечатываться пользователем.
Цели
Учащийся должен:
¦ Уметь задавать информацию, которая будет напечатана на диаграмме Гантта.
¦ Уметь создавать новую таблицу.

Приложение 6. Изучение MS Project 291
Подготовка
Ознакомьтесь с содержанием этого модуля и выполните каждое из упражне-
упражнений по крайней мере один раз, чтобы ознакомиться с их логикой и результатами.
Введение
Для каждого упражнения в этом модуле описана его цель, а также подходит
ли уровень этих упражнений для начинающих или опытных пользователей.
УПРАЖНЕНИЯ
12.1. Как изменять ширину столбца.
УПРАЖНЕНИЕ 12.1. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ИЗМЕНЕНИЕ ШИРИНЫ СТОЛБЦА
Метод 1
Нажать кнопку мыши на правой вертикальной линии заголовка столбца "Task
Name" ("Название задачи") и, не отпуская кнопки, переместить ее.
Метод 2
¦ Выполнить двойной щелчок на правой вертикальной линии заголовка
столбца "Task Name" ("Название задачи").
¦ Ширина автоматически подстроится для оптимального вывода.
Обсуждение
Объясните, что удобно иметь возможность изменять ширину столбца либо
когда текст обрезан, либо когда столбец слишком узок для выводимых чисел
и в ячейке появляются символы "#####".
УПРАЖНЕНИЯ
12.2. Изменение вывода на экран, для того чтобы увидеть, что будет напечатано.
УПРАЖНЕНИЕ 12.2. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ- ПЕЧАТЬ ВИДА "ДИАГРАММА ГАНТТА"
¦ Изменить изображение на экране так, чтобы выводился столбец "Duration"
("Продолжительность").
¦ В меню "File" ("Файл") выполнить команду "Print" ("Печать").
¦ Нажать на кнопку "Print Preview" ("Предварительный просмотр печати").
¦ Обратить внимание, что курсор изменяет свой вид на изображение лупы.
¦ Нажать кнопку мыши, чтобы просмотреть выводимое изображение более
подробно.

292 Ф. О'Коннэл. Как успешно руководить проектами
Обсуждение
Объясните, что, когда печатается файл проекта, будет выведена только та
информация, которую вы задали. Если перетащить правую границу календарной
секции диаграммы Гантта к правому краю экрана, будет напечатана только таб-
таблица диаграммы Гантта.
Печать Мы теперь хотим распечатать план проекта, чтобы позволить другим
ознакомиться с ним. Мы будем печатать эту информацию двумя
различными способами. Сначала мы распечатаем диаграмму Гантта,
а затем список задач с датами их начала и окончания.
MS Project 2000 обеспечивает два режима печати: печать видов и печать
отчетов. В этом разделе мы будем использовать режим печати видов.
Как видно из названия, в нем печатается вид, отображаемый в момент
печати на экране.
Установка Страницы Для каждого вида и отчета мы можем задавать колонтитулы, поля,
шрифты, цвета и т. д. Первоначально мы будем использовать значения
по умолчанию.
Предварительный Функция предварительного просмотра позволяет видеть на экране то,
просмотр что будет напечатано, до посылки его на принтер. Обратите внимание,
что вам следует всегда предварительно просматривать материалы
прежде, чем начать печатать, чтобы проверить, сколько получится
страниц. Также обратите внимание, что функциональные возможности
операции печати позволяют печатать информацию, попадающую
в диапазон между заданными датами.
Для данной диаграммы Гантта мы напечатаем одну страницу, с кратким
обзором проекта. Мы покажем три столбца данных: ID задач, названия
задач и их продолжительность. Мы не будем печатать легенду.
УПРАЖНЕНИЯ
12.3. Как изменить временной масштаб, используемый при просмотре/печати
диаграммы Гантта.
УПРАЖНЕНИЕ 12.3. УРОВЕНЬ ДЛЯ НАЧИНАЮЩИХ - ПЕЧАТЬ ДРУГОГО ВИДА ДИАГРАМ-
ДИАГРАММЫ ГАНТТА
¦ Модифицировать изображение на экране, чтобы был виден столбец
"Duration" ("Продолжительность").
¦ В меню "Format" ("Формат") выполнить команду "Timescale" ("Масштаб
времени").
¦ Под надписью "Major Scale" ("Основной масштаб"), выбрать "Units: = days"
("Единицы: = дни"), "Count" ("Счет") = 1.
¦ Под надписью "Minor Scale" ("Дополнительный Масштаб") выбрать "Units:
= hours" ("Единицы: = часы"), "Count" ("Счет") = 6.

Приложение 6. Изучение MS Project 293
¦ Нажать кнопку "OK".
¦ В меню "File" ("Файл") выполнить команду "Print" ("Печать").
¦ Нажать кнопку "Print Preview" ("Предварительный просмотр").
(У нас показана легенда, которую мы не хотим печатать).
¦ Нажать кнопку "Page Setup" ("Установка страниц").
¦ Нажать на вкладке "Legend" ("Легенда").
¦ Выбрать "Legend on » None" ("Легенда = Нет"), нажать кнопку "ОК".
Обсуждение
Объясните, что иногда пользователь желает видеть больше или меньше под-
подробностей при печати диаграммы Гантта. Изменение масштаба времени - сред-
средство для отражения уровня требуемых подробностей.
Для данной диаграммы Гантта мы выведем на печать несколько страниц, по-
показывая проект с ежедневным масштабом времени. Мы покажем три столбца
данных задач: Ш, название задачи и продолжительность. Мы не будем печатать
легенду.
УПРАЖНЕНИЯ
12.4. Как создать новую таблицу в файле MS Project.
УПРАЖНЕНИЕ 12.4. УРОВЕНЬ: ДЛЯ ОПЫТНЫХ - СОЗДАНИЕ НОВОЙ ТАБЛИЦЫ
¦ В меню "View" ("Просмотр") выполнить команду "Table" ("Таблица").
¦ Выбрать "More tables" ("Дополнительные таблицы"). Выбрать "Entry".
¦ Нажать кнопку "Сору" и изменить название на "Task & List" ("Задача и спи-
список").
¦ В столбце "Field Name" ("Название поля") выбрать строку, содержащую
"Name" ("Название"). В этой строке выбрать ячейку в столбце "Title" ("За-
("Заголовок").
¦ Изменить "Task Name" ("Название задачи") в этой ячейке на "Activity Name"
("Название деятельности").
¦ Аналогичным образом для строки с "Predecessors" ("Предшественники")
в столбце "Field Name" изменить значение в столбце "Width" ("Ширина") ее
на 8.
¦ В столбце "Title" ("Заголовок") в той же строке "Predecessors" ("Предшест-
("Предшественники") записать "Pred".

294 Ф. О'Коннэл. Как успешно руководить проектами
¦ Для строки "Duration" ("Продолжительность") в столбце "Title" записать
"Effort" ("Трудозатраты").
¦ Выбрать строку с "Name". Нажать кнопку "Insert Row".
¦ Выбрать кнопку выбора (раскрывающаяся стрелка в правом конце пустой
ячейки) в столбце "Name" новой строки.
ш Прокрутить список до "WBS" ("Структура распределения работ") и выбрать ее.
¦ Выбрать строку с "Resource Names".
¦ Нажать на кнопку "Delete Row". Нажать кнопку "ОК".
Обсуждение
Объясните, что пользователь может захотеть создать таблицу, которая пока-
показывает определенную информацию из базы данных. Таблицы можно создавать
или модифицировать, чтобы удовлетворить требованиям пользователя.
Прежде чем мы напечатаем таблицу дат, нам надо модифицировать ее струк-
структуру. Мы создадим новую таблицу, удовлетворяющую нашим требованиям. Ин-
Информация, которая нам нужна, аналогична информации в таблице вида "Task
Sheet" ("Лист задач"), однако нам не нужны детали ресурсов.
УПРАЖНЕНИЯ
12.5. Как просмотреть новую таблицу при выводе вида на экран.
УПРАЖНЕНИЕ 12.5. УРОВЕНЬ: ДЛЯ ОПЫТНЫХ - СОЗДАНИЕ ВИДА, СОДЕРЖАЩЕГО НО-
НОВУЮ ТАБЛИЦУ
¦ В меню "View" ("Вид") выполнить команду "More Views" ("Другие виды").
¦ Выбрать вид "Task Sheet" ("Лист задач"). Нажать кнопку "Apply" ("Приме-
("Применить").
¦ В меню "View" ("Вид") выполнить команду "Table" ("Таблица").
¦ Выбрать "More Tables" ("Другие таблицы").
¦ Выбрать "Task List" ("Лист задач"). Нажать кнопку "Apply" ("Применить").
Обсуждение
Это упражнение показывает пользователю, как просмотреть новую таблицу.
УПРАЖНЕНИЯ
12.6. Как отформатировать информацию, которая должна быть напечатана.

Приложение 6. Изучение MS Project 295
УПРАЖНЕНИЕ 12.6. УРОВЕНЬ: ДЛЯ ОПЫТНЫХ - ФОРМАТИРОВАНИЕ И ПЕЧАТЬ НОВОЙ
ТАБЛИЦЫ
¦ В меню "File" ("Файл") выполнить команду "Page Setup" ("Установка стра-
страницы").
¦ Выбрать вкладку "Header" ("Верхний колонтитул").
¦ Изменяемый элемент: центральная часть верхнего колонтитула (вкладка
"Center") строка 1.
¦ Нажать на кнопку "Format Text Font" ("Форматировать шрифт текста").
¦ Выбрать "Шрифт" = "Times New Roman", "Size" ("Размер") = 4", "Bold"
("Полужирный").
¦ Нажать кнопку "OK".
¦ Изменяемый элемент: центральная часть верхнего колонтитула (вкладка
"Center") строка 2.
¦ Нажать на кнопку "Format Text Font" ("Форматировать шрифт текста").
¦ Выбрать "Шрифт" = "Times New Roman", "Size" ("Размер") = 0", "Italics"
("Курсив").
¦ Нажать кнопку "OK".
Вставка второй строки центральной части верхнего колонтитула
¦ Переместить курсор после "& [Project Title] " ["Заголовок проекта"] и на-
нажать "Enter".
¦ Ввести текст "Task List", нажать "Enter".
¦ Добавить строку для ввода данных о руководителе проекта.
¦ Выбрать "Print Preview" ("Предварительный просмотр") и просмотреть из-
изменения.
Вставка строки нижнего колонтитула
¦ Выбрать вкладку "Footer" ("Нижний колонтитул").
¦ Выбрать левую часть нижнего колонтитула (вкладка "Left").
¦ Ввести текст "Printed on": ("Напечатан на") и, используя кнопки, добавить
дату, время.
¦ Выбрать правую часть нижнего колонтитула (вкладка "Right").
¦ Открыть раскрывающийся список и выбрать "File name" ("Имя файла").
Нажать кнопку "Add" ("Добавить").

296 Ф. О'Коннэл. Как успешно руководить проектами
¦ Выбрать "Print Preview" ("Предварительный просмотр") и просмотреть изме-
изменения.
¦ Если Вы удовлетворены результатом, выполнить команду "Print" ("Печать").
Обсуждение
Это упражнение показывает, как форматировать информацию, которая долж-
должна быть напечатана. Подробности форматирования будут сохранены в файле MS
Project.
МОДУЛЬ 13: НАЗНАЧЕНИЕ РЕСУРСОВ
Краткий обзор
Модуль назначения ресурсов показывает, как назначить один или большее
количество ресурсов на задачу. Он также показывает, как назначить стоимости
ресурсов и как модифицировать календари ресурсов.
Цели
Учащийся должен:
¦ Уметь назначать ресурсы задачам.
¦ Быть в состоянии идентифицировать перекрытия.
¦ Знать, как модифицировать рабочие единицы ресурса.
¦ Уметь назначать стоимости ресурса.
¦ Уметь модифицировать календарь ресурса.
Подготовка
Ознакомьтесь с содержанием этого модуля и выполните каждое из упражне-
упражнений по крайней мере один раз, чтобы ознакомиться с их логикой и результатами.
Ресурс Ресурсы - это люди, оборудование и поставляемые материалы,
используемые для завершения задачи в проекте. Ресурсы
рассматриваются программой MS 2000 Project как отдельные типы
данных, и в проекте могут существовать одна или несколько единиц
разных ресурсных типов.
Назначение Это - выделение ресурса определенного типа для работы
в специфической задаче. MS Project 2000 назначает одну единицу (или
100 %) ресурса для работы полный рабочий день на все время
продолжительности задачи.

Приложение 6. Изучение MS Project 297
Создание Вы можете создавать ресурсы отдельной операцией или же при
назначении на задачу. Можно создавать одиночный ресурс
(с максимальными единицами = 1 или 100 %) или группу ресурсов
(с максимальными единицами > 1 или более 100 %).
Введение
Для каждого упражнения в этом модуле описана его цель, а также подходит
ли уровень этих упражнений для начинающих или опытных пользователей.
УПРАЖНЕНИЯ
13.1. Как назначать ресурс с помощью меню.
13.2. Как назначать ресурс с помощью окна информации о задаче.
13.3. Как назначать ресурс с помощью кнопки назначения ресурсов на пане-
панели инструментов "Стандартная".
13.4. Как назначать ресурс, используя вид "Task Form" ("Бланк задачи").
13.5. Как назначать более одного ресурса, используя кнопку назначения ре-
ресурсов.
УПРАЖНЕНИЕ 13.1. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - НАЗНАЧЕНИЕ ЕДИНСТВЕННОГО РЕСУРСА
МЕТОД 1
¦ Открыть файл "GolflE".
¦ Выбрать задачу 4 "Расчистка территории".
¦ В меню "Tools" ("Инструменты") выполнить команду "Resources" ("Ресурсы")
и далее "Assign Resources" ("Назначение ресурсов").
¦ Появится диалоговое окно "Assign Resources" ("Назначение ресурсов").
¦ В первой ячейке напечатать "Бульдозер". Нажать "Enter".
¦ Выбрать "Бульдозер". Нажать кнопку "Assign" ("Назначить").
¦ Нажать "Close" ("Закрыть").
¦ Ресурс "Бульдозер" теперь назначен на задачу 4.
УПРАЖНЕНИЕ 13.2. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - НАЗНАЧЕНИЕ ЕДИНСТВЕННОГО РЕСУРСА
МЕТОД 2
¦ Выбрать задачу 5 "Грубое профилирование".
¦ Сделать двойной щелчок на задаче 5, чтобы вывести окно информации
о задаче.
¦ Выбрать вкладку "Resources" ("Ресурсы").

298 Ф. О'Коннэл. Как успешно руководить проектами
¦ Выбрать первую ячейку и напечатать "Водитель Бульдозера".
¦ Нажать "ОК".
¦ Водитель бульдозера теперь назначен на задачу 5.
УПРАЖНЕНИЕ 13.3. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - НАЗНАЧЕНИЕ ЕДИНСТВЕННОГО РЕСУРСА
МЕТОД 3
¦ Выбрать задачу 6 "Создание прудов и водных препятствий".
¦ Нажать кнопку назначения ресурсов на панели инструментов "Стандартная".
¦ Добавить "JCB".
¦ Нажать кнопку "Assign" ("Назначить").
¦ Нажать "Close" ("Закрыть").
¦ JCB теперь назначен на задачу 6.
УПРАЖНЕНИЕ 13.4. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - НАЗНАЧЕНИЕ ЕДИНСТВЕННОГО РЕСУРСА
МЕТОД 4
¦ Выбрать задачу 7 " Рытье бункеров".
¦ В меню "Window" ("Окно") выполнить команду "Split" ("Разбить").
¦ В нижнем окне выбрать пространство непосредственно под заголовком
столбца "Resource Name".
¦ Появляется кнопка со стрелкой развертки списка.
¦ Нажать на нее и выбрать "JCB".
¦ Нажать кнопку "ОК".
¦ JCB теперь назначен на задачу 7.
УПРАЖНЕНИЕ 13.5. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - НАЗНАЧЕНИЕ НЕСКОЛЬКИХ РЕСУРСОВ
¦ Выбрать задачу 9 "Рытье траншей".
¦ Нажать кнопку назначения ресурсов из панели инструментов "Стандартная".
¦ Добавить "Водитель JCB" в следующую пустую ячейку.
¦ Выбрать "JCB" и "Водитель JCB".
¦ Нажать кнопку "Assign" ("Назначить").
¦ Нажать кнопку "Close" ("Закрыть").
¦ И JCB, и водитель JCB теперь назначены на задачу 9.

Приложение 6. Изучение MS Project 299
Обсуждение
Объясните, что есть ряд способов назначить ресурс на задачу. Ресурс может
быть неким оборудованием, так же как и человеком. Обратите внимание, что MS
Project 2000 автоматически назначает ресурс на полное рабочее время.
Перекрытие Задачи, которые запланированы на одно и то же время для одного и того
же ресурса, означают, что ресурс намечен на большее количество часов
в день, чем мы определили в разделе рабочих часов рабочего
календаря. MS Project 2000 имеет много способов отобразить
перекрытие. Ресурс с перекрытием будет подсвечен красным в любом из
способов просмотра ресурсов.
УПРАЖНЕНИЯ
13.6. Как идентифицировать ресурс с перекрытием.
УПРАЖНЕНИЕ 13.6. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ПРОСМОТР ИСПОЛЬЗОВАНИЯ РЕСУРСОВ
¦ Открыть файл GolflG.
¦ В меню "View" ("Вид") выполнить команду "Resource Sheet" ("Лист ресурсов").
¦ Обратите внимание, что некоторые ресурсы появляются в красном цвете.
¦ В меню "View" ("Вид") выполнить команду "Resource Graph" ("Диаграмма ре-
ресурсов").
¦ Использовать горизонтальную полосу прокрутки слева для нахождения
ресурса JCB, который будет подсвечен красным.
¦ Используйте горизонтальную полосу прокрутки справа, чтобы прокрутить
недели до 26 июня.
¦ Обратите внимание на количество перекрытия.
¦ В меню "Format" ("Формат") выполнить команду "Details|Work" ("Дета-
ли|Работа").
¦ Вертикальная ось должна измениться на дни, на которые был распределен
ресурс, причем красным показывается перекрытие.
Обсуждение
Объясните, что, когда ресурс имеет перекрытия, он изображается красным на
листе ресурсов, диаграмме ресурсов и видах использования ресурсов. Диаграм-
Диаграмма ресурса показывает число единиц ресурсов, которые перекрываются, но
пользователь может изменять диаграмму на ряд других видов, используя коман-
команду "Details" ("Детали").

300 Ф. О'Коннэл. Как успешно руководить проектами
УПРАЖНЕНИЯ
13.7. Как модифицировать рабочие единицы ресурса.
УПРАЖНЕНИЕ 13.7. УРОВЕНЬ: ДОЯ НАЧИНАЮЩИХ- РЕДАКТИРОВАНИЕ РАБОЧИХ ЕДИНИЦ
¦ В меню "File" ("Файл") выполнить команду "New" ("Новый").
¦ Создать задачи 1, 2 и 3, каждая продолжительностью в две недели. Нажать
"Enter".
¦ Выбрать задачу 1.
¦ Нажать значок назначения ресурсов.
¦ Ввести "Джо" в первую ячейку и нажать "Assign" ("Назначить").
¦ Выбрать задачу 2.
¦ Обратите внимание, что окно назначения ресурсов остается открытым.
¦ Выбрать "Джо" и ввести " в ячейку столбца "Units".
¦ Нажать Assign (Назначить) или нажать Enter.
¦ Закрыть окно назначения ресурсов.
¦ Выбрать задачу 3.
¦ В меню "Window" ("Окно") выполнить команду "Split" ("Разбить").
¦ В бланке задачи (Task Form) в нижней части экрана добавить "Фред"под
названием ресурса и ,5" в столбце "Units".
¦ Нажать кнопку К".
¦ Запомнить часы работы, связанные с задачами 1, 2 и 3.
¦ Выбрать задачу 1.
¦ Изменить значение в столбце "Units" на 50 %. Обратите внимание на из-
изменение в продолжительности задачи.
¦ Выбрать задачу 2.
¦ Изменить значение в столбце "Units" на 100 %. Обратите внимание на из-
изменение в продолжительности задачи.
Обсуждение
Объясните, что MS Project использует формулу, чтобы вычислить количество
времени, которое потребуется для завершения задачи. Это количество времени
называется работой (work), и оно может быть определено только умножением
единиц ресурса на продолжительность задачи.

Приложение 6. Изучение MS Project 301
Единицы х продолжительность = работа
Единицы показывают доступность ресурса. Когда пользователь формирует
план, каждой задаче назначается продолжительность, которая оценивает, сколько
времени будет занимать завершение задачи. Если ресурс доступен только 50 %
времени, то задача будет занимать вдвое больше времени для своего завершения.
Модифицируйте количество единиц, приходящееся на ресурс, если вы знаете, на-
насколько доступен данный ресурс, чтобы видеть, какое влияние это оказывает на
план проекта.
Стоимости Основной источник расходов в проектах представляет собой стоимость
ресурсов. MS Project 2000 автоматически вычисляет эти стоимости при
вычислении работы.
УПРАЖНЕНИЯ
13.8. Как назначать стоимости на ресурс.
УПРАЖНЕНИЕ 13.8. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - НАЗНАЧЕНИЕ СТОИМОСТЕЙ НА РЕСУРСЫ
¦ Открыть файл Golf IF.
¦ В меню "View" ("Вид") выполнить команду "Resource Sheet" ("Лист ресурсов").
¦ В столбце "Standard Rate" ("Стандартные расценки") ввести почасовые или
ежедневные расценки для следующих ресурсов:
¦ Бульдозер - ЗОО/d C00/день).
¦ Водитель бульдозера - ЗО/h (ЗО/ч).
¦ JCB-250/d.
¦ Водитель JCB - 25/h.
¦ Бригада - б/h F/ч).
¦ В меню "Project" ("Проект") выполнить команду "Project Information"
("Информация о проекте").
¦ Нажать кнопку "Statistics" ("Статистика").
¦ Обратите внимание на информацию в столбце "Cost" ("Стоимость").
¦ Нажать на кнопку "Close" ("Закрыть").
¦ В меню "View" ("Вид") выполнить команду "Table" ("Таблица").
¦ Выбрать "Cost" ("Стоимость").

302 Ф. О'Коннэл. Как успешно руководить проектами
Обсуждение
Объясните, что затраты могут быть назначены на ресурс, так что эта инфор-
информация может использоваться для оценки общей стоимости проекта и отслежива-
отслеживания финансовых затрат на проект по мере его выполнения.
УПРАЖНЕНИЯ
13.9. Как модифицировать календарь, чтобы показать свободное время для
одного ресурса.
УПРАЖНЕНИЕ 13.9. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - МОДИФИКАЦИЯ КАЛЕНДАРЕЙ РЕСУРСОВ
¦ Открыть файл Golf IF.
¦ Выбрать задачи "Очистка земли" и "Грубое профилирование".
¦ Обратить внимание на конечные даты задач.
¦ В меню "Tools" ("Инструменты") выполнить команду "Change Working time"
("Изменение рабочего времени").
¦ Выбрать в поле со списком "For: "= "Бульдозер".
¦ Установить три нерабочих дня в мае для его обслуживания и нажать К".
¦ Обратите внимание на изменение в конечных датах для этих двух задач.
Обсуждение
Объясните, что, как только ресурсы назначены на проект, MS Project для ка-
каждого автоматически создает календарь. Он используется для определения еже-
ежегодного отпуска и задания рабочих часов для каждого ресурса.
Календарь Ресурса Связывается с каждым типом ресурса. Он может использоваться для
учета информации об отпусках, а также для определения рабочих часов.
Для каждого типа ресурса можно задать различный набор рабочих дней
и/или часов. Тогда MS Project 2000 будет учитывать их при
планировании задач.
УПРАЖНЕНИЯ
13.10. Как манипулировать несколькими ресурсами - метод 1.
13.11. Как манипулировать несколькими ресурсами - метод 2.
УПРАЖНЕНИЕ 13.10. УРОВЕНЬ: ДЛЯ ОПЫТНЫХ - МНОЖЕСТВЕННЫЕ РЕСУРСЫ 1
¦ В меню "File" ("Файл") выполнить команду "New" ("Новый").
¦ В меню "View" ("Вид") выполнить команду "Resource Sheet" ("Лист ресурсов").

Приложение 6. Изучение MS Project 303
¦ Добавить строки ресурсов "JCB", "Бульдозер", "Оператор", каждый со
значением в столбце Max. Units 500 %.
ш В меню "View" ("Вид") выбрать "Gantt Chart".
¦ В меню "Window" ("Окно") выбрать "Split" ("Разбить").
¦ В меню "Format" ("Формат") выполнить команду "Timescale" ("Масштаб
времени"). Отобразить шкалу времени в днях.
¦ Создать задачу 1, продолжительностью две недели. Нажать "Enter".
¦ Выбрать задачу 1. Нажать на значок назначения ресурса, чтобы отобразить
диалоговое окно назначения ресурсов.
¦ Выбрать "JCB" из столбца названий и нажать на кнопку "Assign". Закрыть
диалоговое окно.
Обратите внимание, что JCB имеет 80 часов работы, чтобы удовлетворить
продолжительности работ в две недели.
¦ Мы решаем, это слишком долго, мы хотим окончить скорее, так что мы
будем использовать два JCB.
¦ В окне бланка задачи ("Task Form") изменить доступность JCB на 200 %.
Нажать К".
¦ Новая продолжительность - одна неделя.
Обратите внимание, что 80 часов работы JCB обеспечивают эту продолжи-
продолжительность.
¦ Создать задачу 2 продолжительность две недели.
¦ Выбрать задачу 2. В меню "Tools" ("Инструменты") выполнить команду
"Resources]Assign Resources" ("Назначение ресурсов").
¦ Добавить "Бульдозер" A00 %) и "Оператор " A00 %).
¦ Закрыть окно. Обратите внимание, что оператор и бульдозер обеспечива-
обеспечивают продолжительность в две недели.
¦ В окне бланка задачи (нижняя часть экрана) изменить параметры бульдо-
бульдозера на 200 %.
¦ Обратите внимание, что теперь оператор является определяющим ресурсом.
¦ Чтобы это ясно зафиксировать, применить вид "Resource Usage" ("Исполь-
("Использование ресурсов") к нижней части экрана.
Чтобы вернуться к виду по умолчанию, выполнить команду "Views|More
ViewsjTask Form". Нажать "Apply" ("Применить").

304 Ф. О'Коннэл. Как успешно руководить проектами
¦ Изменить параметры оператора на 200 %. Нажать К".
¦ Продолжительность - одна неделя, поскольку оператор и бульдозер оба
являются определяющими ресурсами.
¦ Все еще обращаясь к задаче 2, добавить "Диспетчер", 50 %, в бланке зада-
задачи (нижняя часть экрана).
¦ Нажать кнопку "ОК".
Отметьте длительности. Обратите внимание, что оператор и бульдозер все
еще определяют продолжительность.
УПРАЖНЕНИЕ 13.11. УРОВЕНЬ: ДЛЯ ОПЫТНЫХ - МНОЖЕСТВЕННЫЕ РЕСУРСЫ, 2
¦ В меню "File" ("Файл") выполнить команду "New" ("Новый").
¦ Разбить экран.
¦ Создать задачу продолжительностью w" (две недели) под названием
"Покраска стены".
¦ В бланке задачи назначить ресурс "Маляр". Нажать ОК.
¦ Мы должны завершить эту задачу как можно быстрее, так что назначим
второго маляра.
¦ Изменить количество ресурса (единицы) на 200 %. Нажать "ОК".
Что случилось с продолжительностью и почему?
¦ Создать задачу продолжительностью w" (две недели) под названием
"Покраска следующей стены".
¦ В бланке задачи в нижнем окне снять флажок "Effort" ("Трудозатраты").
¦ Назначить "Маляра Джо". Щелкнуть на кнопке "ОК".
¦ Снова мы должны завершить эту работу скорее.
¦ Назначить "Маляра Фреда". Щелкнуть на кнопке К".
Работа удвоилась, вместо того чтобы уполовинить продолжительность. Мы
должны количество работы в задаче разделить на два.
¦ Перейти в верхнее окно, выполнить команду "View|Table|Work".
¦ Разделить на два работу (Work) задачи. Нажать "Enter".
Все, что мы хотели, - работа уменьшилась.

Приложение 6. Изучение MS Project 305
МОДУЛЬ 14: ОПТИМИЗАЦИЯ ГРАФИКА
Краткий обзор
Модуль оптимизации графика показывает, как изменить рабочий график про-
проекта, чтобы сделать его более эффективным, реалистическим и достижимым.
Цели
Учащийся должен: уметь оптимизировать график, удаляя искусственные за-
зависимости, назначая большее количество ресурсов или добавляя опережение.
Подготовка
Ознакомьтесь с содержанием этого модуля и выполните каждое из упражне-
упражнений по крайней мере один раз, чтобы ознакомиться с их логикой и результатами.
Введение
Для каждого упражнения в этом модуле описана его цель, а также подходит
ли уровень этих упражнений для начинающих или опытных пользователей.
УПРАЖНЕНИЯ
14.1. Как устанавливать задачи для параллельного выполнения.
УПРАЖНЕНИЕ 14.1. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ПАРАЛЛЕЛЬНЫЕ ЗАДАЧИ
¦ Открыть файл Golf IF.
¦ Удалить зависимость между задачами 6 и 7.
¦ Удалить зависимость между задачами 7 и 9.
¦ Установить задачи 6, 7, 9 в качестве преемников для задачи 5.
¦ Проверить текущую дату окончания.
¦ Удалить зависимость между задачами 10 и 11.
¦ Установить задачу 11 в качестве преемника для задачи 9.
¦ Проверить текущую дату окончания.
¦ Чтобы представить эффект более наглядно, разбить окно на два и вывести
в нижней части вид PERT Chart ("Сетевой график").
Обсуждение
Объясните, что некоторые задачи могут выполняться одновременно с други-
другими и могут начинаться после завершения некоторой определяющей задачи. Час-
Часто при установке задач в параллель дата завершения приближается. Что мы де-
11-2224

306 Ф. О'Коннэл. Как успешно руководить проектами
лаем, когда конечные даты не соответствуют требованиям? Изменяем задачи-
предшественники, чтобы запустить некоторые задачи в параллельное исполне-
исполнение. Во многих случаях для параллельного исполнения можно исключить зави-
зависимость конец-начало между задачами.
В нашем проекте создания поля для гольфа три задачи по выемке земли ра-
разумно независимы друг от друга, так что мы можем запустить их в параллель.
Две задачи монтирования оборудования ведут себя аналогичным образом.
УПРАЖНЕНИЯ
14.2. Как добавить ресурс, чтобы уменьшить время, требующееся для вы-
выполнения задачи.
УПРАЖНЕНИЯ 14.2. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - СОКРАЩЕНИЕ ПРОДОЛЖИТЕЛЬНО-
ПРОДОЛЖИТЕЛЬНОСТИ ЗАДАЧИ ПУТЕМ ДОБАВЛЕНИЯ РЕСУРСА
¦ Назначить другой ресурс "Ландшафтная бригада" к задаче "Заключитель-
"Заключительная планировка", с восемью единицами (800 %) вместо четырех единиц
D00 %).
¦ Проверить текущую дату окончания.
Обсуждение
Объясните, что одним из средств, доступных руководителю проекта, является
добавление ресурсов для того, чтобы уложиться в заданный срок сдачи.
Добавка Иногда возможно добавить дополнительные ресурсы к задаче, чтобы
дополнительных завершить ее быстрее.
ресурсов
Обсуждение
Объясните, что, когда задачи связаны, задержка в 0 дней, помещенная между
ними, означает, что задача-преемник начинается немедленно после окончания
задачи-предшественника. Это время задержки может быть установлено в другое
значение, чтобы задержать начало задачи-преемника или иметь задачу-
преемника, запускаемую перед окончанием задачи-предшественника. Отрица-
Отрицательное значение показывает перекрытие задержки.

Приложение 6. Изучение MS Project 307
Частичные Это те, для которых отношение имеет дополнительный временной
зависимости фактор. Если взять в качестве примера отношение (конец-начало),
то таким фактором будет задержка между окончанием
задачи-предшественника и стартом задачи-преемника.
Опережение появляется там, где задача-преемник запускается
до окончания задачи-предшественника. Это часто может использоваться
руководителем проекта для сокращения продолжительности проекта.
MS Project 2000 обеспечивает только функциональные возможности
задержки. Это не является проблемой, так как отрицательное значение
в задержке эквивалентно опережению. Для проекта поля для гольфа
высевание газонов может начинаться прежде, чем закончена
планировка ландшафта
УПРАЖНЕНИЯ
14.3. Как устанавливать перекрывающую задержку между задачами.
УПРАЖНЕНИЯ 14.3. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ПЕРЕКРЫВАЮЩИЕСЯ ЗАДАЧИ
¦ В меню "View" ("Просмотр") выполнить команду "PERTChart" ("Сетевой график").
¦ Двойной щелчок на линии, соединяющей задачи 13 и 14.
¦ Ввести значение задержки "-3d". Нажать К".
(Обратите внимание на изменение начальной даты в задаче 14.)
¦ В меню "View" ("Просмотр") выбрать вид "Gantt Chart" ("диаграмма Гантта").
¦ Прокрутить экран к задачам 13 и 14 и обратить внимание на перекрывание
полос задач.
МОДУЛЬ 15: ВЫРАВНИВАНИЕ РЕСУРСОВ
Краткий обзор
Модуль выравнивания ресурсов представляет средства для устранения пере-
перекрытия ресурсов в задачах. Это проделывается вручную руководителем проекта
или автоматически - MS Project 2000.
Цели
Учащийся должен:
¦ Уметь находить перекрывающиеся ресурсы.
¦ Уметь запускать автоматическое устранение перекрывающихся ресурсов.

308 Ф. О'Коннэл. Как успешно руководить проектами
Подготовка
Ознакомьтесь с содержанием этого модуля и выполните каждое из упражне-
упражнений по крайней мере один раз, чтобы ознакомиться с их логикой и результатами.
Введение
Для каждого упражнения в этом модуле описана его цель, а также подходит
ли уровень этих упражнений для начинающих или опытных пользователей.
УПРАЖНЕНИЯ
15.1. Как использовать команду "Timescale" ("Шкала времени").
УПРАЖНЕНИЯ 15.1. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ИЗМЕНЕНИЕ ДИАГРАММЫ ГАНТТА
ДЛЯ ПОКАЗА МЕСЯЦЕВ И НЕДЕЛЬ
¦ Открыть файл "GolflG".
¦ В меню "View" ("Просмотр") выбрать вид "Gantt Chart" ("Диаграмма Гантта").
¦ В меню "Format" ("Формат") выполнить команду "Timescale" ("Шкала вре-
времени").
¦ В "Major scale" ("Основная шкала") выбрать "Months" ("Месяцы").
¦ В "Minor scale" ("Дополнительная шкала") выбрать "Weeks" ("Недели").
¦ Установить "Count" ("Счет") равным 1.
¦ Нажать кнопку К".
Обсуждение
Объясните, что, когда организатор проекта пытается вручную выравнивать
ресурсы, легче увидеть перекрытия на более детальном плане проекта. В этом
случае разумно изменить временную шкалу.
Ручное выравнивание Перед проведением автоматического выравнивания следует
попробовать выполнить ручное выравнивание. Попытайтесь устранить
перекрытия ресурсов следующим образом:
• Задержать старт задачи, вводя задержку
• Увеличить максимальное количество единиц доступного ресурса
• Назначить задаче различные ресурсы
• Изменить отношения между задачами
• Задать сверхурочное время
• Продлить рабочие часы.
Прежде чем начать исследование конкретных перекрытий, надо иметь
подходящую временную шкалу диаграммы Гантта. Мы будем
использовать месяцы и недели

Приложение 6. Изучение MS Project 309
УПРАЖНЕНИЯ
15.2. Как добавить панель инструментов "Resource management" ("Управле-
("Управление ресурсами").
УПРАЖНЕНИЕ 15.2. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ДОБАВЛЕНИЕ ПАНЕЛИ ИНСТРУ-
ИНСТРУМЕНТОВ
¦ В меню "View" ("Просмотр") выбрать команду "Toolbars" ("Панели инстру-
инструментов").
¦ Выбрать панель инструментов управления ресурсами "Resource management".
¦ Посмотрите на новую панель инструментов в верхней части вашего экрана.
Обсуждение
Объясните, что существует панель инструментов специально для управления
ресурсами. Теперь мы выведем эту панель инструментов ресурсов на экран.
УПРАЖНЕНИЯ
15.3. Как использовать кнопку перемещения к перекрытию.
УПРАЖНЕНИЕ 15.3. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ОБНАРУЖЕНИЕ ПЕРЕКРЫТИЯ
¦ Прокрутить экран влево, чтобы отобразить начальную задачу.
¦ Выбрать первую задачу.
¦ В меню "Window" ("Окно") выбрать режим разбиения.
¦ Выбрать нижнее окно.
¦ В меню "View" ("Вид") выбрать вид "Resource Graph" ("Диаграмма ресурсов").
¦ В меню "Format" ("Формат") выбрать "Details|Peak Units" ("Детали|пиковые
единицы").
¦ Перейти в верхнее окно к диаграмме Гантта.
¦ Щелкнуть на кнопке "Go to Overallocation" ("Перейти к перекрытию").
¦ Повторить.
Обсуждение
Объясните, что пользователь может использовать объединенное представле-
представление, чтобы видеть, какие задачи являются перекрывающимися и какой ресурс
является перекрывающимся. Нижнее окно покажет диаграмму ресурсов.

310 Ф. О'Коннэл. Как успешно руководить проектами
УПРАЖНЕНИЯ
15.4. Как ликвидировать перекрытие.
УПРАЖНЕНИЕ 15.4. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - РАЗРЕШЕНИЕ ПЕРЕКРЫТИЙ
¦ Перейти на задачу 6 (первое перекрытие).
¦ Выбрать нижнее окно.
¦ Нажать на кнопку информации. Появляется окно информации о ресурсах.
¦ Ввести для ресурса JCB Max. Units = 200 %. Нажать К".
¦ Повторить для ресурса "Водитель JCB".
¦ На первой неделе все еще есть перекрытие в одну единицу. Как его ликви-
ликвидировать?
¦ Выбрать верхнее окно.
¦ В меню "View" ("Просмотр") выбрать "Tables|MoreTables".
¦ Выбрать "Delay" ("Задержка"). Нажать "Apply" ("Применить").
¦ Применить задержку в семь полных дней к задаче 6.
¦ Обратите внимание, что перекрытие устранено.
Обсуждение
Объясните, что, как разрешаются перекрытия - выбор руководителя проекта.
MS Project не может принимать это решение за вас. В этом упражнении руково-
руководитель проекта выбрал добавление дополнительного ресурса, чтобы устранить
перекрытие. JCB перекрывается потому, что мы имеем две задачи, выполняю-
выполняющиеся параллельно. Мы могли бы переместить одну задачу установки, чтобы
она начиналась после другой, но это неприемлемо увеличит время выполнения.
Вместо этого мы выделяем большее количество ресурсов.
Автоматическое MS Project 2000 проделывает его, задерживая начало задач, пока
выравнивание ресурсы не освободятся.
MS Project 2000 просматривает каждый перекрывающийся ресурс по
очереди и ищет задачи, которые он может задержать для исключения
перекрытия. MS Project 2000 не может задерживать задачу, если задача
удовлетворяет одному из следующих условий
• Должна начинаться.
• Должна завершиться.
• Запаздывает на максимально допустимое время.
• Приоритет = не выравнивать.
Задача не может быть отсрочена, если была введена действительная
дата начала, если только задача не была уже перепланирована.

Приложение 6. Изучение MS Project 311
Для каждой потенциальной задачи MS Project 2000 рассматривает:
• Отношения.
• Резерв времени.
• Дату начала.
• Приоритет.
• Ограничения задачи.
Для того чтобы решить, какую из нескольких задач задерживать,
MS Project 2000 использует следующий порядок задержки (стандартное
выравнивание):
• Самый большой резерв времени.
• Самый высокий приоритет.
• Самый высокий ID.
УПРАЖНЕНИЯ
15.5. Как найти задачи ландшафтной бригады.
15.6. Альтернативный способ вывода списка задач, связанных с ландшафт-
ландшафтной бригадой.
УПРАЖНЕНИЕ 15.5. УРОВЕНЬ: ДЛЯ ОПЫТНЫХ - КАК НАЙТИ ЗАДАЧИ ЛАНДШАФТНОЙ
БРИГАДЫ
¦ Выбрать верхнее окно.
¦ В меню "View" ("Просмотр") выбрать "Resource Sheet" ("Лист ресурсов").
¦ Выбрать нижнее окно.
¦ В меню "View" ("Просмотр") выбрать "More views| Resource Form" ("Бланк
ресурса"). Нажать кнопку "Apply" ("Применить").
¦ Выбрать в верхнем окне "ландшафтная бригада".
УПРАЖНЕНИЕ 15.6. УРОВЕНЬ: ДЛЯ ОПЫТНЫХ - КАК НАЙТИ ЗАДАЧИ ЛАНДШАФТНОЙ
БРИГАДЫ (другой способ)
¦ Выбрать верхнее окно.
¦ В меню "View" ("Просмотр") выбрать "Resource Usage" ("Использование ре-
ресурсов").
¦ Выбрать нижнее окно.
¦ В меню "View" выбрать "Gantt Chart" ("Диаграмму Гантта").
¦ Выбратьв верхнем окне "ландшафтная бригада".
¦ Задачи команды отображаются в нижнем окне.
¦ Прокрутите временную шкалу, чтобы отобразить задачи.

312 Ф. О'Коннэл. Как успешно руководить проектами
Обсуждение
Объясните, что есть различные способы показать информацию так, чтобы
руководитель проекта мог принимать решения о том, как разрешать перекры-
перекрытия. В этих упражнениях мы хотели увидеть задачи, на которые была назначе-
назначена ландшафтная бригада. Мы также хотели проверить использование ланд-
ландшафтной бригады и задач, которыми они занимаются.
УПРАЖНЕНИЯ
15.7. Как автоматически выравнивать перекрывающиеся ресурсы.
15.8. Как производить автоматическое выравнивание с использованием ус-
установок приоритетов.
УПРАЖНЕНИЕ 15.7. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ВЫРАВНИВАНИЕ РЕСУРСА, ВСЕ ЗА-
ЗАДАЧИ ПОДОБНЫ
¦ Создать новый проект.
¦ Создать четыре задачи, А, В, С и D, с трудозатратами в один день каждая.
¦ Выделить все четыре задачи.
¦ Нажать кнопку назначения ресурса и назначить "Джо".
¦ Разбить окно. Выбрать нижнее окно.
¦ В меню "View" выбрать "Resource Graph" ("Диаграмма ресурсов").
¦ В меню "Tools" ("Инструменты") выполнить команду "Resource Leveling"
("Выравнивание ресурсов").
¦ Нажать "Level now" ("Выровнять теперь"), затем выбрать "Entire pool".
УПРАЖНЕНИЯ 15.8. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ВЫРАВНИВАНИЕ РЕСУРСА, РАЗ-
РАЗЛИЧНЫЕ ПРИОРИТЕТЫ
¦ В меню "Tools" ("Инструменты") выполнить команду "Resource Leveling"
("Выравнивание ресурсов").
¦ Нажать кнопку "Clear Leveling" ("Отменить выравнивание").
¦ В меню "Tools" ("Инструменты") выполнить команду "Resource Leveling"
("Выравнивание ресурсов").
¦ Выбрать в поле со списком "Leveling Order" ("Порядок выравнивания")
"Priority, Standard" ("Приоритет, Стандартный"). Нажать "ОК".
¦ Выбрать задачу D. Нажать на значок информации о задаче.
¦ Выбрать вкладку "General" ("Общий"), установить "Priority" ("Приоритет")
= 550. Нажать "ОК".

Приложение 6. Изучение MS Project 313
¦ В меню "Tools" ("Инструменты") выполнить команду "Resource Leveling"
("Выравнивание ресурсов").
¦ Нажать кнопку "Level now".
Обсуждение
Объясните, что автоматическое выравнивание делается MS Project на основа-
основании доступности ресурсов. Если в проекте есть ограничения, это повлияет на то,
как MS Project выравнивает перекрытия. Если для задач установлены приорите-
приоритеты, это также влияет на то, как MS Project выравнивает перекрытия.
МОДУЛЬ 16: ИСПОЛЬЗОВАНИЕ ОПОРНОГО ГРАФИКА
Краткий обзор
Модуль опорного графика вводит использование концепции сохранения ко-
копии плана проекта в конце периода планирования. После завершения планиро-
планирования MS Project может сохранить копии дат начала и окончания каждой задачи.
Это называется опорным графиком (baseline). Опорный график используется для
сравнения движения проекта относительно исходного плана.
Цели
Учащийся должен:
¦ Знать различие между опорным графиком, текущим и фактическим.
¦ Знать, как сохранять опорный график.
Подготовка
Ознакомьтесь с содержанием этого модуля и выполните каждое из упражне-
упражнений по крайней мере один раз, чтобы ознакомиться с их логикой и результатами.
Введение
Для каждого упражнения в этом модуле описана его цель, а также подходит
ли уровень этих упражнений для начинающих или опытных пользователей.
УПРАЖНЕНИЯ
16.1. Как устанавливать опорный график для файла в MS Project.
УПРАЖНЕНИЕ 16.1. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - УСТАНОВКА ОПОРНОГО ГРАФИКА
¦ Открыть GolflH.
¦ В меню "Tools" ("Инструменты") выполнить "Tracking" ("Прослеживание").

314 Ф. О'Коннэл. Как успешно руководить проектами
¦ Выбрать "Save Baseline" ("Сохранение опорного графика").
¦ Выбрать "for Entire project" ("Для всего проекта").
¦ Нажать кнопку "ОК".
¦ В меню "Project" ("Проект").
¦ Выбрать команду "Project Information" ("Информация о проекте").
¦ Нажать кнопку "Statistics".
Обсуждение
Объясните, что опорный график устанавливается только тогда, когда пользо-
пользователь уверен, что план был разработан до точки, где он может отслеживаться
и модифицироваться по мере необходимости. Есть несколько правил, которым
надо следовать, относительно опорных графиков и момента, когда они должны
переустанавливаться. Обратите внимание также, что MS Project обеспечивает
запись информации опорного графика, плановой (текущей) информации и ин-
информации в процессе выполнения (фактической).
Опорный график Запись первоначально запланированных дат, продолжительности, работ
и затрат задач.
Переустановка Опорный график можно устанавливать более одного раза, если график
опорного графика слишком сильно отклоняется от плана или если был определен ряд
дополнительных задач.
Есть три набора дат, идентифицируемых MS Project 2000 при использовании
опорного графика:
Текущие Заложенные в рабочий график даты начала и окончания каждой задачи.
Они могут изменяться с каждой поправкой, которую вы делаете к плану.
Опорный график Исходные даты начала и окончания каждой задачи, которые сохранены
в опорном графике.
Фактическая Даты начала выполняемых задач или даты начала и окончания
завершенных задач.
МОДУЛЬ 17: ОБНОВЛЕНИЕ ДЛЯ ОТРАЖЕНИЯ
ФАКТИЧЕСКОГО ВЫПОЛНЕНИЯ ПРОЕКТА
Краткий обзор
Этот модуль показывает, как отслеживать проект, используя состояние каж-
каждой задачи.

Приложение 6. Изучение MS Project 315
Цели
Учащийся должен уметь отслеживать продвижение плана.
Подготовка
Ознакомьтесь с содержанием этого модуля и выполните каждое из упражне-
упражнений по крайней мере один раз, чтобы ознакомиться с их логикой и результатами.
Введение
Для каждого упражнения в этом модуле описана его цель, а также подходит
ли уровень этих упражнений для начинающих или опытных пользователей.
УПРАЖНЕНИЯ
17.1. Как добавить панель инструментов отслеживания и установить теку-
текущую дату.
УПРАЖНЕНИЕ 17.1. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - КОМБИНАЦИЯ ВИДОВ ДЛЯ ОБ-
ОБНОВЛЕНИЯ И УСТАНОВКИ ДАТЫ
¦ Открыть файл Golf2A.
¦ В меню "View" ("Просмотр") выбрать вид диаграммы Гантта.
¦ Установить курсор на панели инструментов, нажать правую кнопку мыши,
выбрать из контекстного меню "Tracking" ("отслеживание").
¦ В меню "Project" ("Проект") выполнить команду "Project Information" ("Ин-
("Информация о проекте").
¦ Установить текущую дату = 1 июня 2000".
¦ Нажать кнопку "ОК".
Обсуждение
Объясните, что панель инструментов "Tracking" ("Прослеживание") - удоб-
удобный инструмент при прослеживании исполнения плана. Чтобы продемонстриро-
продемонстрировать различные способы отслеживания проекта, мы модифицируем состояние
этого проекта на 21 июня 2000 года. Есть два подхода к контролю состояния
проекта в процессе его выполнения:
¦ Обновление на основе подхода "задача за задачей" с использованием состоя-
состояния задач.
¦ Обновление на основе подхода "ресурс за ресурсом" с использованием ресур-
ресурсов работы.

316 Ф. О'Коннэл. Как успешно руководить проектами
В MS Project 2000 может использоваться любой из них, хотя обновления на ос-
основе состояния задачи - намного проще, так как MS Project 2000 обеспечивает для
этого ряд инструментальных средств. Независимо от того, какой метод использу-
используется, требуется некоторая система администрирования проекта, чтобы собирать
необходимые данные.
Информация о состоянии, в которой вы нуждаетесь в каждое время обновле-
обновления, включает:
¦ даты фактического запуска каждой задачи или ее завершения,
¦ как долго задача выполнялась,
¦ какой объем работ осталось выполнить для завершения на момент вашей
проверки состояния.
Вы можете обновить все даты вручную или позволить MS Project 2000 авто-
автоматически обновить их для вас. Чтобы обновить вручную, необходимо исполь-
использовать соответствующий вид - диаграмму Гантта с таблицей отслеживания.
УПРАЖНЕНИЯ
17.2. Как использовать мышь и курсор, чтобы обновить состояние проекта.
УПРАЖНЕНИЕ 17.2. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ОБНОВЛЕНИЕ СОСТОЯНИЕ ПРОЕКТА
СПОМОШЬЮМЫШИ
Информация состояния для обновления на 21 июня:
задача 2 завершена,
задача 4 завершена и закончена на два дня раньше,
задача 5 сделана наполовину.
¦ Указать курсором на левую вертикальную границу полосы задачи 2 (курсор
изменяется на %) и тащить его вправо до состояния завершенности задачи.
¦ Указать курсором на правую вертикальную границу полосы задачи 4 (кур-
(курсор изменяется на вертикальную черту) и тащить его влево приблизитель-
приблизительно на 3,5 недели (увеличить масштаб в случае необходимости).
¦ Указать курсором на левую вертикальную границу полосы задачи 4 и та-
тащить его вправо до состояния завершенности задачи.
¦ Указать курсором на левую вертикальную границу полосы задачи 5 и та-
тащить его вправо до половины срока окончания.

Приложение 6. Изучение MS Project 317
¦ В меню "View" ("Просмотр") выбрать "More views|Tracking Gantt" ("Отслежи-
("Отслеживающая диаграмма Гантта"). Нажать кнопку "Apply" ("Применить").
Обсуждение
Объясните, что пользователь может обновить план проекта непосредственно
на диаграмме Гантта, используя курсор. Курсор изменяет форму в зависимости
от того, где он находится на полосах задач в календарном разделе диаграммы
Гантта.
УПРАЖНЕНИЯ
17.3. Как использовать таблицу отслеживания, чтобы модифицировать со-
состояние проекта.
УПРАЖНЕНИЕ 17.3. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ОБНОВЛЕНИЕ СОСТОЯНИЯ ПРОЕК-
ПРОЕКТА С ПОМОЩЬЮ ТАБЛИЦ
Информация состояния для обновления на 2 августа:
Задача 5 завершилась через шесть недель вместо пяти.
Задачи 6,1,9, 10 выполняются по плану.
Задача 11 началась только 15 июля из-за плохой погоды.
¦ Установить текущую дату = 2 августа 2000.
¦ В меню "View" ("Вид") выбрать "More views|Task sheet" ("Лист задач").
¦ В меню "View" ("Вид") выбрать "Table|Tracking" ("Прослеживание").
¦ Ввести фактические продолжительности задач: 5 = 30d, 6 = 14d, 7 = 6d,
9 = 5d, 10 = 9d. Обратите внимание, что обновляются и другие значения
столбца.
¦ Установить для задачи 11 фактическое начало 15 июля.
¦ В меню "View" ("Вид") выбрать диаграмму Гантта. Нажать кнопку "ОК".
Обсуждение
Объясните, что при попытках обновить проект, используя только курсор,
можно столкнуться с некоторыми трудностями. При использовании таблицы
отслеживания для обновления проекта пользователь может изменять продолжи-
продолжительности задач и начальные даты, вставляя требуемые данные в таблицу.

318 Ф. О'Коннэл. Как успешно руководить проектами
УПРАЖНЕНИЯ
17.4. Как автоматически обновить состояние проекта.
УПРАЖНЕНИЕ 17.4. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - АВТОМАТИЧЕСКОЕ ОБНОВЛЕНИЕ
СОСТОЯНИЯ ПРОЕКТА
Информация состояния для обновления на 30 августа:
Задачи 6,7, 10 закончены по графику.
Задача 11 все еще имеет проблемы.
Проект теперь серьезно отстает от графика, и мы должны предпринять неко-
некоторое корректирующее действие.
¦ Набрать текущую дату = 30 августа 2000 г.
¦ Выбрать задачи 6, 7,10.
¦ В меню "Tools" ("Инструменты").
¦ Выбрать "Tracking" ("Прослеживание").
¦ Выбрать "Update Project" ("Обновить проект").
¦ Установить "For: Selected Tasks".
¦ Нажать кнопку К".
¦ Выбрать задачу 11.
¦ В меню "Tools" ("Инструменты").
¦ Выбрать "Tracking" ("Прослеживание").
¦ Выбрать "Update Tasks" ("Обновить задачи").
¦ Ввести в поля "Actual dur = d" ("Фактическая продолжительность" = "три
дня"), "Remaining dur = 5d" ("Оставшаяся продолжительность = пять
дней").
Обсуждение
Объясните, что в MS Project пользователь может обновить состояние проекта
автоматически. При этом пользователь имеет выбор: обновлять весь проект или
обновлять только выбранные задачи. Это упражнение показывает, как обновлять
только выбранные задачи.

Приложение 6. Изучение MS Project 319
МОДУЛЬ 18: НЕСКОЛЬКО ПРОЕКТОВ
Краткий обзор
Модуль нескольких проектов показывает, как управлять несколькими проек-
проектами в MS Project 2000.
Цели
Учащийся должен:
¦ Знать, как использовать пул ресурсов, чтобы управлять несколькими проек-
проектами.
¦ Знать, как объединить ряд проектов в один файл MS Project.
Подготовка
Ознакомьтесь с содержанием этого модуля и выполните каждое из упражне-
упражнений по крайней мере один раз, чтобы ознакомиться с их логикой и результатами.
Введение
Для каждого упражнения в этом модуле описана его цель, а также подходит
ли уровень этих упражнений для начинающих или опытных пользователей.
УПРАЖНЕНИЯ
18.1. Как устанавливать пул ресурсов для использования в более чем одном
проекте.
УПРАЖНЕНИЕ 18.1. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ИСПОЛЬЗОВАНИЕ ПУЛА РЕСУРСА
¦ В меню "File" ("Файл") выполнить команду "New" ("Новый").
¦ В меню "View" ("Просмотр") выбрать "Resource Sheet" ("Лист ресурсов").
¦ Ввести Джо, Фреда, Мэри, Энн.
¦ В меню "File" ("Файл") выполнить команду "Save As" ("Сохранить как"),
Имя файла - Resource.
¦ В меню "File" ("Файл") выполнить команду "New" ("Новый").
¦ Создать задачи 1, 2, 3.
¦ В меню "Tools" ("Инструменты") выполнить команду "Resources|Share
Resources" ("Общие Ресурсы").
¦ Выбрать "Use Resources from Resources project" ("Использование Ресурсов из
проекта Ресурсов"). Нажать кнопку "ОК".

320 Ф. О'Коннэл. Как успешно руководить проектами
¦ Назначить Джо на задачу 1. Назначить Мэри на задачу 2. Назначить Фреда
на задачу 3.
¦ В меню "File" ("Файл") выполнить команду "New" ("Новый").
¦ Создать задачу А, задачу В, задачу С.
¦ В меню "Tools" ("Инструменты") выполнить команду "Resources|Share
Resources" ("Общие Ресурсы").
¦ Выбрать "Use Resources from Resources project" ("Использование ресурсов из
проекта ресурсов"). Нажать кнопку К".
¦ Назначить Фреда на задачу А. Назначить Мэри на задачу В. Назначить
Энн на задачу С.
¦ В меню "Window" ("Окно") выбрать файл проекта "Resources".
¦ Выполнить команду "View| Resource Sheet" ("Лист ресурсов").
¦ Обратите внимание на перекрывающиеся ресурсы, обозначенные крас-
красным.
¦ В меню "Window" ("Окно") выполнить команду "Split" ("Разбить").
¦ Выбрать перекрывающийся ресурс.
¦ Бланк ресурса отображается в нижней части экрана.
Обсуждение
Объясните, что при наличии ограниченного количества ресурсов и ряда про-
проектов, над которыми они работают, можно создать центральный пул и брать ре-
ресурсы из него. Команда "Share Resources" ("Общие Ресурсы") позволяет брать
ресурсы из другого файла MS Project. Это один метод отслеживания, как ваши
ресурсы перекрываются из-за того, что они работают в ряде проектов одновре-
одновременно. Этот метод также позволяет разрешать проблему перекрытий.
УПРАЖНЕНИЯ
18.2. Как разместить более одного проекта в новом файле MS PROJECT.
УПРАЖНЕНИЕ 18.2. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - СОВМЕСТНЫЙ ОТЧЕТ 0 НЕСКОЛЬ-
НЕСКОЛЬКИХ ПРОЕКТАХ
¦ Открыть все проекты, для которых будет формироваться отчет.
¦ В меню "Window" ("Окно") выполнить команду "New".
¦ Выбрать требуемые проекты.
¦ Нажать кнопку "ОК".

Приложение 6. Изучение MS Project 321
Обсуждение
Объясните, что бывают времена, когда может потребоваться объединить ряд
проектов в одном файле MS Project. Данное упражнение объясняет, как это де-
делается. Обратите внимание, что любые изменения, внесенные в этот файл, отра-
отражаются в исходных файлах.
Просмотр отдельных Можно просматривать вместе любые проекты, без создания связи между
проектов ними. Откройте каждый проект отдельно и используйте команду "New"
меню "Window", чтобы объединить виды. Это можно использовать для
печати отчетов из более чем одного проекта.
УПРАЖНЕНИЯ
18.3. Как добавлять субпроекты к файлу MS Project.
УПРАЖНЕНИЕ 18.3. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - УДАЛЕНИЕ ЭТАПА 1 В СУБПРОЕКТЕ
¦ Открыть GolfZA.
¦ Выбрать детализованные задачи в этапе 1 D - 7).
¦ Нажать кнопку "Cut" ("Вырезать") для удаления законченных задач.
¦ Нажать на кнопку "New file" ("Новый файл").
¦ Нажать на кнопку "Paste" ("Вставить").
¦ В меню "File" ("Файл") выполнить команду "Save" ("Сохранить"), Имя файла =
Phase 1.
¦ В меню "Window" ("Окно") выбрать файл Golf2A.
¦ Удалить строку три и выполнить команду вставки проекта "Insert| Project".
¦ Выбрать файл "Phase 1" и вставить проект.
¦ Изменить продолжительность задачи в проекте "Phase 1" и просмотреть
изменение продолжительности задачи "Этап 1".
Обсуждение
Объясните, что в некоторых случаях пользователь желает вставить проект
или часть проекта в файл MS Project. Данное упражнение объясняет, как это
сделать. Обратите внимание, однако, что функции вырезки и вставки не сохра-
сохраняют начальные даты, первоначально установленные в файле GolGA. Этот ме-
метод может использоваться при установке шаблонов проектов, например, в зада-
задачах локализации.

322 Ф. О'Коннэл. Как успешно руководить проектами
Связывание Эта концепция почти идентична концепции структурирования. Вместо
субпроектов составной задачи при структурировании здесь такой задачей является
отдельный внешний проект. Начальные и конечные даты этой задачи-
субпроекта устанавливаются внешним проектом. Это дает возможность
иметь много субпроектов и сводить их в один или более составных
проекта.
Можно разрабатывать свои проекты в этом формате с самого начала
или, что более обычно, обнаружив, что проект становится слишком
большим для управления, можно произвести его разделение в процессе
выполнения.
Используйте этот метод, чтобы установить шаблоны проектов.
МОДУЛЬ 19: ИСПОЛЬЗОВАНИЕ ОТЧЕТОВ
Краткий обзор
Модуль использования отчетов показывает, как генерировать отчеты с помо-
помощью функции Reports в пакете MS Project 2000.
Цели
Учащийся должен уметь создавать и печатать разнообразные отчеты, исполь-
используя функцию "Reports" ("Отчеты").
Подготовка
Ознакомьтесь с содержанием этого модуля и выполните каждое из упражне-
упражнений по крайней мере один раз, чтобы ознакомиться с их логикой и результатами.
Введение
Для каждого упражнения в этом модуле описана его цель, а также подходит
ли уровень этих упражнений для начинающих или опытных пользователей.
УПРАЖНЕНИЯ
19.1. Как открывать и просматривать каждый отчет с помощью функции
"Reports" ("Отчеты").
УПРАЖНЕНИЕ 19.1. УРОВЕНЬ: ДЛЯ НАЧИНАЮЩИХ - ЗНАКОМСТВО С ТИПАМИ ОТЧЕТОВ
¦ В меню "View" ("Просмотр") выполнить команду "Reports" ("Отчеты").
¦ Имеется пять групп встроенных отчетов.
¦ Просмотрите каждый отчет.

Приложение 6. Изучение MS Project 323
Обсуждение
Объясните, что MS Project 2000 имеет ряд встроенных отформатированных
отчетов, которые будут печатать определенную информацию в табличном фор-
формате. Каждый отчет дает только определенную информацию, которая может
быть использована в некоторый момент в проекте для отчета по определенным
темам. Обратите внимание, что можно создавать собственные отчеты, используя
функции настройки отчетов или применяя команду фильтрации, чтобы изменить
информацию, выводимую на экран.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
И ДАЛЬНЕЙШЕЕ ЧТЕНИЕ
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
Amundsen, Roald A912). The South Pole. John Murray
Boehm, Barry A981). Software Engineering Economics. Prentice Hall
Brooks, P.P. A975). The Mythical Man-Month, Addison-Wesley1
Brooks, F.P. A987). No Silver Bullet: Essence and Accidents in Software
Engineering2. IEEE Computer, April Catton, Bruce A960). Pictorial History of the
Civil War. American Heritage Publishing Co.
Catton, Bruce A961). The Coming Fury. Washington Square Press Catton, Bruce
A963). Terrible Swift Sword. Washington Square Press Catton, Bruce A965). Never
Call Retreat. Washington Square Press Clausewitz A984). On War. Penguin Classics
DeMarco, Tom A978). Structured Analysis and Systems Specification. Prentice Hall
DeMarco, Tom and Lister, Timothy A987). People Ware. Dorset House Publishing
Eberts, Jake and Ilott, Terry A990). My Indecision is Final. Faber and Faber
Fisher, Roger and Ury, William A981). Getting to Yes. Hutchinson Business
Griffiths, Trevor A986). Judgement Over the Dead. Verso
Hampton, Henry and Frayer, Steve A990). Voices of Freedom. Bantam
Huntford, Roland A985). Shackleton. Hodder and Stoughton
Huntford, Roland A985). The Last Place on Earth. Pan Books
Huntford, Roland A993). Scott and Amundsen. Wiedenfeld and Nicholson
Macdonald, John A984). Great Battlefields of the World. Michael Joseph
Macdonald, Lyn A978). They Called It Passchendaele. Macmillan
Macdonald, Lyn A983). Somme. Michael Joseph
McMurtry, Larry A990). Lonesome Dove. Pan Books
1 Юбилейное издание 1995 года издано на русском языке издательством "Символ-Плюс": "Ми-
"Мифический человеко-месяц", Фредерик Брукс, СПб, 2000 г. - Прим. переводчика.
2 Перепечатана в юбилейном издании книги "Мифический человеко-месяц". - Прим. переводчика.

Список использованных источников 325
Milne, A.A. A923). The House at Pooh Corner. Methuen
O'Connell, Fergus A999). How to Run Successful High Tech Project-Eased
Organizations. Artech House
Puttnam, Laurence H. and Myers, Ware A992). Measures for Excellence. Yourdon Press
Rothery, Brian A991). ISO 9000. Gower
Terraine, John A977). The Road To Passchendaele. Leo Cooper
Дальнейшее чтение
Ballard, Robert A987). The Discovery of the Titanic. Hodder and Stoughton
Boorman, John A985). Money Into Light, Faber and Faber
Bradley, Ken A993). PRINCE: A Practical Handbook. Butterworth-Heinemann
Bruce, Phillip and Peterson, Sam M. A982). The Software Development Project.
Wiley-lnterscience
Cherry-Garrard, Apsley A983). The Worst Journey in the World. Penguin Books
Conrad, Joseph A912). Recollections on the loss of the Titanic. New English Review,
May
Crosby, Phillip A979). Quality is Free. McGraw-Hill
Davie, Michael A986). The Titanic. The Bodley Head
DeMarco, Tom A982). Controlling Software Projects. Yourdon Press
Frey, James N. A987). How to Write a Damn Good Novel. St. Martin's Press
Fussell, Paul A975). The Great War and Modern Memory. Oxford University Press
Giles, John A977). The Somme Then And Now. Bailey Brothers and Swinfen
Gliddon, Gerald A987). When the Barrage Lifts. Gliddon Books
Gracie, Colonel Archibald A991). Titanic. The Blackstaff Press
Huntford, Roland A987). The Amundsen Photographs. Hodder and Stoughton
International Standards Organization A987). ISO 9001 - Quality Systems - Model for
Quality Assurance in Design, Development, Production, Installation and Servicing.
First Edition

326 Ф. О'Коннэл. Как успешно руководить проектами
Limb, Sue and Cordingley, Patrick A982). Captain Gates - Soldier and Explorer.
Batsford
Lord, Walter A981). A Night To Remember. Penguin Books
Marcus, Geoffrey A969). The Maiden Voyage. Alien & Unwin
Mear, Roger and Swan, Robert A987). In The Footsteps of Scott. Jonathan Cape
Middlebrook, Martin A971). The First Day on the Somme. Alien Lane
Orr, Philip A987). The Road to the Somme. The Blackstaff Press
Ponting, Herbert A921). The Great White South. Duckworth Railing, Christopher
A983). Shackleton. BBC
Savours, Ann A974). Scott's Last Voyage- Through the Antarctic Camera of Herbert
Ponting. Sidgwick and Jackson
Scott, Robert Falcon A914). Scott's Last Expedition B vols). Smith, Elder & Co.
Scott, Robert Falcon A983). Scott's Last Expedition. Methuen
Seymour, William A982). Tours to Reason Why - Decision in Battle. Sidgwick and
Jackson
The Times History of the War
Tolkien, J.R.R. A968). The Lord of the Rings. Alien & Unwin
Wade, Wyn Craig A980). The Titanic - End Of A Dream, Penguin Books
Ward, Geoffrey C, Burns, Ric and Burns, Ken A990). The Civil War. American
Documentaries
Watson, Arnold and Watson, Betty A984). Roster of Valor - The Titanic Halifax
Legacy. 7 C'S Press
Weinberg, Gerald M. A975). An Introduction to General Systems Thinking. John
Wiley & Sons
Wiener, Lauren Ruth A993). Digital Woes - Why We Should Not Depend on
Software. Addison-Wesley
Winkler, John A989). Winning Sales and Marketing Tactics. Butterworth Heinemann
Yule, Andrew A988). David Puttnam: The Story So Far. Mainstream Publishing Co.

Предметный указатель
А
А-12 штурмовик 128
В
Beck, Andreas 70
Bjaaland, Olav 70,135
Boehm, Barry 115
Brooks, Fred 14,15,50
С
Cam, Dee 124
CASE-технологии 205
Catton, Bruce 113
D
DeMarcoJom 6,9,17
E
Eberts,Jake 16
Evans, P. 0 112
F
Fisher, Roger 196,198
G
Gandhi 16
Griffiths, Trevor 135
H
Hanssen, Helmer 70,135
Hastings, битва при A066) 184
Huntford, Roland 27,69,110,232
Hussein, Saddam 179
I
ISO 9000 процедура оценивания 211-224
WBS 212-214
образец ,...219-225
выбранный вариант 218
доступность ресурса 214
идентификация вариантов 217-218
модель проекта 215
непредвиденные обстоятельства 215-217
J
3ohansen, Hjalmar 54
К
King, Martin Luther 29
L
Lincoln, Abraham 113
Lister, Timothy 6,17
M
Macdonald, Lyn 85,113,184
McClellan, General George В 113
McMurtry, Larry 56
Microsoft Project 2000 см. MS Project 2000
MS Project 2000
Help 269-274
виды
печать 291-297
применение 274-277
задачи
зависимости 277-284
обновление 127,315-319
продолжительности 265-269
создание 260-265
структурирование 287-291
знакомство 254-255
календари организации и проекта 284-287
меню 256-258
непредвиденные обстоятельства 77
несколько проектов 319-322
опорный график 313-314
оптимизация рабочего графика 306-308
основы управления проектами 252-253
отчеты 322-323
перечисление задач, которые надо выполнить 48-49
ресурсы
выравнивание 308-314
распределение 297-303
установки по умолчанию 258-260
Myers, Ware 30,80,120
N
Nansen, Fridtjof 54
0
Oates, Laurence 112
O'Connell 227
P
PERT 306
диаграммы 246
MS Project 284

328
Предметный указатель
PSI см. Индикатор вероятности успеха
Puttnam, Laurence H 30,80,120
R
Rothery, Brian 43
s
SaLLust 81
Shackleton, Ernest 27
T
Terraine,John 113
и
Ury, William 196,198
W
Walker, Harold В 188
Wayne John 56
WBS см. структура распределения работ
A
административная деятельность 152
альфа-тестирование
WBS 151
жизненный цикл программной разработки 129,133
Амундсен, Роальд
запас на ошибки 84
знание, что происходит 110-111
информированиелюдей о происходящем 117
планирование 50
приз 135
пример PSI 232-233,239,240
распределение задач по людям 69-70
стиль руководства 54
цель 27-29
анализ верхнего уровня 152-154
примеры 167
Аттенборо, Сэр Ричард 16
Б
бег 190,191
беременность 242-243
бета-тестирование, жизненный цикл
программной разработки 129,133
битва при Passchendaele 113
битва при Сомме A916)
запасная позиция 85
неожиданные результаты 114
пример PSI 234-235,239,240
цель 28
болезни 112
Брукса Закон 137,238,245
бюджет 245
анализ содержания 148-149
написание плана 175
В
варианты
выбранный 218
идентифицирование 217-218
взятие в клещи 185-186
внешние вмешательства 111
Война в Заливе 186
пример PSI 237-238,239,240
ворота 191
вспыльчивость, как метод
решения проблемы 183
Второй Закон управления проектами 137
выбор времени, решение проблем 187
выбранный вариант 218
выспать решение 187
выходные 191
Г
глоссарий 245-248
групповое мышление 206
д
дата поставки
анализ диаграммы Гантга 163
идентификация вариантов 217-218
непредвиденные обстоятельства 79-80,216
отчеты о состоянии 143
управление ожиданиями 80
двойной обхват 185-186
действие 247
делегирование 210
демонстрации/прототипы 83
Десять Этапов 23-26,92-93
и другие методики. 226-227
применения 10
успех 6-7
детализованная задача 245
диаграмма организационной структуры
анализ содержания 148-149
написание плана 176
руководство 57-59
диаграммы Гантга 246
анализ 152-154
обзорный,
верхнего уровня 153-154,167,169,171-172
все задачи 162-163

Предметный указатель
329
критический путь 160-162
примеры 164-169,171
в содержании 149
написание плана 175
неделя Ленивого руководителя проекта 122
обновление 127
отчеты о состоянии 121,143
персональная 140-141
процедура оценивания ISO 9000 215
распределение задач по людям 71,72
дневная программа, руководители
проектов 144-145
дневники 191
доверие
стиль руководства 98-100,104
Форма 2: 100,104
доктрина "без сюрпризов" 114
отчеты о состоянии 121
документация
WBS 151
образец 225
большие затраты времени 204
варианты, идентификация 217-218
Е
ежемесячная программа,
руководители проектов 139-141
еженедельная программа
руководителя проекта 122-124,142-143
Ж
журналы контроля изменений 31,250-251
за и против, запись 186
зависимость 246
завышение оценки 87-88
задача 246
задачи 246,247
заискивание 184
Закон Паркинсона 172
занятость вне проекта 63-66
запасные позиции См. непредвиденные
обстоятельства
Запрос Коммерческих Предложений (RFP) 154
зарядка положительными эмоциями 183
затраченное время 241,246
затягивание времени 113
зафиксированный график
MS Project 313-314
рабочий график 246
зацикливание на проблеме 189
знать, что происходит 106-116
вкладвР51 116,231
инструментальные средства, применение
плана в качестве 106-110
отрицательные признаки 112-115
положительные признаки 110-112
приложение к разработке программного
обеспечения 115
И
игра в баллы 179
игра с контролем изменений 80
игра, смотреть на проект как на 190
идеальные решения
переговоры 197
решение проблем 178
иерархическая структура команды 66-67
извинения 184
изменения
управление 248
цели 29-31,112,250-251
Индикатор вероятности успеха (PSI) 25,228
анализ 155,238-240
вычисление 228-231
порог 136-137
примеры 167-168,169-170,172-173,231-238
Этап 10: приз 138
Этап б: использование подходящего
стиля руководства 105
Этап 7: знать, что происходит 116
Этап 8: информировать людей о происходящем 124
Этап 9: повтор Этапов 1-8: 133
Этапы 1-5: 95-96,136
Этап 1: наглядное
представление цели 37-38
Этап 2: перечисление задач, которые
надо сделать 51
Этап 3: руководитель 59-60
Этап 4: распределение
задач по людям 74
Этап 5: управление ожиданиями
и непредвиденные обстоятельства 89
интересы, сосредоточиться на 197
информировать людей
о происходящем 117-124
BWiaflBPSI 124,231
Неделя Ленивого руководителя проекта 122-124
отчеты о состоянии 119-122
цикл жизни разработки ПО 132

330
Предметный указатель
йога 190
К
календари, MS Project 284-287,302
калькуляция 246
каменная стена 181
Канны, битва при B16 ВС) 185-186
карты контроля оценок (ESC) 249
анализ рабочего
графика и трудозатрат 157,159,160,174
неделя Ленивого
руководителя проекта 122,143
качество
WBS 151-152
образец 225
анализ диаграммы Гантта 163
идентификация вариантов 217-218
непредвиденные обстоятельства 80,216
отчеты о состоянии 120
управление ожиданиями 80
Клаузевиц 184
командный дух 112,204
комплектация штата
WBS 151
план 214
компьютеризованное планирование
анализ загрузки ресурсов 162
анализ критического пути 160-162
выбранный вариант 218
наличие ресурсов 214
ежемесячная программа
руководителя проекта 140-141
знать, что происходит 106-107,114
идентификация вариантов 217-218
непредвиденные обстоятельства 77
обновление плана 127,132
распределение задач по людям 69,215
см тате MS Project 2000
структура распределения работ (WBS) 213
контрольные точки 242,246
Б0 9000 процедура оценивания 218
MS Project 267
анализ содержания 148-149
написание плана 175
невыполненные 112
примеры 243,244
корпоративная культура 207
кризисы 112,113
критерий завершения
анализ содержания 148-149
написание плана 175
критерии приемки
анализ содержания 148-149
написание плана 175
критический путь 242,244-245,246
MS Project 278-279
анализ 160-162
знать, что происходит 115
примеры 243,244
культурные факторы 207
Л
Ленивый руководитель проекта 92
ежедневная программа 144-145
ежемесячная программа 139-141
еженедельная программа 122-123,142-143
знать, что происходит 106-110
обновление плана 127
стиль руководства 100-104
м
марафонский бег 191
машина слухов 114
медитация 190
методологии и структурное
управление проектом 190
множество проектов одновременно
MS Project 320-323
ежедневная программа 144-145
ежемесячная программа 139-141
еженедельная программа 142-143
модель проекта 215
выбранный вариант 218
мозговой штурм 180
запасная позиция 86
переговоры 197
ускоренный анализ и разработка 129
монолитная структура команды 65, бб
моральный дух 110-111,112
мотивация 29
Н
набор персонала 192-195
образец WBS 224
наглядное представление цели 27-38
вкладвР51 37-38,229
методы 31-32
приложение к разработке программного
обеспечения 34-37
цикл жизни разработки ПО 129,131,132
наезды на людей 187
найм людей 192-195
образец WBS 224

Предметный указатель
331
написание планов проектов 175-176
национальная культура 207
невозможные проекты
взятие 88
отказ браться за 81-82
независимая обратная связь 111,113
неожиданные результаты 114
непредвиденные обстоятельства 77-80
"без сюрпризов" 108
Б0 9000 процедура оценивания 215-216
анализ содержания 148-149
взятое в клещи 185-186
вкладвРБТ. 89,230
написание плана 176
повторение Этапов 1-8: 126
поиск 78-80
примеры 84-86
сверхурочные 123
явные или спрятанные 77-78
О
обзорный анализ
содержания плана 148
написания плана 175-176
обмен в решении проблем 183
обновление плана
MS Project 314-318
выбор времени для 127-128
обратная связь, независимая 111,113
обучение
WBS 150,151
образец 224
распределение задач по людям 69
общее видение 111
объективные стандарты 197-198
объем работ см. трудозатраты
обязательства по проекту 82-83
ожидания, управление 76,80-82
Вкладе PSI 89
повтор Этапов 1-8: 126
пример 84
См. также непредвиденные обстоятельства
освоенной стоимости концепция 115-116
отражатели 180
отрицательные признаки в проекте 112-115
отступление, мнимое 184-185
отчеты 246
отчеты о состоянии 119-122
еженедельная программа Ленивого
руководителя проекта 124,143
обновление плана 127
оценка Паркинсона 87
оценивание 246
Б0 9000 процедура 211-224
WBS 212-214
выбранный вариант 218
доступность ресурса 214
идентификация вариантов 217-218
модель проекта 215
непредвиденные обстоятельства 215-216
образец WBS 219-225
подведение итогов 135-136
оценивание проектных планов 146-148
написание проектных планов 175-176
примеры 164-174
проверки второго уровня 155-162
проверки первого уровня 148-155
проверки третьего уровня 162-163
ошибки 113
MS Project 263-264
ошибки, запас на См. непредвиденные
обстоятельства
П
пари 186
Первый закон руководства
проектами 30,216
переговоры 196-198
управление ожиданиями 80
переменные издержки 246
перечисление всех задач,
которые надо сделать 39-52
BKnaflBPSI 51-52,229
вопросники 41
приложение к разработке
программного обеспечения 42-50,42-50
Форма 1 41-42
цикл жизни разработки ПО 130-131,132
плавание 190
План проекта 246
планирование совещаний 122,143
плоская структура команды 65,66
повтор Этапов 1-8: 126-134
вкладвР51 133
выбор времени обновления плана 127-128
приложение к разработке
программного обеспечения 128-133
подарок себе 187
подбор правильных людей 192-195
подведение итогов 135-136
поделиться проблемами 191

332
Предметный указатель
подход ничегонеделания
в решении проблем 180-181
положительные признаки в проекте 110-112
поставки 247
анализ содержания 148-149
написание плана 175
постепенный разогрев проблемы 182
поэтапная поставка 79
предельный срок 247
предшественник 247
презентации 201-202
приз 135-138
вклад в PSI 138
подыведение итогов 135-136
пороговые значения PSI 136-137
приложение к разработке
программного обеспечения 137-138
принципиальные переговоры 196-198
принятие решений 177-187
ускоренный анализ и разработка 203-209
притворное отступление 184-185
программирование 150-151
продажа чего-то непрятного 183
проект Telecom Ireland Software (TIS) 42-50
проекты 247
как изменение сотояния 21
как путешествия 21
календарь, MS Project 284-287
мониторинг 246
природа 21-22
калькуляция 246
управление 248
промежуточная цель 247
прототипы 83
пульт управления, план как 106-110
Р
рабочего графика
и трудозатрат анализ 155-160
Б0 9000 процедура оценивания 218
написание плана 175
пример 173
рабочий график 241
MS Project 306-308
примеры 242,244
разработка верхнего уровня, цикл
жизни разработки ПО 129,131
разработка нижнего уровня, цикл жизни
разработки программного обеспечения 129,132
разработка продукта 150
разработка тестовой среды,
образец WBS 224
разрешение проблем 177-187
распределение задач по людям 61-74
Б0 9000 процедура оценивания 215
анализ ресурсов 154-155
BwiaflBPSI 74,230
другие обязанности людей 63-66
иерархическая структура команды 66-67
максимизация сил 67
однородная команда
или плоская структура 66
приложение к разработкам ПО 71,71-74
примеры 65-66,70
Форма 2: 70
резерв времени 247
резюме управления проектом
анализ содержания 148-149
написание 175
Рейган, Рональд 182
рейтинги популярности 179
рекогносцировка 181
ресурсы 247
MS Project
выравнивание 307-313
добавление 307
запас (пул) 319-320
календари 302
назначение 296-302
создание 298-300
анализ 162
примеры 167,169,172
доступность 214
загрузка
анализ 162
анализ содержания 148-149
написание плана 175
распределение 247
требования
анализ содержания 148-149
написание плана 275
решение проблем 177-187
ускоренный анализ и разработка 203-209
риски, анализ 245
См. также непредвиденные обстоятельства
руководитель 53-60
вклад в PSI 59-60,229-230
написание плана 176
повтор Этапов 1-8: 126
приложение к разработке программного
обеспечения 57-59

Предметный указатель
333
примеры 57-59
ролевая модель 56-57
трудозатраты на управление проектом 64-66
ускоренный анализ и разработка 205-206,208
цикл жизни разработки ПО 131
руководитель проекта 247
сверхурочные 123
семинары,
ускоренный анализ и разработка 205
сертификация по ISO 9001,
проект получения 42-50
силы, максимизация 67
системы автоматизации
программирования (CASE) 205
Скотт, Роберт Фалькон
допуск на ошибки 84
знать, что происходит 112
информировать людей
о происходящем 117,124
планирование 50
приз 135
пример PSI 231-232,239,240
распределение задач по людям 69-70
стиль руководства 55
управление ожиданиями 84
цель 27-28
собеседование
метод 192-193
вопросы 193-195
совещания 199-200
организация и проведение 200
планирование 122,143
поглощаемое время 204
тревожные признаки 199-200
содержание, проектные планы
анализ 148-149
примеры 166,168,171
написание 175
сокращение проектов 203-209
сокращения 242
сопровождение См. техническая поддержка
составные задачи 247
MS Project 287-291
спецификация (RS) 130
спортивные занятия 190
средняя наработка на отказ (MTTD)
непредвиденные обстоятельства 80
отчеты о состоянии 120
ставить себя в чью-то позицию
переговоры 197
решение проблем 197
ставки, фиксированная цена
две 87
игра с контролем изменений 88
стадия 247
стадия выпуска, образец WBS 223-224
стадия выработки требований и планов,
цикл жизни разработки ПО 129,130-131
стадия выработки требований
к ПО, образец WBS 219-220
стадия выработки требований
на продукт, образец WBS 219
стадия запуска в эксплуатацию
и сопровождения, образец WBS 224
стадия программирования, образец WBS 222
стадия проектирования
архитектуры, образец WBS '. 220
стадия разработки деталей, образец WBS 221-222
стадия тестирования модулей, образец WBS 222
стадия тестирования продукта
в целом, образец WBS 223
стадия тестирования
системы, образец WBS 223
стандарты 207
стиль руководства 97-105
вкладвР51 105,230
Ленивый руководитель проекта 100-104
приложение к разработке программного
обеспечения 104
стоимости
MS Project 302-303
непредвиденные обстоятельства 79-80
управление ожиданиями 80
столкновения индивидуальностей 112
стресс, борьба с 189-191
структура команды 66
структура распределения работ (WBS) 150,245
ISO 9000 процедура оценивания 212-214
образец 219-225
анализ содержания 148-149
написание плана 175
примеры 150-152,164-165,166,168-169,171
субзадачи, MS Project 289
субпроекты, MS Project 321
сюрпризы
доктрина "без сюрпризов" 114
знать, что происходит 108-110,114

334
Предметный указатель
таблицы истинности
переговоры 197
решение проблем 181
тактичность 207
текучесть кадров 112
тестирование, WBS 151,151
техническая поддержка
разработки, образец WBS 224
техническая поддержка, WBS 150,151
технический секретарь, ускоренный
анализ и разработка 205,208
Титаник 86
требования
анализ 150
написание плана 175
трудозатраты 241,248
анализ диаграммы Гантта 162,165
идентификация вариантов 217-218
непредвиденные обстоятельства 79-80,216
отчеты о состоянии 120
примеры 242,244
Си. также рабочего графика
и трудозатрат анализ
У
удовольствие 110-111,112
уныние 113
управление конфигурациями, WBS 151
образец 224-225
управление ожиданиями
См. ожидания, управление
управление проектом
MS Project 252-255
WBS 150,151
образец 224
упражнения, связанные
с вентиляцией легких 190
ускоренный анализ
и разработка (УАР) 130,203-209
практические соображения 208-209
риски 206-207
установки, фиксированная цена
две 87
игра с контролем изменений 88
Ф
факторы успеха 248
фиксированные цены
две 87
игра с контролем изменений 88
фильтры 248
формы запроса на изменения 250
функциональность
анализ диаграммы Гантта 163
идентификация вариантов 217-218
непредвиденные обстоятельства 79,216
отчеты о состоянии 143
управление ожиданиями 80
ц
цель 248
анализ содержания 148-149
идентификация 27
изменения 29-31,113,250-251
мотивация команды 29
наглядное представление см. наглядное
представление цели
написание плана 175
обоснование 28-29
общее видение 111
определение 27-28
цикл жизни разработки ПО 129
циклы жизни разработки
продукта (PDLCs) 129
Ч
"Что бы Вы сделали на моем месте?"
переговоры 197
решение проблем 183
чувство меры 189-190
Ш
шахматы 178-179
экспертизы 137-138
эмпирические правила 242
этап реализации
WBS 151
цикл жизни разработки ПО 129,133

Содержание
ПРЕДИСЛОВИЕ К РУССКОМУ ИЗДАНИЮ 5
ПРЕДИСЛОВИЕ К НОВОМУ ИЗДАНИЮ 5
ПРЕДИСЛОВИЕ КО ВТОРОМУ ИЗДАНИЮ б
БЛАГОДАРНОСТИ 8
ПРЕДИСЛОВИЕ К ПЕРВОМУ ИЗДАНИЮ 9
ОБ АВТОРЕ 13
ВВЕДЕНИЕ 14
СЕРЕБРЯНАЯ ПУЛЯ 14
БЛАГОДАРНОСТИ ЗА РАЗРЕШЕНИЯ 19
ЧАСТЫ 21
АНАЛИЗ И ПЛАНИРОВАНИЕ ПРОЕКТОВ 21
ГЛАВА 1 Этап 1: НАГЛЯДНОЕ ПРЕДСТАВЛЕНИЕ ЦЕЛИ; НАЦЕЛЬТЕСЬ НА ПРИЗ 27
ГЛАВА 2 Этап 2: СДЕЛАЙТЕ СПИСОК ЗАДАЧ, ПОДЛЕЖАЩИХ ВЫПОЛНЕНИЮ 39
ГЛАВА 3 Этап 3: ДОЛЖЕН БЫТЬ ОДИН РУКОВОДИТЕЛЬ 53
ГЛАВА 4 Этап 4: РАСПРЕДЕЛЕНИЕ ЗАДАЧ ПО ЛЮДЯМ 61
ГЛАВА 5 Этап 5: УПРАВЛЯЙТЕ ОЖИДАНИЯМИ,
УСТАНОВИТЕ ДОПУСК НА ОШИБКИ, ОБЕСПЕЧЬТЕ ЗАПАСНЫЕ ПОЗИЦИИ 76
ЧАСТЬ 2 90
КОНТРОЛЬ И ОСУЩЕСТВЛЕНИЕ ПЛАНА ДОСТИЖЕНИЕ ЦЕЛИ 90
ВВЕДЕНИЕ 90
ГЛАВА 6 Этап 6: ИСПОЛЬЗУЙТЕ ПОДХОДЯЩИЙ СТИЛЬ РУКОВОДСТВА 97
ГЛАВА 7 Этап 7: ЗНАЙТЕ, ЧТО ПРОИСХОДИТ 106
ГЛАВА 8 Этап 8: СООБЩАЙТЕ ЛЮДЯМ, ЧТО ПРОИСХОДИТ 117
ГЛАВА 9 Этап 9: ПОВТОРЯЙТЕ ЭТАПЫ 1-8 ДО НАСТУПЛЕНИЯ ЭТАПА 10 126
ГЛАВА 10 Этап 10: ПРИЗ 135
ЧАСТЬ 3 139
ОДНОВРЕМЕННОЕ ВЕДЕНИЕ НЕСКОЛЬКИХ ПРОЕКТОВ 139
ГЛАВА 11 ЕЖЕМЕСЯЧНАЯ ПРОГРАММА "ЛЕНИВОГО РУКОВОДИТЕЛЯ ПРОЕКТА" 139
ГЛАВА 12 ЕЖЕНЕДЕЛЬНАЯ ПРОГРАММА РУКОВОДИТЕЛЯ ПРОЕКТА 142
ГЛАВА 13 ДНЕВНАЯ ПРОГРАММА РУКОВОДИТЕЛЯ ПРОЕКТА 144

336 Ф. О'Коннэл. Как успешно руководить проектами
ЧАСТЬ 4 146
КАК ОЦЕНИВАТЬ ПЛАНЫ ПРОЕКТОВ 146
ГЛАВА 14 ОЦЕНКА ПЛАНОВ ПРОЕКТОВ 146
ЧАСТЬ 5 177
ОСТАЛЬНЫЕ СРЕДСТВА 177
ГЛАВА 15 РАЗРЕШЕНИЕ ВОПРОСОВ: УСТРАНЕНИЕ ПРОБЛЕМ И ПРИНЯТИЕ РЕШЕНИЙ 177
ГЛАВА 16 СНЯТИЕ НАПРЯЖЕНИЯ 188
ГЛАВА 17 ВЫБОР ПРАВИЛЬНЫХ ЛЮДЕЙ 192
ГЛАВА 18 ПЕРЕГОВОРЫ 196
ГЛАВА 19 СОВЕЩАНИЯ 199
ГЛАВА 20 ПРЕЗЕНТАЦИИ > 201
ГЛАВА 21 СОКРАЩЕНИЕ СРОКОВ ПРОЕКТОВ С ПОМОЩЬЮ УСКОРЕННОГО АНАЛИЗА
И РАЗРАБОТКИ 203
ПОСЛЕСЛОВИЕ ДЕЛЕГИРОВАНИЕ (ИЛИ РЕАЛЬНАЯ РАДОСТЬ УПРАВЛЕНИЯ) 210
ПРИЛОЖЕНИЯ 211
ПРИЛОЖЕНИЕ 1 ПРОЦЕДУРА ОЦЕНКИ ISO 9000 211
ПРИЛОЖЕНИЕ 2 СТРУКТУРНОЕ РУКОВОДСТВО ПРОЕКТОМ ("ДЕСЯТЬ ЭТАПОВ") И ДРУГИЕ
МЕТОДИКИ 226
ПРИЛОЖЕНИЕ 3 ИНДИКАТОР ВЕРОЯТНОСТИ УСПЕХА 228
ПРИЛОЖЕНИЕ 4 ОСНОВНЫЕ ПРИНЦИПЫ И ГЛОССАРИЙ ТЕРМИНОВ 241
ПРИЛОЖЕНИЕ 5 ДОПОЛНИТЕЛЬНЫЕ ФОРМЫ 249
ПРИЛОЖЕНИЕ 6 ИЗУЧЕНИЕ MS PROJECT 251
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ И ДАЛЬНЕЙШЕЕ ЧТЕНИЕ 324
Предметный указатель 327

«...Хорошо знакомый программный проект весьма напоминает таких оборотней
(по крайней мере, в представлении менеджеров, не являющихся техническими
специалистами) тем, что, будучи простым и невинным на вид, он может стать
чудищем проваленных графиков работы, раздувшихся бюджетов и неработающих
продуктов. И мы слышим отчаянные крики с просьбами дать серебряную пулю -
нечто, способное снизить стоимость программных продуктов так же резко, как
снизилась стоимость компьютеров.
Но, вглядываясь в предстоящее десятилетее, мы не видим никакой серебряно!^
пули. Нет ни одного открытия ни в технологии, ни в методах управления, одно
только использование которых обещало бы хоть на порядок величин повысить
производительность, надежность, простоту. »
Из книги Фредерика Брукса «Мифический человеко-месяц»
Возможно, вас также заинтересуют другие наши издания
принят
УЯРАВШЧЕСШ
Pf Ш1ИИЙ
Rational
Unified Process
-что легко
B. И. Варфоломеев,
C. Н. Воробьев
Принятие управленческих
решений
ISBN 5-93378-019-7
П. Кролл,Ф. Крачтен
Rational Unified Process -
это легко
ISBN 5-9579-0019-2
Л. Маккарти
1Т-безопасность:
стоит ли рисковать
корпорацией?
ISBN 5-9579-0013-3
Э. Спарроу
Успешный
IT-аутсорсинг
ISBN 5-9579-0041-9
ПРИГЛАШАЕМ
АВТОРОВ КНИГ ПО КОМПЬЮТЕРНОЙ ТЕМАТИКЕ,
ПЕРЕВОДЧИКОВ И НАУЧНЫХ РЕДАКТОРОВ
По вопросу приобретения книг обращайтесь в издательство.
Наш адрес: ул. Профсоюзная, д. 84/32, под. б, эт. 11, из лифта направо
КУДИЦ-ОБРАЗ
тел./факс: @95) 333-82-11,333-65-67; i
E-mail: ok@kudits.ru; http://books.kudits.ru
121354, Москва, а/я 18, "КУДИЦ-ОБРАЗ"