Искусство управления IT-проектами Беркун Скотт
Информация, содержащаяся в данной книге, получена из источников, рассматриваемых издательством как надежные. Тем не менее, имея в виду возможные человеческие или технические ошибки, издательство не может гарантировать абсолютную точность и полноту приводимых сведений и не несет ответственности за возможные ошибки, связанные с использованием книги.
© ООО Издательство «Питер», 2014
Все права защищены. Никакая часть электронной версии этой книги не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, включая размещение в сети Интернет и в корпоративных сетях, для частного и публичного использования без письменного разрешения владельца авторских прав.
Об авторе
Скотт Беркун изучал информатику, философию и дизайн в университете Карнеги Меллон. Он работал в компании Microsoft с 1994 по 2003 год, занимаясь проектированием и разработкой Windows, MSN, Internet Explorer с 1,0 по 5,0 версию. Скотт ушел из Microsoft в 2003 году, намереваясь заполнить одну из своих книжных полок собственноручно написанными книгами. На данный момент он написал две книги – ту, которую вы сейчас читаете, и «The Myths of Innovation».
В качестве независимого консультанта он продолжает учить управлению проектами, разработке программного обеспечения, методологии творческого мышления и проектированию программных продуктов. Скотт выступает с лекциями, ведет семинары и вносит разнообразие в рутину многочисленных производственных конференций. Его труды получили признание на страницах New York Times и Washington Post.
Если вы хотите пообщаться на форуме, относящемся к тематике данной книги и десятка других эссе, почитать весьма популярный блог автора и получить множество полезной и интересной информации, посетите веб-сайт www.scottberkun.com.
Благодарности
К новому изданию
Я благодарен команде издательства O’Reilly: Мери Треселер (Mary Treseler), Марло Шифферу (Marlowe Shaeffer), Саре Пейтон (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) – за составление индексного указателя, Гленну Бизигнани (Glenn Bisignani) – за работу в качестве агента по сбыту.
В следующий список включены люди, не пожалевшие своего времени на то, чтобы дать свои отзывы о ранних проектах глав. Большое спасибо Мишель Бреман (Michelle Breman), Пьерро Сьерра (Pierro Sierra), Эрику Бречнеру (Eric Brechner), Ричарду Стокли (Richard Stoakley), Марку Стацмену (Mark Stutzman), Нэйлу Эннзу (Neil Enns), Джейсону Пасу (Jason Pace), Али Валлаю (Aly Valli), Джо Бельфиору (Joe Belfiore), Биллу Стаплесу (Bill Staples), Лауре Джон (Laura John), Хиллел Куперман (Hillel Cooperman), Стасии Скотт (Stacia Scott), Гвэйн Стоддарт (Gwynne Stoddart), Терри Бронсону (Terri Bronson), Барбаре Уилсон (Barbara Wilson), Террел Леффертс (Terrel Lefferts), Майку Глассу (Mike Glass), Хроматик (Chromatic) и Ричарду Грудману (Richard Grudman). Я особенно благодарен Кену Дай (Ken Dye), моему первому менеджеру в компании Microsoft, и Джо Бельфиору (Joe Belfiore); они предоставили мне перерыв в руководстве программами и сформировали мои представления о том, чем должны заниматься хорошие менеджеры и руководители.
Дополнительная персональная благодарность моей жене, Джилл Штуцман (Jill Stutzman), известной также как «медвежонок»; Ричарду Грудману (Richard Grudman); команде 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, Rollins Band, Sonny Rollins, Charles Mingus, Theloneous Monk, Breeders: Last Splash, AudioSlave, MC5, Chris McGee’s greatest mixes, Jack Johnson, Patty Griffin, Akiva, Flogging Molly, Sinatra, Beatles, Bruce Springsteen, PJ Harvey, Radiohead, Ramones, Weezer, Tom Waits, All Girl Summer Fun Band, Best of Belly, Magnetic Fields, Beth Orton, Elliot Smith, and Nick Cave и the Bad Seeds.
При написании книги не пострадал ни один из руководителей проектов. Но, к сожалению, в самом конце работы ушел из жизни наш пес по кличке Буч, пусть он упокоится с миром, 1991–2004. Он согревал своим теплом мои ноги в ту пору, когда рождались многие идеи и страницы этой книги. Хороший пес, Буч, нам тебя будет не хватать.
Введение
С первым изданием этой книги произошло нечто невероятное. Книга разошлась в огромном количестве экземпляров. Она попала в несколько списков бестселлеров, была номинирована на различные премии и привлекла достаточно внимания для того, чтобы ее автор пустился по всему свету распространять изложенные в ней идеи. Потом случилось нечто еще более безумное: потребовалось изменить ее название.
Мы со специалистами издательства O’Reilly пришли к единому мнению, что раз представилась такая возможность, книге нужно придать большую ценность, дав ей вторую жизнь под новым именем. Книга, которая называлась в первом издании «The Art of Project Management», была исправлена, улучшена, обновлена и дополнена, чтобы вы могли читать ее с еще большим удовольствием. Теперь она называется «Making Things Happen». Если вы удивлены сменой названия, то вот некоторые из причин:
1. Министерство внутренней безопасности (The Department 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 м. Казалось бы, чего уж проще-то? Тот факт, что это нелегко, не опровергает простоты процесса. Возглавлять и управлять тоже нелегко, но природа этих процессов – направлять все в нужное русло на достижение намеченной цели – по своей сути проста.
Ссылки на эти понятия будут встречаться во многих главах. Поэтому, если я буду использовать ссылки, выходящие за стереотипные границы вопросов разработки программного обеспечения, то надеюсь, вы поймете почему. И когда я буду подводить вас к мысли, что принятие решений и составление календарных планов – это простые функции управления, мой расчет будет строиться на том, что вы никоим образом не посчитаете эти функции легкими в осуществлении.
Нужно учиться на ошибках
«Люди, уникальность которых [среди животных] заключается в способности учиться на чужом опыте, также отличаются отсутствием склонности к подобному обучению».
Дуглас Адамс (Douglas Adams)
При изучении истории разработки проектов возникает один простой вопрос: почему кто бы то ни было охотно страдает от ошибок и разочарований, которых можно было бы избежать? Если перед нами открыта как древняя, так и современная история работы над проектами и нам платят за то, чтобы мы совершали разумные поступки, независимо от того, откуда мы черпаем вдохновение, почему поощрения за извлечение уроков истории столь редко проявляются со стороны организаций? Хотя проекты завершаются или закрываются (а ведь многие проекты по разработке именно так и заканчиваются[2]) ежедневно, практически ничего не делается для изучения причин произошедшего. Создается впечатление, что менеджеры большинства организаций крайне редко поощряют людей за поиски сведений в этом направлении. Возможно, в этом проявляется страх перед тем, что будет найдено (и страх перед ответственностью за это). А может быть это просто отсутствие интереса с чьей-либо стороны к анализу неприятных или печальных событий, в то время как время вместо этого может быть потрачено на продвижение к следующему, новому изделию.
В книге Генри Петроски (Henry Petroski) «To Engineer Is Human: The Role of Failure in Successful Design» (Vintage Books, 1992) автор описывает множество прорывов в разработках, происходивших благодаря провалам. В частности, такое случается из-за того, что провалы заставляют нас пристальнее к чему-нибудь приглядываться. Они требуют от нас пересмотра подзабытых предположений (трудно притворяться, что все в порядке, когда прототип горит ярким пламенем). Как говорил Карл Поппер (Karl Popper[3]), есть только два вида теорий: неправильные и несовершенные. Без провалов мы самонадеянно забываем, что наше понимание вещей не настолько совершенно, насколько мы думаем.
Вся хитрость в том, что следует как можно больше учиться на ошибках других. Мы должны использовать их горький опыт, чтобы воспользоваться им в будущем. Хотя внешние детали неудач могут иметь от проекта к проекту существенные отличия, основные причины или действия команды, приведшие к ним, могут быть полностью перенесены (и обойдены). Даже в наших собственных проектах мы должны избегать привычки устраняться и прятаться от неудач. Вместо этого их нужно рассматривать как возможность чему-нибудь научиться. Какие факторы содействовали их возникновению? Какие из этих факторов могут быть легко минимизированы или устранены? Согласно высказываниям Петроски, самым мощным источником прогресса, которым мы располагаем, являются истинные знания, полученные из настоящих провалов, если, конечно у нас есть мужество тщательно исследовать случившееся.
Возможно, именно поэтому компания «Боинг», одна из крупнейших фирм по разработке и производству авиационной техники, ведет черную книгу уроков, извлеченных из конструкторских и инженерных просчетов.[4] Боинг ведет эту документацию со дня основания компании и использует ее для помощи современным конструкторам в извлечении уроков из прошлого. Любая организация, организовавшая подобную практику, не только повысит свои шансы на осуществление успешных проектов, но также поможет создать среду, в которой можно будет открыто обсуждать промахи и противостоять им, вместо того чтобы не признавать их существования и прятаться от них. Пожалуй, разработчикам программного обеспечения неплохо было бы завести свою собственную черную книгу.
Веб-разработка, кухни и пункты первой помощи
Проблема исторических примеров в том, что они не всегда соотносятся с современностью. Порой нелегко воспользоваться уроками спустя десятилетия и доказать сопоставимость каких-то вещей, которые кажутся столь непохожими на то, как это делается сегодня. В качестве альтернативы можно проводить сравнения с интересными разновидностями современных проектов. Хотя такие проекты не обладают солидностью, подкрепленной предысторией подобных разработок, зато они дают доступ к опыту и наблюдению из первых рук. Зачастую именно такое, непосредственное наблюдение является единственным способом получения достаточной информации для наведения мостов между разнообразными идеями.
К примеру, я знаю одного веб-разработчика, который искренне верит в то, что его работа не похожа ни на какую другую за всю мировую историю. Он считает, что его проект и управление задачами непохожи ни на что из ранее существовавшего, поскольку в процессе веб-разработки он должен принимать сложные инженерные решения, связанные с проектированием и согласованием, а также проверкой изменений буквально в течение нескольких часов или даже минут, а потом публиковать результаты своей работы во Всемирной сети. Он с гордостью перечисляет технологии, которыми овладел, – 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 Imperfect Science» (Picador USA, 2003) написал следующее:
Мы рассматриваем медицину как хорошо организованную область применения знаний и навыков. Но это не так. Эта область науки далека от совершенства, в ней постоянно меняются представления, используется неточная информация, допускаются ошибки персонала, и все это на грани жизни и смерти. Можно ли назвать наукой все, что мы делаем? Да, конечно, но это еще и навыки, интуиция, а иногда и просто догадки на основе имеющегося опыта. Промежуток между тем, что мы знаем и к чему стремимся, сохраняется. И этот промежуток значительно усложняет нашу работу.
Это высказывание, как и многие другие в весьма поучительной книге Гаванде, справедливо и в отношении разработки программного обеспечения. Фред Брукс (Fred Brooks) в классической книге «The Mythical Man-Month» (Мифический человеко-месяц), касающейся разработки программ, проводит схожие параллели между командами хирургов и программистов. Несмотря на то что при разработке веб-сайтов или баз данных жизни мало что угрожает, люди из разных команд могут столкнуться с многими схожими ситуациями и сложностями.
Роль управления проектами
Руководство проектами может быть профессией, работой, ролью или обыкновенным действием. В некоторых компаниях есть руководители проектов, чья работа заключается в наблюдении за всеми проектами, в разработке которых участвует двести человек. В других компаниях эта должность относится к категории рядовых младших менеджеров, чья зона ответственности – небольшой участок крупного проекта. В зависимости от структуры организации, сложившейся корпоративной культуры и целей проекта, управление проектами может быть как неформальной ролью («когда понадобится, то этим кто-нибудь займется»), так и четко выраженной («Винсент, Клод и Рафаэль – полноценные руководители проектов»).
В этой книге я буду называть руководителями проектов в первую очередь тех, кто возглавляет проекты и занимается управленческой деятельности. Под деятельностью по управлению проектами я буду подразумевать работу по управлению командой при уточнении деталей проекта (общее планирование, составление календарного плана, выработка требований), проведении проекта через этапы проектирования и разработки (ведение переговоров, принятие решений, выработка стратегии миттельшпиля), доведении проекта до завершения (лидерство, разрешение критических ситуаций и проведение стратегии эндшпиля).
Если в вашей организации структуризация этой разновидности работы носит менее формальный характер, то считайте, что руководитель проекта – это «человек, выполняющий задачи руководства проектом, хотя это для него не является основной работой», или «человек, думающий о проекте в целом». Мне встречалось множество различных способов распределения этой работы в командах, и мои советы в этой книге в большинстве своем подойдут при любом варианте такого распределения. В книге не придается особого значения наименованиям должностей и прочим формальностям, в ней больше говорится о том, как воплощать задуманное. Но чтобы не усложнять повествование, я буду использовать словосочетание руководитель проектов.
Иногда все прекрасно обходятся и без специально назначенного руководителя проекта. Программисты и их начальники составляют графики и технические планы (если таковые предусмотрены), а бизнес-аналитик или специалист по рынку проводит работы по планированию или составлению технических требований. Все остальные обязанности, которые можно определить как руководство проектом, просто распределяются по специалистам команды. Возможно, люди в команду нанимались с прицелом не только на создание программного кода. И они не стали бы сторониться начального планирования, разработки пользовательского интерфейса или выработки бизнес-стратегии. За счет этого можно добиться существенной оптимизации работы. При условии, что все готовы разделить ответственность за общее дело и разделить обязанности, которые выполнял бы в команде руководитель проекта, то команде понадобится на одного человека меньше. Что может быть лучше простоты и эффективности.
Но бывает и так, что в отсутствие руководителя проекта работа разваливается. Без человека, чья основная работа заключается в сплочении усилий всей команды, индивидуальные предвзятости и интересы могут сбить команду с нужного направления. Вокруг инженерных и деловых ролей могут сложиться соперничающие группировки, тормозящие прогресс и расстраивающие работу всех участников. Следует учесть, что в пункте экстренной медицинской помощи решение о курсе лечения пациента берет на себя один врач. Это определяет многие последующие решения и действия каждого специалиста команды травматологов. Без такого рода четких полномочий по решению проблем управления проектами команды разработчиков могут столкнуться с неприятностями. Если нет ответственного за установку очередности оказания помощи или нет человека, назначенного для отслеживания выполнения календарного плана и выявления проблем, то эти задачи могут занять опасную позицию за индивидуальными действиями по созданию программного кода.
Хотя я считаю, что многие профессиональные программисты неплохо разбираются в управлении проектами, чтобы самостоятельно справиться с задачами руководителя, тем не менее они понимают особую ценность человека, специально выделенного для выполнения этой роли.
Управление программами и проектами в Microsoft
В конце 80-х годов компания Microsoft решала непростую проблему увязывания инженерных работ с маркетинговыми и бизнес-задачами каждого подразделения (кто-то может сказать, что Microsoft и многие другие компании до сих пор не могут решить эту проблему). Некий мудрец по имени Джейб Блюменталь (Jabe Blumenthal) додумался до того, что должна быть специальная должность, и ее исполнитель будет занят выполнением этих двух функций, одновременно играя роль лидера и координатора. Он должен был работать над проектом с первого дня планирования и до последнего дня тестирования. На такую должность следовало бы взять того, кто достаточно хорошо разбирается в программировании, чтобы снискать уважение программистов, но это также должен быть человек, не обделенный талантами и имеющий заинтересованность в более широком участии в создании конечного продукта.
Чтобы работать в этой роли, этот сотрудник должен иметь склонность к такой разносторонней деятельности, как составление технических условий, обсуждение маркетинговых планов, составление календарных планов, управление командами, осуществление стратегического планирования, выполнение классификации ошибок и дефектов, поддержание командного духа, а также выполнение ряда других необходимых функций, которыми кроме него больше некому как следует заняться. Эта новая роль в компании Microsoft получила название руководителя проектов. В его непосредственное подчинение попадали не все специалисты команды, но руководителю проектов давались существенные полномочия по руководству и управлению проектом. (В теории управления это примерно соответствует идее матричной организации управления,[5] при которой существуют две линии структуры подчиненности специалистов: одна основана на функциях специалиста, а другая – на конкретном проекте. Таким образом, программист или тестировщик может иметь двойную подчиненность: основную, в соответствии со своей функциональной ролью, и второстепенную, но не менее серьезную, в соответствии с проектом, над котором он работает.)
Джейб сыграл эту роль в разработке продукта под названием Multiplan (который впоследствии перерос в Microsoft Excel), и опыт оказался удачным. В результате улучшились процессы проектирования и разработки, а заодно улучшилась и координация усилий с бизнес-командой, и настроение в коридорах Microsoft существенно повысилось. Постепенно, после множества совещаний и собраний большинство команд компании приняли эту роль. Чтобы вы ни говорили плохого или хорошего о появившихся в результате этого программных продуктах, но идея все-таки была стоящей. Определив роль для рядового универсала, причем не в качестве какого-то мальчика на побегушках или лакея, а в качестве лидера и ведущего команды, компания Microsoft навсегда изменила динамику работы команд разработчиков. Именно в этой роли руководителя проектов я выступал большую часть периода своей работы в этой компании, работая с командами, создававшими помимо всего прочего, Internet Explorer, MSN и Windows. Со временем я даже стал руководить командами руководителей проектов.
На сегодняшний день я не слышал, чтобы многие компании преуспели в переопределении и ввели какие-то особые формы управления проектами. Я много общался с представителями разных фирм, занимающихся веб-разработкой и разработкой программного обеспечения, но всего лишь несколько раз слышал о наличии у них похожей должности (обычно речь шла о сотрудниках, которые решали инженерные или деловые вопросы или, в редких случаях, – вопросы проектирования). Многие компании в организации работ использовали командную структуру, но лишь немногие определяли роли, в которых заведомо пересекались инженерная и деловая соподчиненности. Сейчас в Microsoft работают более 5000 руководителей программ (всего в этой компании более 80 000 человек), и хотя сам смысл идеи был несколько размыт и искажен, ее основное содержание можно найти во многих командах компании.
Независимо от того, что написано в моей визитке или каким сведениям от Microsoft вы верите, а каким нет, мои ежедневные функции сводились к функциям руководителя проектов. Проще говоря, это означало, что именно я нес по мере сил ответственность за успешную реализацию проекта и за всех его участников. Во всех главах данной книги описываются основные задачи, связанные с этой деятельностью, от исходного планирования (главы 3 и 4) до составления технических условий (глава 7) и процесса принятия решений (глава 8) и заканчивая руководством разработкой продукта и его выпуском (главы 14 и 15).
В качестве основы этих навыков выступают соответствующие отношения и индивидуальные черты характера. Не осознав этого, любой человек, возглавляющий проект или руководящий этим проектом, попадет в весьма неблагоприятное состояние.
Взвешенность при руководстве проектами
Подобрать хороших руководителей проектов довольно трудно, поскольку они должны уметь придерживаться взвешенных подходов. Том Питерс (Tom Peters) в своей статье «Pursuing the Perfect Project Manager»[6] называет конфликтующие подходы парадоксами, или дилеммами. Вполне подходящее название, поскольку разные ситуации требуют разного поведения. Значит, руководитель проектов должен не только осознавать эту особенность своей работы, но и выработать инстинкт на поведение, соответствующее конкретно складывающейся обстановке. Это наводит на мысль, что руководство проектами является искусством, требующим проявления интуиции, рассудительности и опыта эффективного использования этих качеств. Следующий список дилемм составлен по материалам статьи Питерса.
Проявление эгоизма – Альтруизм. Благодаря той степени ответственности, которая возложена на руководителей проектов, они часто получают огромное личное удовлетворение от своей работы. Понятно, что они вкладывают в свое дело всю душу, и для многих из них именно эта эмоциональная связь позволяет поддерживать напряжение, необходимое для эффективной работы. В то же время руководителям проектов не следует ставить собственные интересы выше интересов проекта. Они должны быть готовы передать решение важных и увлекательных задач и разделить лавры со всей командой. Эгоизм, конечно, может служить подпиткой, но хороший руководитель проектов должен понять, когда он мешает работе.
Навязывание своей воли – Доверительные отношения. Иногда самым важным является четкое проявление власти и быстрая реакция. Руководитель проектов должен быть достаточно самоуверен и упрям, чтобы контролировать ситуацию и заставить команду совершать определенные действия. Тем не менее основная его задача состоит в том, чтобы избегать экстремальных ситуаций. При хорошо управляемом проекте должна быть создана среда, в которой можно было бы доверить работу и рассчитывать на эффективное сотрудничество.
Терпимость к неопределенности – Стремление к завершенности. Начальная стадия проекта характеризуется высокой открытостью и изменчивостью, где неизвестное в значительной степени перевешивает известное. В главах 5 и 6 будет показано, что управляемая неопределенность является основой для появления хороших идей, и руководитель проекта должен с ней считаться, если она не поддается управлению. Но в другие периоды, особенно на поздних этапах проекта, на первый план выходят дисциплинированность и точность. Нужно проявить определенную мудрость, чтобы понять, когда следует стремиться к завершенности, а когда вполне устроит приблизительное, принятое на скорую руку решение (см. раздел «Поиск и оценка вариантов» в главе 8).
Устное – Письменное общение. Несмотря на ту центральную роль, которую приобрела электронная почта в деятельности большинства организаций, занимающихся разработкой программного обеспечения, для руководства проектами особую важность приобретает искусство устного общения. Без совещаний, переговоров, кулуарных обсуждений и мозговых атак обойтись невозможно, и руководитель проекта должен быть на высоте как в восприятии, так и в пропаганде идей в процессе устного общения. Чем больше организация или масштабнее проект, тем большую важность приобретает искусство письменного общения. Независимо от своих личных предпочтений, руководитель проекта должен понимать, когда эффективнее будет устное, а когда – письменное общение.
Стремление к сложности – Борьба за простоту. Многие люди пали жертвами сложности. Когда они сталкиваются со сложными организационными или инженерными задачами, они тонут в мелких деталях и забывают об общем представлении. Есть и такие люди, которые не признают сложности и принимают плохие решения, поскольку полностью не осознают всех тонкостей происходящего. Взвешенность в данном случае заключается в определении, какое представление проекта наиболее полезно для понимания текущей проблемы или принятия решения, и в умении свободно переключаться между разными представлениями или одновременно держать их в голове (не боясь, что она взорвется). Руководители проектов должны стимулировать команду на борьбу за простоту в их работе, без лишних упрощений там, где нужен хороший, надежный код.
Беспокойство – Терпеливость. Большую часть времени руководитель проектов должен проявлять требовательность, заставляя подчиненных работать рационально и сосредоточенно. Но иногда беспокойство вредит проекту. Некоторые политические, межведомственные или бюрократические действия неизбежно влекут за собой потери времени – люди должны присутствовать в аудитории или привлекаться к селекторному совещанию, и они должны проявлять терпение. Поэтому относитесь к этому по возможности спокойно и философски. Руководители проектов должны развивать в себе чутье, подсказывающее, когда следует надавить, а когда лучше пустить некоторые процессы на самотек.
Храбрость – Осторожность. Одним из самых больших заблуждений, присущих почти всем культурам, состоит в том, что храбрым людям якобы не присуще чувство страха. На самом деле это не так. Храбрые люди чувствуют страх и все-таки принимают решение действовать. Руководитель проектов должен иметь здравое отношение ко всему, что идет не должным образом, и признавать возможность такого развития событий. Но он также должен соответствовать такому отношению и обладать мужеством, необходимым для преодоления больших трудностей.
Уверенность – Скептицизм. Нет ничего более вдохновляющего команду, чем уважаемый всеми лидер, уверенный в том, что он делает. Для руководителя проектов важно быть уверенным в своей работе и понимать истинную ценность тех целей, которые должны быть достигнуты. В то же время не лишним будет и здравый скептицизм (но не цинизм) относительно состояния дел и способов их ведения. Кто-то должен выражать сомнения и задавать вопросы, высказывать предположения и высвечивать сложности. В противовес этому нужно решительно задавать встречные вопросы и оспаривать чьи-то предположения, не разрушая веру команды в то, чем она занята.
Как отмечает Питерс в своей статье, найти людей, способных проявить все виды этих подходов, удается крайне редко, но еще реже попадаются люди, способные сохранять их тонкий баланс. Многие ошибки, допускаемые любым руководителем проектов, связаны с просчетами в сбалансированном применении одной или нескольких из этих пар противоположных действий. Тем не менее каждый может добиться успехов в улучшении своих собственных возможностей в сбалансированном проявлении этих действий. Поэтому, хотя я и не собираюсь снова особо фокусировать ваше внимание на этом списке дилемм (хотя пару раз он еще будет упомянут), на него все же стоило сослаться. Внимательное изучение этого списка противоположных, но необходимых действий поможет, немного отступив назад, пересмотреть свои действия и вызвавшие их причины и принять более благоразумные решения.
Давление и распри
Новички в руководстве проектами боятся того, что для успеха требуется внесение изменений. Новые проекты создаются с целью изменить мир путем модификаций, какой-либо созидательной или разрушительной деятельности. Поддержание status quo, если только это не является по какой-нибудь странной причине явной целью, не является успешным результатом. Мир постоянно изменяется, поэтому если веб-сайт или другой проект сегодня уже не так хорош, каким был год назад, значит, он отстал от жизни из-за неправильно сформулированных задач или просчетов при разработке.
Трудно проигнорировать скрытое давление на руководителей проектов, подразумеваемое при таких обстоятельствах, поскольку оно исходит из их сферы деятельности. Не стоит топтаться на месте, нужно улучшать продукт. Всегда найдется новый способ мышления, новая тема для изучения и практического применения, новый процесс, с которым работа пойдет веселее или эффективнее. Возможно, это больше относится к руководству, чем к управлению, но разница между этими двумя понятиями едва уловима. Как бы вы ни старались их разделить, хорошее управление требует применения навыков руководства, а хорошее руководство – навыков управления. Любой человек, имеющий отношение к управлению проектом, в той или иной степени будет отвечать за обе эти составляющие, независимо от того, как это соответствует его обязанностям согласно штатному расписанию.
Но возвращаясь к вопросу о давлении, я хочу сказать, что повидал на своем веку немало управленцев, самоустраняющихся от решения вопросов руководства (например, в те моменты, когда команда или проект нуждается в ком-то, кто должен принять решение) и занимающих позицию стороннего наблюдателя, вместо того чтобы оказать помощь или принять непосредственное участие в принятии решений. Если чье-либо занятие заключается лишь в констатации фактов и в наблюдении за всем со стороны, то его место, скорее всего, в бухгалтерии. Когда номинальный руководитель неоднократно в ответ на оказываемое на него давление избегает брать «быка за рога», он не руководит, а прячется от руководства. Не выдерживающие стороннего давления руководители проектов стараются раствориться на его задворках, где от них есть хоть какой-нибудь толк.
Путаница в понятиях процесса и целей
Некоторые руководители проектов прибегают к количественной оценке того, что в оценке не нуждается. Испытывая сомнения насчет своих дальнейших действий или опасаясь решения самых насущных вопросов, они тратят время на какие-нибудь второстепенные занятия. И по мере роста пропасти между руководителем и проектом, все больше внимания уделяется составлению ненужных диаграмм, таблиц, табелей и отчетов. Вполне возможно, что в какой-то момент времени руководитель проекта начинает верить в то, что эти данные и процесс их обработки – это и есть проект. Его внимание концентрируется на менее значимых вещах, с которыми проще работать (на электронных таблицах или отчетах), а не на чем-то более важном, с чем приходится сталкиваться в процессе работы (связанном с программированием или с календарным планом работ). Может выработаться убеждение, что достаточно лишь следовать определенным процедурам улучшения работы и правильно проставлять табельные данные, чтобы успех проекту был обеспечен (или, если быть более циничным, чтобы любой просчет, который может произойти, не мог быть технически отнесен на счет такого руководителя).
Чтобы свести к минимуму возможность подобного конфуза, хорошие руководители проектов остерегаются строго определять границы той работы, которой им хочется заниматься, и той, которой не хочется. Они избегают проведения яркой желтой черты между целями руководства проектом и целями самого проекта. Склонность к работе с табелями предполагает наличие вполне определенного процесса с гарантированным конкретным результатом, что абсолютно нереально. В реальности существуют лишь три вещи: цель, объем работ и группа людей. Помочь таким людям в организации работ сможет четкое распределение ролей (см. главу 9), но само по себе распределение ролей не является целью. Ведение табеля может содействовать организации работ по достижению поставленной цели, но само по себе и оно целью не является. Наибольшим просчетом в управлении считается подмена понятий процесса и целей. Мне ли этого не знать, я сам был грешен.
Несколько лет назад, трудясь над проектом Internet Explorer 4.0, я руководил разработкой нескольких сложных компонентов пользовательского интерфейса, и поскольку в ту пору это был мой самый высокий пост, я ощущал весьма значительное давление обстоятельств. В ответ у меня выработалось убеждение, что умение заполнять контрольные документы защитит меня от провала. Контроль хода работ над проектом действительно нужен, но тут я зашел слишком далеко. Для многостороннего представления данных я построил сложную электронную таблицу, а в моем офисе висела огромная классная доска, пестревшая таблицами и сводками (и я собирался повесить еще несколько таких досок).
Мой босс не препятствовал этому увлечению, поскольку дела шли неплохо, но только до тех пор, пока не заметил, что я трачу больше времени на заполнение контрольных документов, чем на работу с командой, после чего выбросил большой красный флаг (в качестве предупреждения). Однажды он пришел ко мне в офис и стал свидетелем комедии с заполнением многочисленных контрольных документов и таблиц, усеивающих все плоские поверхности моего кабинета, после чего он усадил меня на стул, закрыл входную дверь и сказал: «Скотт, все это, конечно, хорошо, но твой проект – это твоя команда. Ты должен управлять командой, а не перекладывать бумажки. Хорошо, если они помогают тебе справиться с командой. Но если ты и дальше будешь продолжать в том же духе, то скоро, чтобы справиться с бумажками, ты обратишься за помощью к команде».
Итак, вместо того чтобы замыкаться на процессах и методиках, руководители проекта должны концентрировать свое внимание на своих командах. Безусловно, в их работе можно использовать простые системы планирования или управления, но они должны соответствовать сложности проекта и рабочей культуре команды. Если точнее, то планирование и контроль должны содействовать команде в достижении целей проекта, а не препятствовать этому. Я уверен, что пока руководитель проекта обращает на это внимание и пользуется доверием команды, недостаток любых процессов, отчетов, контрольных документов или других необходимых руководству проектом механизмов почувствуется еще до того, как проблемы, которые могут быть решены с их помощью, приобретут серьезные очертания.
В главе 10 мы узнаем, что книжные предписания или указания руководителя на создание какого-то продукта или сам факт, что предписываемая методика использовалась в прошлом месяце или году, не являются основанием для того, что все это применялось и сегодня. Все команды и проекты отличаются друг от друга, поэтому существуют весьма веские основания, чтобы подвергнуть сомнениям все прежние положения. Причина консерватизма в применяемых методах и процессах кроется в том, что излишества в данном вопросе могут превратиться в снежную лавину, увлекающую за собой команду в вязкую западню сложных проектов, как об этом говорится в книге Фрэда Брукса (Fred Brooks) «The Mythical Man-Month». Когда от процессов требуется управление процессами, трудно понять, где осуществляется реальная работа. Именно руководителю команды или проекта чаще всего предоставляется великолепная возможность управлять командой без бюрократических излишеств или наоборот послать ее на полной скорости в нескончаемый водоворот различных процедур и заседаний.
Нужная степень вовлеченности
Все руководители, от верхушки пятисот наиболее крупный компаний и до тренеров спортивных команд, склонны себя перегружать, вникая во все, что только можно. Они знают, что достигли своего потенциального «потолка» и чрезмерная вовлеченность во все события – это один из удобных (хотя и порочных) способов попытаться компенсировать это обстоятельство. Этим частично объясняется бесконечная мелочная опека, поскольку самым легким приемом для слабого руководителя является властное давление на подчиненных (сопровождаемое в критических ситуациях обвинениями подчиненных в некомпетентности, что, якобы, и потребовало столь пристального к ним внимания). Неуверенные руководители противятся тому факту, что, выражаясь терминами индустриальной революции, они не включены в технологическую линию. Они ничего не производят собственноручно, поэтому их деятельность не следует приравнивать к работе непосредственных производителей продукции.
Руководителей не нанимают для того, чтобы они проделывали простую работу, ожидаемую от рабочего или программиста. Вместо этого руководители и управляющие нанимаются для повышения отдачи от всех, кто их окружает. Методы их деятельности отличаются от работы на производственном конвейере. Но поскольку многие руководители – это бывшие программисты, выдвинутые на руководящую должность из производственной сферы, шансы на то, что они лучше справляются с созданием программного кода, чем с руководством и управлением людьми, которые этот код пишут, остаются довольно-таки высокими.
Как и в истории с тренером бейсбольной команды, предполагается, что присутствие руководителя вносит в окружающую среду нечто иное, чем личный вклад другого специалиста. Порой это достигается путем улаживания спорных ситуаций или ограждения команды от политических проблем. В иные моменты это выражается в предоставлении хорошо проработанных высокоуровневых планов или в выискивании мудрых путей обхода неожиданных препятствий. Поскольку такой вид вклада труднее с чем-то соизмерить, многие руководители проектов сражаются с неопределенностью, которая возникает вокруг их роли в общем процессе. Руководителям проще попасть под огонь критики и труднее от него укрыться. Преуспеть и почувствовать удовлетворение от своей работы руководителю команды поможет сочетание убежденности, уверенности в себе и осознание правоты своих действий.
Преимущество собственного взгляда на происходящее
Лучшим способом поиска точки опоры является использование психологических отличий, вытекающих из отстраненности от производства. Руководитель проекта в силу своих служебных обязанностей, как и следовало ожидать, больше всех остальных уделяет времени на общение с различными людьми в команде, поэтому он приобретает обширный круг информационных источников и более широкий взгляд на проект. Он способен понять взгляд на проект и бизнесмена и разработчика и при необходимости помочь команде разобраться в этих взглядах. Такой расширенный кругозор позволяет передавать особо важные сведения нужным людям и в нужное время. Но такие полномочия способны привести и к более масштабным последствиям, чем те, которые следуют из простого рассказа, помогающего дать всестороннюю иллюстрацию этому положению.
Я взял в привычку прохаживаться по коридору и заглядывать к программистам, держащим свои двери открытыми. Обычно все сводилось к краткому разговору, в процессе которого я старался их чем-нибудь рассмешить, а заодно и поинтересоваться, над чем они работают. С их согласия я просматривал демонстрационные образцы. Нанося подобные кратковременные визиты с периодичностью в несколько дней, я часто получал неплохое представление о реальном состоянии проекта (в главе 9 мы рассмотрим подобную практику «прогулочного» управления проектом).
К примеру, как-то утром, работая над проектом IE 5.0, я заглянул в офис Фрэда. Он спорил со Стивом, другим программистом, о том, как они собираются заставить заработать элемент управления для просмотра списка, после того как утром внезапно обнаружились проблемы его совместимости с другими компонентами. Никто из них не хотел с этим связываться. И, исходя из всего мною услышанного, на исправление элемента должно было уйти не менее половины рабочего дня. Я подключился к разговору и подтвердил все то, о чем они говорили. Они кивнули головами, словно спрашивая: «Зачем вам это нужно?» Я сказал, что им нужно пройти вниз и поговорить с Биллом. Они опять спросили, зачем, думая, что дело касается весьма тонких вопросов архитектуры проекта, в которых я не слишком-то разбираюсь. Я улыбнулся и сказал: «Дело в том, что я только что от него, и у него на машине есть уже новый великолепно работающий элемент управления. Минувшей ночью ему удалось решить проблему и все исправить попутно с выполнением других дел».
Разумеется, здесь речь не о том, что я избавил или уберег человечество от глобальной катастрофы. Если бы я их не направил в нужное место, было бы потеряно впустую несколько часов или половина рабочего дня (хотя, как показано в главе 8, рабочие графики всегда имеют некоторые отклонения от запланированных сроков). Но дело не в этом. Хорошие руководители проектов считают своей обязанностью быть в курсе всех полезных дел команды, как, впрочем, и всего полезного в окружающем мире, а затем применять эти знания, помогая людям справиться с их делами. Все эти, казалось бы, незначительные порции своевременно преподнесенной информации, наподобие той, о которой шла речь в моем рассказе, и делают из середнячков хорошие команды, а из хороших команд – великие. Никакая система отслеживания хода ведения проекта или обнаружения ошибок не сможет целиком заменить собой потребность людей в обсуждении друг с другом текущих событий, поскольку социальные сети всегда мощнее (а иногда и быстрее), чем сети технологические. Сложные задачи, наподобие концепции проекта, перечней функциональных условий и календарного плана, всегда сводятся к массе мелких задач, на которых благотворно сказывается простота обмена ценными знаниями и сведениями внутри команды. И главная роль в обеспечении активности и осмысленности этого обмена принадлежит руководителям проектов.
Независимо от их масштабности, все предпринимаемые руководителем проекта действия и принимаемые решения должны приносить несомненную пользу всей команде. Она может проявиться спустя неделю или месяц, но хороший руководитель проекта окажет положительное влияние на качество работ, а зачастую и на качество жизни каждого участника проекта. Люди станут по-другому чувствовать свои задачи, открыто говорить, что они стали лучше понимать, чем они заняты и почему, и будут лучше относиться к тому, что им предстоит сделать, нежели к уже проделанной работе. Изменения такого рода происходят на вполне определенном совещании, при приятии решения или проведении дискуссии, но в течение проекта эта атмосфера и предпринимаемые усилия должны существенным образом менять свое направление и совершенствоваться.
Руководители проектов создают уникальные ценности
В результате хорошие управленцы и руководители часто заслуживают особого уважения у тех программистов, тестировщиков, проектировщиков, специалистов по маркетингу и составителей документации, которые вступают с ними в контакт. Руководитель проекта должен демонстрировать мастерство мышления, стратегии и руководства, оказывающее такое положительное влияние на команду, которое доступно немногим. Зачастую это подразумевает поиск наикратчайших путей и продуманной оптимизации ежедневного технологического процесса или подбадривание и поддержку в нужном направлении и в нужное время. Для этого не обязательно быть каким-то суперменом или особо одаренной личностью (каковой я вне всяких сомнений являюсь). Нужно понимать все преимущество собственного взгляда на окружающую обстановку и иметь желание им воспользоваться.
Есть один совершенно неопровержимый факт: руководители проектов или лидеры проводят с каждым специалистом своей команды больше времени, чем кто-либо другой. Никто так часто, как они, не присутствует на совещаниях, не обходит так много офисов и не разговаривает с таким количеством разных людей, вносящих свой личный вклад в проект. Они могут принять или повлиять на принятие большего количества решений, чем какой-либо другой представитель данной организации. Если руководитель проекта чем-то доволен, опечален, увлечен или подавлен, часть его настроения имеет свойство отражаться на каждом, с кем он ежедневно сталкивается. Все, что руководитель привносит в проект, будь то хорошее или плохое, становится заразительным для всей остальной команды.
Поэтому если руководитель проекта на что-то нацелен, чему-то предан, чем-то взволнован и способен в чем-то преуспеть, то шансы на то, что и все другие последуют его примеру, значительно возрастают. Руководители любой направленности имеют приблизительно равный начальный потенциал власти и незначительное число способов приобретения значимости в большинстве производственных условий. Это означает, что если вообще есть возможность способствовать рассмотренным мною до сих пор отношениям и идеям, то все карты находятся на руках у лидеров и руководителей. Это не значит, что руководитель проекта должен быть этакой притягательной героической фигурой, которая способна вести в бой армию программистов лишь слегка пожимая плечами (см. раздел «Комплекс героя» в главе 11). Скорее всего, ему нужна искренняя заинтересованность в оказании помощи своим коллегам по команде и по большей части преуспевать в этом деле.
В конечном счете, основная идея, в которую я уверовал, состоит в том, что пока вы никому не причиняете боли (кроме возможных конкурентов) и ведете людей в правильном направлении, ничто, кроме того, что вы делаете благое дело, не имеет значения. Пока результат положителен, неважно, сколько идей исходит от вас, а сколько – от кого-то другого. Руководство проектом оправдывает любые средства, необходимые для повышения вероятности и сокращения сроков наступления благополучного исхода. Я использовал одну полезную ежедневную молитву, которая звучала примерно так: «Дай случиться чему-нибудь хорошему». Увидев меня в коридоре или за работой с каким-нибудь программистом у классной доски, люди спрашивали: «Ну что, Скотт, чем ты занят?» А я улыбался и говорил: «Даю возможность случиться чему-нибудь хорошему». Это стало основной составляющей моего ежедневного подхода к каждому человеку, и когда я направлял работу других, эта установка распространялась через них на всю команду. Поскольку пора наконец переходить к конкретике, я выражаю надежду на то, что и вы прочувствуете эту установку и проникнитесь основной идеей этой начальной главы.
Выводы
Каждая глава этой книги завершается краткими выводами или ключевыми моментами, помогающими позже освежить в памяти ее содержимое.
• Управление проектами востребовано повсеместно и с незапамятных времен.
• Если сохранится непосредственность, присущая стилю мышления новичка, появится больше возможностей чему-нибудь научиться.
• Руководство проектами может быть работой, ролью или деятельностью (советы, приведенные в данной книге, пригодятся независимо от того, как вы это определите).
• Руководство программами – это вариант руководства проектами, применяемый исключительно в корпорации Microsoft. Оно берет начало в идее матричной организации управления.
• Руководство и управление требует понимания ситуации и интуитивного чутья наряду с несколькими другими всеобщими дилеммами, включая проявление эгоизма или альтруизма, навязывание своей воли или доверительные отношения, храбрость или осторожность.
• Остерегайтесь претенциозности и излишней вовлеченности во все дела в процессе своей управленческой деятельности. Процесс должен содействовать работе команды и никак иначе.
• Если вы штатный менеджер, найдите способы извлечения выгоды из вашего особого взгляда на команду и проект.
Упражнения
1. Выберите одного из своих лучших друзей, который работает или учится в какой-нибудь другой сфере. Как он управляет своими проектами? Существует ли у них должность руководителя проекта или эта работа распределена между разными людьми?
2. Если от хорошего руководителя требуется соблюдение баланса подходов, как может руководитель проекта убедиться в том, что он не зашел слишком далеко в одном направлении по сравнению с другим? Как может руководитель проекта заручиться помощью людей, с которыми работает, чтобы сохранить баланс подходов?
3. Придумайте повод и устройте вечеринку. (Вы выдержали чтение первой главы, чем не повод?) После преодоления похмельного синдрома и вызволения друзей из «кутузки», рассмотрите следующие вопросы: чем вечеринка отличается от проекта? Сравните трудности и награды за роль организатора вечеринки по сравнению с ролью руководителя реального проекта. В чем различия и сходства?
4. Подумайте о неудачном проекте, над которым вам приходилось работать. Какой урок и каким образом вы из этого вынесли? Составьте список допущенных ошибок и то, что можно сделать по-другому в следующий раз, чтобы предотвратить повторение случившегося. Процесс составления этого списка заставит вас призадуматься и получить более глубокое представление о всем, что произошло.
5. Способны ли вы к проявлению качеств лидера или есть ли на вашей памяти события, происходившие благодаря вашей управленческой деятельности? Если вы хотите расширить круг возможностей для проявления лидерских качеств, то что вы можете для этого сделать?
6. Представьте себе команду, в которой люди вознаграждаются исключительно за то, насколько хорошо они следуют процессам и правилам, а не за достижение конкретных целей. Что произошло бы с качеством работы? На что была бы похожа роль руководителя проекта? Что это говорит о потенциальных опасностях, которые могут быть созданы руководителем проекта?
7. Менеджеры среднего звена или те, кто руководит этими менеджерами, особенно склонны к излишнему участию во всех делах и в создании ненужных процессов, потому что они занимают среднее положение в структуре организации. Как рассудительный менеджер среднего звена мог бы избежать искушений к проявлению мелочной опеки и установлению слишком большого количества правил?
Часть 1. Планирование
Глава 2. Правда о календарных планах
Людям свойственно опаздывать. Они часто выбиваются из повседневного графика, пусть всего на несколько минут или пару раз в неделю. (Поскольку возражать люди научились ничуть не хуже, я пойму, если вы откажетесь принимать это утверждение на свой счет.) Студенты опаздывают на занятия, сотрудники – на рабочие совещания, а друзья приходят в бар на десять минут позже назначенного времени. Мы считаем, что понятие «вовремя» относится не к конкретному моменту, а к какому-то интервалу времени, который может быть для кого-то шире, чем для всех остальных. Характерный пример – старшие официанты. Они вас уверяют, что столик вот-вот будет готов, но при этом зачастую заставляют ждать значительно дольше объявленного.[7] Существует множество ситуаций, при которых приходится выбиваться из рабочего графика, сюда можно отнести долгие ожидания у телефонной трубки или очереди на прием к врачу. Такие ситуации заставляют скептически относиться к затее планирования рабочего времени, противоречащей нашему жизненному опыту.
Стоит ли при этом удивляться, что масса проектов не выдерживаются по срокам их реализации. Многие из нас подходят к их планированию с наихудшими представлениями о своевременности поставок или получений каких-либо компонентов. Мы склонны делать оценки на основе смутных предположений, предсказывая результаты работы, исходя из благоприятного стечения обстоятельств, и в то же время с учетом предыдущего опыта не очень-то доверяем тем графикам, которые просматриваем или сами создаем. Данная глава посвящена ответам на вопросы, почему мы так поступаем, как это влияет на календарные планы проектов и как все-таки избавиться от обозначенных проблем.
Но перед тем как искать способы составления совершенных календарных планов, мы должны понять, какие именно проблемы решаются с их помощью. Если они столь ненадежны, стоит ли вообще тратить время на их создание? Календарные планы служат нескольким различным целям, лишь некоторые из них непосредственно связаны с фактором времени.
Три цели составления календарных планов
Что бы вы ни планировали, субботнюю вечеринку или обновление корпоративного сайта, все планы подчинены достижению трех целей. Первая – это определение сроков выполнения. Календарный план предоставляет контракт, связывающий всех участников, подтверждающий вклад каждого специалиста в общее дело, который он намерен внести за определенный период времени. Обычно при обдумывании плана реализации проекта – это первое, что приходит в голову. Планы часто ориентированы не на внутренние, а на внешние по отношению к команде разработчиков факторы, поскольку нацелены на выполнение контракта в соответствии со сроками заказчика. Зачастую клиенты платят не только за сам заказ, но и отдельно за срочность его выполнения (представьте работу почтовых служб). Чтобы предоставить возможность клиентам или партнерам строить планы относительно конкретного проекта, надо согласовать временные параметры по этапам его реализации.
Вторая цель разработки календарного плана заключается в том, чтобы помочь каждому участнику проекта увидеть свою роль в общей работе и способствовать координации усилий отдельного участника и остальных членов проекта. Пока план носит предварительный характер и содержит лишь наметки сроков поэтапной реализации проекта, маловероятно, что в нем удастся учесть все связи и взаимозависимости. Без календарного плана каждый будет сконцентрирован на выполнении своих собственных задач и не будет думать о том, как его работа повлияет на работу других.
И только после указания всех деталей с указанием следом за ними исполнителей появится возможность провести реальные расчеты и исследовать допущения. Это справедливо даже для небольших коллективов или отдельных разработчиков. Календарный план оказывает психологическое влияние, поскольку с его помощью оглашаются взятые обязательства. Совсем не просто забыть или проигнорировать то, что вывешено на всеобщее обозрение, напоминая команде о том, что должно быть сделано. Для руководителей проекта существенно и следующее обстоятельство: когда обнародован проект календарного плана, могут быть подняты вопросы о реалистичности некоторых его разделов и может быть сопоставлен объем работ по проекту с тем, что возможно выполнить на самом деле.
Такой психологический способ называется функцией принуждения. К этой функции относится все, что при вступлении в силу естественным образом вызывает изменения во взглядах, отношении или поведении. Поэтому календарные планы являются функциями принуждения, играющими существенную роль в реализации проектов. Если руководитель проекта будет использовать их должным образом, то каждый, чья деятельность нашла в них отражение, будет вынужден тщательно продумывать возложенную на него работу. Эта функция принуждения является решающим фактором реализации потенциала проекта. Даже если календарный план не выдерживается, удваивается по времени или сокращается вдвое, все обязательства и связи, принятые всеми при его предварительной проработке, могут соблюдаться. Итак, вторая цель создания календарного плана может быть достигнута и сможет полностью оправдать усилия, затраченные на его составление, даже если в нем будут допущены существенные неточности. Например, если проект завершается со значительным опозданием, наличие календарного плана все равно позволит завершить работу над этим проектом.
Третья цель разработки календарных планов состоит в предоставлении команде средства, позволяющего контролировать ход работы и разбить ее на поддающиеся управлению этапы. Разбиение работы на одно– или двухдневные задания помогает исполнителям осознать объем предстоящих работ. Вообразите, что при строительстве дома бригадир определил задание одной строкой: «Построить дом за 120 дней». При такой «степени детализации» всем, включая и самого бригадира, будет довольно трудно понять, что нужно делать. Но если строитель сможет предоставить объемы работ по неделям, каждый сможет понять, когда и какие задания будут выполняться, в чем заключаются приоритеты, и задать более целенаправленные вопросы и уяснить принимаемые им обязательства. С точки зрения руководителя проекта качественно составленный календарный план дает более понятное видение проекта, на ранней стадии рассеивает претензии, сглаживает оплошности и повышает шансы на благоприятный исход.
С ростом масштабности и сложности проекта возрастает и роль календарных планов. В больших проектах усиливается взаимозависимость исполнителей, а при выборе решений и сроков повышается вероятность влияния на других людей. Если у вас всего несколько сотрудников, работающих в небольшой команде, то шансы выявить проблемы в работе друг друга намного выше. Ошибки в планировании работ плохо воспринимаются даже в небольшой команде, но в этом случае потерянные полдня компенсируются ударным трудом трех человек в течение того же времени, позволяя наверстать упущенное. Кто-то может задержаться на работе или, если надо, вся команда может сплотиться и помочь отставшим войти в график. При работе над более объемным проектом с привлечением десятков и сотен сотрудников утраченные сутки могут привести к «эффекту домино» и возникновению различных проблем в самых непредвиденных ситуациях, справиться с которыми силами одной команды порой невозможно. Но при любой команде, большой или маленькой, календарные планы дают возможность руководителям и финансистам проекта ставить вопросы, вносить поправки и оказывать помощь команде разработчиков, выявляя возникающие проблемы и оперативно реагируя на них.
Осознавая эти три цели, нетрудно заметить, что даже самые совершенные календарные планы не решают всех проблем проекта. Планы не могут исправить неудачный проект или его техническое воплощение, не могут защитить проект от слабого руководителя, нечетко сформулированных целей и плохо организованного взаимодействия. Поэтому, сколько бы времени не было затрачено на создание календарных планов, они все равно останутся лишь набором слов и цифр. А вот будут ли они использованы в качестве инструмента управления проектом для его успешного продвижения – зависит от конкретных людей. Осознавая это, пора вытащить толстое руководство и на примере создания программных продуктов исследовать тяжеловесные методологии управления проектами.
Решающие факторы и методологии
Существует множество различных систем планирования и управления, ориентированных на разработку программного обеспечения. Эти системы часто называют методологиями, то есть наборами методов, направленных на достижение конечного результата в конкретной области. Среди основных методологий разработки программных продуктов можно отметить водопадную и спиральную модели, ускоренную разработку приложений, экстремальное программирование и функционально-ориентированную разработку.[8] Все эти методологии призваны решать сходные проблемы организации и управления проектами. У каждой из них есть свои сильные и слабые стороны, и чтобы решить, какая именно методология подходит для тех или иных проектов, нужно обладать достаточными знаниями и опытом.
Однако целью главы, да и всей книги, не является сравнение различных методологий. Я полагаю, что есть концепции, положенные в их основу, и именно ими нужно овладеть, дабы добиться успеха при использовании любой методологии. Во всех случаях методологии нуждаются в корректировке и адаптации под особенности команды и проекта, а такая адаптация возможна только при наличии базовых знаний, более глубоких, чем знание самих методологий. Итак, если вы сможете воспринять и применить основополагающие идеи, рассматриваемые в данной главе и во всей остальной книге, то независимо от применяемой методологии ваши шансы на успех возрастут. Я намерен объяснить аспекты некоторых методов, по мере необходимости прояснения некоторых вопросов, но если вы коллекционируете информацию о методологиях, лучше обратиться к другим источникам.[9]
При всей своей важности для разработки программных средств методы не являются решающими факторами. Нет ничего хуже, чем слепо следовать наборам абсолютно несостоятельных правил только потому, что они изложены в популярных книгах или проповедуются многоуважаемыми гуру. Очень часто я убеждаюсь, что одержимость процессом – весьма тревожный знак, свидетельствующий о затруднениях в руководстве: это может быть попыткой переложить обычные проблемы и ответственность, с которыми сталкиваются руководители, на систему процедур и бюрократических приемов, подменяющих необходимость осмысленных руководящих действий. Возможно, намного более пагубным для команды разработчиков может стать пристрастие к методологии, которой в организации отводится чуть ли не первостепенная роль. Том Демарко (Tom DeMarco) в своей книге «PeopleWare» (Dorset House, 1999) («Человеческий фактор в программировании») отмечал:
Навязчивая идея применения методологий на рабочем месте – еще один пример высокотехнологичной иллюзии. Она берет начало из веры в то, что технология – это единственное, что на самом деле имеет значение… Какими бы ни были технологические преимущества, они могут быть получены только за счет существенного ухудшения социального климата в команде разработчиков.
Сосредоточенность на приемах и методах, подменяющая организацию процесса, направленного на поддержку человеческого фактора, приводит к тому, что планирование проектов начинается с наложения ограничений на вклад каждого из участников в его реализацию. При этом может быть установлена уйма правил и инструкций, вместо того чтобы подумать о корректировке или совершенствовании этих правил. Поэтому будьте очень осторожны в применении любой методологии: она не должна подавлять инициативу команды.[10] Наоборот, она должна стать средством поддержки, стимуляции и помощи команде в продуктивной работе (советы по организации процессов см. в главе 10).
Использование конкретной методологии не может быть единственной причиной своевременного или несвоевременного завершения проекта. Существуют факторы, воздействующие на все проекты, и руководители проектов должны в них разобраться до того, как приступать к любой работе по составлению календарных планов. Но перед тем как говорить об этом, нужно поговорить о составляющих календарного плана.
На что похож календарный план
Существует одно основное правило составления всех календарных планов – так называемое «правило трех частей». При всей его приблизительности и упрощенности оно предлагает самый простой подход к пониманию сути календарных планов. Если у вас уже есть опыт составления календарных планов, то немного потерпите, поскольку я представлю весь процесс в слишком упрощенном виде. Это делается, чтобы заложить элементарную основу для объяснения, что может не получиться, почему это может произойти и как с этим справиться.
Правило трех частей работает следующим образом: все отпущенное время разбивается на три части: проектирование, разработку и тестирование. В зависимости от используемой вами методологии эти части могут называться по-другому, но во всех методологиях предусматривается выделение времени на реализацию этих трех этапов. В любой конкретный день или час вы либо определяете то, что должно быть сделано (проектируете), либо фактически создаете продукт (пишите программный код), либо проверяете, анализируете и совершенствуете сделанное (проводите тестирование).
В соответствии с правилом, на каждый день, отводимый на разработку программного кода, выделяется день на планирование и проектирование и день на проверку и доводку сделанного (рис. 2.1). Вряд ли что-нибудь еще может быть проще – перед вами простой механизм проверки любых существующих календарных планов или создания календарного плана «с нуля». Если все отведенное на реализацию проекта время не разделено приблизительно на три равных этапа работы, должны быть вполне объяснимые причины, почему проекту требуется неравномерное распределение усилий. Если позволяют сроки, правило трех частей допускает некоторый дисбаланс, при котором считается нормальным отводить на тестирование на двадцать и более процентов времени больше, чем на разработку.
Рис. 2.1. Простейшая схема календарного плана, созданного по правилу трех частей
Рассмотрим гипотетический проект разработки веб-сайта: если вам на его запуск отвели шесть недель, то первым шагом должно стать деление этого времени приблизительно на три части и на основе полученного результата вычисление времени завершения работы. Если оказывается, что времени на работу с ожидаемым высоким уровнем качества не хватает, значит, что-то в корне неправильно. Надо либо менять календарный план, либо сокращать предполагаемый объем работ (или снижать ожидаемое качество). Выкраивание времени за счет тестирования всего лишь увеличит шансы на то, что время, потраченное на написание кода, уйдет впустую, или будет получен код, малоприспособленный для управления и поддержки. Правило трех частей полезно тем, что заставляет выявить ситуацию, при которой выигрывая в одном, проигрываешь в другом. Добавление новых возможностей выливается не только в дополнительную работу программиста по их реализации, но и влечет за собой неизбежные издержки на проектирование и тестирование, на которые кто-то должен идти. Когда календарный план срывается, причина заключается в неучтенных скрытых или проигнорированных издержках.
Стоит рассмотреть и самый простой вариант: отсутствие проекта как такового. Вся работа делается по мере поступления заказов, которые сравниваются по объему с другой работой и включаются в следующее свободное место календарного плана. Некоторые команды разработчиков, создатели веб-сайтов или отделы программирования информационных систем часто именно таким образом и действуют. Эти организации редко вкладывают деньги в крупные проекты или вообще за них не берутся. Гибкие методы (которые будут вскоре рассмотрены) в силу присущей им возможности перенаправления усилий, простоте и ожидаемости изменений часто рекомендуются таким командам в качестве наиболее естественной системы организации работы. Если вы работаете сразу над несколькими мелкими заданиями (не проектами), вам придется экстраполировать приводимые в данной книге примеры, ориентированные исключительно на проекты.
И все же правило трех частей применимо и к этим ситуациям. Даже если каждый программист работает в одиночку над выполнением мелких заданий, он, вероятнее всего, затрачивает примерно одну треть общего времени на разработку алгоритма, одну треть – на его реализацию и одну треть – на проверку и отладку. Он может перескакивать по этим этапам взад и вперед каждые несколько минут, но для упрощенного понимания работы какой бы то ни было разновидности правило трех частей применимо для любого масштаба.
Разделяй и властвуй (большие планы равны множеству мелких)
Изучая большинство методологий разработки программного продукта, вы можете обнаружить, что в их основу заложено правило трех частей. Преследуемые при проектировании или разработке конкретные цели и используемые подходы могут существенно различаться, но желаемые результаты на самом высоком уровне схожи.
Там, где проекты усложняются из-за своей объемности или продолжительности, календарные планы делятся на части, каждая из которых имеет собственные периоды проектирования, разработки и тестирования. В экстремальном программировании (Extreme Programming, XP) такие части называются итерациями, в спиральной модели – фазами, а в некоторых организациях их называют этапами. Хотя в XP считается, что эти отрезки времени занимают всего несколько недель, а в спиральной модели счет идет на месяцы, в них заложена одна и та же фундаментальная идея: создание подробных календарных планов для ограниченных периодов времени.
Чем больше ожидаемых изменений и проектных отклонений, тем короче должен быть каждый этап. Таким образом снижается степень суммарного риска, связанного с выполнением календарного плана, поскольку общий план оказывается поделенным на управляемые фрагменты. Такое деление календарного плана на этапы предоставляет естественную возможность вносить коррективы и повышает шансы на более четкую организацию работ на следующем этапе. (О том, как это делается, рассказывается в главе 14.)
Экстремальное программирование и другие гибкие методы предполагают, что будущее всегда изменчиво, поэтому они делают ставку на процессы, включающие естественные изменения направления. Дорогостоящие проекты (скажем, строительство небоскреба, создание игровой видеоприставки или встроенной операционной системы) реализуются по-другому и предполагают большие затраты на планирование и проектирование. При реализации проекта каждый должен следовать решениям, принятым в процессе проектирования, а непомерно высокая стоимость внесения изменений приводит к единственно возможному пути реализации.
Большинство проектов по разработке программных продуктов представляют собой нечто среднее. В них присутствует некое первичное планирование, но для того чтобы справиться с будущими изменениями требований и желаний заказчиков, работа делится на фазы, в которых время распределяется на проектирование, разработку и проверку качества. Если возникают новые проблемы, их можно решить в течение текущей фазы или поместить в очередь работ для более тщательной проработки и осмысления в следующей фазе.
В большинстве проектов время, отведенное на первичное планирование, тратится на сбор от заказчиков и бизнесменов информации, достаточной для определения требуемого количества фаз, сути и содержания каждой из них (рис. 2.2). В зависимости от общего плана в каждой фазе может быть отведено больше времени на проектирование или тестирование. Фаза может быть разбита на две меньшие (делая стиль разработки более гибким) или две фазы могут быть совмещены (разработка становится более цельной). Но в любом случае время должно распределяться между фазами таким образом, чтобы можно было воспользоваться преимуществом от проводимых изменений. Сюда включается и реакция на проблемы, возникшие в течение предыдущей фазы, заняться которыми в ходе этой фазы не представилось возможным.
Все это я объясняю, собираясь перейти к методологии создания календарного плана высшего уровня. В главах 14 и 15 рассматривается порядок управления проектом на протяжении выполнения всего календарного плана, но в них обращается внимание на перспективы управления и руководства, а не на детали применения конкретной методологии. Если вы смогли усвоить материал нескольких последних разделов (даже если вы не совсем согласны с изложенной в них точкой зрения), советы, излагаемые в главах 14 и 15, будут уместны и полезны независимо от того, как вы организовали или спланировали свой проект.
Рис. 2.2. Большой проект должен представлять собой последовательность более мелких проектов
Так или иначе, я прошу прощения у всех опытных разработчиков, почувствовавших недомогание при чтении данного раздела или вовсе лишившихся чувств. Заканчивая его, я обещаю, что подобный облегченный и упрощенный взгляд на планирование – это практически все, что вам понадобится, чтобы усвоить понятия, излагаемые в оставшейся части главы.
Почему рушатся планы
Как только что-нибудь идет не так, обычно винят во всем календарный план проекта. Если кто-нибудь допускает просчет, не выполняет требование или попадает под автобус, критике подвергается календарный план (или сотрудник, ответственный за его разработку). Если электрические сети страны выходили из строя на десять дней или лучшие программисты команды становились жертвами эпидемии, обязательно кто-нибудь скажет: «Я же говорил, что план провалится» – и погрозит планировщику пальцем. С тех пор как люди следуют планам, они задирают вверх планку на недосягаемую высоту. Самые лучшие в мире планировщики, с самими светлыми головами, имеющие в своем распоряжении самые лучшие инструменты, все еще пытаются каким-то образом предсказать будущее, но человеку редко удается достичь высот в этом деле.
Однако если команда приступает к проекту, всецело осознавая возможные причины, по которым план может провалиться, и предпринимает некоторые меры для минимизации подобного риска, календарный план может стать весьма полезным и точным инструментом создания программного продукта.
Выстрел вслепую издалека
Если календарный план создан в период первичного планирования, то должны быть приняты сотни решений, способные на него повлиять. Будут возникать проблемы и сложности, которые никто не в состоянии предвидеть, поскольку способов, позволяющих принять их во внимание на ранней стадии теоретического планирования, попросту не существует. До тех пор пока не будут осмыслены требования и не пойдет полным ходом проектирование высокого уровня, руководитель проекта обладает слишком скудной информацией для построения реалистичных прогнозов. Кроме того, довольно часто черновой календарный план создается с вымышленными цифрами и грубыми допущениями, и этот муляж вручается команде под видом правдоподобного плана реализации проекта. Зачастую люди попадают в ловушку, где точность подменена подробностью описания. Впечатляющий календарный план с определенными датами и сроками (подробность) совсем не обязательно отражает реальность (точность). Проще достичь подробности, точность дается намного сложнее.
Тем не менее рано или поздно все проекты и их планы должны быть запущены в дело. Этот «выстрел в тумане» может быть использован для мобилизации команды и расстановки некоторых границ. Он может инициировать процесс исследования с целью конкретизировать календарные планы, поставить важные вопросы и найти на них ответы. Но если в основу календарного плана легли непроверенные и неисследованные поверхностные предположения, к тому же не подвергающиеся дальнейшему уточнению, степень риска весьма высока. Совершенно очевидно, что в начале проекта оценить требуемое время не под силу никому.
Барри Боэм (Barry Boehm) в 1988 году в своем эссе на тему разработки программных продуктов[11] писал, что ошибки тем масштабнее, чем раньше при реализации проекта делались расчеты для календарного плана (рис. 2.3). Если все расчеты делались на ранней стадии, отклонения могут составлять до 400 % в обоих направлениях (подозреваю, что ошибки всегда работают против нас, стремясь отнять больше времени, чем мы ожидаем, хотя Боэм в своих данных этого не показал). В период проектирования по мере конкретизации решений расхождение сокращается, но остается еще весьма значительным. И только когда проект достигает стадии реализации, диапазон расчетов календарного плана приобретает разумные очертания, но даже тогда остается 20-процентный разброс вероятности планирования.
Рис. 2.3. Диапазон возможных отклонений от расчетных сроков в процессе реализации проекта (заимствовано из книги Боэма «Software Engineering Economics»)
То есть руководители проектов должны усвоить, что расчеты для календарного плана со временем становятся точнее. Календарные планы требуют внимания в ходе реализации проекта и корректировки по мере его продвижения.