Скотт БеркунИскусство управления

IT-проектамиСерия «Бестселлеры

O`Reilly (Питер)»

http://www.litres.ru/pages/biblio_book/?art=8320841Скотт Беркун. Искусство управления IT-проектами: Питер;

Санкт-Петербург; 2014ISBN 978-5-388-00543-4

Оригинал: ScottBerkun, “Making Things Happen Mastering ProjectManagement”

Перевод:Н. Вильчинский

АннотацияВ отличие от множества трудов, посвященных

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

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

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

СодержаниеОб авторе 11Благодарности 12

К новому изданию 12К предыдущему изданию 13

Введение 16Предисловие 19

Для кого предназначена эта книга 22Предположения о вас, читатель,придерживаясь которых я работал надэтой книгой

26

Как нужно читать эту книгу 28Глава 1. Краткая история управленияпроектами (и почему ей стоит уделитьвнимание)

30

Использование исторического опыта 32Нужно учиться на ошибках 38Веб-разработка, кухни и пункты первойпомощи

42

Роль управления проектами 48Управление программами и проектами вMicrosoft

52

Взвешенность при руководствепроектами

57

Давление и распри 63Путаница в понятиях процесса и целей 65

Нужная степень вовлеченности 70Преимущество собственного взглядана происходящее

72

Руководители проектов создаютуникальные ценности

75

Выводы 79Упражнения 81

Часть 1. Планирование 84Глава 2. Правда о календарных планах 84

Три цели составления календарныхпланов

86

Решающие факторы и методологии 91На что похож календарный план 95

Разделяй и властвуй (большиепланы равны множеству мелких)

100

Почему рушатся планы 105Выстрел вслепую издалека 106Календарный план – это оценкавероятности

109

Расчет – дело тонкое 113Качественное проектирование –залог хороших расчетов

116

Элементарные просчеты 121Эффект снежного кома 125

Что должно произойти, чтобыкалендарные планы заработали

127

Выводы 132Упражнения 133

Глава 3. Как определить, что делать 136Снятие покрова таинственности свопросов планирования программныхпродуктов

138

Типы проектов 141Как на планирование влияет егоорганизация

142

Документы, разрабатываемые приобычном планировании

146

Подходы к планированию – тривзгляда на проект

150

Взгляд бизнесмена 151Взгляд разработчика 156Взгляд потребителя 160

Магия единой точки зрения 164Баланс сил 170

Постановка правильных вопросов 172Ответы на правильные вопросы 175Что делать при дефиците времени? 176

Перечень типичных просчетов приопределении конечной цели проекта

177

Процесс планирования 178

Повседневная работа 182Исследование потребительскихзапросов и допускаемые при этомпросчеты

184

Объединяем все вместе – выработкатребований

190

Проблемы превращаются всценарии

194

Объединение деловых итехнологических требований

197

Выводы 198Упражнения 200

Глава 4. Разработка качественныхконцептуальных документов

203

В чем ценность ведения записей 205Какой по объему концептуальныйдокумент вам нужен?

207

Общекомандные и индивидуальныецели

210

Пять качеств хорошей концепции 215Простота 215Целенаправленность 216Консолидирующая способность 218Вдохновляющая способность 219Запоминаемость 220

Ключевые моменты 221

Умение четко излагать мысли 226Простота дается не легко 226У хорошей разработки только одинглавный автор

228

Качество не определяется объемом 230Прикидки, пересмотры и переработки 231Перечень неудачных положенийконцепции (которых следует избегать)

237

Примеры концептуальных положенийи целей проекта

239

Обоснование концептуальныхположений и целей

241

Концепции должны быть наглядными 242Наглядное представлениенеочевидных вещей

245

Ежедневное поклонениеконцептуальным положениям

248

Выводы 251Упражнения 252

Конец ознакомительного фрагмента. 255

Скотт БеркунИскусство управления

IT-проектамиИнформация, содержащаяся в данной книге, полу-

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

© ООО Издательство «Питер», 2014

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

©Электронная версия книги подготовлена компани-

ей ЛитРес (www.litres.ru)

Об авторе

Скотт Беркун изучал информатику, философию и

дизайн в университете Карнеги Меллон. Он работал вкомпании Microsoft с 1994 по 2003 год, занимаясь про-ектированием и разработкой Windows, MSN, InternetExplorer с 1,0 по 5,0 версию. Скотт ушел из Microsoft в2003 году, намереваясь заполнить одну из своих книж-ных полок собственноручно написанными книгами. Наданный момент он написал две книги – ту, которую высейчас читаете, и «The Myths of Innovation».

В качестве независимого консультанта он про-должает учить управлению проектами, разработкепрограммного обеспечения, методологии творческо-го мышления и проектированию программных продук-тов. Скотт выступает с лекциями, ведет семинары ивносит разнообразие в рутину многочисленных произ-водственных конференций. Его труды получили при-знание на страницах New York Times и WashingtonPost.

Если вы хотите пообщаться на форуме, относя-щемся к тематике данной книги и десятка других эс-се, почитать весьма популярный блог автора и полу-чить множество полезной и интересной информации,посетите веб-сайт www.scottberkun.com.

Благодарности

К новому изданию

Я благодарен команде издательства O’Reilly: МериТреселер (Mary Treseler), Марло Шифферу (MarloweShaeffer), Саре Пейтон (Sara Peyton) и Робу Рома-но (Rob Romano). Хочу также высказать свое уваже-ние Файсалу Джоудату (Faisal Jawdat), Нейлу Еннсу(Neil Enns), Дэвиду Гоберту (David Gobert), Линде Ли(Linda Lee), Кену Нортону (Ken Norton), Линде Уайт-селл (Linda Whitesell) и Стивену Леви (Steven Levy) задолгие часы рецензирования первого издания и пред-ложения по внесению изменений. И большое спаси-бо всем, кто приобрел первое издание, помог распро-странить мой труд и дать возможность появиться вто-рому, исправленному изданию.

К предыдущему изданию

Большое спасибо Майку Хэндриксону (Mike

Hendrickson), моему редактору в издательствеO’Reilly, за то, что он протянул мне руку помощи.Огромное спасибо Файсалу Джоудату (Faisal Jawdat),Бену Либерману (Ben Lieberman) и Эндрю Стеллману(Andrew Stellman) за их превосходную и развернутуютехническую рецензию ранних вариантов книги.

В создании этой книги участвовало множество лю-дей: спасибо ведущему редактору Марло Шиффер(Marlowe Shaeffer) за руководство проектом, МаршеФридман (Marcia Friedman) – за дизайн страниц, Ро-бу Романо (Rob Romano) – за иллюстрации, Дже-реми Менде (Jeremy Mende) – за дизайн обложки,Эндрю Доулу (Audrey Doyle) – за корректуру, ЭлленТроутман-Зэйг (Ellen Troutman-Zaig) – за составле-ние индексного указателя, Гленну Бизигнани (GlennBisignani) – за работу в качестве агента по сбыту.

В следующий список включены люди, не пожа-левшие своего времени на то, чтобы дать своиотзывы о ранних проектах глав. Большое спасибоМишель Бреман (Michelle Breman), Пьерро Сьер-ра (Pierro Sierra), Эрику Бречнеру (Eric Brechner),Ричарду Стокли (Richard Stoakley), Марку Стацме-

ну (Mark Stutzman), Нэйлу Эннзу (Neil Enns), Джей-сону Пасу (Jason Pace), Али Валлаю (Aly Valli),Джо Бельфиору (Joe Belfiore), Биллу Стаплесу (BillStaples), Лауре Джон (Laura John), Хиллел Куперман(Hillel Cooperman), Стасии Скотт (Stacia Scott), ГвэйнСтоддарт (Gwynne Stoddart), Терри Бронсону (TerriBronson), Барбаре Уилсон (Barbara Wilson), ТеррелЛеффертс (Terrel Lefferts), Майку Глассу (Mike Glass),Хроматик (Chromatic) и Ричарду Грудману (RichardGrudman). Я особенно благодарен Кену Дай (KenDye), моему первому менеджеру в компании Microsoft,и Джо Бельфиору (Joe Belfiore); они предоставили мнеперерыв в руководстве программами и сформирова-ли мои представления о том, чем должны заниматьсяхорошие менеджеры и руководители.

Дополнительная персональная благодарность мо-ей жене, Джилл Штуцман (Jill Stutzman), известнойтакже как «медвежонок»; Ричарду Грудману (RichardGrudman); команде Reservoir Dogs, включая КрисаМакГи (Chris McGee), Майка Виола (Mike Viola), Дэви-да Сандберга (David Sandberg), Джо Мирза (Joe Mirza)и Фила Саймона (Phil Simon), а также Ванессе Лонгак-ре (Vanessa Longacre); Бобу Баксли (Bob Baxley) и за-мечательным ребятам из команд Gnostron, Unhinged,и PM-clinic. И вообще я благодарен самой идее су-ществования вселенной; слову папайя; большим ле-

сам с высокими деревьями; людям, которые так и непоумнели, их любопытству и умению радоваться, неутраченным, несмотря на прожитые годы; букве Q ицифре 42. Спасибо за тот багаж сведений, которыйсодержится в системе библиотек King County library ивсех библиотек по всему миру. Межбиблиотечный об-мен The Interlibrary loan program – это настоящий по-дарок судьбы. Спасибо всем.

Долгие часы, проведенные за клавиатурой, со-провождались музыкой, не давшей помутиться мо-ему рассудку: White Stripes, Palomar, Aimee Mann,The Clash, Johnny Cash, Social Distortion, RollinsBand, Sonny Rollins, Charles Mingus, Theloneous Monk,Breeders: Last Splash, AudioSlave, MC5, Chris McGee’sgreatest mixes, Jack Johnson, Patty Griffin, Akiva,Flogging Molly, Sinatra, Beatles, Bruce Springsteen, PJHarvey, Radiohead, Ramones, Weezer, Tom Waits, AllGirl Summer Fun Band, Best of Belly, Magnetic Fields,Beth Orton, Elliot Smith, and Nick Cave и the Bad Seeds.

При написании книги не пострадал ни один из руко-водителей проектов. Но, к сожалению, в самом концеработы ушел из жизни наш пес по кличке Буч, пустьон упокоится с миром, 1991–2004. Он согревал своимтеплом мои ноги в ту пору, когда рождались многиеидеи и страницы этой книги. Хороший пес, Буч, намтебя будет не хватать.

Введение

С первым изданием этой книги произошло нечто

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

Мы со специалистами издательства O’Reilly при-шли к единому мнению, что раз представилась та-кая возможность, книге нужно придать большую цен-ность, дав ей вторую жизнь под новым именем. Кни-га, которая называлась в первом издании «The Artof Project Management», была исправлена, улучшена,обновлена и дополнена, чтобы вы могли читать ее сеще большим удовольствием. Теперь она называется«Making Things Happen». Если вы удивлены сменойназвания, то вот некоторые из причин:

1. Министерство внутренней безопасности (TheDepartment of Homeland Security) усмотрело в старомназвании террористическую угрозу.

2. Тим О’Рейлли (Tim O’Reilly) понял, что его медиа-

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

3. (А сюда вставьте тот повод, который подсказыва-ет ваше собственное воображение.)

Как бы то ни было, книга вышла. Я приложил всеусилия, чтобы представить ее улучшенный вариант ине потерпеть такого же фиаско, как Джордж Лукас сосвоими «Звездными войнами». В общем изменилосьследующее:

• Текст переработан с целью добиться большей яс-ности и краткости. Книга приобрела более четкое из-ложение, избавившись от оговорок.

• Книга дополнена более чем 120 наводящими наразмышления упражнениями, которые помещены вконце каждой главы.

• По многочисленным просьбам, ссылки, помещен-ные в конце книги, были перенесены в сноски в самомтексте.

• Появилось новое руководство по ведению дискус-сий, призванное помочь вам в наборе групп для про-должения обучения.

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

После того как два года назад вышло первое изда-ние, я был занят другой работой. Я написал еще однукнигу под названием «The Myths of Innovation», выпу-стил ряд статей, радиопередач и видеофильмов, про-должая при этом вести популярный блог по творче-ской деятельности и управлению. Обо всем этом мож-но прочитать по адресу www.scottberkun.com.

С приветствиями и наилучшими пожеланиями,Скотт Беркун

Предисловие

Мне нравится спрашивать «как». Как это работа-

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

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

Несмотря на широкое толкование названия этойкниги, большую часть своего рабочего опыта я при-обрел в технической области, работая, в частности,в корпорации Microsoft. Я проработал в этой корпо-рации с 1994 по 2003 год, возглавляя команды спе-

циалистов, работающих над такими проектами, какInternet Explorer, Microsoft Windows и MSN. Несколь-ко лет я проработал в группе совершенствования раз-работок корпорации Microsoft, отвечая за обучение иконсультации команд в рамках всей компании, и до-вольно часто получал приглашения выступить с до-кладами на публичных конференциях, в корпорацияхи университетах. Большинство советов, уроков и ис-торий, приводимых в этой книге, являются плодамиэтого опыта работы.

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

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

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

Для кого предназначена эта книга

Чтобы понять, нужна ли вам эта книга, я предла-

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

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

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

точки зрения. Свежеиспеченные менеджеры и руководители

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

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

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

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

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

Предположения о вас, читатель,

придерживаясь которыхя работал над этой книгой

Вы достаточно разумный человек. Полагаю, что

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

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

те. Вы не любите непонятных выражений или про-

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

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

Как нужно читать эту книгу

Если что-то вам покажется скучным или найдутся

отвлеченные, на ваш взгляд, примеры, можете пропу-стить это место и читать дальше. Я написал эту книгус расчетом на тех, кто бегло просматривает содержи-мое или, столкнувшись с определенной проблемой,нуждается в немедленном совете. Ее главы вполнесамодостаточны, особенно те, в которых раскрывает-ся человеческая натура (главы с 8 по 13 и глава 16).Тем не менее последовательное чтение тоже имеетсвои преимущества, поскольку некоторые понятия зи-ждутся на ранее упомянутых, а сама книга пример-но придерживается хронологии разработки большин-ства проектов. В первой главе рассматриваются са-мые широкие понятия, и она имеет более фундамен-тальный оттенок, чем все остальные. Если вы зада-етесь вопросом, зачем проявлять интерес к руковод-ству проектами или что об этом говорили знаменито-сти, то эта глава заслуживает внимания. Если же онас самого начала вам не приглянется, я настоятельнорекомендую попытаться перейти к чтению второй гла-вы, прежде чем окончательно отложить книгу в сторо-ну.

Все ссылки и URL-адреса, приведенные в

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

А теперь, поскольку у вас хватило мудрости и тер-пения прочитать это предисловие до конца, я смеюпредположить, что вы по инерции прочитаете все, чтоесть в этой книге (номера страниц, сноски и т. п.), и,не снижая скорости, пойдете дальше.

Глава 1. Краткая история

управления проектами (и почемуей стоит уделить внимание)

Во многих организациях должность человека, воз-

главляющего проект, не называется «Руководительпроекта». И это правильно. Каждый в своей повсе-дневной работе управляет проектом, независимо оттого, работает ли он в одиночку или возглавляет ко-манду. На данный момент эти различия не существен-ны. Я стремлюсь уловить то, что приводит проек-ты к успеху, и как люди, возглавляющие успешныепроекты, этого добиваются. Для успешных стратегийне требуются определенные иерархии, наименованиядолжностей или методы. Стало быть, если вы работа-ете над проектом и несете за исход дела хоть какую-тоответственность, то все, что будет изложено далее,имеет к вам непосредственное отношение. А если навашей визитке написано, что вы руководитель проек-та – тем лучше.

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

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

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

Использование

исторического опыта

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

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

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

Проявляя любопытство к самым эффективнымспособам ведения разработки программных продук-тов и веб-приложений, я всерьез заинтересовалсяэтими основами. Я изучил другие области, чтобы по-смотреть, как в них решаются основные проблемы,присущие их проектам, и удивился тому, как были раз-работаны и реализованы такие проекты, как космиче-ский телескоп «Хаббл» и самолет «Боинг-777». Мож-но ли воспользоваться чем-нибудь из принадлежа-щей им совокупности процессов составления техни-ческих заданий и планирования? Или же, если взятьсооружение небоскреба компании «Крайслер» в Нью-Йорке и храма Парфенон в Афинах, неужели ведущиеэтих проектов планировали и рассчитывали свои кон-струкции точно так же, как это делают мои программи-сты? В чем состояли интересные различия и что мож-

но получить в результате их изучения?А как насчет редакторов газет, осуществляющих ор-

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

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

них не упоминалось в тематических журналах.Ключевые уроки из моего экскурса в прошлое мож-

но свести к трем моментам.1. Управление проектами и разработка про-

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

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

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

3. Просто – отнюдь не означает легко. Лучшие ат-леты, писатели, программисты и менеджеры стреми-лись быть среди тех, кто всегда рассматривает своюдеятельность как простую по сути, но в то же времяи сложную. Следует помнить, что понятие простотыне является эквивалентом легкости. К примеру, чтосложного в том, чтобы пробежать марафонскую ди-станцию. Побежал – и не останавливайся, пока непробежишь 42 км 195 м. Казалось бы, чего уж про-

1 Сознание начинающего является начальным понятием дзен-буддиз-ма. В канонической притче фигурирует пустая чаша: если сконцентри-роваться на том, чем заполнена ваша чаша, в ней никогда не будет ме-ста для новых знаний. См. книгу Сюнрю Судзуки (Shunryu Suzuki) «ZenMind, Beginner’s Mind» (Weatherhill, 1972).

ще-то? Тот факт, что это нелегко, не опровергает про-стоты процесса. Возглавлять и управлять тоже нелег-ко, но природа этих процессов – направлять все в нуж-ное русло на достижение намеченной цели – по своейсути проста.

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

Нужно учиться на ошибках

«Люди, уникальность которых [среди

животных] заключается в способностиучиться на чужом опыте, такжеотличаются отсутствием склонности кподобному обучению».Дуглас Адамс (Douglas Adams)

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

2 Об этом свидетельствует отчет «CHAOS Report» (The StandishGroup) – документ о бюджете, календарном плане и общих провалахпроектов разработки программного обеспечения. Публикуется по адре-су http://standishgroup.com/sample_research/.

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

В книге Генри Петроски (Henry Petroski) «ToEngineer Is Human: The Role of Failure in SuccessfulDesign» (Vintage Books, 1992) автор описывает мно-жество прорывов в разработках, происходивших бла-годаря провалам. В частности, такое случается из-затого, что провалы заставляют нас пристальнее к че-му-нибудь приглядываться. Они требуют от нас пере-смотра подзабытых предположений (трудно притво-ряться, что все в порядке, когда прототип горит яркимпламенем). Как говорил Карл Поппер (Karl Popper3),есть только два вида теорий: неправильные и несо-вершенные. Без провалов мы самонадеянно забыва-ем, что наше понимание вещей не настолько совер-шенно, насколько мы думаем.

Вся хитрость в том, что следует как можно больше

3 Карл Поппер был одним из видных философов ХХ века. (См. http://en.wikipedia.org/wiki/Karl_Popper).

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

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

4 Из книги Джеймса Чайлза (James R. Chiles) «Inviting Disaster: Lessonsfrom the Edge of Technology» (HarperBusiness, 2002).

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

Веб-разработка, кухни ипункты первой помощи

Проблема исторических примеров в том, что они не

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

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

но в течение нескольких часов или даже минут, а по-том публиковать результаты своей работы во Всемир-ной сети. Он с гордостью перечисляет технологии, ко-торыми овладел, – CSS, XHTML, Flash, Java, – утвер-ждая, что каких-нибудь 50 лет назад они могли бы оза-дачить самые светлые умы человечества. Я уверен,что вам тоже попадались подобные люди. А можетбыть и у вас складывались ситуации, когда казалось,что еще никто и никогда не решал такие сложные про-блемы.

Я предложил бы этому разработчику пройти как-ни-будь в разгар рабочего дня на кухню его любимогокафе. Побывать на кухне интересно по многим при-чинам (почитайте замечательную книгу Энтони Бурд-эйна (Anthony Bourdain) «Kitchen Confidential» (Ecco,2001), но мое внимание привлекла производитель-ность работы. Когда впервые сталкиваешься с та-кой оперативностью управления и скоординирован-ностью действий команды, какие бывают в час пикна профессиональной кухне, начинаешь по-другомуотноситься к сложности собственной работы. Поваразачастую просто жонглируют сковородками, на кото-рых жарятся блюда из разных заказов, находящиеся вразной степени готовности, и протискиваются междуплитами, расположенными в противоположных кон-цах кухни, а официанты тем временем носятся ту-

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

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

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

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

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

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

Мир медицины, особенно травматология, являетсобой превосходный образец командной работы, при-нятия решений в критических ситуациях и результа-тов реализации проектов, которые ежедневно влияютна судьбы многих людей (на рис. 1.1 дается пример-ное сравнение этой и других областей работы). АтулГаванде (Atul Gawande) в своей превосходной кни-ге «Complications: A Surgeon’s Notes on an ImperfectScience» (Picador USA, 2003) написал следующее:

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

Это высказывание, как и многие другие в весь-ма поучительной книге Гаванде, справедливо и вотношении разработки программного обеспечения.Фред Брукс (Fred Brooks) в классической книге «TheMythical Man-Month» (Мифический человеко-месяц),касающейся разработки программ, проводит схожиепараллели между командами хирургов и программи-стов. Несмотря на то что при разработке веб-сайтовили баз данных жизни мало что угрожает, люди из раз-ных команд могут столкнуться с многими схожими си-туациями и сложностями.

Роль управления проектами

Руководство проектами может быть профессией,

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

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

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

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

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

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

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

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

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

Управление программами

и проектами в Microsoft

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

Чтобы работать в этой роли, этот сотрудник дол-жен иметь склонность к такой разносторонней дея-тельности, как составление технических условий, об-суждение маркетинговых планов, составление кален-

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

Джейб сыграл эту роль в разработке продукта подназванием Multiplan (который впоследствии перерос в

5 Хорошее описание как матричного, так и других типов организацииможно найти в книге Стивена Силбигера (Steven A. Silbiger) «The Ten-Day MBA» (William Morrow and Company, 1993) на с. 139–145. Впрочем,эту информацию можно найти практически в любой книге, посвященнойтеории управления.

Microsoft Excel), и опыт оказался удачным. В резуль-тате улучшились процессы проектирования и разра-ботки, а заодно улучшилась и координация усилий сбизнес-командой, и настроение в коридорах Microsoftсущественно повысилось. Постепенно, после множе-ства совещаний и собраний большинство команд ком-пании приняли эту роль. Чтобы вы ни говорили пло-хого или хорошего о появившихся в результате этогопрограммных продуктах, но идея все-таки была стоя-щей. Определив роль для рядового универсала, при-чем не в качестве какого-то мальчика на побегушкахили лакея, а в качестве лидера и ведущего команды,компания Microsoft навсегда изменила динамику ра-боты команд разработчиков. Именно в этой роли ру-ководителя проектов я выступал большую часть пери-ода своей работы в этой компании, работая с коман-дами, создававшими помимо всего прочего, InternetExplorer, MSN и Windows. Со временем я даже сталруководить командами руководителей проектов.

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

о сотрудниках, которые решали инженерные или де-ловые вопросы или, в редких случаях, – вопросы про-ектирования). Многие компании в организации работиспользовали командную структуру, но лишь немно-гие определяли роли, в которых заведомо пересека-лись инженерная и деловая соподчиненности. Сей-час в Microsoft работают более 5000 руководителейпрограмм (всего в этой компании более 80 000 чело-век), и хотя сам смысл идеи был несколько размыти искажен, ее основное содержание можно найти вомногих командах компании.

Независимо от того, что написано в моей визиткеили каким сведениям от Microsoft вы верите, а какимнет, мои ежедневные функции сводились к функци-ям руководителя проектов. Проще говоря, это означа-ло, что именно я нес по мере сил ответственность зауспешную реализацию проекта и за всех его участни-ков. Во всех главах данной книги описываются основ-ные задачи, связанные с этой деятельностью, от ис-ходного планирования (главы 3 и 4) до составлениятехнических условий (глава 7) и процесса принятиярешений (глава 8) и заканчивая руководством разра-боткой продукта и его выпуском (главы 14 и 15).

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

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

Взвешенность при

руководстве проектами

Подобрать хороших руководителей проектов до-вольно трудно, поскольку они должны уметь придер-живаться взвешенных подходов. Том Питерс (TomPeters) в своей статье «Pursuing the Perfect ProjectManager»6 называет конфликтующие подходы пара-доксами, или дилеммами. Вполне подходящее назва-ние, поскольку разные ситуации требуют разного по-ведения. Значит, руководитель проектов должен нетолько осознавать эту особенность своей работы, нои выработать инстинкт на поведение, соответствую-щее конкретно складывающейся обстановке. Это на-водит на мысль, что руководство проектами являет-ся искусством, требующим проявления интуиции, рас-судительности и опыта эффективного использованияэтих качеств. Следующий список дилемм составленпо материалам статьи Питерса.

Проявление эгоизма – Альтруизм. Благодаря тойстепени ответственности, которая возложена на ру-ководителей проектов, они часто получают огромное

6 Опубликована по адресу http://www.tompeters.com/col_entries.php?note=005297&year=1991.

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

Навязывание своей воли – Доверительные от-ношения. Иногда самым важным является четкоепроявление власти и быстрая реакция. Руководи-тель проектов должен быть достаточно самоуверен иупрям, чтобы контролировать ситуацию и заставитькоманду совершать определенные действия. Тем неменее основная его задача состоит в том, чтобы избе-гать экстремальных ситуаций. При хорошо управляе-мом проекте должна быть создана среда, в которойможно было бы доверить работу и рассчитывать наэффективное сотрудничество.

Терпимость к неопределенности – Стремлениек завершенности. Начальная стадия проекта харак-теризуется высокой открытостью и изменчивостью,где неизвестное в значительной степени перевешива-

ет известное. В главах 5 и 6 будет показано, что управ-ляемая неопределенность является основой для по-явления хороших идей, и руководитель проекта дол-жен с ней считаться, если она не поддается управ-лению. Но в другие периоды, особенно на позднихэтапах проекта, на первый план выходят дисциплини-рованность и точность. Нужно проявить определен-ную мудрость, чтобы понять, когда следует стремить-ся к завершенности, а когда вполне устроит приблизи-тельное, принятое на скорую руку решение (см. раз-дел «Поиск и оценка вариантов» в главе 8).

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

общение.Стремление к сложности – Борьба за простоту.

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

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

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

Храбрость – Осторожность. Одним из самыхбольших заблуждений, присущих почти всем культу-рам, состоит в том, что храбрым людям якобы не при-суще чувство страха. На самом деле это не так. Храб-рые люди чувствуют страх и все-таки принимают ре-шение действовать. Руководитель проектов должениметь здравое отношение ко всему, что идет не долж-ным образом, и признавать возможность такого раз-вития событий. Но он также должен соответствоватьтакому отношению и обладать мужеством, необходи-мым для преодоления больших трудностей.

Уверенность – Скептицизм. Нет ничего болеевдохновляющего команду, чем уважаемый всеми ли-дер, уверенный в том, что он делает. Для руководи-теля проектов важно быть уверенным в своей рабо-те и понимать истинную ценность тех целей, которыедолжны быть достигнуты. В то же время не лишнимбудет и здравый скептицизм (но не цинизм) относи-тельно состояния дел и способов их ведения. Кто-то должен выражать сомнения и задавать вопросы,

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

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

Давление и распри

Новички в руководстве проектами боятся того, что

для успеха требуется внесение изменений. Новыепроекты создаются с целью изменить мир путем мо-дификаций, какой-либо созидательной или разруши-тельной деятельности. Поддержание status quo, ес-ли только это не является по какой-нибудь страннойпричине явной целью, не является успешным резуль-татом. Мир постоянно изменяется, поэтому если веб-сайт или другой проект сегодня уже не так хорош, ка-ким был год назад, значит, он отстал от жизни из-занеправильно сформулированных задач или просче-тов при разработке.

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

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

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

Путаница в понятиях

процесса и целей

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

нически отнесен на счет такого руководителя).Чтобы свести к минимуму возможность подобно-

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

Несколько лет назад, трудясь над проектом InternetExplorer 4.0, я руководил разработкой несколькихсложных компонентов пользовательского интерфей-са, и поскольку в ту пору это был мой самый высокийпост, я ощущал весьма значительное давление обсто-ятельств. В ответ у меня выработалось убеждение,

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

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

Итак, вместо того чтобы замыкаться на процессах и

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

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

кающую за собой команду в вязкую западню сложныхпроектов, как об этом говорится в книге Фрэда Брук-са (Fred Brooks) «The Mythical Man-Month». Когда отпроцессов требуется управление процессами, труднопонять, где осуществляется реальная работа. Имен-но руководителю команды или проекта чаще всегопредоставляется великолепная возможность управ-лять командой без бюрократических излишеств илинаоборот послать ее на полной скорости в несконча-емый водоворот различных процедур и заседаний.

Нужная степень вовлеченности

Все руководители, от верхушки пятисот наиболее

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

Руководителей не нанимают для того, чтобы онипроделывали простую работу, ожидаемую от рабоче-го или программиста. Вместо этого руководители и

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

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

правоты своих действий.

Преимущество собственноговзгляда на происходящее

Лучшим способом поиска точки опоры является

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

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

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

К примеру, как-то утром, работая над проектом IE5.0, я заглянул в офис Фрэда. Он спорил со Стивом,другим программистом, о том, как они собираются за-ставить заработать элемент управления для просмот-ра списка, после того как утром внезапно обнаружи-лись проблемы его совместимости с другими компо-нентами. Никто из них не хотел с этим связываться.И, исходя из всего мною услышанного, на исправле-ние элемента должно было уйти не менее половинырабочего дня. Я подключился к разговору и подтвер-дил все то, о чем они говорили. Они кивнули голова-ми, словно спрашивая: «Зачем вам это нужно?» Я ска-зал, что им нужно пройти вниз и поговорить с Биллом.Они опять спросили, зачем, думая, что дело касаетсявесьма тонких вопросов архитектуры проекта, в кото-рых я не слишком-то разбираюсь. Я улыбнулся и ска-зал: «Дело в том, что я только что от него, и у негона машине есть уже новый великолепно работающийэлемент управления. Минувшей ночью ему удалось

решить проблему и все исправить попутно с выпол-нением других дел».

Разумеется, здесь речь не о том, что я избавил илиуберег человечество от глобальной катастрофы. Ес-ли бы я их не направил в нужное место, было бы по-теряно впустую несколько часов или половина рабо-чего дня (хотя, как показано в главе 8, рабочие гра-фики всегда имеют некоторые отклонения от заплани-рованных сроков). Но дело не в этом. Хорошие руко-водители проектов считают своей обязанностью бытьв курсе всех полезных дел команды, как, впрочем, ивсего полезного в окружающем мире, а затем приме-нять эти знания, помогая людям справиться с их де-лами. Все эти, казалось бы, незначительные порциисвоевременно преподнесенной информации, наподо-бие той, о которой шла речь в моем рассказе, и де-лают из середнячков хорошие команды, а из хорошихкоманд – великие. Никакая система отслеживания хо-да ведения проекта или обнаружения ошибок не смо-жет целиком заменить собой потребность людей в об-суждении друг с другом текущих событий, посколь-ку социальные сети всегда мощнее (а иногда и быст-рее), чем сети технологические. Сложные задачи, на-подобие концепции проекта, перечней функциональ-ных условий и календарного плана, всегда сводятсяк массе мелких задач, на которых благотворно сказы-

вается простота обмена ценными знаниями и сведе-ниями внутри команды. И главная роль в обеспеченииактивности и осмысленности этого обмена принадле-жит руководителям проектов.

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

Руководители проектов

создают уникальные ценности

В результате хорошие управленцы и руководите-

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

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

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

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

В конечном счете, основная идея, в которую я уве-

ровал, состоит в том, что пока вы никому не причи-няете боли (кроме возможных конкурентов) и веде-те людей в правильном направлении, ничто, крометого, что вы делаете благое дело, не имеет значе-ния. Пока результат положителен, неважно, сколькоидей исходит от вас, а сколько – от кого-то другого.Руководство проектом оправдывает любые средства,необходимые для повышения вероятности и сокра-щения сроков наступления благополучного исхода. Яиспользовал одну полезную ежедневную молитву, ко-торая звучала примерно так: «Дай случиться чему-ни-будь хорошему». Увидев меня в коридоре или за ра-ботой с каким-нибудь программистом у классной дос-ки, люди спрашивали: «Ну что, Скотт, чем ты занят?»А я улыбался и говорил: «Даю возможность случитьсячему-нибудь хорошему». Это стало основной состав-ляющей моего ежедневного подхода к каждому чело-веку, и когда я направлял работу других, эта установ-ка распространялась через них на всю команду. По-скольку пора наконец переходить к конкретике, я вы-ражаю надежду на то, что и вы прочувствуете эту уста-новку и проникнитесь основной идеей этой начальнойглавы.

Выводы

Каждая глава этой книги завершается краткими вы-

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

• Управление проектами востребовано повсемест-но и с незапамятных времен.

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

• Руководство проектами может быть работой, ро-лью или деятельностью (советы, приведенные в дан-ной книге, пригодятся независимо от того, как вы этоопределите).

• Руководство программами – это вариант руковод-ства проектами, применяемый исключительно в кор-порации Microsoft. Оно берет начало в идее матрич-ной организации управления.

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

• Остерегайтесь претенциозности и излишней во-

влеченности во все дела в процессе своей управлен-ческой деятельности. Процесс должен содействоватьработе команды и никак иначе.

• Если вы штатный менеджер, найдите способы из-влечения выгоды из вашего особого взгляда на коман-ду и проект.

Упражнения

1. Выберите одного из своих лучших друзей, кото-

рый работает или учится в какой-нибудь другой сфе-ре. Как он управляет своими проектами? Существуетли у них должность руководителя проекта или эта ра-бота распределена между разными людьми?

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

3. Придумайте повод и устройте вечеринку. (Вы вы-держали чтение первой главы, чем не повод?) По-сле преодоления похмельного синдрома и вызволе-ния друзей из «кутузки», рассмотрите следующие во-просы: чем вечеринка отличается от проекта? Срав-ните трудности и награды за роль организатора вече-ринки по сравнению с ролью руководителя реальногопроекта. В чем различия и сходства?

4. Подумайте о неудачном проекте, над которымвам приходилось работать. Какой урок и каким об-разом вы из этого вынесли? Составьте список допу-

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

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

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

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

ком большого количества правил?

Часть 1. Планирование

Глава 2. Правда окалендарных планах

Людям свойственно опаздывать. Они часто выби-

ваются из повседневного графика, пусть всего нанесколько минут или пару раз в неделю. (Посколькувозражать люди научились ничуть не хуже, я пойму,если вы откажетесь принимать это утверждение насвой счет.) Студенты опаздывают на занятия, сотруд-ники – на рабочие совещания, а друзья приходят вбар на десять минут позже назначенного времени. Мысчитаем, что понятие «вовремя» относится не к кон-кретному моменту, а к какому-то интервалу времени,который может быть для кого-то шире, чем для всехостальных. Характерный пример – старшие официан-ты. Они вас уверяют, что столик вот-вот будет готов,но при этом зачастую заставляют ждать значитель-но дольше объявленного.7 Существует множество си-

7 Как-то в Питтсбурге мы с приятелями зашли пообедать в пиццерию иполучили заверение, что столик будет готов через десять минут. Ровночерез десять минут мой друг Чад МакДаниел поинтересовался готовно-стью столика и получил ответ распорядителя, что все будет готово че-

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

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

Но перед тем как искать способы составления со-вершенных календарных планов, мы должны понять,какие именно проблемы решаются с их помощью. Ес-ли они столь ненадежны, стоит ли вообще тратить

рез десять минут. Тогда он спросил: «Это те же десять минут или другиедесять минут?» – но его шутку должным образом так и не оценили.

время на их создание? Календарные планы служатнескольким различным целям, лишь некоторые из нихнепосредственно связаны с фактором времени.

Три цели составлениякалендарных планов

Что бы вы ни планировали, субботнюю вечерин-

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

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

И только после указания всех деталей с указаниемследом за ними исполнителей появится возможностьпровести реальные расчеты и исследовать допуще-ния. Это справедливо даже для небольших коллекти-вов или отдельных разработчиков. Календарный планоказывает психологическое влияние, поскольку с егопомощью оглашаются взятые обязательства. Совсемне просто забыть или проигнорировать то, что выве-шено на всеобщее обозрение, напоминая команде отом, что должно быть сделано. Для руководителейпроекта существенно и следующее обстоятельство:когда обнародован проект календарного плана, могутбыть подняты вопросы о реалистичности некоторыхего разделов и может быть сопоставлен объем работ

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

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

Третья цель разработки календарных планов со-

стоит в предоставлении команде средства, позволя-ющего контролировать ход работы и разбить ее наподдающиеся управлению этапы. Разбиение работына одно– или двухдневные задания помогает испол-нителям осознать объем предстоящих работ. Вообра-зите, что при строительстве дома бригадир опреде-лил задание одной строкой: «Построить дом за 120дней». При такой «степени детализации» всем, вклю-чая и самого бригадира, будет довольно трудно по-нять, что нужно делать. Но если строитель сможетпредоставить объемы работ по неделям, каждый смо-жет понять, когда и какие задания будут выполнять-ся, в чем заключаются приоритеты, и задать более це-ленаправленные вопросы и уяснить принимаемые имобязательства. С точки зрения руководителя проек-та качественно составленный календарный план даетболее понятное видение проекта, на ранней стадиирассеивает претензии, сглаживает оплошности и по-вышает шансы на благоприятный исход.

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

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

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

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

Решающие факторы и методологии

Существует множество различных систем планиро-

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

8 В оригинале «Feature-driven development». – Примеч. ред.

ными знаниями и опытом.Однако целью главы, да и всей книги, не являет-

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

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

9 Сравнительное обсуждение традиционных и гибких методов разра-ботки программных средств вы сможете найти в книге Барри Боэма(Barry Boehm) и Ричарда Тернера (Richard Turner) «Balancing Agility andDiscipline: A Guide for the Perplexed» (Addison Wesley, 2003).

потому, что они изложены в популярных книгах илипроповедуются многоуважаемыми гуру. Очень частоя убеждаюсь, что одержимость процессом – весьматревожный знак, свидетельствующий о затруднени-ях в руководстве: это может быть попыткой перело-жить обычные проблемы и ответственность, с кото-рыми сталкиваются руководители, на систему проце-дур и бюрократических приемов, подменяющих необ-ходимость осмысленных руководящих действий. Воз-можно, намного более пагубным для команды разра-ботчиков может стать пристрастие к методологии, ко-торой в организации отводится чуть ли не первосте-пенная роль. Том Демарко (Tom DeMarco) в своей кни-ге «PeopleWare» (Dorset House, 1999) («Человеческийфактор в программировании») отмечал:

Навязчивая идея применения методологийна рабочем месте – еще один примервысокотехнологичной иллюзии. Она беретначало из веры в то, что технология –это единственное, что на самом деле имеетзначение… Какими бы ни были технологическиепреимущества, они могут быть получены толькоза счет существенного ухудшения социальногоклимата в команде разработчиков.

Сосредоточенность на приемах и методах, под-меняющая организацию процесса, направленного на

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

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

10 Информацию об определениях и понятиях изменений процесса раз-работки программного обеспечения, а также об управлении этими из-менениями можно найти в книге Уоттса С. Хамфри (Watts S. Humphrey)«Managing the Software Process» (Addison Wesley Professional, January1989).

На что похож календарный план

Существует одно основное правило составления

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

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

В соответствии с правилом, на каждый день, отво-димый на разработку программного кода, выделяет-ся день на планирование и проектирование и деньна проверку и доводку сделанного (рис. 2.1). Вряд личто-нибудь еще может быть проще – перед вами про-стой механизм проверки любых существующих кален-дарных планов или создания календарного плана «снуля». Если все отведенное на реализацию проектавремя не разделено приблизительно на три равныхэтапа работы, должны быть вполне объяснимые при-чины, почему проекту требуется неравномерное рас-пределение усилий. Если позволяют сроки, правилотрех частей допускает некоторый дисбаланс, при ко-тором считается нормальным отводить на тестирова-ние на двадцать и более процентов времени больше,чем на разработку.

Рис. 2.1. Простейшая схема календарного плана,созданного по правилу трех частей

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

лагаемый объем работ (или снижать ожидаемое ка-чество). Выкраивание времени за счет тестированиявсего лишь увеличит шансы на то, что время, потра-ченное на написание кода, уйдет впустую, или будетполучен код, малоприспособленный для управленияи поддержки. Правило трех частей полезно тем, чтозаставляет выявить ситуацию, при которой выигры-вая в одном, проигрываешь в другом. Добавление но-вых возможностей выливается не только в дополни-тельную работу программиста по их реализации, но ивлечет за собой неизбежные издержки на проектиро-вание и тестирование, на которые кто-то должен идти.Когда календарный план срывается, причина заклю-чается в неучтенных скрытых или проигнорированныхиздержках.

Разработка по частям(беспроектный проект)

Стоит рассмотреть и самый простой вариант: от-

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

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

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

Разделяй и властвуй (большие

планы равны множеству мелких)

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

Там, где проекты усложняются из-за своей объем-ности или продолжительности, календарные планыделятся на части, каждая из которых имеет собствен-ные периоды проектирования, разработки и тестиро-вания. В экстремальном программировании (ExtremeProgramming, XP) такие части называются итерация-ми, в спиральной модели – фазами, а в некоторых ор-ганизациях их называют этапами. Хотя в XP считает-ся, что эти отрезки времени занимают всего несколь-ко недель, а в спиральной модели счет идет на меся-цы, в них заложена одна и та же фундаментальнаяидея: создание подробных календарных планов дляограниченных периодов времени.

Чем больше ожидаемых изменений и проектныхотклонений, тем короче должен быть каждый этап.

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

Гибкий и традиционный методы

Экстремальное программирование и другие гибкие

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

Большинство проектов по разработке программных

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

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

ным.Все это я объясняю, собираясь перейти к методо-

логии создания календарного плана высшего уровня.В главах 14 и 15 рассматривается порядок управле-ния проектом на протяжении выполнения всего кален-дарного плана, но в них обращается внимание на пер-спективы управления и руководства, а не на деталиприменения конкретной методологии. Если вы смог-ли усвоить материал нескольких последних разделов(даже если вы не совсем согласны с изложенной в нихточкой зрения), советы, излагаемые в главах 14 и 15,будут уместны и полезны независимо от того, как выорганизовали или спланировали свой проект.

Рис. 2.2. Большой проект должен представлять со-бой последовательность более мелких проектов

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

Почему рушатся планы

Как только что-нибудь идет не так, обычно винят

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

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

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

Выстрел вслепую издалека

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

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

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

Барри Боэм (Barry Boehm) в 1988 году в своем эс-се на тему разработки программных продуктов11 пи-

11 «Understanding and Controlling Software Costs», IEEE Transactions onSoftware Engineering, т. 14, № 10, октябрь 1988, стр. 1462–77; а также

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

книга «Software Engineering Economics» (Prentice Hall, 1991).

Рис. 2.3. Диапазон возможных отклонений от рас-четных сроков в процессе реализации проекта (за-имствовано из книги Боэма «Software EngineeringEconomics»)

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

Календарный план –

это оценка вероятности

Когда я выпустился из университета и работалнад своими первыми крупными проектами (Windowsи Internet Explorer), то общий календарный план мо-ей команде должен был представлять кто-то поваж-нее меня. Поскольку я был слишком молод, чтобы вдостаточной степени быть причастным к процессу, вмои обязанности после получения календарного пла-на входило применение этого главного расписания кдеятельности небольшого коллектива программистови тестировщиков, с которыми я работал.

Когда мы обсуждали, в чем состоит разница меж-ду этим главным планом и календарным планом, со-

зданным моей командой на основе списка работ,12

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

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

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

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

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

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

их возникновения) и кто-либо из создателей планане может предложить каких-либо объяснений относи-тельно сделанных допущений, то остается предполо-жить, что выполнение календарного плана возможно,но маловероятно13 План должен быть открытым длявысказываемых командой предложений, чтобы пред-лагаемые соображения или информация могли до-полнить или скорректировать план в целях повыше-ния вероятности его выполнения.

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

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

Расчет – дело тонкое

В процессе проектирования (обсуждаемого в гла-вах 5 и 6) одной из задач проектировщиков, програм-мистов и тестировщиков является разбиение проек-та на небольшие части работы, которая имеет некиезавершенные формы. Эти части, часто называемыеэлементами структурной декомпозиции работ (WorkBreakdown Structure, WBS14), или просто работами,становятся строками в главном календарном планепроекта. Работы разумно (скрестите пальцы) распре-деляются15 среди программистов команды и в соот-ветствии с ними строится календарный план. Каждаяиз этих работ должна иметь предполагаемый срок за-вершения, назначенный программистом, и на основеэтих предположений создается календарный план.

14 Процесс проведения структурной декомпозиции работ описан вомногих книгах. К этой теме я вернусь в главе 14, но если вы хотите изу-чить ее более обстоятельно, начните с материалов, размещенных поадресу http://en.wikipedia.org/wiki/Work_breakdown_structure, или с книгиСтефана Дево (Stephen Devaux) «Total Project Control» (Wiley, 1999).

15 В книге Кента Бека (Kent Beck) «Extreme ProgrammingExplained» (Addison Wesley, 1999) предлагается программно-ориенти-рованная модель распределения работ, при которой программисты са-ми выбирают себе работы. В идеале должен быть выдержан компро-мисс между тем, что лучше для проекта, и тем, что лучше для отдель-ных специалистов команды.

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

Весь мир держится на расчетах

Трудности планирования заключаются в том, что

далеко не всем нравится вести сложные расчеты,

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

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

строят ли они небоскреб, занимаются перепланиров-кой кухни или запускают космический зонд для посад-ки на другие планеты. Я много читал о том, как этиребята проводят расчеты, и мне вовсе не показалось,что их сомнения и применяемые технологии в кор-не отличаются от тех, с которыми приходится сталки-ваться разработчикам веб-сайтов и программ. Основ-ное отличие состоит во времени, отводимом ими нарасчеты, и в рациональности его использования (бо-лее детально этот вопрос рассматривается в главах5 и 6).

Качественное проектирование

– залог хороших расчетов

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

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

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

Я выработал очень удобный прием на случай, ко-гда программист задерживается с расчетами. Я егоспрашиваю: «О чем нужно спросить, чтобы придатьвам уверенности в расчетах?» Заставив его сосре-доточиться, я даю возможность побороть те чувствастраха и неуверенности, которые могли им овладеть.Конечно, я должен был бы помочь найти ответы на еговопросы и, возможно, обсудить проблемы, которые,

как я считал, он должен был решить самостоятельно,но, по крайней мере, мы поговорим о повышении ка-чества расчетов.

Вот несколько дополнительных советов, позволяю-щих добиться качественных расчетов:

Установите базовые показатели доверия рас-четам. Предположение – 40 % доверия, качествен-ный расчет – 70 %, подробный и полный анализ –90 %. Руководители команд должны прийти к согла-шению, насколько точными должны быть расчеты,сколько времени отвести программистам для их про-ведения и как управлять риском неверных расчетов.Не заостряйте внимание на цифрах: пользуйтесь имилишь для конкретизации качества расчетов. Расчет с90-процентным доверием должен означать, что сро-ки выдерживаются в 9 случаях из 10. Если вы реши-те обратиться к команде с просьбой поднять качестворасчетов, то должны подкрепить свою просьбу выде-лением дополнительного времени.

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

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

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

Расчеты зависят от понимания программиста-ми целей проекта. Расчеты основываются на про-граммистской интерпретации не только проектиро-вочных спецификаций (если таковые имеются), нотакже целей и параметров, заложенных в проект.Джеральд Вейнберг (Gerald Weinberg) в книге «ThePsychology of Computer Programming» (Dorset House,1971) отмечал прямое влияние недостаточно четкопоставленных целей высокого уровня на низкоуров-

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

Расчеты должны основываться на опытепредыдущих работ. Хорошо, если в привычку про-граммистов войдет сохранение преемственности рас-четов от проекта к проекту. Эта тема должна статьчастью их дискуссии с руководителем проекта; в ин-тересах руководителя выяснить, кто из команды пре-успел в тех или иных расчетах. В экстремальном про-граммировании в отношении возможной производи-тельности программиста (или команды), основаннойна предыдущих показателях производительности, ис-пользуется понятие скорость.16

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

16 См. книгу Кента Бека (Kent Beck) и Мартина Фоулера (Martin Fowler)«Planning Extreme Programming» (Addison Wesley, 2002), стр. 60–62.

о качестве выработки технических условий будет ве-стись в главе 7.

Существуют известные методы улучшения ка-чества расчетов. Наиболее известным является ме-тод PERT (Program Evaluation and Review Technique– метод оценки и пересмотра планов), в которомпредпринимается попытка минимизировать риски пу-тем вычисления усредненной величины из результа-тов лучшего, среднего и худшего расчетов.17 Этот ме-тод хорош по двум причинам. Во-первых, всем да-ется понять, что расчеты сродни прогнозам, отража-ющим диапазон возможных результатов. Во-вторых,руководителям проектов дается возможность отрегу-лировать агрессивность или консервативность кален-дарных планов (больший вес может придаваться низ-ким или высоким оценкам).

Элементарные просчеты

Хотя качественные расчеты оказывают большоевлияние на улучшение календарных планов, множе-ство факторов, влияющих на эти планы, буквальноперечеркивают их отдельные элементы. Беда в том,

17 Стандартная формула для метода PERT: лучший расчет + (4 × наи-более вероятный расчет) + худший расчет/6. Имейте в виду, что суще-ствует огромное количество разновидностей и теорий наилучших взве-шенных расчетов.

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

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

ние? Как внести изменения? Что нужно сделать дляисправления ситуации?)

• Существует ли в календарном плане отдельнаяформа учета дней болезни и отпусков всех сотрудни-ков?

• Были ли учтены периоды праздников или дру-гие времена года с большими нерабочими периодами(например, от Дня благодарения до Рождества в СШАили летние отпуска в Европе)? В эти периоды добить-ся соблюдения намеченных сроков крайне трудно.

• Допущены ли сотрудники к календарному плануи вменялось ли им (в мягкой форме) в обязанностьрегулярно отчитываться за проделанную работу?

• Проводит ли кто-нибудь ежедневный или ежене-дельный анализ выполнения календарного плана вцелом? Обладает ли этот человек достаточными пол-номочиями, чтобы задавать резонные вопросы и вно-сить поправки?

• Чувствует ли команда причастность к календарно-му плану и ответственность за его выполнение? Еслинет, то почему? Внесла ли команда свой вклад в со-ставление календарного плана и в определение объ-ема работ или все это было спущено им сверху?

• Чего больше было в действиях руководства ко-мандой, добавления требований по характеристикампродукта или помощи в их исключении? Говорили

ли когда-нибудь руководители команды решительноенет новым объемам работ и предоставляли ли онисвоей команде разумную философию реагированияна новые (запоздавшие) требования?

• Находили ли сотрудники поощрение и поддержку,если говорили нет новым требованиям, если те шливразрез с их целями и представлениями?

• Какая вероятность была заложена в расчеты?90 %? 70 %? 50 %? Нашла ли она отражение в глав-ном календарном плане высокого уровня? Был ликлиент, вице-президент или заказчик уведомлен обэтом? Обсуждалось ли другое предложение, болеезатратное по времени, но имеющее более высокуювероятность соблюдения сроков?

• Имели ли место периодические согласования ипересмотры календарного плана со стороны руково-дителей команд и руководителей проекта?

• Учтено ли в календарном плане сокращенное ра-бочее время в период праздников. (Обычно чередапраздников снижает продуктивность работы.) Учтеныли в плане наиболее вероятные разрушительные по-годные явления (например, снежные заносы в Чикаго,торнадо в Канзасе или жара в Сиетле)?

• Был ли достаточно качественным уровень разра-ботки технических требований и проектирования дляполучения качественных расчетов времени, отводи-

мого на работы?• Была ли у расчетчиков достаточная практика или

опыт в производстве расчетов времени, отводимогона работы?

Эффект снежного кома

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

На самом деле все еще хуже. Вероятность на-

ступления ряда независимых событий равна произ-ведению вероятностей наступления каждого отдель-ного события (так называемая совместная вероят-ность). Отсюда следует, что если вероятность про-чтения вами этой главы до конца равняется девятишансам из десяти (9/10), а вероятность того, что выосилите и следующую главу, также равна 9/10, то сум-марная вероятность, что вы дочитаете до конца обеглавы, равняется уже не 9/10, а 81/100. Это означа-ет, что если у вашей команды 90-процентная веро-ятность точного следования еженедельному графикуработ, с течением времени шансы срыва сроков воз-растают. Вероятность – вещь холодная и беспощад-ная, напоминающая нам, что энтропия существует по-всеместно и не благосклонна ни к проектам, ни к ихруководителям.

Рис. 2.4. Эффект снежного кома

Что должно произойти, чтобыкалендарные планы заработали

Теперь, когда стало понятно, почему так трудно

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

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

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

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

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

Делайте ставку на проектирование. В процес-се проектирования закладываются лучшие гарантииот неизвестных и неожиданных осложнений. Каче-ственное проектирование – это единственный спо-соб сделать более гладким преодоление командойфазы разработки и других фаз реализации проекта.Навыки проектирования отличаются от навыков раз-работки, поэтому самый сильный или самый продук-тивный специалист по составлению программного ко-да не обязательно будет лучшим проектировщикомили специалистом по решению проблем. Качествен-ному проектированию не учат на курсах информати-ки, несмотря на всю его важность в поиске путей и ре-шений по разработке и управлению проектами. Этатематика подробнее рассматривается в главах 5 и 6.

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

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

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

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

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

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

ко что сформированной команде поручалась работанад сложным и рискованным проектом или предла-гался агрессивный календарный план.

Беритесь за риски как можно раньше. Если из-вестно, что Салли поручена наиболее сложная рабо-та, учтите это в самом начале календарного плана.Чем выше риск, тем больше времени нужно зарезер-вировать для того, чтобы с ним справиться. Если выоткладываете учет рисков в календарном плане наболее поздний срок, у вас останется меньше степенейсвободы, чтобы справиться с этими рисками. То же са-мое относится к политическим, организационным илиресурсозависимым рискам. Мы поговорим об управ-лении работами при рассмотрении производственно-го конвейера в главе 14.

Выводы

• Календарные планы выполняют три функции: поз-

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

• Большие календарные планы должны разбивать-ся на более мелкие с целью минимизации рисков и

увеличения частоты внесения поправок.• Все расчеты имеют вероятностный характер. По-

скольку календарные планы опираются на множествооценок, они также носят вероятностный характер. Этообстоятельство отрицательно влияет на их точность,поскольку вероятности накапливаются (80 % × 80 %= 64 %).

• Чем раньше сделаны оценки, тем менее они точ-ны. Но несмотря на это, приблизительные расчеты –единственный способ создания фундамента для бо-лее точных расчетов.

• Календарные планы должны составляться не соптимистических, а со скептических позиций. Чтобыпролить свет на предположения и приобрести уверен-ность в успехе, нужно вложить достаточные силы исредства в проектирование.

Упражнения

1. Если вы пользуетесь ежедневным планировани-

ем, взгляните на вчерашний распорядок. Много ли со-бытий произошло в срок? Из тех, которые произошлис опозданием, сколько было связано с вашими ошиб-ками?

2. Кто из известных вам людей постоянно опазды-вает? Меняется ли из-за этого отношение к нему со

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

3. Найдите оригинал календарного плана предыду-щего проекта. Сравните его с реальными событиями.Чтобы вы сделали по-другому, если бы знали все, чтознаете теперь? Как воспользоваться этой информа-цией в интересах следующего проекта?

4. Проведите день, начиная и заканчивая все делаточно в срок. После задайтесь вопросом, стоило лиради этого стараться? Почему да или почему нет?

5. Найдите друга, который работает в какой-нибудьдругой сфере. Как он составляет календарное пла-нирование своих проектов? Какими инструментамипользуется для подсчета времени, затрачиваемого нату или иную работу? Какие в его сфере деятельностинаиболее типичные ошибки и чему можно научитьсяиз того, как он с ними справляется? (Если у вас неттаких друзей, то интересно будет поучиться, сравни-вая свою деятельность со строительством, кинопро-изводством, устроительством свадебных торжеств.)

6. Правило трех частей – это примерная норма, длякоторой есть исключения. Какие разновидности про-ектов требуют другого распределения времени? Мо-

гут ли быть проекты, в которых доминирует только од-на из этих трех разновидностей работ?

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

8. Ваш руководитель настаивает на определеннойдате, а ваш опыт подсказывает, что это нереаль-но. Как можно воспользоваться календарным планом,чтобы объяснить вашу обеспокоенность руководите-лю?

9. Если элементарные просчеты, рассмотренные вэтой главе, касаются большинства проектов, то какдолжен поступить толковый руководитель проектов:а) поставить в известность команду об их существо-вании, или б) поощрять людей за стремление умень-шить их влияние на проект? Um delis num velese dipexero eum velenibh ex et, susting exer si.

Глава 3. Как

определить, что делать

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

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

подробных технических требований, включаяпользовательский, программный и аппаратныйинтерфейсы. Никакая другая невернопроделанная часть работы не способна такиспортить общие результаты. Именно еетруднее всего впоследствии исправить. Поэтомунаиболее важной функцией, выполняемойсоздателем программного продукта в интересахпотребителя, является постоянное добываниеи обработка требований, предъявляемых кпродукту.Фред Брукс (Fred Brooks)

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

имущество над тем, кто этого не понял.Итак, данная глава посвящена подходам к процес-

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

Снятие покрова таинственности

с вопросов планированияпрограммных продуктов

Для небольшого индивидуального проекта корпо-

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

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

При планировании проекта нужно найти ответына два вопроса. Ответ на первый вопрос, «Что де-лать?», обычно называется выработкой требований.Ответ на второй вопрос, «Как делать?», называ-ется проектированием или выработкой техническихусловий (рис. 3.1). Требование должно заключатьсяв тщательном описании критерия, которому работапризвана соответствовать. (Например, требование кприготовлению пищи может состоять в приготовле-нии недорого, вкусного и питательного блюда.) Хо-

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

Рис. 3.1. Самый простой, но весьма удобный взглядна планирование. Если неизвестно, что делать, зна-чит, не настало время определять, как делать

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

Типы проектов

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

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

Небольшая команда, работающая по контрак-ту. Фирма, состоящая из пяти—десяти программи-стов и одного руководителя, нанятая заказчиком длясоздания веб-сайта или программы. С ними заключа-ется контракт, оговаривающий взаимные обязатель-ства. По окончании контракта все связи обрывают-ся до заключения следующего контракта или началаследующего проекта.

Многочисленная команда штатных сотрудни-

18 Сравнить другие типы проектов вы сможете, обратившись по адресуhttp://www.joelonsoftware.com/articles/FiveWorlds.html.

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

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

Как на планирование

влияет его организация

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

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

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

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

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

Кому поручено составление бюджета? Компе-

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

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

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

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

Документы, разрабатываемые

при обычном планировании

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

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

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

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

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

ления о том, каким должен быть проект. Если исполь-зуется анализ потребностей рынка, то этот документдолжен с ним тесно перекликаться. В концептуаль-ном документе определяются цели проекта, смысл ихдостижения, а также видение в целом характеристик,требований или сроков реализации проекта (см. главу4). Этот документ непосредственно определяет дляпроекта ответ на вопрос «что?», то есть в чем его суть.

Технические условия. В них формулируется ко-нечный результат работ для определенной части про-екта. Обоснованные технические условия вырабаты-ваются на основе набора требований. Затем они мно-гократно прорабатываются в процессе проектирова-ния (см. главы 5 и 6), в ходе которого изменениями уточнениям могут подвергаться и исходные требо-вания. Выработка технических условий завершается,когда они обеспечивают работоспособный план, ко-торый в процессе разработки и управления проектомможет быть использован для удовлетворения требо-ваний (степень их детализации должна быть полно-стью обговорена с разработчиками и управленцами).Технические условия должны унаследовать как мож-но больше идей, выдвинутых в концептуальных доку-ментах. Они определяют для проекта ответ на вопрос«как?», то есть как его реализовать с конструкторскойи технической точек зрения. (Сценарии использова-

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

Структурная декомпозиция работ (WorkBreakdown Structure, WBS). Технические условиядетализируют объем выполняемых работ, а докумен-ты структурной декомпозиции работ определяют, какгруппа разработчиков должна справляться с их вы-полнением. Что должно быть сделано в первую оче-редь? Кто этим займется? Что из себя будут пред-ставлять все индивидуальные рабочие задания и какможно отслеживать их выполнение? В зависимостиот потребностей проекта эти документы могут бытьоформлены предельно просто (в виде электроннойтаблицы) или довольно сложно (в виде диаграмм исредств выполнения). К разработке документов струк-турной декомпозиции работ относятся главы 7 и 13.Эти документы определяют для проекта ответ на во-прос «как?» с точки зрения группы разработчиков. (Внекоторых методах гибкой разработки все задейство-ванные карточки историй показываются на досках за-даний, которые становятся чем-то вроде структурнойдекомпозиции работ.)

Подходы к планированию

– три взгляда на проект

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

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

ВНИМАНИЕПри планировании должны быть также учтены

и производственные мощности. Если попадаютсявопросы или ситуации, не применимые в данном

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

Взгляд бизнесмена

Деловой взгляд фокусируется на понятиях, влияю-щих на прибыли и убытки (Profit and Loss, P&L), учи-тываемые организацией. В эти понятия включаютсяпродажи, прибыль, расходы, конкуренция и издержки.Каждый должен разбираться в своей прибыли и убыт-ках – из прибыли выплачиваются зарплаты или опла-чиваются контракты. Когда команда разработчиков незнает, как работает бизнес, многие решения, прини-маемые руководством, им кажутся нелогичными илинеинтересными. Поэтому в интересах тех, кто отвеча-ет за бизнес-планирование, помочь понять всем дру-гим, почему проект имеет право на существование сделовой точки зрения. В технической сфере деловую

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

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

Хороший деловой взгляд означает, что у командыесть ответы на следующие вопросы:

• Почему этот проект необходим для нашего бизне-са?

• Какие неудовлетворенные потребности или жела-ния имеются у наших клиентов?

• Какие характеристики или услуги мы можем пред-ложить для удовлетворения этих желаний или потреб-ностей?

• Что сможет побудить клиентов приобрести этот

продукт или воспользоваться этими услугами? Чтостанет причиной такого поступка?

• Во что это обойдется (с точки зрения затрат люд-ских и материальных ресурсов)? Сколько на это уйдетвремени?

• Каков уровень возможных доходов (или сниженияорганизационных и производственных затрат)? За ка-кой период времени?

• От производства каких изделий нужно отказать-ся, чтобы справиться с производством данного про-дукта?

• Сможет ли проект внести вклад в нашу долгосроч-ную деловую стратегию или защитить другие доход-ные активы? (Даже некоммерческие или IT-органи-зации придерживаются бизнес-стратегии: они всегдавыставляют счета на оплату, стремятся получить до-ход или имеют для поддержки своей деятельности ко-манды, работающие на извлечение дохода.)

• Как проект поможет нам идти в ногу с конкурента-ми, обойти или превзойти их?

• На какие рыночные интервалы времени можно на-целить данный проект?

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

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

Маркетинг – слово совсем не ругательное

Самой несправедливой критике бизнесмены под-

вергаются в среде «технарей», где их обзывают «тор-гашами». Я думаю, что маркетинг в данном слу-чае получает удар ниже пояса. В терминологии об-разовательной программы MBA (Master of BusinessAdministration – магистр делового администрирова-ния) маркетинг можно определить четырьмя «P»:Product (продукция), Price (цена), Placement (распро-странение продукта) и Promotion (продвижение про-дукта на рынке). Определение вида продукции и цены– процесс творческий. Его цель состоит в том, чтобыпроработать идею продукции, продаваемой с прибы-лью и отвечающей потребностям определенного по-купателя. Чтобы добиться в этом деле успеха, необ-ходимы исследования, анализ и творческая работа.Распространение продукта (третья буква «P») подра-

зумевает способы получения продукта покупателем.(Через веб-сайт? Через супермаркет? Из багажникаавтомобиля?)

И наконец, продвижение продукта на рынке, чтопо сложившемуся стереотипу и принимают за мар-кетинг, – означает распространение положительныхотзывов о продукте среди влиятельных людей и по-тенциальных покупателей. Как ни странно, но продви-жение продукта занимает весьма скромную часть ра-бочего времени бизнес-аналитика или менеджера попродажам (возможно, 10–20 %). Получается, что мар-кетинговые планы определяются куда больше вопро-сов, чем внешний вид рекламы или приемы продви-жения товара на рынке, которые будут предприняты.К тому же следует заметить, что четыре «P» марке-тинга применимы практически ко всему. Всегда естьпродукт (защищенный веб-сайт), цена (бесплатный),размещение (интранет) и продвижение (сообщенияпо электронной почте).

Но когда деловые перспективы рассматриваютсяоднобоко, проявляется только треть потребностей.На объем продаж влияет качество продукции, но ононе зависит от маркетинга. Качество19 является про-

19 Эндрю Стеллман (Andrew Stellman), один из научных редакторовданной книги, несколько раз угрожал мне физической расправой, еслия не расскажу о качестве программного продукта, но эта глубокая те-

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

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

Взгляд разработчика

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

ма так и не вписалась в рамки моей книги. Для начала порекомендуювам две другие книги: «Out of the Crisis» (MIT Press, 2000) У. ЭдвардсаДэминга (W. Edwards Deming) и «Quality Is Free» (Signet Books, 1992)Филиппа Кросби (Philip Crosby).

Вообще-то мы думали, что кругом царит сплошноенадувательство. Нашу критику выдерживали далеконе все продукты. Мы удивлялись, почему рынок за-вален посредственной продукцией. Для объяснениявредных решений, которые, как мы думали, прини-мались вразрез с понятиями технического совершен-ства и вопреки здравому смыслу, мы даже изобрелитеорию тайного заговора. Зачастую мы во всем обви-няли отделы маркетинга20 (совсем немногие из нас по-нимали, чем на самом деле занимаются специалистыпо маркетингу). Даже в мои первые годы на производ-стве разговоры на эту тему велись практически посто-янно. Только тогда мы еще больше ко всему присмат-ривались, поскольку конкурировали со многими про-граммными продуктами или веб-сайтами, о которыхшли разговоры.

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

20 Файзал Джафдат (Faisal Jawdat), один из научных редакторов дан-ной книги, угрожал мне изощренными пытками, если я не отмечу всюиронию ситуации, в которой после всего сказанного я продолжал рабо-тать на Microsoft.

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

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

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

• Что именно в соответствии с ним (проектом) тре-буется сделать?

• Как это будет работать? Как будет работать каж-дый компонент?

• Как это будет создаваться? Как мы будем прове-рять, что это работает в соответствии с нашими пред-положениями?

• Насколько надежны, эффективны, расширяемыи производительны существующие и нами создавае-мые системы? Существуют ли пробелы между всемэтим и требованиями проекта?

• Какие технологии или архитектуры на данный мо-мент нам полностью доступны? Будем ли мы делатьставку на какую-нибудь новую технологию, котораяеще недоступна, но будет вскоре готова к использо-ванию?

• Какие технологические процессы и подходы соот-ветствуют данной команде и данному проекту?

• Какими знаниями и деловым опытом обладают на-ши специалисты? Работу над чем они приостановят,чтобы заняться данным проектом?

• Чем мы восполним недостаток делового опыта?

(Методом проб и ошибок, наймом на работу другихспециалистов, обучением своих специалистов? Илипроигнорируем эти пробелы в надежде, что они вол-шебным образом исчезнут сами по себе?)

• Сколько времени займет создание продукта и ка-ков при этом будет его уровень качества?

Взгляд потребителя

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

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

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

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

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

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

21 Эта сноска дана специально, чтобы заставить читателя обращатьна сноски хоть какое-то внимание. А если серьезно: когда проектиров-щики работают на себя, они имеют склонность многократно переделы-вать сделанное, возможно, расслабляясь в отсутствие образа потреби-теля, на которого надо работать.

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

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

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

• Чем обычно заняты люди? (Не наши домыслы и

не то, что они об этом рассказывают.)• Какие проблемы они испытывают, стараясь зани-

маться своим делом? Что их ставит в тупик, смущаетили расстраивает?

• Что им нужно или хотелось бы делать, но не пред-ставляется возможным?

• Есть ли конкретные возможности сделать продуктпроще, безопаснее, быстрее или надежнее для потре-бителей?

• Какие конструкторские идеи по улучшению потре-бительских свойств продукта, с точки зрения обыч-ных людских занятий, имеют наибольшие перспекти-вы произвести впечатление на потребителя?

• Как можно исследовать подобные идеи? Какиепрототипы прикидки или варианты нуждаются в ис-следовании, чтобы помочь нам осмыслить потенциалпроекта?

• Какие основные идеи и концепции должны бытьпредставлены в проекте, чтобы донести информациюдо пользователей?

Магия единой точки зрения

Все три взгляда на проект всегда имеют некоторые

совпадения. На каждое деловое соображение оказы-вают влияние технические и потребительские сторо-

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

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

Использование диаграммы Венна (подобной той,что изображена на рис. 3.2), которая помогает выпра-вить нездоровый уклон во взглядах, допускаемый ин-женерами и специалистами по маркетингу, имеет по-чти такое же по важности значение, как и стратеги-

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

Рис. 3.2. Три взгляда на проект

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

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

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

В прежние годы я и сам порой оказывался втяну-тым в эти бессмысленные войны. Я был руководите-лем проекта создания поисковых функций в InternetExplorer 4.0. К нам были назначены два специалистапо развитию бизнеса, которые вели переговоры об ис-пользовании основных поисковых машин того време-ни (Excite, Yahoo! Lycos, AltaVista и т. д.). Мы вели спо-ры с этими экспертами по бизнесу вокруг конструктор-

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

Я убежден, что более широкий взгляд на окружаю-щий мир поможет каждому участнику процесса. Мывсе были настолько эгоистичны и самоуверенны, чтоне жалели тратить время на битву по мелочам, вме-сто того чтобы попытаться учесть все точки зрения нато, что мы, собственно, создавали. Нам мог бы помочьболее образный концептуальный документ, но в ту по-ру (примерно в 1997 году) это было невозможно, по-скольку задачи бизнеса в Интернете были слишкомновыми для производства. Тем не менее, не затеваймы тогда войну, а поделись знаниями друг с другом,возможно, нам удалось бы достичь успеха в поискахвзаимовыгодного компромисса.

Внедрение в проект обобщенного взгляда позволит

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

Баланс сил

При работе в крупной организации следует учиты-вать распределение сил по всем точкам зрения. На-

пример, если инженеры превосходят по численностибизнес-аналитиков в соотношении три к одному, впринимаемых решениях будет уклон на доминирова-ние технологического взгляда. Соотношение сил – этопростое соотношение количества приверженцев тогоили иного взгляда. Для баланса взглядов соотноше-ние должно быть 1:1:1 (с позиций разработчика, биз-несмена и потребителя). Чем больше несбалансиро-ванность, тем больше усилий требуется от руководи-телей, чтобы ее скомпенсировать.

Разумеется, примерное количество людей не опре-деляет объем имеющихся у них полномочий. В армииНаполеона были тысячи солдат, но Наполеон былтолько один. В команде может быть 10 программи-стов и 1 специалист по маркетингу (10:1:0), но послед-ний может иметь больше полномочий в рамках про-екта, определяющих его роль или старшинство. Этоозначает, что руководитель в состоянии компенсиро-вать натуральное соотношение, наделяя полномочи-ями тех, кто должен иметь больше влияние на проект.А поскольку сущность проекта со временем меняет-ся, представители различных взглядов должны в раз-ное время получать различный уровень полномочий.О том, как можно поручать принятие решений для до-стижения нужного баланса в нужное время, рассказы-вается в главе 12.

Постановка правильных вопросов

Уточнение набора вопросов, на которые необходи-

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

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

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

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

• Почему появился этот проект? Почему именно мыподходим для его осуществления? Почему его следу-ет реализовать именно сейчас?

• Что собой представляют три или четыре категориилюдей, которых можно рассматривать в качестве раз-личных типов потребителей? (Например, для тексто-вого процессора это могут быть студенты, професси-оналы и обыкновенные пользователи, для информа-ционной базы данных – продавцы, секретари и руко-водители.) Как отличаются их потребности и привыч-ки?

• Какая демографическая информация может по-мочь разобраться в типаже потребителей? (Возраст,заработок, вид компании, профессия, образование,пользование другими программными продуктами иливеб-сайтами и т. д.)

• Для каких целей каждой из групп используетсяпрограммный продукт? В какой степени это соответ-ствует целям покупки? Как это соответствует органи-зации продаж продукта? С какими проблемами онистолкнулись при использовании продукта для удовле-творения своих потребностей?

• Кто потенциально может стать новым покупате-лем и какие характеристики, сценарии работы или ти-пы продукции нам нужно предоставить, чтобы превра-тить их в реальных покупателей? (Каковы демографи-ческие данные этих новых покупателей?)

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

• Можем ли мы создать технологию или набрать-ся опыта для создания продукта, удовлетворяющегоэтим запросам или решающего эти проблемы? (Да,может быть, нет.)

• Присутствуют ли эти значимые возможности в но-вом продукте или линейке продуктов? Или связаны линепосредственно с продуктом (линейкой продуктов)выявленные запросы?

• Существуют ли действенные бизнес-модели дляиспользования нашего делового опыта и технологиив решении выявленных проблем или в удовлетворе-нии запросов? (Смогут ли доходы превысить затратыв обозримом будущем?)

• Какими должны быть сроки выпуска на рынок сле-

дующей версии или следующего продукта? В какиеблагоприятные моменты лучше всего выпустить про-дукт?

• Чем в этой рыночной нише заняты конкуренты?В чем по нашему мнению заключается их рыночнаястратегия и как мы можем с ними конкурировать?

Ответы на правильные вопросы

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

но и в промежуточных фазах проекта, при внесениипоправок и изменений.

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

Что делать при дефиците времени?

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

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

Перечень типичных просчетов при

определении конечной цели проекта

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

ником проблем.

Таблица 3.1. Наиболее распространенные просче-ты в определении конечной цели проекта

Процесс планирования

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

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

для их самовыражения.Если вы используете те документы по планирова-

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

Рис. 3.3. Взаимосвязь между уровнями планирова-ния

Черновой вариант каждого входящего в планирова-ние документа должен быть готов как можно раньше,чтобы до выработки окончательной версии включитьв него все обратные связи, выработанные командой.Это могут быть простые циклы обратной связи междудокументами плана, изображенные на рис. 3.3. Послесоздания чернового варианта анализа потребностейрынка – MRD, появится возможность приступить к ра-боте над концептуальным документом, во время кото-рой будут возникать новые вопросы, касающиеся это-го анализа, улучшающие документ до его заверше-ния. Эта же схема работы повторяется при разработ-ке всех документов. Таким образом, даже если срокиокончания разработки документов плана поджимают,некоторые перекрытия по времени разработки каждо-го из них пойдут только на пользу и повысят качествовсего процесса. Как показано на рис. 3.4, когда разра-ботка проекта достигает середины (стадии выполне-ния), распространение вверх по структуре планиро-вания подобных обратных связей дается все труднее,хотя и не исключается. (Можно считать, что рис. 3.4иллюстрирует работу нанятой по контракту команды,сфера влияния которой ограничена выработкой тех-нических условий и определением характера и объе-ма работ.)

Рис. 3.4. Со временем становится все труднее вно-сить коррективы в верхние элементы структуры пла-нирования, хотя такая возможность не исключается

Повседневная работа

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

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

Наиболее важная часть процесса – распреде-ление ролей. Кто получит полномочия на выдвиже-ние требований? На проектирование? Если к процес-су привлекается много людей, как будут приниматьсярешения? Как быть при равенстве голосов? Если по-добные вопросы взаимоотношений решить на раннейстадии, то удастся избежать многих проблем или, чтоболее вероятно, справиться с ними хладнокровно исвоевременно. (Наиболее полно проблемы взаимоот-ношений и распределения ролей рассмотрены в гла-ве 10.)

О промежуточных пунктах должны знать все.Какие этапы нужно пройти от начала до конца пла-нирования? Непосредственные исполнители сначаладолжны составить календарный перечень мероприя-

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

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

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

Исследование потребительских

запросов и допускаемыепри этом просчеты

Существует множество разнообразных неправиль-

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

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

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

Таблица 3.2. Типичные методы исследования по-требительских запросов

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

2 Оцените свое собственное усердие при участии в

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

3 В оригинале «Usability study». – Примеч. ред.

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

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

знатоком под стать узким специалистам).Но даже при нехватке ресурсов или финансирова-

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

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

Объединяем все вместе– выработка требований

При планировании создается большой объем ин-

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

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

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

Для выработки и документирования требований су-ществует ряд устоявшихся методов, и я рекомендуюознакомиться с ними самостоятельно.22 В зависимо-сти от уровня имеющихся при выдвижении требова-ний полномочий применяются различные способы ре-шения этой задачи, позволяющие достичь хорошихрезультатов. Особенности этих методов и способы ихприменения в данной книге не рассматриваются. Темне менее один метод, отличающийся простотой, лег-костью в применении и эффективностью, я могу вампредложить – это метод постановки задач.

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

22 Обратите внимание на замечательную книгу Дональда Гауса(Donald Gause) и Джералда Вейнберга (Gerald Weinberg) «ExploringRequirements: Quality Before Design» (Dorset House, 1989).

щегося к потребительскому взгляду на проект (в про-тивовес взглядам разработчика или бизнесмена). Темсамым будет гарантирована поддержка точки зренияпотребителя, она не будет искажена другими точкамизрения.

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

• С домашней страницы затруднен поиск часто вос-требуемых разделов.

• Ведомственная информационная страница долгозагружается, заставляя пользователя ждать.

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

• Веб-сайт не обеспечивает автоматического досту-па к защищенным услугам, а ручной доступ отнимаетмного времени.

• Результаты поиска трудно просматривать в суще-ствующем формате.

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

• Страница состояния не включает информацию обэлектронной почте, и пользователи не могут узнать,почему их электронная почта не работает.

• Отсутствует способ сохранения предпочтений иливариантов появления домашней страницы.

Заметьте, что это – не отчет об ошибках. Возмож-но, данные проблемы ранее не рассматривались какобязательные условия работы веб-сайта. Постановказадач должна быть более масштабной и отличатьсяпо виду от перечня ошибок, поскольку сама идея со-стоит в том, чтобы ухватить упущенные детали, отно-сящиеся к потребительскому взгляду, а не оцениватьвсе неудачи с точки зрения разработчика.

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

Проблемы превращаются в сценарии

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

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

23 Этот метод описан в книге Алистера Кокборна (Alistair Cockburn)«Writing Eff ective Use Cases» (Addison Wesley, 2000).

зиться анализ их бизнес-потенциала или возможно-стей технической реализации.

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

Итак, возможные характеристики проекта X:• Часто востребуемые разделы можно будет легко

обнаружить на домашней странице.• Результаты поиска будут представлены в доступ-

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

• Веб-сайт обеспечит простой автоматизированныйдоступ к защищенным услугам.

• Регистрационная страница позволит упроститьбезошибочный ввод информации.

• Ведомственная информационная страница будетзагружаться, по крайней мере, так же быстро, как идомашняя страница.

• Интерфейс запросов к базе данных будет по на-дежности сопоставим с остальными компонентамисистемы.

• Пользователи получат возможность видеть состо-яние сервера электронной почты в простом и удобномформате.

• У пользователей будет удобный способ сохранятьсвои предпочтения при настройке системы.

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

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

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

Объединение деловых и

технологических требований

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

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

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

Выводы

• Разные проекты требуют различных подходов к

планированию.• Результаты планирования часто определяются

тем, кто и какими полномочиями обладал. На пла-

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

• Существует ряд общих разработок для планиро-вания проекта: документы, отражающие анализ по-требностей рынка (MRD), документы, определяющиеконцепцию и рамки проекта, технические условия идокументы структурной декомпозиции работ (WBS).

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

• Постановка вопросов наводит на правильные раз-мышления и эффективно направляет энергию плани-ровщиков в нужное русло.

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

• Формулировка проблем и выработка сценариевпредставляют собой простейший способ определе-ния перечня требований и доведения его до участ-ников проекта. Эти документы легко превращаютсяв конструкторские идеи, сохраняя видение главных ивторостепенных составляющих проекта.

Упражнения

1. Составьте список лиц, обладавших конструктор-

скими, технологическими и деловыми полномочиямипри реализации вашего последнего проекта. Была лиэта информация разъяснена команде с самого нача-ла? Был ли правильным подбор людей для принятияподобных решений? Как это повлияло на проект?

2. Из трех взглядов на проект – с точки зрения биз-несмена, разработчика и потребителя – какой былпредставлен меньше других в последнем, реализо-ванном вами проекте? Как это повлияло на качествоконечного изделия?

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

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

шений? (Подсказка: Какие вопросы не были подняты?Какие точки зрения не были представлены?)

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

6. Составьте список мер, которые вы в качестве ру-ководителя, а не саботажника могли бы предпринятьдля предотвращения действий или в ответ на меры,перечисленные в предыдущем списке.

7. Какие в проекте были признаки осложнений, по-требовавшие слишком большого внимания при пла-нировании? Что можно было бы сделать, если вы какруководитель проекта заметили бы все эти признаки?

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

любой книги на эту тему.9. Должен ли специалист, составляющий требова-

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

Глава 4. Разработка качественных

концептуальных документов

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

В главе 3 был дан краткий обзор документов пла-нирования, где были упомянуты документы, отражаю-щие анализ потребностей рынка (MRD), концептуаль-ные документы и технические условия. В данной гла-ве основное внимание уделено концептуальным до-кументам как наиболее важной составляющей всехматериалов планирования. Я объясню, почему наразработку концептуальных документов стоит потра-

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

Рис. 4.1. Готовый концептуальный документ знаме-нует окончание фазы планирования, так же как готов-ность технических условий означает окончание фазыпроектирования

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

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

В чем ценность ведения записей

Дэниел Бурстин (Daniel Boorstin), автор велико-

лепных работ «The Creators» (Vintage, 1993) и «TheDiscoverers» (Vintage, 1985), как-то сказал, что пись-менное слово было величайшей из всех технологий,когда-либо изобретенных человеком. Без него нампришлось бы всецело зависеть от нашей печальноизвестной своей дырявостью памяти,24 занимаясь та-кими сложными вещами, как создание динамита (гм,в каком весовом соотношении должны быть нитро-

24 Прочтите книгу Дэниела Шактера (Daniel Schacter) «The SevenSins of Memory» (Mariner Books, 2002) или посмотрите замечательныйфильм «Помни» («Memento»). Это поможет вам осознать, сколь огра-ничена и ненадежна человеческая память.

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

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

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

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

Какой по объему концептуальный

документ вам нужен?

Мне попадались концептуальные документы объ-емом в 50 страниц, состоящие из тщательно отфор-матированных результатов исследований, диаграмм

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

Рассмотрение следующих вопросов поможет вамопределить структурную сложность и трудоемкостьвашего концептуального документа:

• Много ли обоснованных вопросов имеется у самойкоманды относительно будущей работы? Наскольколюди осведомлены о предстоящей работе и о важно-сти ее результатов?

• Сколько разных людей будет вовлечено в реа-лизацию проекта? Сколько различных организацийпредставляют эти люди? Каким образом вы сможетеправильно оценить ожидаемый вклад каждой органи-зации?

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

• В какой мере вы допускаете влияние стороннихорганизаций на основную направленность проекта?

• Сколько проницательности, компетентности и рас-судительности потребуется от руководителя проектапри принятии ключевых проектных решений? (Оче-видно, именно эти свойства будут востребованы привыработке концепции.)

• Насколько глубоко команда сможет вмешиватьсяв стратегию проекта в процессе работы над его реа-лизацией?

• Какие объемы исследований в процессе планиро-вания проекта ожидает от вас руководство? Как вы бу-дете доводить до руководства результаты этих иссле-дований?

• Возникнет ли в последующем необходимость на-поминать команде о целях проекта? Склонны ли со-трудники возвращаться к спорам по отдельным по-ложениям, с которыми они совсем недавно согласи-лись?

Чем детальнее и точнее вы ответите на данные во-просы, тем большую ценность приобретет концепту-

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

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

Общекомандные и

индивидуальные цели

Для подробного разговора о концептуальном доку-

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

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

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

Индивидуальные цели. Подраздел общекоманд-ных целей, являющийся сферой ответственности от-дельного работника.

Для небольших проектов разница между общеко-мандными и индивидуальными целями может бытьнезначительной (рис. 4.2). Проект даже может бытьнастолько мал, что ее и вовсе не будет. Но для боль-

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

Рис. 4.2. Три уровня целей

Давайте в качестве примера возьмем некий про-

ект создания корпоративного веб-сайта под названи-ем «Гидра»:

• Концепция. Веб-сайт «Гидра» предоставит удоб-ный доступ к большинству наиболее востребованныхисточников корпоративной информации (поиск, учет,инвентарь, внутренние ресурсы, перевозки) из едино-го места с использованием простого и понятного ин-терфейса.

• Общекомандные цели. Команда А будет отвечатьза создание доступных и простых в применении си-стем поиска и учета. Команда Б будет отвечать за со-здание систем инвентаризации, учета внутренних ре-сурсов и перевозок.

• Индивидуальные цели. Фрэд (из команды А) бу-дет заниматься проектированием и разработкой всехфункций, необходимых для поисковой системы. Майк(из команды Б) будет курировать все работы по об-щему устройству веб-сайта и вырабатывать техниче-ские условия на создание интерфейса для «Гидры».Боб (из команды Б) будет заниматься проектирова-нием и разработкой всех функций, необходимых дляучета внутренних ресурсов и перевозок.

Здесь прослеживается строгая наследственностьсверху вниз: общекомандные цели происходят из це-лей проекта, а индивидуальные цели – в основном, изсферы целей общекомандных (наиболее важным ис-

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

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

Пять качеств хорошей концепции

Поскольку первоисточником всех целей является

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

Простота

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

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

Целенаправленность

Концептуальный документ – это первоисточник це-лей проекта. Он задает тон правильной формулиров-ке целей, определяет их количество и объем возмож-ных корректировок в ходе реализации проекта. Четкосформулированная цель определяет ясность намере-ний всех специалистов команды. Люди должны знать,что именно является критерием достижения цели, а

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

Для правильной формулировки целей широко ис-пользуется деловой подход, выражаемый акронимомSMART (Specific, Measurable, Action-oriented, Realistic,Timely – точность, измеряемость, действенность, ре-алистичность, своевременность). Идея состоит в том,что если цель соответствует этим пяти требовани-ям, то, скорее всего, она достаточно хорошо опре-делена для дальнейшего использования (тем не ме-нее остаются субъективные рассуждения о том, на-сколько конкретной или реалистичной должна бытьцель). При формулировке цели можно воспользовать-ся и другим приемом – отнестись к ней максимальнопридирчиво и задаться вопросом, не провалится ли

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

Консолидирующая способность

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

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

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

Вдохновляющая способность

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

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

Запоминаемость

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

добиться желаемого эффекта невозможно. Люди ред-ко запоминают то, в чем не могут разобраться.)

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

Ключевые моменты

В основу концепции должны быть положены отве-

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

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

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

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

• Как этот проект содействует целям организации?

Почему он важнее других проектов, которые также мо-гут содействовать достижению этих целей?

• Какие сценарии или потребительские свойства яв-ляются основными для данного проекта? (Приоритет– 1.)

• Какие сценарии или потребительские свойства, неявляющиеся основными, желательно реализовать?(Приоритет – 2.)

• Что представляют собой потребители продукта?Какие проблемы решаются в их интересах реализаци-ей данного проекта? Какими очевидными признакамиили исследованиями (в противовес мнениям и пред-положениям) подкреплены эти утверждения? Как по-требители справляются со своей работой без продук-та, реализуемого данным проектом?

• Кто представляет в организации стороны, заин-тересованные в данном проекте (люди, облеченныеполномочиями по реализации данного проекта, кото-рые не обязательно должны быть пользователями со-здаваемого в его рамках продукта)? Какая роль им от-водится в проекте? (Заинтересованные стороны бу-дут рассмотрены в главе 16.)

• Почему потенциальные потребители станут поку-пать изделие или подписываться на услугу? (Туман-ные фразы вроде «потому что это круто» или «пото-му что им не из чего выбирать» в качестве ответа не

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

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

• Какие решения, направленные на удовлетворениепотребительских нужд, были востребованы или пред-ложены, но определенно не станут частью проекта?

• Какие существуют не связанные с технологиейподходы к исследованию проблемы?

• Что не планируется выполнять в рамках проекта?(Перечислите без лишнего педантизма те идеи, кото-рые могут кем-то рассматриваться в качестве частипроекта, но в него не войдут. Включите в рассмотре-

ние деловые и потребительские взгляды на проект,если очередь до них еще не доходила.)

• Каковы более-менее вероятные возможности про-вала данного проекта и как их можно исключить илисвести к минимуму? (В ранних прикидках могут бытьтолько оценки рисков без планов, как их избежать илисправиться с ними.)

• Что в успехе данного проекта зависит от другихкомпаний или групп? Зависит ли успех других компа-ний или групп от реализации данного проекта?

• Как в общем представлении будет распределенаработа между командами? Кто возглавит каждое изосновных направлений проекта, какими полномочия-ми будут наделены эти люди?

• Какие были выдвинуты предположения, от кото-рых зависит успех проекта? В какой степени данныйпроект зависит от других проектов, компаний или ор-ганизаций?

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

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

Умение четко излагать мысли

Даже тем из нас, кто обладает способностью

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

Простота дается не легко

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

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

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

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

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

У хорошей разработки

только один главный автор

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

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

Каноническим примером единоличного авторстваслужит Декларация независимости США. В 1776 го-ду Континентальный конгресс сформировал комис-сию для выработки этого документа. Комиссия соби-ралась несколько раз, однако осознав особую важ-ность такой характеристики документа, как доходчи-вость, поручила разработать проект Томасу Джеф-ферсону. Джефферсон поступил так же, как я реко-мендую поступать и команде проектировщиков, – онразработал множество проектов и принял участие вих обсуждении в Конгрессе, по нескольку раз пере-сматривая некоторые из них. Несколько недель спу-стя, группа представила Конгрессу окончательный ва-

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

Качество не определяется объемом

Следует понимать, что ясная мысль не требуетмногостраничного изложения. Самые действенныеруководящие документы в мире не отличались боль-шим объемом. Конституция США, включая Билль оправах, содержит всего лишь 7000 слов (около 6 стра-ниц). Десять заповедей состоят из 300 слов. Великаяхартия вольностей – из 5000. Светлые головы способ-ны извлечь из идей самую суть и выразить их намно-го доходчивее любых описаний, занимающих вдвоебольше места. Не следует путать понятия объема икачества. К сожалению, из-за того, что объем даетсялегче, чем качества, мы иногда поддаемся следующе-му искушению: «Если ничего хорошего не выходит, томожно выиграть хотя бы за счет объема, а вдруг ни-кто не заметит разницы» (еще одна привычка в рабо-те авторитетных комиссий). Итак, с учетом всего вы-шеизложенного, вполне уместно спросить меня о том,почему же я не сократил объем этой книги. Виноват,

не смог.Все эти рассуждения предполагают, что к назначе-

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

Прикидки, пересмотры и переработки

В каждой организации бытуют собственные пред-

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

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

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

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

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

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

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

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

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

Рис. 4.3. Основной график рассмотрения и коррек-тировки концептуального документа

Как только концептуальный документ будет готов,стадия планирования завершится (см. рис. 4.3). Ко-манда должна располагать информацией, необходи-мой для успешного проектирования в соответствии споставленными целями. Если работа над концепциейвелась в той последовательности, которая показанана рис. 4.2, команда должна приступить к проектиро-ванию, поскольку основные направления ей были из-вестны заранее.

Перечень неудачных

положений концепции(которых следует избегать)

За свою профессиональную карьеру мне приходи-

лось читать десятки концептуальных документов и са-мые плохие из них содержали одни и те же стереоти-пы. Плохо составленные концепции не имеют целост-ности, не предлагают никакого плана и не выражаютсовокупности мнений. Вместо этого в них излагают-ся размышления и прописные истины. Если в концеп-ции нет четкого взгляда на то, что должно быть сдела-но, руководители команд никогда не станут работатьс душой, обрекая проект на провал. Герой фильма«Бойцовский клуб» («Fight club») Тайлер Дурден (TylerDurden) говорит: «Если вы воткнете себе сзади перья,то все равно не станете курицей». Если вы создаетедокумент с надписью «концепция» на титульном ли-сте, это еще не означает, что в результате вы получитеименно концепцию. Можно делать все по правилам,проводить совещания, пользоваться формализован-ными документами и все же упустить всю суть, радикоторой и создается концептуальный документ. Точнотак же, как титул «руководитель проекта» не означа-ет волшебного превращения всего, что вы делаете в

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

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

Таблица 4.1. Типичные примеры неудачных кон-цептуальных положений

Примеры концептуальныхположений и целей проекта

В данном разделе я приведу несколько примеров

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

Вот примеры вполне удачных концептуальных по-ложений:

• SuperEdit 3.0 – это инструмент редактирования,предназначенный для опытных литературных редак-торов, позволяющий облегчить их работу, ведущую-ся по пяти самым распространенным сценариям, бо-лее надежный и быстродействующий по сравнению сSuperEdit 2.0.

• Superwidgets.com станет ведущим веб-сайтом Ин-тернета, предназначенным для приобретения разно-го рода небольших приспособлений и устройств снаб-женцами средних по величине компаний. Он сделаетвесь процесс приобретения простым, легким и надеж-ным.

• В версии 5.5 Helpdesk Automated Services Site(HASS) будут учтены десять самых распространен-

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

В качестве примера удачных целей проекта приво-дится перечень, использовавшийся разработчикаминаладонного органайзера Palm Pilot:25

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

2. Стоимость. Устройство должно стоить меньше,чем органайзер элитного класса (около 300 долларовСША).

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

4. Синхронизация с персональным компьютером.Компьютер должен стать основным средством взаи-модействия с пользователем.

Удачно сформулированные цели проекта, подоб-ные перечисленным, отличаются простотой и ясно-

25 Из книги «Piloting Palm: The Inside Story of Palm, Handspring andthe Birth of the Billion-Dollar-Handheld Industry» авторов Андреа Баттера(Andrea Butter) и Дэвида Поги (David Pogue) (Wiley, 2002), стр. 72.

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

Обоснование концептуальных

положений и целей

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

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

Концепции должны быть наглядными

Указывая пальцем на Луну, не

перепутайте палец с Луной.Дзен-буддистская притча

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

туальным положениям и идеям изображения придаютнаглядность – изображения воспринимаются намногобыстрее и понятнее, чем словесные описания. Я де-сятки раз в своем офисе вел переговоры с програм-мистами или с разработчиками архитектуры компью-терных систем, которые настойчиво пытались доко-паться до сути приводимых аргументов, и все закан-чивалось лишь тогда, когда кто-нибудь из нас, в кон-це концов, подходил к доске, воплощал идею в эски-зе и спрашивал: «Вы именно это имели в виду?» По-сле чего обычно раздавался взрыв хохота, вызванныйосознанием того факта, что мы затратили впустую уй-му времени, пытаясь объяснить суть объектной моде-ли или конструктивных особенностей на словах илина пальцах, в то время как сделать это с помощьюдоски и фломастера было намного проще и быстрее.Думаю, что в американской культуре основной упорделается на развитие навыков устной речи и уме-ние производить математические выкладки, а не наразвитие артистических и изобразительных способ-ностей, поэтому многим профессионалам для приоб-ретения соответствующих навыков требуется некото-рая практика. Я убежден, что мы многое теряем, за-бывая об эффективности выражения идей изобрази-тельными средствами.

Все лучшие образцы концептуальных документов

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

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

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

Наглядное представление

неочевидных вещей

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

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

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

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

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

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

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

Ежедневное поклонение

концептуальным положениям

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

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

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

Но этих мер явно не достаточно для поддержанияконцепции в актуальном состоянии. Лишь то, что лю-ди ее запомнили, еще не означает, что они ее исполь-зуют в своей работе. Сохранение актуальности кон-цепции требует усилий со стороны руководства ко-манды. Оно должно постоянно обращаться к тем са-мым мотивам, которые и привели к созданию самой

концепции.В процессе работы над реализацией проекта на

каждом совещании по подведению итогов или поста-новке задач обращайтесь к следующим вопросам:

1. Насколько точно концепция отражает наши цели,определенные для этого проекта?

2. Помогает ли концепция ведущим и рядовым со-трудникам принимать решения, а также отклонять за-просы, не имеющие к ней отношения?

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

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

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

всех четкость представлений и осмысленность основ-ных концептуальных замыслов.

Выводы

• Концептуальные документы являются квинтэссен-

цией всех остальных материалов планирования и на-ходят свое выражение в едином обобщенном плане.

• Документирование приносит пользу и создателюконцепции, и всей команде. Тем самым закладывают-ся основы для проведения дискуссий и рабочие ори-ентиры, не зависящие от нашей «дырявой» памяти.

• Степень детализации вашего концептуального до-кумента зависит от особенностей команды и самогопроекта.

• Цели команды должны быть производными от це-лей, определенных в концепции, а индивидуальныецели, в свою очередь, от целей, поставленных передкомандой.

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

• Объем не является эквивалентом качества. Акраткость требует больших усилий.

• Концепция должна сохранять актуальность за

счет ее повседневной сверки с решениями, принима-емыми в ходе реализации проекта.

Упражнения

1. Выберите какой-нибудь фильм или книгу, ко-

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

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

3. Исследуйте историю прорицателей. Выберите

любых двух из следующего списка: Ганди, МалкольмХ, Торо, Будда, Сократ, Иисус Христос или Конфуций.Какими были их мировоззренческие концепции? Какони развивали свои идеи? Что они делали для выра-жения этих идей? Для их продвижения и популяриза-ции?

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

5. Что может произойти, если чьи-то индивидуаль-ные цели вступают в конфликт с целями команды илипроекта? Кто должен разрешить подобную ситуацию?Какие действия нужно предпринять?

6. Когда настанет время для команды написатьконцептуальный документ или технические условия,распечатайте несколько копий Конституции США иоставьте все это на стуле любого из авторов техни-

ческих условий с запиской: «Они составили техниче-ские условия для целого правительства всего на ше-сти страницах. А сколько понадобится тебе для опи-сания отдельной характеристики?» Как на это отреа-гирует команда?

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

Конец ознакомительного

фрагмента.

Текст предоставлен ООО «ЛитРес».Прочитайте эту книгу целиком, купив полную ле-

гальную версию на ЛитРес.Безопасно оплатить книгу можно банковской кар-

той Visa, MasterCard, Maestro, со счета мобильноготелефона, с платежного терминала, в салоне МТСили Связной, через PayPal, WebMoney, Яндекс.День-ги, QIWI Кошелек, бонусными картами или другимудобным Вам способом.