Акупунктура, Аюрведа Ароматерапия и эфирные масла, Консультации специалистов: Рэйки; Гомеопатия; Народная медицина; Йога; Лекарственные травы; Нетрадиционная медицина; Дыхательные практики; Гороскоп; Правильное питание Эзотерика

Об авторе

Скотт Беркун изучал информатику, философию и дизайн в университете Карнеги Меллон. Он работал в компании 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»)

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

Календарный план – это оценка вероятности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

Упражнения

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

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

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

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

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

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

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

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

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

Глава 3. Как определить, что делать

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

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

Фред Брукс (Fred Brooks)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ВНИМАНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Чем обычно заняты люди? (Не наши домыслы и не то, что они об этом рассказывают.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Баланс сил

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итак, возможные характеристики проекта X:

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

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

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

Упражнения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дэниел Бурстин (Daniel Boorstin), автор великолепных работ «The Creators» (Vintage, 1993) и «The Discoverers» (Vintage, 1985), как-то сказал, что письменное слово было величайшей из всех технологий, когда-либо изобретенных человеком. Без него нам пришлось бы всецело зависеть от нашей печально известной своей дырявостью памяти,^[24] занимаясь такими сложными вещами, как создание динамита (гм, в каком весовом соотношении должны быть нитроглицерин и древесный уголь?) или ядерного реактора (а куда исчезает уран?). Применительно к работе над проектом записи дают возможность однократно определить характер технической работы или зафиксировать общие для всей команды цели, а затем многократно использовать эти сведения. Документирование деталей принятых решений перекладывает с нашей памяти на бумагу все заботы о точности их формулировок и сохранности, после чего их можно восстановить в памяти, всего лишь взглянув на записи. Такая разгрузка памяти позволяет нам решать поставленную задачу полным ходом, имея под рукой ее описание, и пребывать в полной уверенности, что мы всегда, если понадобится (собьемся с курса, столкнемся с разногласиями или запутаемся), сможем вернуться к написанному. Из этого следует, что чем больше в работе сложностей и чем больше прилагаемых к ней усилий, тем выше вероятность того, что запись некоторых деталей решения повысит шансы на ее успешное выполнение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Простота

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

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

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

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

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

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

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

Вдохновляющая способность

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

Запоминаемость

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

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

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

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

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

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

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

• Какие сценарии или потребительские свойства являются основными для данного проекта? (Приоритет – 1.)

• Какие сценарии или потребительские свойства, не являющиеся основными, желательно реализовать? (Приоритет – 2.)

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

• Кто представляет в организации стороны, заинтересованные в данном проекте (люди, облеченные полномочиями по реализации данного проекта, которые не обязательно должны быть пользователями создаваемого в его рамках продукта)? Какая роль им отводится в проекте? (Заинтересованные стороны будут рассмотрены в главе 16.)

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

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

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

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

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

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

• Что в успехе данного проекта зависит от других компаний или групп? Зависит ли успех других компаний или групп от реализации данного проекта?

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

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

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

Умение четко излагать мысли

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

Простота дается не легко

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

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

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

У хорошей разработки только один главный автор

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

Каноническим примером единоличного авторства служит Декларация независимости США. В 1776 году Континентальный конгресс сформировал комиссию для выработки этого документа. Комиссия собиралась несколько раз, однако осознав особую важность такой характеристики документа, как доходчивость, поручила разработать проект Томасу Джефферсону. Джефферсон поступил так же, как я рекомендую поступать и команде проектировщиков, – он разработал множество проектов и принял участие в их обсуждении в Конгрессе, по нескольку раз пересматривая некоторые из них. Несколько недель спустя, группа представила Конгрессу окончательный вариант документа. Автор не должен быть постоянно на виду, Джефферсон в процессе работы над Декларацией не занимался сбором подписей и согласованиями. Он просто получил полномочия и использовал свой талант во благо всей группы разработчиков.

Качество не определяется объемом

Следует понимать, что ясная мысль не требует многостраничного изложения. Самые действенные руководящие документы в мире не отличались большим объемом. Конституция США, включая Билль о правах, содержит всего лишь 7000 слов (около 6 страниц). Десять заповедей состоят из 300 слов. Великая хартия вольностей – из 5000. Светлые головы способны извлечь из идей самую суть и выразить их намного доходчивее любых описаний, занимающих вдвое больше места. Не следует путать понятия объема и качества. К сожалению, из-за того, что объем дается легче, чем качества, мы иногда поддаемся следующему искушению: «Если ничего хорошего не выходит, то можно выиграть хотя бы за счет объема, а вдруг никто не заметит разницы» (еще одна привычка в работе авторитетных комиссий). Итак, с учетом всего вышеизложенного, вполне уместно спросить меня о том, почему же я не сократил объем этой книги. Виноват, не смог.

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

Прикидки, пересмотры и переработки

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

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

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

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

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

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

Рис. 4.3. Основной график рассмотрения и корректировки концептуального документа

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

Перечень неудачных положений концепции (которых следует избегать)

За свою профессиональную карьеру мне приходилось читать десятки концептуальных документов и самые плохие из них содержали одни и те же стереотипы. Плохо составленные концепции не имеют целостности, не предлагают никакого плана и не выражают совокупности мнений. Вместо этого в них излагаются размышления и прописные истины. Если в концепции нет четкого взгляда на то, что должно быть сделано, руководители команд никогда не станут работать с душой, обрекая проект на провал. Герой фильма «Бойцовский клуб» («Fight club») Тайлер Дурден (Tyler Durden) говорит: «Если вы воткнете себе сзади перья, то все равно не станете курицей». Если вы создаете документ с надписью «концепция» на титульном листе, это еще не означает, что в результате вы получите именно концепцию. Можно делать все по правилам, проводить совещания, пользоваться формализованными документами и все же упустить всю суть, ради которой и создается концептуальный документ. Точно так же, как титул «руководитель проекта» не означает волшебного превращения всего, что вы делаете в действии руководителя, присваивание какому-нибудь документу название концептуального не означает, что он возымеет описанный выше эффект.

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

Таблица 4.1. Типичные примеры неудачных концептуальных положений

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

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

Вот примеры вполне удачных концептуальных положений:

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

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

• В версии 5.5 Helpdesk Automated Services Site (HASS) будут учтены десять самых распространенных претензий, предъявленных пользователями из числа преподавателей и студентов университета, при этом исключаются любые негативные влияния на среднюю производительность, надежность или на время отклика системы.

В качестве примера удачных целей проекта приводится перечень, использовавшийся разработчиками наладонного органайзера Palm Pilot:^[25]

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

2. Стоимость. Устройство должно стоить меньше, чем органайзер элитного класса (около 300 долларов США).

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

4. Синхронизация с персональным компьютером. Компьютер должен стать основным средством взаимодействия с пользователем.

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

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

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

Концепции должны быть наглядными

Указывая пальцем на Луну, не перепутайте палец с Луной.

Дзен-буддистская притча

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

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

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

Наглядное представление неочевидных вещей

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

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

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

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

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

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

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

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

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

1. Насколько точно концепция отражает наши цели, определенные для этого проекта?

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

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

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

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

Выводы

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

• Документирование приносит пользу и создателю концепции, и всей команде. Тем самым закладываются основы для проведения дискуссий и рабочие ориентиры, не зависящие от нашей «дырявой» памяти.

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

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

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

• Объем не является эквивалентом качества. А краткость требует больших усилий.

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

Упражнения

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

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

3. Исследуйте историю прорицателей. Выберите любых двух из следующего списка: Ганди, Малкольм Х, Торо, Будда, Сократ, Иисус Христос или Конфуций. Какими были их мировоззренческие концепции? Как они развивали свои идеи? Что они делали для выражения этих идей? Для их продвижения и популяризации?

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

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

6. Когда настанет время для команды написать концептуальный документ или технические условия, распечатайте несколько копий Конституции США и оставьте все это на стуле любого из авторов технических условий с запиской: «Они составили технические условия для целого правительства всего на шести страницах. А сколько понадобится тебе для описания отдельной характеристики?» Как на это отреагирует команда?

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

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

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

Глава 5. Откуда берутся идеи

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

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

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

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

Разрыв между требованиями и решениями

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

Рис. 5.1. Проектирование зачастую выглядит как некий таинственный переход от первичного планирования к выработке технических условий

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

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

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

Качественные требования и ошибки

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

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

Итак, чем больше внимания уделено выработке требований, тем выше шансы на то, что проектировщики найдут соответствующие им решения. Если требования не сформулированы, проектировщикам придется работать на собственный страх и риск (то есть если вы ведете проектирование, не имея требований, в ваших собственных интересах составить их самостоятельно). В качестве примерного руководства по улучшению требований я привожу краткий перечень типовых ошибок, которых следует избегать во время разработки этих требований.^[27]

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

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

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

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

 Постарайтесь уточнить или исключить все случайно вкравшиеся неоднозначные понятия. Такие слова, как быстрый, большой, маленький, хороший, красивый и удобный, понятны лишь в сравнении. Их неопределенность может устраивать только в том случае, когда все участники выработки требований (заказчики, руководители, программисты и т. д.) согласны отложить их уточнение до следующих переговоров. В противном случае каждый составитель требований не захочет вносить уточнения там, где это ему не выгодно. Зачастую простейшим способом устранения неоднозначности является установка определенных границ («Наша домашняя веб-страница должна загружаться в Firefox как минимум с такой же скоростью, как страница www.cnn.com, но лучше, если она будет загружаться так же быстро, как www.oreilly.com»). При этом должны быть легко различимы абсолютные (должно быть так) и желательные (было бы неплохо, но можно обойтись) требования.

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

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

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

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

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

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

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

Рис. 5.2. Конструкторские замыслы возникают на основе формулировки задачи

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

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

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

Страх перед просчетами и размышления о прогрессе

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

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

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

Идеи бывают плохими…

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

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

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

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

С чем сравнивать, хорошо это или плохо?

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

Существует и иной подход к оценке идеи. Открытие формулы E = mc² стало для Эйнштейна его звездным часом, но для любителя этой формулы, пытающегося свести концы с концами, или для человека, потерявшегося где-то в пустыне Сахара^[30] (не говоря уже о тех, кто потерялся в пустыне и при этом испытывает материальные затруднения), это открытие оказалось совершенно бесполезным. Так хороша или нет идея, заключенная в формуле E = mc²? Возможно, она будет хороша, если вы расширите область требований и пространство решения проблем, чтобы включить в них общую идею о совершенствовании ваших знаний о вселенной. А возможно и нет, когда все, что вас тревожит на данный момент, – это судьба друга, затерявшегося где-то в Сахаре. Идеи выглядят хорошими или плохими лишь на фоне различных обстоятельств. Независимо от того, насколько гениальными они представлялись при абстрактной оценке, когда они вносятся в проект, который направлен на создание реальных вещей, предназначенных для решения реальных проблем, ошибки, допускаемые при попытке отличить абстрактный подход от прагматичного, всегда приводят к неприятностям.

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

Стандартное и нестандартное мышление

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

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

Рис. 5.4. Головоломка, требующая нестандартного мышления, с готовым решением

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

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

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

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

Хорошие вопросы привлекают к себе хорошие идеи

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

Пабло Пикассо

Чтобы избежать выполнения ряда нежелательных требований, предъявляемых в колледже, для получения степени бакалавра я изучал теорию логики и философию. Многое я, конечно, выучил и забыл, но среди того, что запомнилось с тех времен, был и вопрос о том, как задавать хорошие вопросы. У меня было развито чувство логики, но я был единственным новичком в выпускных классах теории логики, поэтому обычно (а точнее, всегда) отставал от остальной группы. Я быстро понял, что нужно задавать однокашникам и профессорам четко сформулированные вопросы, иначе меня завалят грудой непонятной и бесполезной для меня информации. Я обнаружил, что множество инженеров, докторов и других представителей интеллигенции с радостью готовы поделиться своими знаниями независимо от того, о чем я их спрашиваю. Люди порой могут теряться и в собственных знаниях.

Четко заданные вопросы являются одним из способов вести сложные переговоры в нужном направлении. Я могу привести пример из личного опыта общения с профессорами логики, заставлявшими меня обращать пристальное внимание на то, как я задаю вопросы. Все могло начинаться с моего вопроса типа: «Не могли бы вы объяснить вот эту часть теоремы незавершенности Геделя?» Профессор мог ответить следующим образом: «Разумеется. Вы понимаете, все методы доказательств могут быть сведены к основному набору характеристик, определяемых основными рекурсивными первичными функциями». Я мог сказать: «Ну, да. Хорошо. Но не могли бы вы объяснить вот эту строку?» и указать на маленькую строчку доказательства, очерченную толстой красной линией с нарисованным рядом огромным вопросительным знаком. Профессор мог кивнуть головой и сказать: «Ну, конечно <пауза>. Итак, история методики доказательств берет свое начало от замечательной попытки выражать аспекты существования через систему, поддающуюся проверке…» Я мог сказать: «О, боже. Нет, я имею в виду вот это <показываю снова>. Что означает это место? Как оно соотносится с верхней строкой?» Он мог ответить: «Да, да. Понимаете, теория доказательств относится к математической логике, поскольку лемма неосязаемости между наборами неупорядоченных, но бесконечных значений…» В конце концов, я обычно бросал эту затею и направлялся в ближайшую пивную.

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

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

Вопросы, концентрирующие внимание

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

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

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

Какую именно проблему вы пытаетесь решить?

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

Креативные вопросы

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

Риторические вопросы

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

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

Плохие идеи ведут к хорошим идеям

Впервые я наблюдал за реальной работой дизайнера еще юношей, во время обучения в колледже. Я не разбирался в сути его работы и, по большому счету, думал, что дизайнеры работают над внешним видом изделий: разрабатывают покрой джинсов, фасоны дамских сумочек и т. д. Как бы то ни было, а тот молодой человек разрабатывал новый тип переносной стереосистемы. Он сидел за своим столом в студии учебного отдела проектирования, которая представляла собой большое, открытое пространство, увешанное массой таблиц, эскизов, зарисовок прототипов и проектов.^[31] Он делал наброски различных идей, каждый из которых представлял собой очередной вариант стереосистемы. Я спросил у него, чем он занят, а точнее, как все, что он делает, соотносится с понятием «проектирование», что бы это для него ни означало.

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

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

Лучшие идеи и конструкции требуют какого-то начального толчка. Они не возникают в результате магических заклинаний или волевых усилий («Сейчас тебя должно осенить! Именно сейчас…!»). Каждый рисунок, эскиз или прототип, пускай даже самый нелепый и жалкий, дает проектировщику (инженеру, ученому) толику нового в осознании проблемы и повышает шансы следующей попытки стать лучше предыдущей. Все великие умы, занятые решением сложных мировых проблем, не обходятся без груды скомканной бумаги, окружающей их рабочее место. Кто-то лукавит, что это не так, а кто-то соглашается с этим. Мысль о том, что неудачные идеи приводят к удачным, как ничто иное вдохновляет нас на проектирование всего, что угодно. Мы должны настроиться, засучить рукава и наделать поначалу массу ошибок, зато чем скорее это произойдет, тем раньше мы приблизимся к ценным идеям.

Хорошие проекты рождаются из множества хороших идей

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

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

 У архитектора два самых главных инструмента: в студии – ластик, на строительной площадке – кувалда (Фрэнк Ллойд Райт).

 Самый важный инструмент физика – мусорная корзина (Альберт Эйнштейн).

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

 Неудач не бывает. Бывают лишь слишком ранние отказы от продолжения работы (Джонас Солк).

 Лучшие способы есть всегда, их только надо найти (Томас Эдисон).

 Неудача. Опять неудача. Почти что удача (Сэмьюэл Бэкет).

 Если хотите достичь успеха, удвойте квоту неудач (Том Уатсон, IBM).

 На одну страницу шедевра у меня приходится 99 страниц мусора (Эрнест Хемингуэй).

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

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

Широта взглядов и импровизация

С подачи Оука Юксела (Ayca Yuksel) и Ванессы Лонгакрэ (Vanessa Longacre), двух бывших сотрудников компании Microsoft, вся наша троица записалась в общественный колледж в класс импровизационной комедии. После первого же дня я понял, что мой страх выставить себя на посмешище перед командой совершенно не обоснован. Я узнал, что большинство людей, если они учатся замечать что-нибудь вокруг себя (чему нас и учили в этом классе), смогут находить смешное во многих совершенно заурядных ситуациях. Учеба часто позволяет видеть вещи, обычно ускользающие от внимания, и строить взаимосвязи между ними.

Когда я вернулся к работе, к миру проектов и разработок, я обнаружил, что нечто подобное характерно и для решения наших проблем. Тем, кому удавалось находить верные решения, замечали то, что не видели другие. Они замечали больше подробностей, выстраивали больше ассоциаций и обладали большей глубиной восприятия, продвигаясь в поиске взаимосвязей между вещами. В интервью журналу «Wired»^[32] Стив Джобс (Steve Jobs) так прокомментировал эту весьма важную особенность творческой работы:

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

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

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

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

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

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

Правила импровизации для генерации идей

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

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

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

1. Да, и вот еще что… Когда кто-нибудь другой предлагает некую мысль, допускается лишь одна реакция: «Да, и вот еще что <далее следует соответствующее продолжение>». Вашим первым побуждением должно стать продолжение его направления мысли. Обычно вы подхватываете его идею или точку зрения и продвигаете их дальше или меняете их направление, к примеру: «Мы можем использовать поисковое поле вот здесь…», «Да, и разумнее было бы после того, как пользователь что-нибудь ввел, перевести его взгляд в нужное место». Или: «Да, и вот еще что, здесь нужно воспользоваться тем самым новым поисковым движком, который мы создаем, и ускорить выдачу результатов». Все внимание направлено на то, чтобы развитие дискуссии шло в позитивном направлении и вырабатывалась привычка прислушиваться к другим участникам, помогая в развитии предложенных ими идей, а не выжидая благоприятного момента для высказывания собственных.

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

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

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

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

Другие подходы к генерации идей

Если вы не готовы к импровизационным играм или хотите подойти к генерации идей более прямолинейно, то вам подойдет ряд традиционных предложений:

 Подберите себе книгу по творческому мышлению. Существует немало хороших книг на выбор. Две мои самые любимые – «Thinkertoys» Майкла Майкалко (Michael Michalko) (Ten Speed Press, 1991) и «Six Thinking Hats» Эдварда Де Боно (Edward De Bono) (Back Bay Press, 1999). Существует множество других популярных книг, которые по-своему тоже хороши, но наибольшую пользу я сумел извлечь их этих двух.

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

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

 Купите колоду карт для мозговой атаки, ThinkPak, созданную Майклом Майкалко (Michael Michalko). Эта колода игровых карт разработана для того, чтобы помочь человеку или группе придумывать новые идеи в любой области деятельности.^[33] Можно найти и другие подобные наборы, но мне все же больше помог именно этот.

Проектирование начинается с восприятия пользователя

Провидцам от технологии не дано осознать различие между выполнимым и желаемым.

Эдвард Мендельсон (Edward Mendelson)

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

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

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

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

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

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

1. Динамически выстраивать страницы по приоритетам на основе их востребованности.

2. Избавиться от материала, который никогда не вызывается по ссылкам.

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

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

Проектирование представляет собой серию переговоров

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

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

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

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

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

Выводы

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

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

• Идеи могут быть удачными или неудачными только по отношению к целям проекта или к другим идеям.

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

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

• Лучшей исходной точкой для проектирования служит пользовательское восприятие.

• Идеи воплощаются в проекты в ходе переговоров между специалистами разного профиля.

Упражнения

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

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

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

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

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

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

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

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

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

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

Глава 6. Как правильно распорядиться имеющимися идеями

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

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

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

Идеи выходят из-под контроля

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

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

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

В первые месяцы существования проекта IE 4.0 мы получили настоящий вал программ. Параллельно мы пытались перейти от небольших команд и релизов (а-ля IE 2.0 и 3.0) к выпуску главного продукта. Мы были вовлечены в гонки, развернувшиеся между компаниями Microsoft и Netscape, из которых пресса раздула войну не на жизнь, а на смерть. А затем наш продукт перешел в разряд стратегических уже в соответствии с внутренней политикой компании. В таких условиях любому было бы нелегко удержать судно на плаву. И, как и в большинстве проектов, стоило только наступить переходному моменту от планирования к разработке, как возникло столкновение мнений и амбиций. Людям пришлось принимать первые трудные для себя решения, они почувствовали груз ответственности. На фоне явного нарастания неуверенности и напряженности одно оставалось неизменным – сроки. На горизонте нетерпеливо маячила очередная календарная дата, приближавшаяся с наступлением каждого следующего дня.^[35]

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

Управление идеями требует твердой руки

Наиболее распространенной ошибкой является представление процесса проектирования в виде своеобразного рубильника, который можно включать и выключать, когда захочется. Развивая эту фантазию, можно представить следующий ход событий: однажды вы обнаруживаете, что сроки поджимают, а в вашем распоряжении еще слишком много идей и замыслов (и слишком мало готовых решений), но вы говорите команде: «Итак, с идеями мы покончили. Берите проект и приступайте к программированию. Вперед!» Даже если представить, что в вашем распоряжении вполне зрелый проект (чего на самом деле быть не может), подобное непредсказуемое поведение собьет с толку и дезориентирует всю команду. Вплоть до этого момента все занимались проектом, для окончательной готовности которого требовалось время. Без указания конкретной даты у них могло сложиться впечатление, что они имеют право принимать важные решения вплоть до 23 часов 59 минут суток, предшествующих дате готовности технических условий.

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

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

Рис. 6.1. Пространство решения проблем по мере приближения к контрольной точке должно сужаться

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

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

Причины этого явления могут быть разными.

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

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

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

Изменения вызывают цепную реакцию

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

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

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

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

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

Применительно к практике проектирования, итерация означает два шага вперед, шаг назад. Чем труднее и сложнее работа, тем больше это соотношение стремится к равенству (например, полтора шага вперед на каждый шаг назад). Но пока вы не сделаете этот шаг вперед и не примете какое-нибудь решение («Давайте создавать конструкцию Б!»), вы не сможете вскрыть все проблемы и вопросы. Принятие решений в процессе проектирования, даже если они окажутся неверными, – единственный способ вывести проблемные вопросы на поверхность. Если вы все правильно спланируете, то все равно будете многократно спотыкаться при проектировании, но, пройдя все это, вы значительно повысите свои шансы на успех. Большинство инженерных, конструкторских и научных изысканий следуют тем же принципам, выраженным следующей цитатой Джошуа Ледерберга (Joshua Lederberg), лауреата Нобелевской премии 1958 года:

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

Творчество – процесс инерционный

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

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

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

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

Рис. 6.2. Пространство решения проблем расширяется и сужается в процессе проектирования под воздействием непредвиденной инерционности творческого процесса

Контрольные точки фаз проектирования

Чтобы наилучшим образом распорядиться идеями, нужно начинать любой серьезный проект с расстановки четких контрольных точек, задающих распределение времени. Перед тем как творческий процесс пойдет в полную силу, в дополнение к двум контрольным точкам, моменту окончания выработки требований (формулировки проблем) и моменту выдачи технических условий, нужно определить еще ряд промежуточных точек. Расставить эти точки во времени (и убедить всех в их пользе) – задача руководителя проекта, хотя, может быть, лучше, чтобы проектировщики и разработчики сами определили, где именно их следует расставить и какими должны быть критерии их достижения.^[36] Для этого существует масса различных способов, и лучшие из них варьируются от проекта к проекту и от команды к команде. Однако, исходя из практического опыта, на временной шкале можно рекомендовать несколько ключевых точек (рис. 6.3).

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

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

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

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

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

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

Рис. 6.3. Контрольные точки процесса проектирования

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

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

ПРИМЕЧАНИЕ

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

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

Как объединить идеи

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

Для этого существует масса технологий,^[37] но самая простая из тех, что я знаю, – это созданная антропологом Кавакита Джиро (Kawakita Jiro) диаграмма сходства (также известная как KJ-диаграмма). Реализованный в этой диаграмме подход требует наличия четырех составляющих: идей, стены, клейких листочков и команды (хотя пиво с закуской тоже не помешают). В диаграмме сходства каждая идея представляется заметкой из нескольких слов, приклеенной к стене. Идеи могут быть результатом мозговых атак или перечнем, составленным силами одного-двух человек из команды. Может быть от двадцати до ста идей, а то и больше. Круг решаемых проблем и творческие способности людей ведут к невероятному разбросу в количестве идей от проекта к проекту.

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

Рис. 6.4. Когда идей много, справиться с ними нелегко

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

Рис. 6.5. Неплохо было бы сгруппировать идеи

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

• убрать дополнительные элементы управления, которыми никто не пользуется;

• улучшить формат страницы результатов поиска;

• использовать улучшенную поисковую машину HyperX;

• сократить количество одновременно отображаемых результатов;

• позволить пользователям устанавливать индивидуальные предпочтения в отношении внешнего вида страницы;

• открывать результаты в новом окне;

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

• провести доводку системы обработки запросов (включить поддержку логического поиска).

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

• Упростить:

• убрать дополнительные элементы управления, которыми никто не пользуется;

• улучшить формат страницы результатов поиска;

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

• Сориентировать на потребителя:

• позволить пользователям устанавливать индивидуальные предпочтения в отношении внешнего вида страницы;

• открывать результаты в новом окне.

• Реконструировать архитектуру:

• провести доводку системы обработки запросов (включить поддержку логического поиска);

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

• использовать улучшенную поисковую машину HyperX.

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

Оптимизация и расстановка приоритетов

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

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

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

Прототипы – ваши друзья

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

С чего начинаются прототипы?

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

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

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

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

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

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

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

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

Прототипы для проектов с пользовательским интерфейсом

Прототипы должны создаваться последовательно, сверху вниз. Начните с того, что должны видеть пользователи, и в той последовательности, в которой они все это должны видеть. Для получения вполне обоснованных замыслов и предположений с самого начала привлеките к работе своих специалистов по потребительским свойствам и дизайну. Пока не будут созданы несколько экранов, нет смысла тратить дни на выработку структур баз данных и XML-схем – это все равно что возводить стены дома еще до того, как вы узнали его планировку. Если вы это сделаете, потеря качества конечного продукта вам гарантирована – именно от этого и призваны защищать прототипы.^[38]

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

Что касается самого создания прототипов, то тут не существует никакой волшебной тайны. Чтобы понять, какие составляющие могут быть сымитированы или приукрашены, а какие потребуют дополнительных осмысления и затрат,^[39] требуется лишь некоторый опыт. На практике основной принцип заключается в том, чтобы добыть требуемую информацию с наименьшим показателем трудозатрат. Основой прототипа может послужить любое средство – Flash, HTML, VB и даже бумага. В этом деле важнее искусство дизайнера и(или) создателя прототипа, чем используемая для его создания технология или инструментарий.

Прототипы для проектов без пользовательского интерфейса

Даже если проект изначально не имеет пользовательского интерфейса или отношения к Интернету, он все равно нуждается в прототипе.^[40] Вместо вопросов дизайна пользовательского интерфейса нужно взять наиболее трудные или сложные технические проблемы и создать прототипы их решения. Подтвердите действенность основных алгоритмов, соответствие основным тестовым показателям или набору критериев производительности. Цель создания прототипов не зависит от типа проекта – эта работа позволяет понять, можно ли в отведенное время реализовать рассматриваемый вами примерный подход (или подходы) и обеспечивает ли он фактическое решение обозначенных проблем. Это шанс оценить риски еще до начала создания самого продукта и узнать, что нужно сделать до перехода к его созданию.

Прототипы – это опора программистов

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

Вот краткий перечень вопросов, на которые программисты должны ответить в данный период:

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

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

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

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

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

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

Альтернативные варианты повышают вероятность успеха

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

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

Вопросы относительно последовательного приближения

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

Вот часть вопросов, относящихся к ранним образцам прототипов:

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

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

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

• Что поучительного, пригодного для следующей версии прототипа содержал данный образец? Можно ли его уничтожить?

• Что нужно попробовать сделать в следующем образце, чтобы добиться лучшего результата?

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

А вот ряд вопросов для более поздних прототипов:

• Какое решение с его помощью мы можем принять?

• Какие спорные вопросы он поможет нам закрыть?

• Подтверждается ли данным образцом существование проблемы, подлежащей исследованию? Решается ли эта проблема с его созданием?

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

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

Список открытых проблем

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

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

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

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

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

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

Выводы

• Идеи обладают собственной инерционностью. Доминирование идей в творческом процессе продлится дольше ваших ожиданий. Изменения влекут за собой цепную реакцию во всем проекте.

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

• Для объединения идей используйте диаграмму сходства.

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

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

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

Упражнения

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

2. В каком режиме должно вестись управление идеями, в закрытом или открытом? Кто в вашей проектной команде должен иметь доступ к: а) просмотру; б) изменению; в) добавлению или удалению идей?

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

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

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

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

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

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

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

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

Часть 2. Как подготовить хорошие технические условия

Глава 7. Практические навыки

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

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

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

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

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

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

Что могут и чего не могут технические условия

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

Технические условия могут принести существенную пользу проекту в следующих вопросах:

• Предоставить толковое описание характеристик создаваемого изделия.

• Заставить проектировщиков разъяснить их решения, поскольку эти решения впоследствии превращаются в технические условия.

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

• Стать источником распространения информации от одного специалиста ко многим.

• Создать общекомандные ориентиры для отдельных планов (и если планы были сверстаны при проектировании, использоваться в качестве документации, по которой сверяется ход процесса^[42]).

• Предоставить четкие контрольные точки для рабочего графика, на которые будет сориентирована команда.

• Дать гарантию автору (или авторам), что его права не ущемляются.^[43]

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

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

• Прибавить команде (и автору) уверенности и рассудительности.

А вот, чему технические условия не могут и не должны послужить:

• Исключить всяческие дебаты внутри команды.

• Доказать команде авторскую состоятельность.

• Доказать, насколько важна та или иная деталь (и почему от нее нельзя отказаться).

• Привить людям философский взгляд на окружающий мир.

• Стать полем демонстрации авторского мастерства в работе с Visio или UML.

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

Что включать в технические условия

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

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

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

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

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

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

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

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

Кто отвечает за подготовку технических условий

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

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

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

Подготовка технических условий не относится к проектированию

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

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

Описание окончательного замысла и его реализации

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

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

Упрощение хороших технических условий

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

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

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

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

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

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

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

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

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

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

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

Гарантия верного хода процесса

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

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

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

Кто, когда и как

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

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

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

Технические условия – это для одного или для многих?

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

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

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

Когда считать законченной подготовку технических условий

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

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

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

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

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

Как справиться с открытыми проблемами

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

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

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

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

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

• Чем может разрешиться проблема в случае выбора каждого из вариантов, которые еще находятся в стадии рассмотрения? (Например, если мы решим использовать технологию ASP или PHP вместо JSP.) Как выбор каждого из вариантов повлияет на технические условия?

• Нельзя ли вообще проигнорировать эту проблему? Как это реально повлияет на пользователя с точки зрения самого приоритетного сценария его работы?

• Можно ли разбить проблему на более мелкие, которые могут (или должны) быть поручены другим специалистам?

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

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

Устранение пробелов в технических условиях

Если вы неплохо справляетесь с решением открытых проблем, то можно ликвидировать белые пятна в рабочем графике, проведя оценку времени разрешения этих проблем. Основную идею, часто называемую «усесться на переднем сидении», иллюстрирует рис. 7.1. При правильном воплощении этой идеи в жизнь технические условия могут считаться подготовленными и рассматриваться, даже если проектные проблемы остаются отчасти нерешенными. Этот прием представляет собой рискованную затею: вы прикидываете, насколько успешно командой будут решены оставшиеся проблемы, а не ждете их реального решения. Тем не менее подобные действия совсем не обязательно связаны с высокой степенью риска. Все зависит от того, насколько хорошо понятна суть этих проблем и насколько верны предположения относительно их решения. Рассмотрим для примера две команды. Команда А располагает длинным, но вполне понятным перечнем проблем, а команда Б – коротким, но малопонятным. Какая команда, по-вашему, скорее всего, уложится в назначенные сроки? Я бы отдал предпочтение команде А (в этом месте звучит гимн команды А). Здоровый скепсис подсказывает, что короткий перечень команды Б свидетельствует о том, что ею еще не выявлены все проблемы, связанные с техническими условиями. Что касается команды А, она уделила больше времени на осознание всех имеющихся у нее открытых проблем и лучше подготовлена к тем испытаниям, которые уготовил ей проект.

Рис. 7.1. Устранение пробелов, оставшихся при проектированиии составлении технических условий

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

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

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

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

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

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

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

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

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

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

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

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

СОВЕТ

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

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

Обсуждение документов и получение отзывов

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

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

Как проводить обсуждение технических условий

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

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

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

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

Кто должен присутствовать и как все должно происходить

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

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

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

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

Список вопросов

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

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

Вот мой перечень вопросов, пересмотр и дополнение которого только приветствуется.

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

• Где самые узкие места проекта? Каковы самые слабые компоненты или элементы интерфейса? Почему они не могут быть улучшены?

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

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

• Не лучше ли упростить замысел? Неужели нам на самом деле нужна такая сложность и функциональность? Какие у нас основания или веские аргументы против упрощения конструкции?

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

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

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

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

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

• Удалось ли нам добиться соответствия требованиям относительно доступности и локализации пользовательского интерфейса?

• Каковы угрозы безопасности данного проекта? Почему бы их не устранить? Задокументированы ли эти угрозы в технических условиях, включая потенциальные средства восстановления (например, есть ли модели угроз)?

• Располагаем ли мы достоверными доказательствами, свидетельствующими о том, что конкретные пользователи могут успешно работать с данным интерфейсом?

Выводы

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

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

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

• Составление технических условий в корне отличается от проектирования как такового.

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

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

• Проведение обсуждения – простейший способ определения уровня технических условий и контроля их качества.

Упражнения

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

2. Почему руководители проектов пытаются использовать технические условия для продуктов, которые не в состоянии создать? Какую проблему они пытаются (и не могут) решить?

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

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

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

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

7. Вам знаком какой-нибудь человек, увлеченный Visio, UML или другими инструментальными средствами? Есть ли у вас доказательства, что эта увлеченность приводит к созданию плохих технических условий? Сделайте для команды полезное дело: организуйте протест против применения Visio. Пригласите всех, кто пользуется его техническими условиями, соберите их подписи под петицией об ограничении использования документов, созданных с помощью Visio, и передайте эту петицию руководителю проекта. Приобщите к ней список, какие технические условия могут и не могут быть выполнены с помощью инструментальных средств.

8. Если вы знаете, что работа над техническими условиями завершится всего лишь через несколько дней, как можно убедиться в том, что оставшееся время используется эффективно? Можете ли вы предложить остальной части команды помочь вам в работе? Что можно сделать, чтобы максимально увеличить шансы на успешное обсуждение технических условий?

9. Представьте себе следующий сценарий: вы создали великолепные технические условия, с замечательными иллюстрациями, ясным изложением и полной документацией. Но вашим лучшим разработчикам они не понравились. Им не понравилось не только, как они написаны, но и идеи, которые в них представлены. До сдачи технических условий осталось только два дня. Что нужно сделать? Что можно сделать в следующий раз, чтобы предотвратить подобную ситуацию?

Глава 8. Как принимать хорошие решения

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

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

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

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

Любопытно, что при преподавании в университетах «искусства принятия решений» студенты обычно изучают методы теории полезности или анализируют дерево решений, когда вариантам выбора назначаются числовые значения, для которых выполняются вычисления (другим часто преподаваемым методом является анализ затрат и результатов). Подобные упражнения включаются во многие программы по совершенствованию управления бизнесом (Master of Business Administration, MBA^[46]). Однако принятию высокоуровневых решений и анализу других практических решений за пределами учебного класса внимания уделяется мало. Методы, подобные анализу дерева решений, требуют определения общего количества элементов, что неплохо срабатывает только для решений в области финансовой деятельности, но практически неприменимо в областях проектных, стратегических и организационных решений.

Неудивительно, что из всех опрошенных мною руководителей проектов очень немногие прошли формальное обучение принятию решений, а из тех, кто обучался этому, очень немногие считали, что полученные знания являются часто востребованными. Это курьезное наблюдение согласуется с тем, что написал Гэри Клейн (Gary Klein) в своей книге «Sources of Power: How People Make Decisions» (MIT Press, 1999): «…к курсам по формальным методам принятия решений нужно относиться скептически. На них преподаются методы, которые людьми используются крайне редко». В продолжение этой мысли Клейн объяснил множество различных путей принятия решений опытными пилотами, пожарными и травматологами, показав, насколько редко они на практике применяют вычитанные из учебников формальные методы. Это не означает, что подобные методы так уж плохи, только вот в учебниках довольно редко описываются свидетельства тех, кто их применяет, или доказательства их эффективности по сравнению с другими методами.

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

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

Оценка значимости решения (что поставлено на кон)

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

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

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

 Какая проблема является ключевой при принятии решения? Решения часто возникают на основе новой информации, а их первоначальные наметки базируются на самых острых и узких аспектах проблемы. Итак, первое, что нужно сделать – это провести исследование. Например, изначально проблема может быть определена так: «У нас не хватает времени на устранение всех 50-ти обнаруженных ошибок» – однако истинная суть проблемы, возможно, следующая: «У нас нет критериев для сортировки ошибок по степени их значимости». Переопределение сути проблемы и решения в более пригодную форму имеет большое влияние на качество решения. Спокойное отношение к кажущейся срочной проблеме способствует именно такому развитию событий. Задайтесь следующими вопросами: Чем вызвана проблема? Является она изолированной или будет оказывать влияние на другие области? Чья это проблема? В каких концептуальных целях не определен риск возникновения этой проблемы? Встречается ли нужное решение в технических условиях или концептуальных документах, и если да, имеются ли у нас достаточно веские основания для его пересмотра в данный момент?

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

 Какова цена ошибки? На какие решения будет в результате оказано влияние? При незначительном влиянии потери минимальны. Но это еще не означает, что можно принимать решения, подбрасывая монетку. Для таких аспектов проекта, как потребительские свойства и надежность, качество слагается из массы мелких решений, дополняющих друг друга. Крылатая фраза «смерть от тысячи вырезок»^[47] описывает именно такую ситуацию, в которой одна допущенная вами большая ошибка на самом деле складывается из массы более мелких. Поэтому вы должны, по крайней мере, подумать, является ли выбранное решение на самом деле изолированным от всего остального. Если это не так, лучше рассмотреть и принять сразу несколько решений. К примеру, либо следовать одним и тем же принципам использования пользовательского интерфейса на всех страницах, «перелопатив» весь программный код, в котором используется соответствующий набор API-функций, либо полностью их исключить. Проследите как можно дальше влияние каждого возможного решения.

 Каким является «окно благоприятных обстоятельств»? Затягивание принятия решения будет чревато последствиями; пути окажутся закрытыми, и вариантов не останется. Так уж сложилось в этом мире, что на принятие более важных решений не всегда отводится больше времени. Иногда приходится принимать жесткие стратегические решения быстро из-за того, что слишком сужено так называемое «окно благоприятных обстоятельств». А иногда скорость принятия решения куда важнее самого решения.^[48]

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

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

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

Поиск и оценка вариантов

В уже упоминавшейся книге «Sources of Power: How People Make Decisions» автор определяет два основных способа принятия решений: проведение исключительной и сравнительной оценок (табл. 8.1). При проведении исключительной оценки рассматривается и оценивается по определенным критериям первый же найденный вариант (хочется ли мне сегодня надеть эту зеленую рубашку?). Если он отвечает заданным критериям, то принимается в качестве решения, и человек, отвечающий за принятие решений, переходит к более важным проблемам. Если первый найденный вариант этим критериям не отвечает, рассматривается следующая идея или вариант, и процесс повторяется (а что, если все-таки надеть желтую рубашку?). Примером может послужить поиск туалета после выпитой литровой бутылки газировки или попытка найти местечко, где можно было бы перекусить после трехдневной голодовки. В этом случае вполне достаточно найти первый же попавшийся туалет или ресторан и в поиске еще одного подобного объекта смысла уже не будет.

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

Таблица 8.1. Два основных подхода к принятию решений

Проводить исключительную оценку имеет смысл в тех ситуациях, когда совсем неважно, каким именно должно быть решение, грандиозным или просто приемлемым. Автор относит такие ситуации к зоне безразличия, поскольку человек, принимающий решение, если соблюден основной оценочный критерий, относится к основным аспектам решения абсолютно безразлично. Способность определить момент, когда все возможные варианты находятся в зоне безразличия (рис. 8.1), поможет сэкономить в работе над проектом массу времени, позволяя свернуть дебаты и дискуссии на ранней стадии и сосредоточить усилия на сложных решениях, более достойных обдумывания. Хорошие специалисты по принятию решений не тратят время понапрасну на оптимизацию тех вещей, которые в этом не нуждаются. Как сказал Тайлер Дерден (Tyler Durden): «Не стоит уделять внимание тому, что не имеет значения».

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

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

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

Эмоции и ясность

Хотя эта тема и не столь популярна, но без эмоциональных и психологических проблем процесс принятия решений обойтись не может. Ритчард Ристак (Richard Restak), автор книги «The Secret Life of the Brain» (Joseph Henry Press, 2001), писал: «Ничто не обходится без эмоций». Осознаем мы это или нет, но нас постоянно преследуют опасения, желания и личные побуждения. Эмоциональный компонент присутствует даже в альтруистических побуждениях, вроде пожелания всего наилучшего для проекта или для работающих над ним людей.

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

Простой способ сравнения

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

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

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

Рис. 8.2. Список всех аргументов «за» и «против»

Предположительно, дата рождения списка аргументов «за» и «против» относится как минимум к 15-му веку, когда он начал использоваться в качестве средства улаживания дебатов. Затем, столетия спустя, Бенджамин Франклин применил эту методику для принятия собственных решений, поэтому ее популяризацию в США предписывают именно ему.^[49]

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

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

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

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

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

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

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

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

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

ПРИМЕЧАНИЕ

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

Обсуждение и оценка

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

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

Шерлок Холмс, бритва Оккама и размышления

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

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

Другим инструментом, помогающим сократить количество возможных вариантов, является принцип, известный как «бритва Оккама». Уильям Оккам был средневековым философом, жившим в 12 веке. Ему приписывают использование понятия простоты для управления решениями. Он верил, что людям свойственно излишне усложнять ситуацию. Он предложил считать лучшим способом осознания вещей поиск простейших объяснений, которые нужно использовать в первую очередь, поскольку, в большинстве случаев, такие объяснения бывают верными (то есть, выражаясь современным языком, чем проще, тем лучше).^[50]

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

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

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

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

Информированность – это путь к решению

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

Это относится не только к решениям – как правило, нам нравится получать доказательство каких-либо утверждений именно в числовой форме. Согласитесь, насколько полезнее и правдоподобнее звучит фраза: «Наша поисковая машина на 12 % медленнее обрабатывает запросы из трех слов», чем фраза: «Система работает медленно». Числовые данные придают процессу такую степень точности, которая недоступна простому человеческому языку. Более того, числовые данные зачастую требуются людям для поддержки их утверждений. Заявление: «Система работает медленно» – влечет за собой вопрос: «Как вы об этом узнали?» Недостаток в ответе специфических понятий или результатов исследований вызывает недоверие к заявлению или ставит его в исключительную зависимость от мнения или взглядов заявителя. Порой при наличии специфической информации можно ответить на важный вопрос или принять решение намного быстрее, чем при других обстоятельствах.

Данные не принимают решений

Главное заблуждение, связанное с информацией, заключается в утверждении, что данные иногда принимают решения за нас самих. Ценная информация играет роль фонарика, помогающего осветить окружающее пространство и позволяющего всем, кто в него пристально вглядывается, разглядеть ранее невидимые детали и границы. Если важные для вас утверждения еще не подкреплены соответствующими данными, то время, потраченное на получение информации, окупится ускорением процесса принятия решения. Туман рассеется и ситуация прояснится. Но со временем эта компенсация затраченного времени сходит «на нет». Как только упадет первый луч света, который покажет основные детали, никакая дополнительная информация не сможет изменить природу обнаруженного. Если вы сели на мель посредине Тихого океана, то сведения о температуре воды или подвидах местной рыбы не окажут существенного влияния на ваши решения по спасению собственной жизни (хотя на них могут оказать влияние сведения о направлении течений, маршрутах движения торговых кораблей и созвездиях). Для большинства трудных решений проблема заключается не в дефиците данных. Эти решения существуют во вселенной независимо от того, каким объемом информации вы располагаете. Феномен аналитического ступора, при котором люди одержимы идеей анализа, является симптомом безрассудной веры в то, что при наличии достаточного объема данных решение придет само собой. К сожалению, это далеко не так. Осведомленность помогает лишь до поры до времени.

Данные легко истолковать неправильно

Второе заблуждение, касающееся данных, состоит в том, что все они добываются сходным образом. Но оказывается, что при работе с числами неверно истолковать информацию совсем не трудно. Как писал Даррел Хаф (Darrell Huff) в своей книге «How to Lie with Statistics» (W. W. Norton, 1993): «Секретный язык статистики, столь привлекательный для склонной к фактам культуры человеческого мышления, используется для порождения сенсаций, раздувания фактов, их запутывания и упрощения». Хаф показывает множество простых способов манипуляции одними и теми же данными для получения совершенно противоположных аргументов. Его советы повсеместно должны лечь в основу подготовки всех, кто принимает решения. Большинство трюков строится на пропуске важных деталей или на подтасовке информации, которая ложится в основу нужного утверждения.

К примеру, в рекламе популярного спортивного напитка утверждается, что «его употребляют пять из шести суперзвезд». Звучит впечатляюще, но кто из суперзвезд его употребляет? Чем именно звезды отличаются от суперзвезд? Кем бы они ни были, как именно они были выбраны для опроса? Как именно они употребляют этот напиток? Может, они моют им свои машины? Платили ли им заранее? А не исключались ли они из опроса, когда прекращали употреблять напиток? Кто знает. Реклама об этом умалчивает. Если вы повнимательнее приглядитесь ко всем видам информации, от результатов медицинских исследований до деловой аналитики и тенденций развития технологий, то обнаружите, что в великолепном обрамлении припрятана или вовсе не упомянута масса всевозможных удивительных предположений и предостережений. Многие опросы или отчеты об исследованиях напрямую финансируются людьми, которые извлекают немалую выгоду из вполне конкретных результатов. Хуже того, во многих случаях соответствующие статьи в журналах и газетах пишутся людьми, не имеющими никакого отношения к исследовательским работам, из которых мы черпаем нужную информацию, а объективность и понимание этими людьми сути научных исследований зачастую оставляют желать лучшего.

Исследования в качестве аргументов

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

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

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

Точность не значит достоверность

Как и в последнем замечании об информации и данных, многие из нас забывают, в чем различие между точностью и достоверностью. Точность характеризует качество отдельного измерения, а достоверность показывает, насколько близко к реальности оказалось это измерение. То, что нам просто предлагают точное число (скажем, работа займет 5,273 дня), еще не означает, что оно окажется достовернее неточного числа (4 или 5 дней). Мы склонны путать точность и достоверность, поскольку допускаем, что если кто-то потратил время на вычисление столь конкретного числа, анализ лишь повысит шансы на то, что его расчеты верны. Загвоздка в том, что фиктивная точность ничего не стоит. Если я возьму с потолка данные, что прибыль в следующем году составит 5,5 миллиона долларов, и таким же способом выведу сумму затрат в том же году (2,35 миллиона долларов), я могу объединить эти догадки и выдать вполне убедительный прогноз на чистую прибыль в 3,15 миллиона долларов. Точная цифра? Конечно. Достоверная? Кто знает. Не задав вопроса: «Откуда вы это узнали?» или «Как были получены эти данные?» невозможно убедиться в том, что именно отражают эти десятичные знаки, достоверность или всего лишь точность. Заведите себе привычку безжалостно искоренять склонность других за счет точности пускать вам пыль в глаза.

Мужество решений

Путь знают все, но лишь немногие в действительности идут этим путем.

Бодхидхарма

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

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

Некоторые решения не дают выигрышных вариантов

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

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

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

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

В данной конкретной ситуации с IE4 я выбрал бездействие. После бессонной ночи я решил, что лучше буду противостоять шумихе в печати, случись таковая (что отнимет время у меня, а не у программистов), а не страховаться от того, что еще не случилось. Я был не в восторге от этого, но чувствовал, что для проекта это решение было наилучшим. Команда еще раньше согласилась, что я приму решение единолично, так что мы сразу же двинулись дальше.^[51]

Хорошие решения могут давать плохие результаты

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

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

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

Внимательность и умение оглянуться назад

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

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

У медиков есть тоже нечто подобное под названием совещания по заболеваемости и смертности (Morbidity and Mortality session, M&M) и проводящееся обычно только при фатальном исходе или применении какого-нибудь оригинального или сложного лечения.

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

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

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

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

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

 Помогло ли решение продвижению проекта? Иногда принятие плохого решения все же способствует продвижению проекта. Решение мобилизует людей. Быстрое принятие решения о движении на Восток и изменение перспективы могут привести к абсолютной ясности, что фактически верным является направление на Север. Но пока команда только готовится к движению на Восток, она может этого не обнаружить. Оглядываясь назад, выясните, почему первоначальное решение имело успех: благодаря правильной постановке задачи или потому, что было принято в нужный момент?

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

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

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

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

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

Выводы

• Следует придать важность искусству принятия метарешений, то есть решений о том, каким решениям следует уделять время.

• Оцените решения, прежде чем тратить на них слишком много времени.

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

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

• Признаем мы это или нет, но всем решениям присуща эмоциональная компонента.

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

• Информация и данные не способны принимать решения за вас.

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

Упражнения

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

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

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

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

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

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

7. С кем в вашей жизни вы проводите разбор самых важных жизненных решений? Почему вы выбрали их для этой важной роли? Составьте список людей, с которыми вместе работаете, и список всех «за» и «против» их ценности для вас при рассмотрении ранее принимавшихся решений.

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

Глава 9. Общение и взаимоотношения

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

Эта библейская история предельно коротка и занимает всего лишь одну страницу. Тем не менее на протяжении веков она привлекает внимание многих художников и писателей, которые используют ее для исследования современных проблем. Красочные картины с изображением Вавилонской башни кисти Брюгеля^[52] (Brueghel) и других художников придали этой истории гипертрофированное влияние на инженерные и управленческие задачи тех времен. Толкование самой истории, как и вид башни, с веками менялись, но суть оставалась прежней. Одни полагали, что эта история является предостережением от людской гордыни и напоминанием о том, что некоторые вещи должны быть для нас недосягаемы. Другие же видели в ней людей, стремящихся достичь вершин своих способностей, раздвинуть границы возможного. Но для меня и для этой главы основной урок вавилонской истории довольно прост: если вы не умеете общаться, вы ни в чем не сможете преуспеть.

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

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

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

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

Управление посредством общения

Возможно, это звучит странно, но мне понадобилось немало времени, чтобы понять, какое значение имеют разговоры с людьми на их рабочих местах. Я постоянно болтал и шутил, но не считал общение на рабочем месте реальной работой. Мой жизненный опыт вселил в меня веру в то, что я должен решать все свои проблемы самостоятельно. В первый год службы в компании Microsoft я редко просил других высказывать их мнение или искал помощи у кого-нибудь, кто обладал более широкими познаниями. Я тихо переживал эту ситуацию и больше брал усидчивостью, чем головой. В то же время мне доводилось замечать, что оба моих первых руководителя Кен Дай (Ken Dye) и Джо Бельфиор (Joe Belfiore) вели себя как-то странно и проводили массу времени в разговорах с другими людьми. Я часто видел их сидящими в офисах разных людей и непринужденно болтающими. При моей занятости я удивлялся, как они позволяли себе тратить столько времени на болтовню. Будучи новичком, я не задавал вопросов, а просто навесил на них ярлык «экстравертов», который по тем временам я считал чуть ли не оскорбительным. Меня раздражало их поведение (когда же они, наконец, начнут работать, по крайней мере, не менее напряженно, чем я?), и я не видел в их времяпрепровождении никакого толку. Как же я тогда ошибался.

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

Рис. 9.1. Свидетельство того, что программисты не столь одиноки, как мы думаем

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

Взаимоотношения улучшают общение

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

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

В классическом труде Тома Петерса (Tom Peters) и Нэнси Остин (Nancy Austin) «A Passion for Excellence» (Warner Business Books, 1985) подобный стиль поведения назван руководством методом обхода (Management by Walking Around, MBWA). Он описан как основное качество удачливых руководителей, за которыми они наблюдали (методу MBWA посвящена целая глава их книги). Но правильно следовать этому стилю не так-то просто. Они рекомендуют выбрать для себя небольшую группу людей, у которых в команде разные роли и задачи, и заняться выстраиванием с ними неформальных взаимоотношений.^[53] Но еще важнее, что от вас потребуется понимание механизма здорового общения и хороших взаимоотношений, а также стремление к постоянному совершенствованию своих навыков в этом деле. Даже если вы не станете придерживаться для выстраивания взаимоотношений подходов MBWA, навыки общения и построения межличностных отношений пригодятся в любом деле.

Базовая модель общения

Лишь немногие действительно умеют в рабочей обстановке диагностировать проблемы общения или взаимоотношений либо обладают необходимыми полномочиями для их улаживания. Тем не менее совсем нетрудно, с точки зрения руководства проектом, изучить простую систему взглядов на то, чему служат задачи общения, и применять эти знания в повседневной практике. С такими познаниями вы сможете вовремя остановиться в случае неудачи и лучше адаптируетесь к решению проблем, поскольку станете лучше понимать, что именно не срабатывает. Вот что говорит Джон Брадшоу (John Bradshaw):

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

В простейшей из известных мне моделей содержится пять основных уровней, которых нужно достичь при любом сеансе общения.^[54] Они располагаются в порядке возрастания важности и трудности достижения. Общение становится успешным лишь при достижении третьего уровня (усвоение), а то и четвертого (согласия) или пятого (действие). Чтобы проиллюстрировать каждый из уровней, я использую пример из фильма «Космическая одиссея 2001 года»: астронавт Дэйв находится в маленькой космической шлюпке и хочет вернуться на базовый корабль. Электронный Хал – единственный, кто может открыть створки базового корабля, чтобы впустить его вовнутрь.

 Передача. Когда вы посылаете сообщение по электронной или голосовой почте, вы передаете кому-то порцию информации. Это не означает, что получатель прочитал или услышал данное сообщение, это означает лишь то, что сообщение ушло от вас и вы стремились к тому, чтобы оно попало к адресату. Используя электронную почту и Интернет, отправлять информацию совсем не трудно, но нет никакой гарантии, что кто-нибудь когда-нибудь соберется ее прочесть. В нашем примере Дэйв говорит: «Хал, ты читаешь мое сообщение?» (А в ответ – тишина.)

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

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

 Согласие. Понимание еще не означает согласия. Я могу полностью понимать каждый аспект требования, поступившего от руководителя за день до выпуска финальной версии продукта, согласно которому нужно создать Linux-порт для нашей программы видеоредактора, предназначенной исключительно для компьютеров семейства Mac. Однако в этом понимании никоим образом не отражается то, насколько безумной мне представляется сама идея. Достижение согласия между двумя умными, но крайне упрямыми людьми может стать трудным и довольно продолжительным делом, особенно если возражения не находят явного выражения. Несмотря на сложность этого процесса, согласие является основой для принятия решений, влияющих на работу всей команды.^[55] Дэйв говорит: «О чем ты говоришь Хал?», а Хал отвечает: «Эта миссия слишком важна для меня, чтобы позволить вам подвергать ее опасности». Дэйв не может получить согласия Хала, и дверь остается закрытой.

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

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

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

Наиболее распространенные проблемы общения

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

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

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

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

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

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

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

 Персональные нападки. Ситуации переходят на личности, когда одна из сторон уводит дискуссию в сторону от спорного вопроса и направляет ее на личные отношения. К примеру, Фред мог бы сказать: «Я сейчас занят», а Сэм ответить: «Вечно с тобой проблемы. Почему у тебя никогда нет времени на то, чтобы рассмотреть планы тестирования?» Это несправедливо по отношению к Фреду, поскольку он вынужден защищать не столько собственное мнение, сколько собственное поведение. Персональные нападки носят характер преднамеренной грубости.^[56] Часто человек, допускающий грубость, чувствует свою уязвимость и видит в них единственное средство, с помощью которого можно выиграть спор. Помешать этому и отделить проблемы друг от друга сможет тот, кто мудрее (или, возможно, сам Фред).

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

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

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

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

Успех проекта зависит от взаимоотношений

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

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

Распределение ролей

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

Стивен Ковей (Stephen Covey). The 7 Habits of Highly Effective People

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

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

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

Рис. 9.2. Дискуссии относительно распределения ролей помогают наладить взаимоотношения (это всего лишь пример, ваши списки могут отличаться от этих)

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

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

Улучшение отношения к работе

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

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

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

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

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

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

Иногда, задавая людям вопрос о том, как добиться от них наилучшей отдачи, вы можете получить ответ: «Оставьте меня в покое», «Не задавайте мне глупые вопросы» или другой не менее содержательный ответ. Но даже если вам показалось, что человек не пошел с вами на контакт, он все равно задумается над вашим вопросом. У меня были программисты, игнорировавшие мой первоначальный вопрос («Нет, Скотт, ты мне ничем не поможешь»), а затем, через неделю, возвращавшиеся ко мне с серьезными предложениями, направленными на помощь всей команде разработчиков. Вдобавок ко всему, они еще благодарили меня за то, что я прислушиваюсь к их мнению.

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

Как заставить людей работать лучше

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

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

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

 Предъявляйте (или не предъявляйте) требования. Для человека, обладающего властью, самый очевидный способ заставить людей работать – предъявить требование («Упал, отжался!»). Чем умнее люди, с которыми вы работаете, тем меньше вероятность, что такой подход сработает. Если есть хорошая концепция, интересная работа и люди справляются с делом, то необходимости предъявлять какие-то требования практически не возникает. Мотивация появляется естественным образом. Когда нужно закрутить гайки, следует подыскать способ поумнее. Заключите приятельское соглашение: «Если мы успеем в срок, я выкрашу голову в синий цвет» или «Та команда программистов, которая первой устранит все ошибки, получит вечернее барбекю на моей яхте».^[58] Требования имеют право на существование, но не проявляйте недоброжелательности, будьте честным. «Послушайте, это надо сделать. Обсуждать это уже поздно, я прошу прощения, если не объяснил этого раньше. Пожалуйста, просто сделайте это для меня, хорошо?»

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

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

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

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

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

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

Мотивация

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

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

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

• Повышает качество создаваемого продукта.

• Увеличивает шансы на своевременное завершение работы над проектом.

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

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

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

• Позволяет упростить поддержку разработки.

• Повышает настроение или создает ощущение подъема у членов команды.

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

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

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

Выводы

• Осуществление проекта невозможно без общения. В наше время общению препятствует не скорость, а качество.

• Хорошие взаимоотношения улучшают и ускоряют общение.

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

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

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

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

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

Упражнения

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

2. Вам стало известно, что ваш проект зависит от успешного завершения Проекта X. В свою очередь, этот проект отложен, а его команда перенацелена на Проект Y, который вас совершенно не интересует. Составьте просьбу в адрес спонсора Проекта X, чтобы убедить его продолжить работу над проектом.

3. Вы руководите проектом с высокой степенью риска. За несколько последних отчетных периодов вы включали в отчет график, показывающий истощение бюджета проекта. Вы даже привлекали внимание к этой проблеме на регулярных селекторных совещаниях, но спонсор проекта никак на это не отреагировал. За неделю до исчерпания средств вы вышли напрямую на спонсора и спросили его, когда можно ждать дополнительных средств. Спонсор изобразил недоумение и спросил, почему он не знал об этом раньше. Как более эффективно можно было бы довести до него складывающуюся ситуацию и призвать к действию?

4. Ваш менеджер прерывает очередное совещание, чтобы сообщить, что вашей команде следует отказаться от текущей конструкции и заняться другой. При этом он рассказывает о решении, увиденном на телевизионном шоу. Согласно вашему пониманию требований спонсора проекта, вы уверены, что текущая конструкция лучше предлагаемой и не менее рентабельна. Каким образом вы смогли бы убедить менеджера отменить сделанное заявление?

5. В следующий раз, когда вы станете спорить с другом, с недругом или с сотрудником, прежде чем говорить, подумайте о пятиступенчатой модели общения. Вы понимаете, о чем они говорят? Делаете ли вы паузу, чтобы убедиться, что они поняли то, что вы им сказали? Запишите на листке бумаги эти пять ступеней и держите их в поле зрения.

6. В середине проекта вы узнаете, что команда отстает от календарного плана. Вам также становится известно, что ведущий программист дружит с заказчиком проекта и рассматривает распоряжения о внесении изменений после работы, в соседнем кафе. Этот программист оказывает влияние на команду разработчиков, а заказчик – на вашего начальника. Что бы вы предприняли в подобной ситуации?

7. Составьте два упорядоченных списка, в один из которых внесите всех важных специалистов вашей команды, а в другой – всех тех, с кем у вас складываются самые хорошие взаимоотношения. Посмотрите на два этих списка и определите возможности для улучшения взаимоотношений: если бы удалось их улучшить на 25 %, то с кем именно это нужно было бы сделать, чтобы максимально повлиять на ход проекта?

8. Создайте плакат из списка наиболее острых проблем общения и прикрепите его на стену конференц-зала команды. Призовите команду воспользоваться этим плакатом, чтобы определить, когда общение выходит за рамки нормального.

9. Когда вам приходит в голову мысль, что нужно работать с полной отдачей? Может ли кто-нибудь другой вдохновить вас на это или вам нужна своя внутренняя мотивация? Что из всего этого говорит вам о том, как заставить других людей работать с полной отдачей?

Глава 10. Как не раздражать людей на работе, в ходе электронной переписки, на совещаниях

Бюрократия (сущ.) – административная система, в которой потребность или склонность к следованию жестким или сложным процедурам мешает эффективной работе.

Чем многочисленнее команда, тем выше шансы, что ваша деятельность на посту руководителя проекта будет кого-то раздражать. Как только вы приступаете к проверке чьей-то работы или принимаете решение, касающееся других людей, вы неизбежно становитесь потенциальным источником раздражения. Если у вас хватает сообразительности, вы будете искать способы действий, не раздражающие работающих с вами людей. Люди повеселеют, работа над проектом пойдет лучше, и вы реже станете чувствовать на себе косые взгляды, проходя по коридору.

Наиболее раздражительны для людей три вида деятельности: общение по электронной почте, проведение собраний и коллективная работа (например, разработка продукта или выработка технических условий). В этой главе рассматриваются элементарные ошибки и ключевые подходы к осуществлению этих видов деятельности с минимальным фактором риска раздражения (Minimal Annoyance Risk Factor, MARF).

Почему люди раздражаются

Поскольку мне не удалось найти печатного источника на тему людской раздражительности, в своих обобщениях я полагаюсь на собственные наблюдения. У меня достаточно опыта в этой области: я сам многократно испытывал раздражение, наблюдал за людьми, находящимися в этом состоянии, а бывало, и сам своим поведением вызывал раздражение у других людей.

Чтобы усилить эффект восприятия, все примеры изложены от первого лица (это должно помочь вам представить перед собой конкретного человека, с которым вы имели удовольствие работать вместе).

 Не считайте меня идиотом. Если меня наняли, чтобы я выполнил работу X, которая мне вполне по плечу, то я, естественно, буду испытывать раздражение, если кто-то усомнится в моих возможностях справиться с этой работой или заявит, что мне для этого понадобится 20-ступенчатая методика, свод правил, технологическая карта, ежедневная оценка проделанной работы, чей-то постоянный надзор или что-нибудь еще. Определить, что ход работы удовлетворяет любым объективным руководящим установкам можно по той ее части, которая уже сделана. Но пока я не допускаю промашек и не проявляю некомпетентности, сомнений в моих способностях быть не должно. Мне, в пределах разумного, нужно дать свободу выбора лучших способов выполнения работы.

 Доверяйте мне. Меня будет раздражать ежедневное ожидание двойных или тройных проверок и необходимость отчитываться за все решения, находящиеся в пределах моей компетенции. Если мне нужно все согласовывать, то каковы мои реальные полномочия? Почему все нужно документировать и учитывать, если я вполне справляюсь с работой? Даже если поначалу я почему-то не внушаю доверия, руководители должны предоставить мне реальную возможность его завоевать и помочь мне в этом.

 Не тратьте мое время попусту. Меня будет раздражать, если работа в команде потребует от меня выполнять многократно повторяющиеся (рутинные) задания или трудиться на износ из-за каких-нибудь непредвиденных обстоятельств или совершенно необоснованной паранойи руководства. Сюда относятся колебания в принятии важных решений или крайняя непоследовательность в словах и поступках без каких-либо попыток объяснить происходящее (или хотя бы извиниться), даже если об этом просят.

 Не распоряжайтесь мною без должного уважения. Меня будет раздражать, если меня без всяких на то оснований когда-либо заставят заниматься не свойственными мне задачами или подставят и возложат на меня всю вину за то, что лежит вне сферы моей ответственности. Кто-то должен меня курировать, следить за тем, чтобы мои усилия направлялись в рамки проекта, и вести меня к успеху. Поэтому к моим просьбам о помощи нужно относиться серьезно, не игнорируя их и не откладывая в долгий ящик.

 Не заставляйте меня слушать или читать всякие глупости. Меня будет раздражать требование кого-то выслушивать или читать что-то кем-то написанное, не имеющее никакого значения для работы. У нас же есть шкала сортировки ошибок, почему нет такой же для отсеивания глупостей? Тот факт, что кто-то созывает совещание, пишет бумагу или отсылает сообщение по электронной почте, еще не означает, что на это стоит тратить мое время. Чем больше меня будут просить (или заставлять) заниматься второстепенными или третьестепенными вещами, тем менее продуктивно и охотно я буду работать.

Большинство из приведенных причин раздражительности объясняют, почему многие люди не любят саму идею контроля производственного процесса. Они опасаются, что любая попытка систематизировать их работу приведет лишь к бюрократии и другим вредным проявлениям. Я считаю, что это необоснованное опасение. Люди разрабатывают производственные процессы почти так же, как и все остальное, и если проектировщик не глуп и преследует верные цели, его разработки могут стать полезными для всех. Производственный процесс может помочь людям, не ограничивая их возможностей и не вызывая раздражения.

Положительное влияние хорошо организованного производственного процесса

Я могу охарактеризовать производственный процесс как повторяющийся набор тех или иных действий, которого команда решает придерживаться для соблюдения определенных подходов к созданию каких-нибудь изделий. Производственные процессы проходят под многими названиями: правила, нормы, формы, процедуры или ограничения. (Наиболее типичными примерами производственных процессов являются создание, тестирование и сдача программного кода. Другие примеры включают составление технических условий, управление календарными планами и графиками работ и т. д.) Хорошо организованный производственный процесс повышает шансы на завершение проекта и приносит выгоду, превышающую затрачиваемые на него средства. Тем не менее, поскольку время редко тратится в соответствии с предназначением конкретного процесса или в соответствии с решаемыми (или требующими решения) проблемами, многие команды выполняют сразу несколько производственных процессов, лишаясь тех преимуществ, которые можно было бы получить.

Иногда проблема кроется в том, кто стоит у власти. Любой недоумок, облеченный полномочиями, может придумать совершенно идиотскую систему организации труда и попытаться заставить следовать ей всю команду. А затем, когда вдруг окажется, что команда смогла не только пережить этот процесс, но и что-нибудь выдать в качестве результата, вождь может даже выставить сам процесс как ключ к успеху (не замечая того факта, что команда добилась успеха вопреки бездарной организации процесса). Сосредоточив в своих руках достаточно власти, такие руководители способны подавить любые мятежи, продолжая мучить команду постоянными нововведениями.

Иногда проблема кроется в следующем философском подходе: «Этот процесс срабатывал раньше, сработает и теперь». В такой ситуации руководитель команды, добившийся в прошлом неких результатов определенным способом, настаивает на применении испробованного метода или процесса в работе каждой новой возглавляемой им команды (об этой пагубной привычке в руководстве я уже упоминал в главе 8). Вред здесь в том, что повторить предыдущий успех можно лишь при полном совпадении текущей ситуации с предыдущей. При реальной оценке пригодности процесса с оглядкой на прошлое нужно придавать особое значение потребностям настоящего.

Однако в большинстве случаев проблема кроется в сложности, сопутствующей организации производственных процессов. Производственный процесс является попыткой организовать работу людей и установить порядок их взаимодействия, то есть касается двух наиболее важных и тесно связанных элементов. У людей разный стиль работы. У них разные предпочтения и степень терпимости к формальному контролю. Если организатор процесса не проявит должной осмотрительности, сам процесс легко может стать камнем преткновения, мешающим людям и ущемляющим их свободу и полномочия.

Секрет организации хорошего технологического процесса состоит в понимании сочетания двух вещей: что вообще приносит успех проекту и команде и в чем уникальность данного проекта и команды (рис. 10.1). Здесь недостаточно знать как, скажем, вообще принимаются верные командные решения: нужно учесть производственную культуру, индивидуальные особенности и привычки той команды, с которой вы работаете. Иногда культура или проект требуют различных подходов (например, процессы тестирования встроенных систем антиблокировки тормозов по сравнению с процессами тестирования, посвященного панк-рок-бэнду веб-сайта для Стива). Вместо того чтобы регламентировать все сверху, зачастую лучше позволить команде самой устанавливать правила. Вместо многократного использования избитого шаблона, дайте им возможность внести нужные изменения и создать собственный вариант. В организации производственного процесса много общего с ведением любого вида переговоров (см. главу 11) – нужно ясно представлять себе преследуемые цели, а не отстаивать определенную позицию.

Рис. 10.1. Хорошо организованному процессу требуется не только ориентация на проекты вообще, но и учет уникальных особенностей текущего проекта

Чтобы помочь вам найти и распознать хорошо организованные производственные процессы, я предлагаю перечень их признаков и эффектов, оказываемых ими на проект. Этот список можно использовать в качестве контрольного, когда вы усядетесь за создание или совершенствование положений производственного процесса.

 Ускорение продвижения проекта. Вопреки интуитивному предубеждению, хорошо организованный порядок действий не снижает, а повышает производительность труда. Например, вспомним белые разделительные полосы на автострадах. Благодаря тому, что они устанавливают одни и те же ограничения для всех участников движения, отдельные водители могут ездить очень быстро. Хорошо организованный процесс предоставляет систему, от которой люди могут зависеть и строить на ее основе свои решения. В некоторых случаях процесс распределяет исполняемые роли, Стиву становится проще получить то, что нам нужно, от Молли (например, найти кого-то для просмотра программного кода). Каноническим примером могут послужить автоматизированные инструментальные средства, позволяющие людям реализовывать проекты несколькими нажатиями клавиш, если они следуют необходимым определенным в инструментальной системе соглашениям по созданию программного кода.

 Предотвращение проблем. Наиболее распространенной мотивацией внедрения производственного процесса является предотвращение проявлений (или повторений) некоторых разновидностей глупости. Трудность в том, что это нужно сделать без усложнения процесса и без создания благоприятных условий для какой-нибудь новой глупости. Для этого нужно понимать причины возникновения проблем и наиболее важные факторы, обеспечивающие прогресс. Задайте вопрос: «Каков наименее навязчивый, наименее раздражающий и наименее затратный способ никогда не повторять больше ошибок X, Y и Z?» Или подойдите с другой стороны: «Какую проблему процесс может предотвратить? Насколько серьезна или реальна эта проблема?» Если процесс не препятствует возникновению проблем или не способствует прогрессу, то от него лучше отказаться (см. следующий раздел).

 Наглядность и возможность оценки важных действий. Процессы выявления ошибок или выпуска технических условий облегчают отслеживание частоты подобных действий. Можно отслеживать их состояние, результаты и тенденции в работе всей команды. Что касается ошибок, технических условий и тестов, хорошо продуманный процесс упростит определение состояния проекта. Это играет важную роль для выработки стратегии в промежуточной и авершающей стадиях проекта (см. главы 14 и 15).

 Наличие встроенного процесса для изменения или упразднения главного процесса. Поскольку в проектах все время что-то меняется, процесс, который был полезен или необходим в этом месяце, может утратить свое значение в следующем. В самом процессе должен быть встроенный механизм, позволяющий решать, когда его нужно обновить или прекратить. Никогда не нужно брать в расчет, что процесс будет идти всегда, поэтому избегайте определять чьи-либо задачи на его основе. Кто-нибудь, кто определяет свою работу как «я тот самый парень, который гоняет пятый тест», будет стремиться грудью стать на защиту теста номер пять и бояться любых касающихся его изменений. А это плохо. Лучше назначьте людей ответственными за те последствия и результаты, которые процесс приносит проекту.

 Польза для людей, вовлекаемых в процесс. Людям нравятся полезные процессы. Хорошо организованный процесс станет желанным для всех, кто в нем нуждается. Если вы предлагаете внедрить новый процесс, затрагивающий работу программистов, и этот процесс будет полезным для проекта, то уговорить их попробовать его в деле окажется совсем не трудно. Люди естественным образом должны быть вовлечены в придумывание новых процессов. Ну а если вовлекаемые в предлагаемый процесс люди смогут привести массу доводов против него, то, возможно, они правы.

Формула хорошего процесса

При продумывании процесса нужно сопоставить ценность от привносимых им положительных эффектов и стоимость его внедрения и выполнения. Существует и формула, которая поможет это сделать. Чтобы извлечь пользу из этой формулы, вам не понадобятся реальные числа. Я предлагаю ее лишь в качестве упражнения, помогающего задуматься о соотношении достоинств и недостатков дополнительных технологических процессов. Если вам не нравятся упражнения или формулы, перейдите к следующему разделу – канву повествования вы не потеряете.

Сначала рассмотрим стоимость процесса: время на выработку замысла процесса (DT), время на его освоение командой (LT), фактическое время выполнения работы при применении процесса, помноженное на частоту его применения (AT x N). Полная стоимость любого процесса равна:

DT + LT + (AT x N).

Теперь рассмотрим суммарную выгоду, получаемую от процесса: стоимость провалов, которых процесс позволит избежать (FC), помноженную на показатель вероятности возникновения этих провалов (FP) без внедрения процесса в пределах определенных временных единиц, и все это помноженное на количество таких временных единиц в проекте (T). Полная суммарная выгода равна

(FC x FP) x T.

Таким образом, ценность процесса приблизительно равна:

((FC x FP) x T) – (DT + LT + (AT x N)).

Я полностью согласен с тем, что в этой формуле имеются грубые допущения, но сам ее смысл не может вас не заинтересовать. Чем больше полученное в результате число, тем ценнее процесс. Отрицательное число будет означать, что суммарные выгоды от процесса перевешены затратами на него.

В первую очередь эта формула предполагает, что создать процесс, который эффективно устраняет проблему, совсем не трудно. Но этот процесс может стоить дороже, чем весь угрожаемый период, связанный с этой конкретной проблемой (например, покупка за 5000 долларов системы сигнализации для защиты коробки печенья). Если вы, взяв в расчет время на выработку замысла процесса и время на его освоение командой, обнаруживаете, что добились лишь снижения вероятности провала, соотношение потерь и выгод работает против изменения процесса.

Кроме этого, вам следует оценить время действия выгод: зачастую оно может превышать время работы над отдельным проектом. Что еще более важно, вероятность провала в некоторых следующих проектах может возрасти до 100 %. Значение T имеет для формулы весьма важное значение: даже если вероятность провала (FP) низка, то чем продолжительнее временной интервал, тем больше шансов возникновения провала и тем больше возрастает ценность процесса, который его предотвращает. (Тем самым раскрывается еще одна основная сложность роли лидера: нужно решать, когда нести существенные краткосрочные затраты в расчете на менее существенную, но долгосрочную компенсацию. Она проявляется повсеместно: при найме работников, закупке оборудования и аппаратуры, обучении сотрудников и т. д. Что посеешь, то и пожнешь. Долгосрочные инвестиции являются единственным способом получения долгосрочных же улучшений.)

И последнее замечание по формуле: значение AT (фактическое время выполнения работы при применении процесса) намного важнее, чем это может показаться на первый взгляд. Удачный процесс может сократить время работы: если на самом деле происходит экономия времени, то при сравнении AT со временем, затрачиваемым на работу без применения процесса, будет получаться отрицательное число. В соответствии с формулой это изменит соотношение выгод и потерь. Например, если AT = 5 часов, но ранее на выполнение работы требовалось 7, то разница составит 2 часа. То есть на выполнение работы теперь понадобится на 2 часа меньше, и итоговая ценность процедуры значительно возрастет.

Как создавать и запускать процессы

Когда вы определяете суть проблемы, которая, по вашему мнению, может быть решена с помощью внедрения процесса, следуйте приблизительной процедуре, описанной в главе 11. (Даже в отсутствие кризисной ситуации все будет похоже на основную процедуру выполнения краткосрочного плана.) Дайте четкое определение проблемы, которую пытаетесь решить, и выделите небольшую группу людей, которые смогут с ней справиться лучше других. Работайте по принципу маленькой группы, вырабатывающей альтернативные предложения и затем выбирающей из них самые перспективные.

Затем выделите изолированную, наименее рискованную часть проекта, чтобы испробовать новый процесс на ней. Если получится, подберите людей, задействованных в процессе и готовых к его изменению, и привлеките их к созданию процесса. Согласуйте, какие желаемые эффекты будет иметь измененный процесс и, по возможности, установите для них систему оценки. Далее устройте все так, чтобы изменения были внесены вовлеченными в создание процесса людьми. Назначьте предстоящую дату оценки степени эффективности изменений процесса.

Как только наступит день оценки, соберите снова небольшую группу людей, включая тех, кто привлекался к эксперименту. Обсудите все, что произошло. Если эксперимент провалился, повторите процесс и проведите второй небольшой эксперимент. А если все получилось удачно, пересмотрите процесс, основываясь на том, что вы о нем узнали, и запустите его для более многочисленной группы (возможно, и для всей команды). Всем, кого вы попросили стать участником процесса, должно быть понятно, какие проблемы вы пытаетесь решить с его помощью и почему вы убеждены, что предложенное решение действительно поможет (в этом в значительной степени вам должны помочь свидетельства и характеристики, полученные от людей, вовлекавшихся в эксперимент).

Управление процессом снизу

Никогда не нужно недооценивать влияние недоумков в больших группах.

Тодд Бланчард (Todd Blanchard)

Иногда люди, имеющие более высокое влияние в организации, инициируют в команде процесс, с которым вы не согласны. Вы можете просто остаться в меньшинстве или не иметь достаточных полномочий для пересмотра процесса. Такое случается даже с лучшими из нас. Я знаю три способа, как справиться с этой ситуацией. Правда, они не всегда срабатывают, но ими все же стоит воспользоваться.

 Прикройте свою команду от процесса. Иногда можно поглотить процесс, навязанный команде. Если требуется некая бумажная работа, выполните ее самостоятельно. При этом можно почувствовать, что вы работаете секретарем у команды, но если единственная цена вопроса – потерянный вами, но не командой день, значит, овчинка стоит выделки. В определенных случаях вы сможете набрать в глазах команды довольно много очков доверия, защищая ее от глупых занятий. Ведение карт хронометража, отчеты о расходах, обязательные (но бестолковые) многочасовые совещания, изъятие оборудования на профилактику и другие раздражающие пустяки – типичные примеры процессов, от которых можно легко защититься.

 Докажите, что в процессе нет необходимости. Сплотите команду вокруг встречного предложения. Узнайте, что именно процесс пытается предотвратить или обеспечить, и гарантируйте влиятельным персонам, что ваша команда добьется того же самого и без процесса. Установите оценочный период времени. Если по его истечении команда потерпит неудачу, вам придется согласиться с процессом. Но, если все пройдет удачно, вы снимете процесс с повестки дня. Если не останется ничего другого, сфокусируйте обсуждение процесса на правильных вопросах (какие проблемы мы пытаемся решить?), тогда, даже если вы потерпите провал, то хотя бы улучшите сам процесс. (В редких случаях исследование положение дел в аналогичных и успешно работающих организациях, которые не занимаются подобными процессами или проводят их иным, менее бестолковым образом, могут помочь вам набрать очки и избежать ненужного спора.)

 Игнорируйте навязываемый процесс. Я предпочитаю игнорировать бессмысленные, неоднозначные, бюрократические и организационные нововведения, которых не понимаю. При этом я предполагаю, что, игнорируя их, я веду дело к наступлению одного из двух событий. Либо лицо, отвечающее за процесс, обратится ко мне и спросит, почему я им не занимаюсь, предоставляя мне шанс убедить его в отсутствии необходимости им заниматься. Либо, если никто меня не спросит, почему я им не занимаюсь, значит, никому до процесса нет никакого дела. Я буду заниматься своим делом, добиваясь успеха и без спорного нововведения, имея «железное» оправдание, если кто-нибудь меня однажды спросит, почему я не занимаюсь процессом («Послушайте, мы прекрасно справились с X и без него. Может быть, вы сможете убедить меня, чем нам помог бы Y?»). Зачастую лучше всего это срабатывает в новых организациях, поскольку у вас есть дополнительное оправдание, основанное на незнании организационных начал. Хотя будьте осторожны: игнорирование бюрократических начинаний может подвергнуть опасности ваши политические перспективы.

Электронные сообщения, не вызывающие раздражения

Каким бы прекрасным средством ни казалась электронная почта, она остается основным фактором раздражения участников проекта. Объем поступающей почты способен запросто вызвать гнетущее чувство, заставляя постоянно читать все новые и новые сообщения и как можно быстрее на них отвечать, зачастую в ущерб качеству чтения и письма. Большинство из нас не уделяют чтению и составлению электронной почты должного внимания. Самое забавное, что быстрота и удобство электронной почты становятся невостребованными, если мы не можем понять, о чем же нам пытается сообщить наш корреспондент, или не можем добиться понимания от него, чего же мы сами пытались сообщить.

А для руководства проектом, возможно, самое главное состоит в том, что электронная почта является главным средством связи для лидеров. Рассылая новые сообщения и отвечая на сообщения других, лидер влияет на информационный поток проекта и управляет им. Если лидер обладает ясностью мышления и задает толковые вопросы, он служит примером для всех остальных. Один ответ в серьезной дискуссии, в которую вовлечено множество людей, способен разом прояснить ситуацию во всей организации. Но если лидер не обладает четким мышлением, выражается неясно или путанно, это мешает нормальному общению всей команды.

Сложность в том, что лишь немногие способны признать, что послали неудачное сообщение. К примеру, проведите следующий тест: используя собственную субъективную оценку, скажите, какой процент корреспонденции, полученной вами от ваших сотрудников, отличается высоким качеством? Средним качеством? Полной бесполезностью? А теперь спросите сами себя, какой процент посланной вами корреспонденции можно отнести к каждой из этих трех категорий. В качестве эксперимента я однажды задал небольшой группе руководителей проектов, тестировщиков и программистов этот же вопрос. В соотношении примерно 2:1, все утверждали, что другие присылают им больше бестолковой почты, чем они посылают другим. Поскольку все они работали вместе, из этих анекдотичных данных следовало, что все относили проблемы, возникающие при обмене корреспонденцией по электронной почте, на чужой счет. Я не располагаю более весомыми данными для подтверждения этого заявления, но оно похоже на истину. Так или иначе, когда происходит сбой в общении, среднестатистический сотрудник стремится обвинить в этом другого (получить многочисленные тому подтверждения можно из истории западной цивилизации).

Толковые электронные сообщения

В Microsoft я перенял привычку поощрять за толковые сообщения, посланные по электронной почте. Многие важные дебаты проводились по электронной почте, и к ним обычно привлекались люди, стоящие на разных ступенях иерархической лестницы; рядовые руководители проектов, управленцы среднего звена и вице-президенты получали возможность на равных обмениваться сообщениями по электронной почте. Я часто оказывался в самой гуще этих дебатов, обычно потому, что кое-что из сферы моей ответственности внезапно становилось весьма важным объектом дележа.

Время от времени в этих почтовых дискуссиях в ответ на чьи-либо слова я допускал по-настоящему крепкие выражения. Я тщательно все формулировал, многократно пересматривал, чтобы получилось корректно: просто, строго и понятно. Затем я все это отсылал. Иногда от моих аргументов не оставляли камня на камне, а иногда их просто игнорировали. Но бывало, что я попадал в десятку. Зачастую в таких случаях через несколько минут я получал сообщение личного характера от вице-президента или даже от еще более важной персоны, состоявшее всего из двух слов: «Неплохое послание». Дискуссия могла еще бушевать, но я то знал, что уже выиграл пару очков в споре. Более важным для меня было то, что кто-то не пожалел времени сообщить мне о силе моих доводов, и о том, что мне удалось их выразить в манере, достойной похвалы.^[59]

Умные руководители ценят хорошую почту. Им ежедневно приходится читать массу неудачно составленных электронных посланий, и если у их не находится времени на поощрение тех, кто умеет доходчиво излагать свои мысли, то круг таких людей вряд ли расширится. На отправку такого сугубо личного сообщения уходит всего около 15 секунд, но, как следует из моего рассказа, его значение для кого-нибудь из вашей организации может стать более весомым, чем вы думаете.

Но хвалить других проще, чем нести ответственность за собственные скверные манеры при составлении электронных посланий. Как уже отмечалось, люди считают, что они пишут лучше, чем другие об этом думают (и чем выше ваша должность, тем труднее получить объективный отзыв о качестве ваших почтовых отправлений). Поскольку у лидеров и управленцев объем почтовых отправлений больше, чем у других, для вас очень важно подмечать за собой дурные привычки и пытаться от них избавляться. Я предлагаю рассмотреть некоторые советы, изложенные с позиции руководителя проекта, которые помогут понять, на что похожи хорошие электронные сообщения и что собой представляют наиболее распространенные дурные привычки.

 Старайтесь писать кратко, просто и понятно. Паскаль, математик, чьим именем назван язык программирования, однажды признался: «Чем большим временем я располагал, тем более короткие письма у меня получались». Язык, подобно коду, может быть оптимизирован. Но вместо оптимизации с целью достижения логической эффективности нужна оптимизация с целью повышения эффективности общения. В отличие от кода корректное с точки зрения грамматики и логики сообщение из трех слов может быть бесполезным для получателя, который не сможет понять, что оно означает.^[60] В расчете на то, что ваше сообщение будет читать конкретный человек, подумайте, как бы вы объяснили ему все это при личном общении. Какие детали пригодились, а какие нет? Какими сведениями он по вашему мнению располагает? Какие метафоры можно использовать? Если сообщение важное, прежде чем его отослать, отвлекитесь на пару минут, а затем прочитайте снова, задаваясь этими вопросами. Или подберите в своей команде человека, который бы бегло просматривал важные и циркулярные сообщения и высказывал вам свое мнение.

 Предлагайте конкретное действие и срок его выполнения. Самые удачные сообщения электронной почты содержат ясно выраженное конкретное требование и, по возможности, связанный с ним разумный срок выполнения. Людям, читающим сообщение электронной почты, должно быть сразу понятно, зачем оно им отправлено, каким образом они будут задействованы и что им нужно сделать (к определенному сроку). Назначая срок выполнения («Требования должны быть у меня к пятнице»), вы ставите себя выше этих людей, заставляя их обратить внимание на будущие действия, обозначенные вами по электронной почте, что ставит вас в положение начальника.

 Определяйте приоритеты. А нужно ли вам посылать сообщение? Чем больше сообщений вы посылаете, тем больше работы создаете другим, вынуждая их распределять ваши требования по приоритетам. Сколько из всего упомянутого носит важный характер? Если обсуждается 10 вопросов, разбейте их на две группы и сосредоточьте внимание на наиболее важной из них. Подумайте, может быть, некоторые вещи лучше обсудить по телефону, на очередном совещании или при личном общении. Если вы не выстроите все по приоритетам, ждите, что получатели сделают это за вас в соответствии со своими, а не вашими интересами.

 Не думайте, что люди читают все подряд (особенно если сообщение носит для вас важный характер). Не обольщайтесь и не ждите, что кто-то прочитает ваше сообщение только потому, что вы его послали. Люди ежедневно получают целый ворох сообщений, многие из которых приходят от не менее важных персон, чем вы. Чем серьезнее для вас какой-то вопрос, тем больше усилий надо приложить, чтобы люди действительно обратили на него внимание и должным образом отреагировали. Чем выше репутация в глазах команды, тем более оптимистичными могут быть ваши предположения о том, как люди откликнутся на посланные вами сообщения.

 Избегайте репортажей. Вряд ли кому-то понадобится знать последовательность событий, ведущих к какому-нибудь результату. Не пишите сообщений, опирающихся на личные вклады разных участников событий: «Когда Салли проектировала наш производственный процесс, ее интересовало следующее…». Или сообщений в форме повествования: «Совещание началось превосходно, Боб и Стив давали весьма эмоциональные и убедительные пояснения к своим слайдам. Все шло хорошо, до тех пор пока…». Лучше сосредоточьтесь на фактах: что случилось, как в связи с этим изменился окружающий мир, как мы собираемся на это реагировать. Если вы вынуждены включать в сообщение второстепенные детали, расположите их ниже всех важных моментов. То же самое относится к слайдам, веб-сайтам, документам и т. п. Вам следует дать людям возможность, просмотрев две первые строчки, самим решать, есть ли для них что-нибудь важное, что имело бы смысл читать дальше.

 Изолируйте FYI-сообщения. Мне попадались команды, упорно рассылавшие массу сообщений «обо всем и ни о чем». Кто-то называет такие сообщения «к вашему сведению» (For Your Information, FYI). Любознательность и стремление быть в курсе всех новинок индустрии – хорошие привычки, но не позволяйте им доминировать на электронных форумах, используемых для более конкретной работы. Создайте специальный электронный адрес или откройте дискуссионную группу адресов «тенденции развития индустрии» или «технически новинки», куда команда сможет посылать все найденные «изюминки». Если это будет приемлемо для ваших корреспондентов, попросите их сопровождать подобные сообщения пометкой о низком приоритете или указывать в строке темы префикс «FYI:», чтобы их было проще отфильтровать.

 Телефон – ваш друг. Если вам что-то непонятно в полученном вами важном сообщении, не отвечайте на него сложным вопросом из пяти частей. Изыщите возможность связаться с отправителем по телефону. Непосредственное общение больше подходит для улаживания недоразумений и конфликтов, чем электронная почта. 30-секундный телефонный разговор часто заменяет длительную, отнимающую много времени переписку. Если вы переговорили с отправителем по телефону и решили проблему, вы сможете поделиться своим пониманием вопроса в почтовой рассылке: вполне вероятно, что подобные трудности возникали и у других людей. Телефонные переговоры (или беседа на ходу) – хороший повод для рассылок по электронной почте.^[61]

Пример неудачного электронного сообщения

Бестолковые сообщения распознать не трудно. Они, как правило, слишком пространны, скудны по содержанию, сопровождены целой кучей вложений и не предназначены для беглого просмотра. Все это сразу бросается в глаза, и обычно они либо игнорируются, либо вызывают соответствующую реакцию: «Фрэд, по-моему, в сообщении слишком много путаницы. Если с этим согласятся все остальные, не мог бы ты его переделать или высказать свои соображения на совещании? Если ты против, то я с тобой созвонюсь. Заранее благодарен». Поэтому бестолковые сообщения еще не самая опасная разновидность электронной почты.

Реальную опасность представляют те виды сообщений, которые выглядят вполне нормально, но на самом деле в них масса всего отвлекающего, незрелых мыслей и двусмысленностей. Теперь приведу два примера сообщений, плохое и хорошее. Начнем с плохого:

От: Джек Колоно.

Кому: Ведущему команды разработчиков.

Тема: Резюме недавних дискуссий, связанных с разработкой проверочных процедур.

В течение последних четырех недель многие из нас хотели бы узнать, когда будет окончательно завершен процесс доработки наших процедур проверки программного кода. Я понимаю, что потрачено много времени и проведено множество кулуарных дебатов и совещаний в поисках путей решения, которые так ни к чему существенному и не привели. Выбор членов комиссии был для меня нелегким и, как многие из вас уже знают, потребовал больше времени, чем ожидалось. Я извиняюсь, но так уж вышло.

Поэтому, сначала мне хотелось бы предоставить Вам некоторые наиболее существенные детали наших новых предложений, в случае если Вы пропустили одну из наших еженедельных дискуссий или не присутствовали на беседе со мной по этому вопросу в течение последних двух недель:

1. Проверки крайне важны. Они дают возможность определить, что нами реально создано.

2. У всех есть свое мнение. Все мы выслушали Рэнди и Боба и каждый из них детально пояснил, почему они считают плохой текущую систему.

3. Легких ответов не существует. У большинства обсуждаемых изменений есть свои недостатки. Таким образом, когда мы наконец-то придем к итоговому заключению, останутся некоторые шероховатости к моменту передачи программного продукта, а возможно, и в дальнейшем.

Вместе с тем, как ни странно, я хотел бы сообщить, что чуть позже, на этой неделе, я отошлю пересмотренное предложение. Пожалуйста, следите за следующим сообщением с моего адреса. Вскоре оно должно к Вам прийти.

Заранее благодарен,

Джек.

Пример хорошего электронного сообщения

В отличие от примера неудачного сообщения, этот пример не содержит исторических экскурсов или попыток оправдаться: все здесь по существу. Его отличает краткость, ясность и конкретность. Вместо разговоров о предложениях сообщение содержит реальное предложение. Хотя в нем чувствуется ультимативность, его цель – придать предложению ускорение и помочь его протолкнуть.

От: Джек Колоно.

Кому: Ведущему команды разработчиков.

Тема: Новый проверочный процесс.

Окончательное предложение по новому проверочному процессу составлено и находится по адресу http://intman/proc/checkin/.

Поскольку вопрос был спорным, я обсудил предложение один на один с большей частью команды и учел мнение каждого. Если ваше мнение не попало в предложение и у вас имеются существенные возражения, пожалуйста, вышлите их мне по электронной почте как можно быстрее.

Но учтите, что это второе публичное уведомление о возможных изменениях. Возможностей для внесения изменений уже немного и с каждым днем их становится все меньше. Пожалуйста, действуете немедленно или согласитесь с тем, что есть.

В 17.00 в пятницу назначен крайний срок для связи со мной по поводу отзыва на упомянутое ранее предложение. Я рассмотрю любые вопросы и комментарии, присланные до установленного срока, и отвечу на них (в сотрудничестве с компетентными специалистами). В противном случае вопрос будет закрыт, и процедуры будут введены в действие на следующей неделе.

Заранее благодарен,

Джек.

Как только вам станет ясно, в чем разница между этими двумя сообщениями, вы можете в них больше не вчитываться. Их не стоит рассматривать как шаблон для ваших сообщений. Каждое отправляемое вами сообщение может иметь иные цели, их смысл может противоречить этим примерам. Если вы пишете их обдуманно и обоснованно, включайте в них все, что нужно, в целях выполнения работы. Но всегда ищите способы сократить его до минимума и использовать для того, чтобы что-то осуществилось.

Как не раздражать присутствующих на совещании

Признаюсь: я не люблю постоянных совещаний. Пока нет силы, способной сдерживать их в рамках краткости и порядка, они неизбежно будут затянутыми, раздутыми, бесполезными и тратящими понапрасну ваше время. Но если такая сила есть, совещания могут активизировать работу, объединяя опыт всех присутствующих. Вся сложность состоит в том, чтобы организатор и ведущий совещания знал, что он делает.

Для начала важно понять, насколько дорого обходятся совещания. Если совещание длится в течение часа и на нем присутствует 10 человек, значит, оно стоит 10 человеко-часов. Вместо того чтобы исправлять ошибки или закрывать проблемы – что является двумя гарантированными формами прогресса, – вся команда запирается в конференц-зале в ожидании, что произойдет нечто такое, на что стоило потратить их рабочее время. Может быть, так именно и произойдет, а может быть и нет. Поэтому я думаю, что когда программисты и другие специалисты жалуются на совещания, у них есть для этого основания. Время, потраченное на совещания, зачастую неравноценно времени, проведенному за компьютером.

Но если необходимость совещания связана с какими-то новыми идеями или решениями, на нем доводится информация, изменяющая последующее поведение всей команды, выражается некая вдохновляющая для всего проекта идея, ценность совещания значительно возрастает. Из обычной рутины оно превращается в способ усвоения или обмена информацией, которую трудно получить другими средствами.

Искусство содействия

Несколько лет назад я, помнится, сильно возражал по поводу того, как мы собираемся выстраивать архитектуру одного из важных компонентов Windows. Я пришел пораньше и наблюдал, как все входили в комнату и усаживались на свои места, уверенные в правоте своих мнений. Я смотрел, как сотрудники, развалившись на стульях, обдумывали свои доводы перед началом совещания. И, конечно же, спор разгорелся именно вокруг того, что мы делали. Дискуссия в течение 10 минут в повышенных тонах шла на встречных курсах. Классные доски яростно расчерчивались конкурирующими диаграммами, руки вскидывались в протестующих жестах, раздавались многочисленные саркастические заявления и задавались риторические вопросы. И наконец, мой руководитель группы, Хади Партови (Hadi Partovi), встал и медленно пошел к доске, висящей перед всеми присутствующими.

Не проронив ни слова, он стал составлять список вопросов. Зал затих. Спор прекратился, и все стали наблюдать за тем, что он делает. Когда он закончил, то спросил, верно ли он изложил на доске все вопросы. Все утвердительно кивнули. Затем он разобрал с нами все вопросы поочередно. Споры продолжались, но наличие структуры позволило значительно сократить их продолжительность. Хади не навязывал собственного мнения (хотя я знал, что оно у него было). Взамен он постарался помочь всем нам прийти к согласию. В этом и состоит искусство содействия.

Содействие (гл.) – действия, направленные на упрощение или облегчение какого-нибудь процесса.

Совещания бывают удачными лишь тогда, когда в комнате присутствует человек, понимающий, как оказать содействие. У кого-то все получается инстинктивно, все остальные даже не понимают, как это происходит. Как и с другими проявлениями навыков общения, у людей разные понятия о путях общения и о том, как на них влиять.

Содействие может выражаться в полуформальной роли человека, которому поручено вести совещание (обычно руководителя проекта), или того, кто это совещание созвал. У некоторых команд настолько высокий уровень культуры содействия (я имею в виду, что многие владеют этим навыком), что они могут передавать эту роль тому, кто в ней на данный момент наиболее органичен. Однако зачастую во многих проектах испытывается дефицит навыков содействия.

Несколько советов относительно содействия

Содействие относится к таким навыкам, наличие которых командами считается само собой разумеющимся. Есть неплохие книги^[62] и курсы, посвященные искусству содействия, но вам лучше осваивать азы этого мастерства, наблюдая за чьими-то успешными действиями и пробуя применить все подмеченное на следующем проводимом вами совещании. Тем не менее существует ряд советов, достойных упоминания. Чтобы понять все это, у меня ушло немало времени, и советы могут стать для вас большим подспорьем в развитии, независимо от наличия естественных навыков содействия.

 Утвердитесь в роли хозяина. Если вы являетесь организатором совещания, то де-факто содействуете его проведению. Начните совещание с представления участников, доведения повестки дня и с завязки дискуссии. Если вы ведете себя по-хозяйски с момента, когда участники входят в зал, они будут вести себя как гости и относиться к вам уважительно. Тщательно выберите то место, где вы будете сидеть: место во главе или в центральной части стола обычно придает вам более авторитетный вид, чем место где-нибудь в углу.

 Слушайте и воспроизводите. Ключевая функция содействующего состоит в том, чтобы стимулировать общение присутствующих. Если кто-нибудь выразился невнятно (но в его словах есть рациональное зерно), помогите ему развить его мысль в полноценную идею. Попробуйте применить прием воспроизведения, пересказывая сказанную кем-то фразу: «Майк, я думаю, что ты хотел сказать следующее: <далее звучит точка зрения Майка в более понятном изложении>. Ты согласен?» Этот прием уточняет мнение и показывает всем, как вести дискуссию в духе сотрудничества. Но остерегайтесь навязывания собственного мнения: быть в роли содействующего, если вы всецело поглощены собственными намерениями, очень трудно. Некоторые организации нанимают профессиональных содействующих, которые помогают на совещаниях выйти из спорных ситуаций.

 Направляйте разговор в нужное русло. Используя в качестве подспорья повестку дня, вмешивайтесь по необходимости в дискуссию, чтобы вернуть ей правильное направление. Проявляйте гибкость, давайте людям высказаться, но если разговор уводится на Юг, когда повесткой дня предписано движение на Запад, нужно предпринимать какие-то меры. Вежливо прервите разговор, обратите внимание на вывешенную на стене повестку дня и попросите придерживаться этого направления дискуссии до тех пор, пока не охвачены вопросы повестки дня (или предложите уточнить повестку дня, если вновь возникшие вопросы того стоят). Обратите внимание на тех, кто говорит слишком много, и на тех, кому не дают достаточной возможности высказаться, и, соответственно, управляйте очередностью выступлений («Боб, прервись на секунду… Стив, у тебя есть что сказать по этому поводу?»).

 Обрывайте беседу. Наметьте в своем сознании порог, за которым вопрос должен быть вынесен за рамки совещания и решаться где-нибудь в другом месте. Часто вполне достаточно выявить суть проблемы и попросить того, кто ее выдвинул, чуть повременить и снова вынести ее на рассмотрение завтра или через несколько дней, имея при себе готовые предложения по ее решению. Это прекрасный способ завершить посторонние дебаты, которыми охвачены совещания: «Ребята, постойте. Сэм и Боб, выйдите и разберитесь с этим вдвоем, хорошо? Затем вернитесь и доведите до нас, что вы там решили». Никогда не позволяйте какой-нибудь парочке в течение часа перехватывать слово друг у друга, пока остальные пять или шесть человек отвлеченно скучают.

 Фиксируйте происходящее. Уделите время документированию дискуссии (если представится такая возможность). Вам в роли содействующего это поможет отслеживать повестку дня и сообщать об этом группе. Для этого меня вполне устраивает классная доска. Она предоставляет самое простое и наиболее гибкое средство фиксации высказываний, составления списков намеченных дел или определения согласованных и несогласованных вопросов. Но сам способ не имеет значения. Главное, чтобы по окончании совещания все его этапы и важные моменты были записаны и разосланы по электронной почте всем присутствовавшим. Кто-то может сказать, что все данные могут быть изложены с позиции силы, поскольку вы можете влиять на то, как именно все записывается и какие аспекты при этом выделяются. Но даже если такое случится, рассылка заметок заставит других внести уточнения во все, что было вами представлено в искаженном виде.

Если вы не согласны с данными советами, я надеюсь, они помогут вам понять, в чем состоит роль ведущего совещание. Если никто за эту роль не берется, совещание становится бесполезным и(или) скучным мероприятием. Основной рефрен таков: «Все совещания – отстой, и их нужно избегать», но на самом деле проблема в том, как проводятся совещания, а не в идее совещаний как таковых.

Три разновидности совещаний

Величайшей западней для организаторов может стать игнорирование универсальности самой идеи совещаний. Незачем одинаково по единой структуре проводить абсолютно все совещания. Причиной скуки, испытываемой 90 % людей на многих совещаниях, является конфликт целей со структурой и числом участников совещания. У вас не получится оживленной дискуссии, если в ней будет участвовать более семи-восьми человек независимо от того, кто будет ей содействовать. По весьма грубым прикидкам существуют три вида совещаний, с различными ограничениями и областями применения. Нужно всегда продумывать, какой из видов совещаний наиболее соответствует решаемой проблеме.

 Оживленная дискуссия. Ожидается, что в совещании примут активное участие все присутствующие. Цель – глубокая и тщательная проработка вопроса. Усилия сосредоточиваются на исследовании, разрешении определенных проблем или на поиске альтернативных идей. Число участников: от малого до среднего (2–8). Примеры: дискуссии по вопросам проектирования, мозговые атаки, преодоление кризисных ситуаций, определение первоочередных задач.

 Сообщение или умеренное обсуждение. Кто-то о чем-то хочет сообщить и ему нужно, чтобы люди отреагировали на это сообщение или уловили его смысл. Цель состоит в получении отзывов общего характера или в распространении знаний. Оживленный диалог может завязаться только в какой-нибудь подгруппе. В ходе совещания слово может предоставляться нескольким разным людям, при этом роли ведущего и содействующего могут тоже переходить разным людям. Число участников: от среднего до большого (5–15). Примеры: пересмотр технических условий, пересмотр архитектуры программного продукта, пересмотр вопросов управления проектом, небольшие презентации.

 Обзор текущего состояния дел и хода реализации проекта. Цель состоит в подведении итогов работы команды и работы над проектом в целом. Дает возможность лидерам провести коррекцию курса и довести новые указания руководства сразу всей группе. Когда на таких совещаниях заставляют всех выслушивать информацию о состоянии дел или собирают отчеты о проделанной работе, оно превращается в самое скучное мероприятие на свете. Число участников: от среднего до большого (10–100). Примеры: обзор состояния дел, обзор хода реализации проекта, крупные презентации, всеобщий сбор.

Самые вредные совещания получаются при несоответствии целей и организационных форм. Если в зале более 10 человек, то завязать оживленную беседу или углубленную дискуссию будет слишком сложно. Для того чтобы в них приняли участие все присутствующие, просто не хватит времени, и получится, что большую часть выделенного времени займет небольшая группа активистов (если это не препятствует целям содействующего, наличие такой группы – вполне нормальное явление). Заседания большинства комиссий приобретают именно такую форму, что приводит к вполне ожидаемым посредственным или совсем плохим результатам.

Вред регулярных совещаний

Вторыми по степени вредности являются повторяющиеся совещания (еженедельно, ежедневно, ежемесячно), сохраняющие затем свою регулярность на протяжении многих недель, несмотря на то что надобность в них давно миновала (в некоторых зданиях компании Microsoft выкроить время для совещания в зале заседаний было вообще невозможно, поскольку расписание его загруженности на весь год вперед было занято вошедшими в привычку регулярными совещаниями). Повторяемость хороша там, где задается ритм работы, заставляющий людей собираться в одном месте, в одно и то же время. Всевозможные мелкие проблемы могут быть решены быстро и в рабочем порядке при личной встрече, которая может понадобиться всего пару раз в неделю. «Привет, Сэм! Я хотел бы тебя спросить… будет ли изменена эта API-функция? Я просмотрел ваши контрольные результаты и подумал, что они могут повлиять на мою работу, но не был в этом уверен». Сообщение по электронной почте или телефонный звонок не гарантирует ответа, но когда человек сидит напротив вас, то вы обычно получаете все, что вам нужно.

Проблема состоит в том, что совещания слишком легко приобретают регулярный характер даже после того, как их ценность утрачивается. Если кто-то вообще перестал приходить, а остальные используют время для просмотра электронной почты на своих ноутбуках, значит, дело плохо, совещание больше не оправдывает затрачиваемого на него времени. Однако пугливые руководители (и другие устроители совещаний) зачастую думают, что если они отменят совещание, то утратят контроль. Скорее бывает наоборот, мучения команд на абсолютно ненужных совещаниях приводят к тому, что руководители утрачивают свой начальственный авторитет, который они пытаются спасти.

Есть хорошее правило: не переусердствуйте с совещаниями. Включите регулярные совещания в график работ и попросите всех за пять минут до назначенного времени просмотреть в электронной почте повестку дня. Если есть четкая повестка дня, организатор ее рассылает, и группа собирается на совещание. Если повестки дня нет, вы рассылаете сообщение об этом, и совещание отменяется (на данной неделе). Команде остается сохраненное время, и людей не вынуждают посещать совещание, проводимое «для галочки». Регулярные совещания должны быть полностью отменены, если они не проводятся в течение трех или четырех недель.

Несколько советов относительно ведения совещаний

В этом последнем разделе приводится список тактических советов по успешному ведению совещаний и участию в них, которые зачастую упускаются из виду. Здесь вы не найдете ничего захватывающего – это всего лишь конкретные вещи, с которыми вы сталкиваетесь при работе с небольшими группами людей. Любой многократно проводивший совещания человек имеет собственный список излюбленных приемов или советов: при прочих равных условиях я надеюсь, что предлагаемый список поможет вам поразмыслить о тех вещах, которые в прошлом вам удавались.

 Все ли нужные люди прибыли на совещание? Кто-то придет, если вы его пригласите. Кто-то не придет до тех пор, пока вы не вытащите его силой (или не выманите каким-нибудь пряником). Основные усилия руководителей проекта направляются на то, чтобы собрать нужных людей в нужное время, поэтому не ленитесь пробежаться по коридору или вломиться на другое совещание, если специалист, чье присутствие предполагается на вашем совещании, до сих пор на него не прибыл. Более того, если вы, открывая совещание, не обнаруживаете на нем нужных людей, прекратите это совещание. Не тратьте время впустую, занимаясь тем, что нужно будет повторить завтра или через несколько дней, когда кворум в конце концов соберется. И наконец, если все нужные люди собрались, но вы видите в зале и тех, кому здесь не место, скажите им об этом. Будьте дипломатичны, предложите прислать им заметки или итоги, но удалите их из зала, в особенности если они намерены мешать ходу совещания.

 Сидя или стоя. Один из приемов, позволяющих не затягивать совещание, – провести его стоя (например, собраться в холле или на свежем воздухе). Теоретически это заставит людей работать по существу и подымать вопросы, имеющие реальную ценность для обсуждения в составе группы. Такое совещание должно продлиться максимум минут 5–10. SCRUM^[63] предписывает постоянные ежедневные совещания для выяснения состояния процесса. На таком совещании задаются лишь три вопроса: Что сделано со времени предыдущего совещания? Что вам мешает? Что вы сделаете к завтрашнему совещанию? С такими бескомпромиссными обязательствами будет обеспечено присутствие на совещании даже самого капризного разработчика. Традиционные сидячие совещания нужно оставить для более мелких групп. Стоит хотя бы попробовать провести такое совещание в качестве эксперимента: при прочих равных условиях это вынудит людей принять во внимание, что совещанию, запланированному на один час, на самом деле столько времени не понадобится.

 Подготовка. Совещания часто проходят плохо из-за их недостаточной подготовленности. Нужно всегда учитывать, сколько времени требуется на подготовку совещания, чтобы оно отвечало своим целям. Иногда приходится тратить минимум времени: составить список вопросов или открытых проблем или организовать электронную рассылку, отправляемую загодя и содержащую повестку дня. А иногда требуется детальная подготовка: изготовление слайдов, демонстраций, основных тезисов. Если же совещание все равно прошло не так удачно, как бы вам этого хотелось, задайтесь вопросом, что нужно было сделать по-другому. Зачастую ответ будет касаться небрежности подготовки. Секрет успеха кроется в том, чтобы учесть, когда достаточно обеспечить рассылку, а когда приходится выделять время в личном календаре, достаточное для соответствующей подготовки.

 Ноутбуки и электронные секретари. У меня сильное предубеждение против использования электронных секретарей и ноутбуков во время совещания. Если присутствующие не думают, что происходящему стоит уделять полноценное внимание, то их не должно быть в зале (если только совещание не относится к подведению итогов или к обзору проекта, где соотношение сигнал/шум весьма низкое). Очное общение слишком дорого обходится и должно использоваться для таких дел, важность которых ни у кого не вызывает сомнений и стоит потраченного на них времени, тогда как электронная и голосовая почта разработаны для работы в режиме ожидания. Если у вас на этот счет имеется собственное мнение, поговорите с командой и подумайте, нужно ли соглашаться с политикой, допускающей использование на совещаниях ноутбуков.

 Пунктуальность. Это понятие относится к стилю поведения, присущему высшему начальству. Если вице-президент имеет склонность к опозданиям, опаздывать будут и все остальные. Если же начальник пунктуален, все остальные тоже постараются ему соответствовать. Вы могли бы взять в привычку начинать совещания вовремя, но если на совещании отсутствуют важные персоны, при их появлении вам придется прерываться и повторять сказанное. Однако если опаздывающий – человек, равный вам по положению или ожидаемый вами докладчик, попробуйте подшутить над ним. Мой любимый прием – позвонить каждому опаздывающему в офис. Если он все еще там, слегка посмейтесь над ним по телефону, чтобы слышали все остальные: «Привет, Сэм. Мы сочли бы за честь видеть тебя в аудитории номер 5». Если его там нет, оставьте ему сообщение на автоответчике. Вызовите его по селектору и пусть все присутствующие в аудитории скажут в унисон: «Мы любим тебя, Сэм!» или пропоют ему Happy Birthday. Проделывайте это на каждом совещании с теми, кто опаздывает или приходит последним. Таким образом, вы начнете совещание со смешной нотки, а опоздавшие получат дополнительную мотивацию, чтобы прибывать вовремя.

 Завершайте совещание, имея четкую последовательность действий и ответственных за их выполнение. Когда совещание заканчивается, самым существенным становится то, что произойдет потом. У вас может быть самое скверное, самое противное и самое жестокое совещание за всю историю человечества, но если вы покидаете зал с нужным списком из пяти дел, которые необходимо выполнить, и с именами пяти человек, которые согласились их выполнить, значит, вы достигли успеха. Не позволяйте людям покидать зал без четкого плана очередного этапа работы. Часть ваших приготовлений должна быть основана на размышлениях, как достичь нужных результатов и кто подойдет для решения каждой задачи.

Выводы

• Руководители проектов имеют склонность раздражать других людей. Некоторых раздражающих моментов можно избежать.

• Люди раздражаются по разным причинам. Зачастую это реакция на то, что их время потрачено впустую, на то, что их принимают за идиотов, и на то, что от них ждут терпеливого отношения к скучному мероприятию или скверному обращению.

• Хорошо организованные производственные процессы имеют множество положительных эффектов, включая ускорение хода разработки и предупреждение возможных проблем. Но их довольно сложно подготовить.

• Электронные сообщения воспринимаются без раздражения, если они составлены коротко и деловито, позволяя читателю сразу понять, что сообщение достойно большего, чем усвоение темы и чтение содержимого первой строки.

• Совещания проходят успешно, если кто-то содействует их проведению.

• Совещание становится бесполезным, когда его цели не совпадают с типом самого совещания.

Упражнения

1. Кто из ваших знакомых раздражает вас больше всех? Что именно вас в нем раздражает? Как вы думаете, кто-нибудь ему говорил об этих раздражающих факторах? Если вы хотите как можно меньше раздражать свою команду, то как вы могли бы вызвать их на откровенную оценку своего поведения?

2. Каков был лучший рабочий процесс, в котором вам приходилось участвовать? Из-за чего он стал лучшим? Сохранил ли он свою ценность для проекта спустя год после внедрения?

3. Каков был на вашей памяти самый плохой процесс? Из-за чего он стал таким плохим? Могли ли лидеры сделать что-нибудь по-другому? Вы предлагали какие-нибудь изменения, которые были проигнорированы, или вы хранили молчание? Как руководитель команды может получить информацию от команды о раздражающих ее процессах?

4. Когда в последний раз вы кого-нибудь хвалили за простые и понятные сообщения, посланные по электронной почте? В течение следующей недели каждый день благодарите того, кто прислал вам самое понятное и наиболее эффективное сообщение по электронной почте.

5. Отслеживайте содержимое своего ящика электронной почты. Не существует закона, обязывающего читать почту сразу по мере ее поступления или отвечать на нее в течение часа. Некоторые исследования показывают, что если обрабатывать электронную почту партиями, два или три раза в день, то время, затрачиваемое на ее обработку, уменьшается, а эффективность всей работы повышается. В качестве эксперимента регистрируйте каждую проверку почтового ящика. Задайтесь целью проверять его содержимое на один раз меньше завтра, то же самое сделайте на следующий день, до тех пор, пока не будет утрачен контроль за его содержимым.

6. А вот эксперимент для всей команды: выберите полдня в неделю в качестве времени без электронной почты, к примеру, с 14.00 до 17.00 никто не должен ожидать ответов на сообщения электронной почты. Это в течение нескольких часов позволит всем вплотную заняться своей работой. После эксперимента спросите команду, почувствовали ли они всплеск производительности, ее спад или не почувствовали вообще никакой разницы.

7. Захватите с собой на несколько следующих совещаний блокнот. Для каждого совещания определите, кто ему будет содействовать, и помечайте, как эти люди справляются со своей задачей. В конце недели составьте список наилучших из подмеченных вами приемов и действий и задайтесь целью повторить их на проводимых вами совещаниях.

8. Если вы поняли, что формат совещания не соответствует поставленным целям, что вы предпримите? а) подождете, пока кто-нибудь не пожалуется; б) намекнете организатору совещания, что изменение формата повысит шансы на успех; или в) приступите к игре в музыкальные стулья и станете выгонять людей до тех пор, пока совещание не приобретет нужный формат?

9. Каждое проявление бюрократизма в истории брало свое начало в простом, рациональном процессе. Исследуйте историю самой отвратительной на ваш взгляд бюрократической системы (например, системы государственного налогообложения, системы приема на работу в отделе кадров, системы отчетов о производственных затратах и т. п.). Определите, каков был первоначальный порядок, установленный в этой системе, и как он превратился в ту систему, которую вы знаете сегодня. Можно ли предотвратить бюрократию? Чтобы вы, изучив историю, сделали по-другому?

10. Обратите внимание на все ваши регулярные совещания и распределите их по степени важности. Отмените наименее важные регулярные совещания и попробуйте перенести их задачи в повестки дня других совещаний или в общение по электронной почте.

Глава 11. Что делать, если все идет не так

Независимо от того, чем вы заняты, сколько сил на это тратите и с кем вместе работаете, дела могут пойти не лучшим образом. Попасть в трудную ситуацию может даже лучшая в мире команда, имеющая в своем составе самых лучших лидеров и специалистов, обладающая высоким моральным духом и вполне достаточным количеством ресурсов. Единственный способ полностью избежать трудностей – это не делать ничего существенного или постоянно находиться в таких ситуациях или участвовать в таких проектах, которые начисто лишены всех форм риска, что крайне редко способствует успеху. Вот что думает по этому поводу Уильям А. Коэн (William A. Cohen):

Все успешные проекты – это просто длинная череда неприятностей, требующих преодоления. В возникновении неприятностей нет ничего необычного, это вполне нормальная ситуация, и преодолеть их – наша обязанность. Настоящее испытание состоит не в том, чтобы без проблем добиться успеха, а чтобы ощутить триумф вопреки всем проблемам.

Именно поэтому хорошие руководители проектов должны быть подготовлены к разрешению трудных ситуаций. Требуется определенная мудрость, чтобы понять, что неприятности действительно произошли и ничего уже не поделаешь. Способность команды противостоять неприятностям может быть более значимым фактором в успехе проекта, чем ее способность избегать этих неприятностей. Важны обе этих способности, но стойкость к неприятностям и способность выправить ситуацию являются свойствами, помогающими справиться с неожиданностями. Без них превосходная команда, имеющая замечательный план, может утратить контроль над ситуацией, стоит ей лишь слегка сбиться с курса.

В этой главе затрагиваются три темы: примерное руководство (или средства первой помощи) по выходу из неприятных ситуаций, размышления о том, как люди и команды справляются с трудностями, и обзор тактических приемов и подходов к управлению персоналом в трудные времена.

Элементарные принципы руководства

Вы можете ругаться в темноте на тех, кто свалил все вещи в кучу, а можете зажечь свечи. Неправильным ваш ход будет лишь тогда, когда, зная о проблеме, вы вообще не захотите ничего предпринять.

Пол Хокен (Paul Hawken)

Данный раздел представляет собой начальное учебное пособие по выходу из трудных ситуаций. Чуть позже я рассмотрю некоторые типичные ситуации и дам конкретные советы, но это руководство поможет вам преодолеть любые неприятности и привлечет ваше внимание к данной главе.

1. Успокойтесь. Ничто так не усугубляет ситуацию, как действия, основанные на страхе, злости или отчаянии. Если случилось что-то нехорошее, у вас волей-неволей возникнут все эти эмоции. Осознаете вы это или нет, но они повлияют на ход ваших мыслей и действий. (Исходя из опыта, чем менее осознанно вы даете волю своим чувствам, тем более уязвимыми становитесь.) Нужно устоять и не допустить резких действий, нужно проявить терпение, сохранить хладнокровие и присутствие духа.

2. Оцените проблему с точки зрения ее влияния на проект. Если кто-то считает, что небо рухнуло на землю, это еще не значит, что так оно и есть. А существует ли проблема вообще? Чья это проблема? В какой степени сам проект или его цели подвергнуты риску или требуют корректировки в связи со сложившейся ситуацией: на 5, 20 или 90 %? Разложите все по полочкам. Разве кто-нибудь умрет из-за этой ошибки (вы ведь не нейрохирург, верно?). Неужели будут стерты с лица земли целые города? Неужели жуткое бедствие постигнет ни в чем не повинных людей? Помогите всем ввести проблему в нужные эмоциональные и смысловые границы. Задайте кучу вопросов и заставьте людей думать, а не переживать. Постарайтесь избавиться от предположений. Убедитесь в том, что трезво оцениваете проблему и ее реальные последствия. Затем расставьте все по приоритетам: в чем имеется крайняя необходимость (что нужно сделать в срочном порядке!), что является источником наибольшего беспокойства (сделать сегодня), некоторого беспокойства (сделать на этой или следующей неделе), а о чем вообще не стоит беспокоиться (оставить без внимания). Осознайте, насколько вас отвлечет от всей текущей работы реакция на новую проблему и необходимость распределения ответных действий по приоритетам. Если проблема не стоит выеденного яйца, заставьте крикнувшего «Волк!» задать вопросы по неясным для него моментам, прежде чем снова подымать красный флаг.

3. Еще раз успокойтесь. Теперь, когда вы уже кое-что знаете о проблеме, вы действительно можете успокоиться («Как эти идиоты могли допустить <здесь вставьте ту несусветную глупость, которая была допущена>?!»). Найдите способ безопасного выражения эмоций: покричите в небо, позанимайтесь в спортзале или поговорите с приятелем. Но обязательно выпустите пар.^[64] Найдите наиболее подходящий для себя способ и воспользуйтесь им. Затем вернитесь к решению проблемы. Учтите, что для принятия верного решения необходимо не только ваше спокойствие, но и спокойствие всей команды. Посмотрите, кто из команды расстроен, и помогите ему успокоиться. Для начала неплохим подспорьем послужат юмор, искренность, еда и напитки. Сохраняйте спокойствие и собранность, и они передадутся другим. А взяв ответственность за случившееся на себя (см. далее раздел «Берите ответственность на себя»), независимо от того, кто на самом деле виноват, вы усилите стремление команды выпутаться из проблемы.

4. Оставьте в комнате только нужных людей. Любая серьезная проблема не может касаться только вас лично. Определите, кто кроме вас несет за нее наибольшую ответственность, обладает наибольшей компетентностью и может принести пользу в сложившейся ситуации, и немедленно соберите этих людей вместе. Освободите их от всех других совещаний и задач: если дело срочное, действуйте решительно, прерывая или откладывая на потом все, что лежит на вашем пути. Усадите их, закройте дверь и начните с того, что вы усвоили из пункта 2. Группа не должна быть многочисленной; чем более спорной или сложной является проблема, тем меньше должна быть группа.^[65] Кроме того, учитывая, что зачастую вам самому не обязательно входить в состав этой группы, соберите людей в комнате, сообщите о проблеме, а уж потом передавайте бразды правления. Предложите поддержку, но в их дела не вмешивайтесь (уйдите, если они не нуждаются в вашем присутствии). Четко определите, кто отвечает за решение проблемы (см. далее раздел «Роли и четко определенные полномочия»), вы или кто-то другой.

5. Исследуйте альтернативные варианты. После ответа на все вопросы и оценки обстановки определите возможные варианты (см. главу 8). Иногда для этого нужно провести некоторые исследования: поручите это кому-нибудь другому. Если нужно, убедитесь, что проблема уже воспринята как срочная; никогда не полагайтесь на то, что люди понимают, насколько срочным является порученное им дело. Будьте предельно точны в своих предположениях о сроке, к которому понадобятся ответы на вопросы.

6. Постройте простейший план. Взвесьте все возможные варианты, наметьте лучший из них и постройте простейший план. Наилучшее доступное решение, независимо от того, насколько оно неприятно, таковым и останется (кризис – не время для проявлений идеализма). Чем более срочной является проблема, тем проще должен быть ваш план. Чем глубже яма, в которую вы провалились, тем более прямым должен быть ваш путь наверх. Разбейте план на элементарные действия, чтобы убедиться, что в нем никто не запутался. Набросайте два списка людей: тех, от кого требуется одобрение вашего плана, и тех, кого надо поставить о нем в известность перед его реализацией. Представьте план первой группе, учтите их пожелания и заручитесь поддержкой. Затем доведите эту информацию до второй группы.

7. Выполните намеченное. Реализуйте план (см. главу 13). Убедитесь, что все, выполняющие эту работу, всецело вовлечены в процесс и обладают предельно глубоким осознанием того, зачем они все это делают. Здесь не место предположениям или неопределенностям. Наметьте своеобразные контрольные точки (каждый час, день, неделю), чтобы быть уверенным в том, что план приносит ожидаемый эффект и заставляет вас и других обладателей властных полномочий продумывать вопрос о приложении любых дополнительных усилий, необходимых для решения существующей проблемы. Если возникнут новые проблемы, начните с пункта 1.

8. Проведите разбор. Когда пожар будет потушен, соберите нужных людей и составьте список извлеченных уроков. (Эта группа может отличаться от тех, кто был упомянут в пункте 4, поскольку вам захочется включить в новую группу людей, которые оказались в сфере влияния принятого решения, но не участвовали в его принятии.) Задайте вопрос: «Что мы можем сделать, чтобы избежать возникновения проблемы в будущем?» Чем серьезнее проблема, тем больше ответов на этот вопрос вы получите. Расположите пункты списка по приоритетам. Решите, кто будет отвечать за реализацию каждого из нескольких верхних пунктов списка.

Стандартные ожидаемые ситуации

Существует ряд неприятных ситуаций, неизменно сопровождающих реализацию проектов. Эта книга в основном посвящена минимизации шансов на возникновение подобных ситуаций, а также сглаживанию тех трудностей, которые связаны с их возникновением. Наш мир не благоволит проектам, поскольку путей неблагоприятного развития событий куда больше, чем благоприятного. Чем больше проектов будет в вашем активе, тем выше шансы на то, что вы столкнетесь со всеми перечисленными здесь ситуациями и получите возможность непосредственно научиться справляться с ними.

Моя первая по-настоящему трудная ситуация возникла в 1996 году, когда я работал над функциями родительского контроля в IE 3.0. Мы обеспечивали поддержку стандартов W3C в системе родительского контроля, пытаясь создать первый веб-браузер, «умеющий» делать что-либо существенное для того, чтобы Интернет был более «безопасным». Я считал, что проект успешно продвигается, пока не состоялось первое обзорное совещание. Из десяти присутствующих девять были настолько разочарованы моими ответами на их вопросы, что даже не дослушали их до конца, и совещание приобрело неуправляемый характер. Все они были опытными разработчиками и создателями программных систем, и их вопросы были куда лучше моих ответов. Все казалось неправильным: люди кричали, а моя команда была деморализована. Через десять минут после начала совещания я понял, что произошла катастрофа. На двенадцатой минуте мне захотелось провалиться сквозь землю. К концу часа я едва мог оторвать взгляд от пола.

Ребята из Microsoft иногда называют такую ситуацию испытанием огнем. Замысел состоит в том, что работа – это испытание, и здесь не место детским рукавичкам. Мне хорошо запомнился тот день, так как я впервые полностью осознал, как много всего требуется, чтобы хорошо справляться со своей работой. Мне приходилось слышать истории о таких же случаях, но, не ощутив все это на собственной шкуре, я не имел о них полного представления. Но потом все стало понятно: нужно было обеспечивать приемлемый уровень работы, чтобы никогда больше не доводить дело до подобного рода совещаний. Как бы больно мне ни было, но я получил возможность постичь то, чему не научишься никаким другим образом.

Мой опыт обучения других руководителей привел меня к выводу, что людям трудно полностью проникнуться проблемой, не испытанной на собственной шкуре (это стало еще одной причиной применения в обучении приемов моделирования ситуаций). Слушая чьи-нибудь истории о срыве рабочих графиков или изменениях в требованиях, многие из нас почему-то легкомысленно верят, что с ними такого никогда не случится. Или, если выразиться поточнее, верят в то, что имевшиеся (или имеющиеся на данный момент) у них проблемы в некотором роде уникальны, а поэтому неизбежны и не похожи на те, которые когда-либо довелось испытать другому.

Итак, на волне полного оптимизма я предложу вам, дорогой читатель, перечень наиболее распространенных сложных ситуаций. Изучение этого перечня поможет вам, по крайней мере, пересмотреть свой личный опыт, а также те ситуации, в которых вы оказались на данный момент.

Как понять, что вы попали в сложную ситуацию

Что касается реализации проектов, я считаю сложной такую ситуацию, которая отвечает каким-либо из следующих критериев:

1. Образовался большой разрыв между реальным положением дел и текущим планом. («Предполагалось, что мы выложим новую версию в Интернет через час, но Фрэд говорит, что вся клиентская база «полетела», электропитание отключилось, а программисты напились».)

2. Возникла неразбериха в отношении масштабов отставания, его причин, того кто должен его ликвидировать; непонятно также, существует ли оно вообще. («Какой айсберг? Не вижу никакого айсберга».)

3. Непонятно, как подключить дополнительные ресурсы, чтобы устранить отставание. Могут возникнуть опасения, что принятие каких-нибудь мер или бездействие только ухудшит ситуацию. («Не стойте на месте, делайте же что-нибудь! Хотя нет, подождите… не делайте ничего, оставьте все как есть!»)

Стоит не без ехидства заметить, что некоторым скверным проектам эти черты свойственны с первого же дня. И это правда. Что для одних организаций – норма, для других – пожар. Хотя борьба с хаосом – задача руководства (которое надеется, что имеют дело со специфической проблемой, возникшей в особый период, а не с общей тенденцией, характеризующей всю рабочую обстановку), нам-то всем хорошо известно, что иногда наши руководители просто не справляются со своей работой (здесь вставьте второе ехидное замечание). Это говорит о том, что приведенные в данной главе советы пригодятся всегда, независимо от того, как часто вам придется к ним прибегать. Но если вы, читая эту главу, поймете, что они слишком часто перекликаются с вашей работой, подыщите себе нового руководителя или новое место работы.

Перечень сложных ситуаций

Элементарные принципы руководства, приведенные в начале главы, могут быть применены к любой из следующих ситуаций, хотя привлекаемые области знаний и навыков могут различаться. Для каждой из ситуаций я включил ссылки на некоторые из возможных ответов, которые вам стоит обдумать (информация к размышлению для пункта 5 из перечня элементарных принципов руководства):

 Просчеты в ходе реализации проекта. Неудачи проекта чаще всего связаны с просчетами. Некоторые решения, принятые несколько дней назад, не срабатывают, поэтому что-то на данный момент не ладится. Проблема в том, что график работ остается прежним: чтобы ему соответствовать, нужно что-то делать. Возможная реакция: внесите изменения в требования, скорректируйте рабочий график (пожертвуйте следующей по списку характеристикой, имеющей самый низкий приоритет) или, если понадобится, исследуйте новые варианты. Если вы будете проводить проектные исследования (см. главы 5 и 6), то в вашем распоряжении может оказаться неплохая резервная и заранее понятная альтернатива.

 Принуждение вас или вашей команды к нерациональным действиям. Причиной такой ситуации может стать какое-нибудь решение со стороны руководства или заказчика, не желающего учесть все аспекты проблемы. Ситуация не из приятных, поскольку вы ею лучше владеете, но ничего не можете предпринять в силу недостатка полномочий. Возможная реакция: смиритесь с тем, что попали в управленческую ловушку. Если вам в этой ситуации как-то удастся добиться успеха, то в будущем вас еще не раз поставят в такое же положение. Если вы потерпите неудачу, то вас обвинят в отсутствии веры в успех. Если проблема приобретает хронический характер, придется прилагать дополнительные усилия (см. главу 16). Расположите по приоритетам ваши возражения, запаситесь конкретными предложениями и используйте все свое мастерство политика и переговорщика (см. далее раздел «Разрешение конфликтов и ведение переговоров»), чтобы пойти по пути компромисса. Пусть вы не одержите победу, но если сможете добиться более толкового руководства, то защитите свою команду. Постарайтесь отложить реализацию бестолкового решения на будущее или перенести ее на тот этап работы, на котором ущерб от нее будет минимальным (см. далее раздел «Борьба за живучесть»).

 Срыв рабочего графика или нехватка ресурсов. Когда вероятность выполнения намеченного к следующей контрольной дате объема работ падает ниже 75 %, вера в успех теряется. Удачный исход возможен, но маловероятен. Возможная реакция: обратитесь к главам 2 и 14. Там вы найдете описание критериев выхода из подобных ситуаций и их возможную расстановку по приоритетам. Вам нужно либо урезать функциональность и добавить время к рабочему графику, либо проигнорировать всю доступную вашему пониманию логику развития событий, отписать завещание и все-таки попытаться любыми средствами выдержать сроки. Попробуйте прикинуть, нельзя ли каким-то образом изолировать риск срыва рабочего графика и убрать проблемный пункт с критического пути. А нельзя ли его обменять на что-нибудь менее важное из предстоящего этапа работы. Закон Брука (Brook)^[66] гласит, что привлечение дополнительной рабочей силы при угрозе срыва сроков может не оправдать ваших ожиданий.

 Низкий уровень качества. Если вы не будете контролировать качество, то не сможете узнать о его снижении. Если вы построили работу по принципу ежедневных заданий или имеете ряд часто отслеживаемых параметров (подсчет ошибок и т. д.), то узнаете об этом практически сразу. Существует множество критериев снижения качества: сложный для последующей модификации программный код, не выполненные в полном объеме требования, низкая производительность или нестабильность работы программы. Причин снижения качества тоже немало: технические (связанные с основными методами разработки), производственные (связанные с контрольными процедурами и инструментальными средствами) или планировочные (связанные с календарным и общим планированием). Возможная реакция: установите для команды критерии высокого качества и ставьте ежедневные цели по их достижению (см. главу 15). Для повышения качества нужно чем-то пожертвовать (функциональностью, временем). Часто бывает, что лучше снизить темп работы до тех пор, пока уровень качества не достигнет нужных высот, и все не узнают, как этого достичь, а затем восстановить прежний темп.

 Смена направления. Руководство или складывающаяся рыночная ситуация может потребовать изменений. Для проекта в этом может и не быть ничего плохого (можно даже рассчитывать на некий прогресс), но и радоваться тут, пожалуй, особо нечему. В смену направления могут вмешаться бюджетные сокращения или новые общие цели. Возможная реакция: нужно выяснить, нельзя ли ограничиться изменениями отдельных компонентов? Выделите те технические условия или их части, которые все еще жизнеспособны, и сохраните их в конвейере разработки (см. главу 14), затем расположите по приоритетам все, что требуется изменить. Убедитесь в том, что вы не попадаете в сферу действия безапелляционного приказа; ведь сказать: «Сделайте X» – не одно и то же, что сказать: «Мы должны увеличить доход на 10 %». Первое является директивой, второе – решаемой проблемой. Добейтесь выяснения сути проблем и вмешайтесь в процесс, предлагая приемлемые для себя решения (см. далее раздел «Разрешение конфликтов и ведение переговоров»).

 Общекомандные или личные проблемы. Бывает, что недовольство одного или нескольких человек негативно отражается на всей команде. Недовольство может быть вызваны кем-то («Я не могу работать с Фрэдом») или чем-то («Я ненавижу наш способ анализа программного кода»). Возможная реакция: сначала поговорите с глазу на глаз со всеми фигурантами. Спросите каждого, что происходит и что можно сделать (вам или ему), чтобы улучшить ситуацию. Устраните проблему и дайте людям возможность найти выход. Ищите не только симптомы, но и причины (см. далее раздел «Разрешение конфликтов и ведение переговоров»).

 Разногласия и конфликтные ситуации. Люди открыто не согласны с тем, что должно быть сделано (потенциально это может пойти проекту на пользу), но их несогласие тормозит прогресс. Больше времени тратится не на саму работу, а на дебаты и постоянные пересмотры того, что следует делать. В экстремальных случаях разные группы тайком работают в разных направлениях. Возможная реакция: обратитесь далее к разделу «Разрешение конфликтов и ведение переговоров».

 Недостаток веры. Команда совсем не верит в направление работ по реализации проекта. Люди успешно справляются со своей работой и не выражают активного несогласия, но считают, что корабль плывет прямиком на айсберг. Возможные варианты: посмотрите, может быть, они и правы. Если нет, воспользуйтесь всем своим влиянием (см. главу 16), чтобы убедить команду в обоснованности выбранного направления. Начните с малого: кто верит в успех больше всех? Как можно развить его веру и распространить ее на всю команду? Попробуйте поставить команде более узкие задачи и дать толчок к их выполнению. Пройдитесь по офисам и задайте вопрос начистоту: «Послушайте, я знаю, что вы не верите в это направление, но я в него верю. Могу ли я как-нибудь убедить вас последовать этому направлению? Если нет, то не могли бы вы все равно мне довериться, хотя бы на неделю?»

 Угроза мятежа. Это экстремально резкая форма выражения неверия в успех. Такой момент наступает, когда командой уже пройден порог крушения всех надежд, и люди практически не реагируют на любую вновь вскрывшуюся проблему, какой бы мелкой она ни была. Более того, люди больше жалуются на мнимые проблемы (к примеру, «Почему руководство, или тестировщики, или маркетологи продолжают работать в прежнем направлении?»), а не решают проблемы насущные. Если ничего не предпринимается, недовольство могут поддержать старые сотрудники, и начнется мелкий или символический саботаж (например, устранение некоторых ошибок может внезапно усложниться). Кто-то должен прямо выступить против сложившейся ситуации и разрядить обстановку. Нужно публично признать факт кризиса, составить список всех жалоб и открыто заняться рассмотрением некоторых из них.

Многое из того, что может усложнить ситуации такого рода, относится не к ситуации как таковой, а к обстановке, в которой она происходит. Чем позже в рабочем графике возникнут проблемы и чем слабее моральный дух команды (или руководителя проекта), тем сложнее будет справиться с ситуацией. Ближе к концу вариантов возможных действий по решению проблемы становится все меньше, а ставки в игре все выше. Иногда это обстоятельство упрощает завершение дебатов, стоит только указать на рабочий график. На этапе эндшпиля многие проблемы разного характера требуют для внесения изменений в проект просто непомерных затрат, и доводы в пользу того, чтобы оставить все как есть, устранив проблему в следующей версии (или на следующем этапе), воспринимаются намного легче. Но учтите, что замораживание проблемы не приводит к ее решению: это всего лишь означает, что, отказавшись от решения, вы избрали наиболее простой путь, что, в рамках текущего проекта может быть как правильным, так и неправильным шагом.

Также важно понять, что у трудных ситуаций часто бывают неявное начало и такое же не вполне очевидное завершение. На вашем столе не загорится никакая красная лампочка, предупреждающая о падении морального духа или о том, что мгновение назад был допущен просчет. Вам самим нужно быть на страже, но даже тогда вам не всегда будет на все 100 % понятно, что именно происходит. Ну, а если возникнет проблема и вы решите на нее прореагировать, то вполне вероятно, что вам удастся лишь смягчить ее или минимизировать ее влияние, поскольку ее полного решения может просто не существовать. А это значит, что, в конечном итоге, вам в течение многих недель или даже месяцев придется справляться с более мелкими проблемами и симптомами, порожденными главной проблемой. (Например, справляться с двумя программистами или тестировщиками, которые никак не могут ужиться вместе. Вы можете помочь им навести мосты, но полностью погасить их конфликт вам не удастся.) Итак, частью вашей реакцией на неблагоприятную ситуацию может стать выделение времени на то, чтобы вывести все хронические или не имеющие решения проблемы на некий терпимый уровень. Чем больше будет проблем, с которыми вы справляетесь таким способом, тем больше времени вам придется посвятить их нейтрализации и борьбе за живучесть.

Практикуйтесь в преодолении трудностей

Хорошая тренировка для руководителей проектов должна включать упражнения и игры, в которых моделируется их пребывание в сложных ситуациях. Я пришел к выводу, что обучение людей действиям в идеальной обстановке лучше всего подходит для изучения теоретических основ, а совершенствование управленческого мастерства и усвоение теории достигается лишь изучением действий в неблагоприятных и сложных ситуациях. В самых успешных из проводимых мною курсов основное внимание уделялось не формулам и концепциям, а ситуациям и упражнениям на действия в сложной обстановке. Если проще выразиться, управление проектами – это не тихое плаванье в полный штиль при ясном небе. Для этого занятия требуется знать, как выкручиваться, как расставлять все по приоритетам, как реагировать на все неожиданности и сложности, встречающиеся на пути. (Хотя, возможно, вершина мастерства руководителей проектов и состоит в том, чтобы превратить бурное море в гладкую воду перед тем, как команда поставит паруса.)

Итак, если вы работаете с руководителями проектов или являетесь их начальником и не имеете возможности для надлежащего обучения, то вам в качестве возможностей для обучения необходимо воспользоваться возникающими сложными ситуациями. Несмотря на все стрессы и неприятности с ними связанные, приобретаемый при этом опыт станет бесценным вкладом в следующий проект, если, конечно, у вас впоследствии найдется время для анализа. Стюарт Брэнд (Stewart Brand) как-то сказал: «Бестолковая суета ведет к наслоению ошибок, а продуманное поведение позволяет на них учиться».^[67] Даже при самых крупных неприятностях руководители проектов демонстрируют сдержанную реакцию. И пока ситуация не приобретет для команды по-настоящему фатальный характер, всегда есть возможность извлечь из нее какие-то уроки.

В отношении других сложных ситуаций можно сказать следующее: способов преодоления возможных проблем великое множество. Если вы хотите изучить их расширенный список, то лучший, из всех мне встречавшихся источников находится в главе 3 книги Стива Мак-Коннела (McConnell) «Rapid Development» (Microsoft Press, 1996). Вторым по ценности можно назвать бессистемный каталог http://c2.com/cgi/wiki?AntiPatternsCatalog, который в настоящее время является наиболее интересным и колоритным чтивом, правда, его труднее применить на деле и он не всегда отличается хорошим языком (что не удивительно, поскольку он относится к Вики-системам).

Берите ответственность на себя

То, что вы берете всю ответственность на себя, еще не означает вашей вины – это означает, что вы будете отвечать за разрешение возникшей ситуации. Многие боятся этого, потому что не хотят отвечать за что-нибудь и подставлять себя под взыскания. Хороший руководитель должен вести себя совсем иначе: в вопросах, касающихся его команды, он должен искать любую возможность, чтобы взять всю ответственность на себя и использовать ее на благо команды и проекта. Если избавление разработчика или тестировщика от опасений попасть под обвинения позволит мне принять лучшее или более быстрое решение, я с удовольствием возьму этот прием на вооружение. А если мой собственный руководитель достаточно профессионально работает, то принятая мною ответственность заслужит его одобрение. Возлагая на себя реальную ответственность за решение проблемы, я сразу же делаю ее менее опасной для проекта (см. далее раздел «Роли и четко определенные полномочия»).

Идею о возложении ответственности можно вывести за область обвинений или неудач и распространить на всю сферу взаимоотношений с людьми. Ларри Константин (Larry Constantine) в книге «Beyond Chaos: The Expert Edge in Managing Software Development» (Addison Wesley, 2001) пишет:

Вместо того чтобы удивляться, почему у некоторых людей такой сложный характер, куда полезнее спросить самого себя, почему у меня возникают сложности в общении с ними. Разумеется, заметить соринку в чужом глазу намного проще, чем бревно в собственном, но все неприятности общения со сложными людьми дают возможность лучше понять себя самого. Должно пройти достаточно времени, прежде чем вы сможете заметить, что для вас сложных в общении людей становится все меньше и меньше.

Это обстоятельство особенно трудно переоценить в сложных ситуациях, когда люди могут проявлять раздражительность и невыдержанность. Если вы сможете положиться на собственную зрелость и мудрость, чтобы преодолеть опасения или нелогичное поведение других людей, то у вас появится возможность довести проект до успешного завершения, несмотря на недовольство и неконструктивное поведение сотрудников.

Возложив на себя ответственность, особенно за провальные ситуации, вы неизменно получаете возможность профессионального роста. Подставляя собственное плечо, вы облекаете себя определенной властью, поскольку оказываетесь в самом центре событий. Отрицание вины или уклонение от ответственности дадут вам возможность избежать кратковременных проблем, связанных с неразберихой, или дать ответы старшему руководству на сложные вопросы, но не позволят извлечь уроки или совершенствовать и демонстрировать свои возможности. Если вы хотите развить навыки выхода из критических ситуаций, вы непременно сами должны гореть желанием принять огонь на себя.

Используйте на практике свою готовность взять ответственность на себя, чтобы поддержать других в кризисной ситуации. Добавьте в свой сценарий работы с людьми следующую фразу: «Я не знаю, как это случилось, но меня сейчас волнует совсем не это. Мы можем разобраться с этим чуть позже, а когда мы все сделаем, я помогу ответить за все, что случилось. Но, поскольку так уж вышло, сейчас нам нужно сделать X, Y и Z. Ну что, поможете мне понять, как сделать X, Y и Z?»

В качестве альтернативы в некоторых ситуациях самым сильным вашим ходом может стать передача полномочий (в главе 12 я подымаю вопрос о том, какую важную роль играет доверие и как можно использовать в интересах проекта одну их основных его форм – делегирование полномочий). Подтверждение вашей веры в чьи-то возможности в тяжелые времена может стать более эффективным поступком, чем любой ваш интеллектуальный или технический вклад: «Послушай, Салли. Я тебе доверяю. Я знаю, что это непростая проблема, но ты ведь специалист в этом деле. Что бы ты ни думала о том, как с ней справиться, я поддержу твое мнение. Но вот моя оценка ситуации. Обдумай ее. Если ты с ней все же не согласишься, поступай как знаешь».

Борьба за живучесть

Если одновременно возникнет слишком много проблем или однажды произойдет действительно что-то из ряда вон выходящее, то на первый план должна выйти борьба за живучесть. Это значит, что с самого первого шага главным приоритетом будет возвращение проекта в более-менее приемлемое состояние. Представьте, что вы пилот Боинга-747 и у вас пропала тяга всех двигателей. Пока вы не выведете двигатели на рабочий режим, ни что иное для вас не будет иметь ни малейшего значения. Все ваши силы должны быть брошены на решение одной-единственной проблемы, от которой зависит решение всех остальных проблем. Это значит, что вы работаете в режиме борьбы за живучесть.

В такой ситуации пилоты и капитаны обучены проводить диагностику проблемы и пытаться изолировать как ее симптомы, так и причины. Пилоты воздушных лайнеров и астронавты имеют на этот счет конкретные процедуры, применяемые для каждой сложной ситуации, в которую они могут попасть (часто из-за своей многочисленности эти процедуры расписаны в специальной книге). Замысел состоит в том, что когда жареный петух клюнет их в мягкое место, у них уже не будет времени изобретать процедуру, у них даже может вообще не быть времени на какие бы то ни было процедуры. Поэтому, когда пилоты неожиданно оказываются в критической ситуации, они приступают к проведению цикла диагностики и методично работают над проблемой, пока не найдут ее решения (или пока не произойдет крушения, если они этого не сделают).

Работая руководителем проекта, вы когда-нибудь все равно попадете в ситуацию, требующую вступить в борьбу за живучесть. Вам некогда будет исследовать альтернативы или разбираться с вариантами. Нечто очень важное окажется у вас в весьма плачевном состоянии и не будет ясного представления о том, как с этим справиться. Чтобы разрешить такую ситуацию, действуйте следующим образом:

 Свистать всех наверх. Когда в чем-то очень важном происходит серьезный сбой, эта новость моментально распространяется по всей команде. Чем дольше вы будете затягивать свое обращение к народу, тем больше будет в команде разброда и шатаний на момент объявления аврала. Берите быка за рога и созывайте совещание или разошлите по электронной почте сообщение с наивысшим приоритетом. Коротко обрисуйте ситуацию и предпринимаемые действия. По возможности объясните свои действия за последние сутки (см. ранее раздел «Элементарные принципы руководства») и назначьте следующее время для новостей. Не скрывайте серьезных проблем: команда почувствует неладное, как бы хорошо вы все не скрывали.

 Если люди с вами не согласны, найдите общую точку зрения. Этот момент лучше объяснен в следующем разделе. Но если вам кажется, что все присутствующие не согласны с тем, что происходит, или с тем, что нужно делать, наведите порядок и верните дискуссию в исходное состояние. Вернитесь к последней согласованной точке зрения: «Все согласны с тем, что наши задачи – это А, Б и В, и именно в такой последовательности?» Как только вы обретете согласие, пусть по самой простой позиции, снова подведите всех к возникшим проблемам. Ставьте вопросы по одному и не позволяйте дискуссии перескакивать через них, пока не будет найдено решение или для его принятия не будет назначен кто-нибудь отсутствующий на совещании.

 Каким было последнее известное стабильное состояние команды или проекта? Если проблема носит технический характер, осуществите экскурс в историю ежедневных разработок (которые вами сохранялись или архивировались) и найдите последнюю удачную сборку. Возьмите ее за основу и верните проект к этому состоянию. Возможно, такой путь окажется более быстрым, чем продолжение проекта с той точки, в которой он оказался. Программисты смогут вручную внести все утраченные поправки, а вы сможете ужесточить контроль, чтобы исключить причину возникшей проблемы. Шаг, конечно, радикальный, но он обеспечивает стабильность и осуществляется в рамках рабочего графика.

 Нельзя ли изолировать проблему? Подумайте о корабле, охваченном огнем. Может ли пожар распространиться дальше? Нельзя ли защитить от огня те части корабля, от которых зависит его живучесть? Подумайте, как локализовать проблему и предупредить ее влияние на наиболее критичные части вашего проекта. Возможно, потребуется пожертвовать какими-то менее важными обязательствами или перекинуть часть ресурсов от одной группы к другой. Может, понадобится кратковременная поддержка со стороны специалистов из других областей, чтобы помочь изолировать или сдержать проблему, поскольку обеспечение стабильности проекта того стоит.

 Нельзя ли для заделывания бреши привлечь дополнительные ресурсы? В некоторых случаях для устранения проблемы вы можете потратить имеющийся у вас резерв (в смысле денег или кадров). Как и в случае с реальным несчастьем, землетрясением или торнадо, вы можете потратить деньги на перенастройку проекта или на немедленную закупку нового оборудования, чтобы помочь проекту удержаться на плаву, пока не будут найдены долгосрочные решения. Если вы обнаружили серьезный пробел в вопросах качества, то в некоторых случаях можно привлечь дополнительные силы со стороны и прикрыть оголенные на данный момент участки тестирования или процессы разработки. Иногда при правильном определении цели и верной постановке задачи вливание денежных и других ресурсов может оказаться вполне эффективным.

Разрешение конфликтов и ведение переговоров

Нас должно волновать не количество людей, выступающих против, а то, насколько хороша их аргументация, чтобы выступать против.

Ален де Боттон (Alain de Botton)

Устранение разногласий является постоянной обязанностью руководителей. Рассмотрение вопроса ведения переговоров лишь в этой главе еще не означает, что на переговоры приходится идти только в условиях, когда что-то идет не так, как надо. Наоборот, у вполне здоровой команды может быть множество мнений, регулярно вызывающих разногласия. Пока люди обсуждают достоинства различных идей и уважительно относятся друг к другу, разногласия обеспечивают существование различных точек зрения и ведут к прогрессу. Важно, как именно люди, испытывающие разногласия, относятся друг к другу, как эти разногласия разрешаются и перерастают ли споры и дебаты в полезные действия.

Из этого следует, что в кризисной ситуации способность разрешать разногласия приобретает решающее значение. На данный момент лучший источник, помогающий выработке правильного отношения к данному вопросу и навыка в его решении, – небольшая книга Роджера Фишера (Roger Fisher) и других «Getting to Yes» (Penguin Books, 1991).^[68] Она попалась мне на глаза, когда моя карьера уже в достаточной степени сложилась, и читая ее, я лучше понимал все, что происходило на тех переговорах, которые я когда-то вел. Я также понял, что переговоры принимают множество различных форм. Иногда мне приходилось помогать двум сотрудникам своей команды решить их проблему. А иногда я сам был одним из тех двоих, имеющих разногласия, и не было никого третьего, кто бы был заинтересован в разрешении конфликта, поэтому я сам был вынужден вести переговоры. Во всех подобных случаях срабатывал найденный мною подход.

 Найдите общую точку зрения. Независимо от глубины своих разногласий, оба человека согласны в том, что: Земля круглая, небо голубое, проект нужно закончить в срок. Отыщите существенные общие точки зрения и взаимного согласия и воспользуйтесь ими в качестве отправных во всех своих дискуссиях. Любые переговоры хочется начать с положительного импульса. Направляйте все спорные вопросы в русло общих интересов и разделяемых точек зрения. Составьте диаграммы Венна для вопросов, интересующих сторону А, и для вопросов, интересующих сторону Б, после чего посмотрите, где лежат области их пересечения. Если такие области отсутствуют, значит, что-то упущено: откуда могут взяться разногласия, если нет общих интересов?

 Выявите конфликты, имеющие персональный характер, и забудьте о них. Вы можете довольно легко попасть в ловушку, позволив чьим-то проявлениям характера увести вас в сторону от цели переговоров, особенно если вы сами представляете одну из сторон. Вместо попыток поиска взаимоприемлемых ситуаций переговоры можно довольно легко превратить в соревнование, из которого вам захочется выйти победителем или, хуже того, в котором захочется заставить проиграть своего оппонента. Это полностью отвлечет вас от реальных задач. Если вы поймете, что человек, конфликт с которым вы пытаетесь разрешить, вам не нравится, постарайтесь найти способ отделить эти чувства от решаемой задачи (или передайте свои полномочия кому-нибудь другому). Сконцентрируйте внимание на том, как выиграет проект от решения проблемы, и мотивируйте свои действия именно этим.

 Ищите взаимный интерес. Если вы воспользуетесь возможными способами разрешения какой-нибудь ситуации, то найдете варианты, выгодные для обеих сторон. Найти их можно, лишь направив дискуссию в русло поиска взаимных интересов, а не выяснения противоположных позиций. Позиция представляет собой набор определенных потребностей («Я буду есть только шоколадный торт»). А интерес является целью высокого уровня («Я хочу получить вкусный и качественный десерт»). Интересы могут быть удовлетворены множеством различных способов, а у позиции решений немного. Зачастую конфликтующие друг с другом люди даже не подозревают об интересах друг друга, тратя энергию на столкновение различных позиций. Воспринимать интересы и иметь дело с ними намного проще, чем разбираться с позициями. Заставьте людей перевести разговор на интересы и прийти к согласию (или хотя бы к пониманию) на данном уровне, перед тем как затевать дискуссию по поводу позиций. Составьте список интересов обеих сторон и обратите их к общей точке зрения.

 Действуйте решительно, но гибко. Если у вас есть твердая позиция, которую непременно нужно отстоять, поищите другие менее важные позиции, в отношении которых можно проявить гибкость. Если вы не можете сдвинуть свои сроки, может, имеет смысл внести изменения в функциональность вашего продукта? Если вы не можете выделить больше времени, может, имеет смысл выделить больше денег? Вам нужно знать, в каких вопросах можно проявить гибкость, а в каких следует стоять на своем. Чем лучше вы знаете человека, с которым ведете переговоры, тем проще будет предложить ему те вещи, которые для него имеют больше ценности, чем для вас. Можно с уверенностью сказать, что если вы ни в чем не проявите гибкость, то, скорее всего, вы недостаточно понимаете, в чем состоят ваши собственные интересы (возможно, из-за того, что руководство посвятило вас только в свои позиции, а не в интересы).

 Изучите альтернативы. Никогда не прекращайте переговоры, не понимая, во что вам обойдется ваш уход из-за стола и во что это выльется для ваших партнеров. В книге «Getting to Yes» это называется BATNA (Best Alternative To Negotiated Agreement – лучшая альтернатива для переговорного соглашения). Идея в том, чтобы понять, какие интересы и позиции вы отстаиваете. Чем лучше ваш вариант BATNA по отношению к альтернативе партнеров, тем, вероятно, больше ваша пробивная переговорная сила. Пусть, к примеру, вы оказались в пустыне с одним галлоном пресной воды и встретили дюжину измученных жаждой людей. Фрэд предлагает за воду 5 долларов. Вы можете ему отказать и, вероятно, дождетесь более выгодного предложения от других, но Фрэд может вести переговоры только с вами. У него мало разумных альтернатив, а у вас много. Фрэд может быть лучшим переговорщиком в мире, но это обстоятельство не будет играть существенной роли, если вы знаете о превосходстве своих вариантов над теми, что есть у него.^[69]

 Убеждайте и аргументируйте. В большинстве случаев интересы и запросы обеих сторон основываются на субъективных мнениях об относительной ценности вещей. Значит, если вы сможете проникнуть в чувства одной из сторон, вам, возможно, удастся склонить ее к тому, что какой-то из аспектов ситуации более (или менее) желаем, чем ранее казалось. Умение убеждать – это настоящее искусство: в нем сочетается харизма, коммуникабельность, логика и психология, то есть все те вещи, которые при желании приходят с опытом. Убеждая других, постарайтесь быть тактичным и сосредоточить основное внимание на наиболее важных для прогресса вопросах.

Ведение переговоров на самом деле является особой формой дискуссии. Соберите в зале только нужных вам людей (см. ранее раздел «Элементарные принципы руководства»), наметьте повестку дня, включающую дискуссию по проблемам и интересам, а затем займитесь поиском возможных альтернатив, с помощью которых их можно разрешить и удовлетворить. Если конфликт возник внутри вашей организации, то для выработки базы для высокоуровневых интересов всех вовлеченных сторон (общей точки зрения) вы вполне можете опереться на цели проекта. Различные предложения и контрпредложения могут рассматриваться до тех пор, пока не будет достигнуто соглашение.

Если конфликт возникает между людьми из двух разных организаций, ситуация усложняется, поскольку между вовлеченными в него людьми может быть меньше доверия и слабее уровень взаимоотношений. На первый план должна быть выдвинута задача создания некоего подобия целям проекта. (Зачем мы ведем совместные дела? В чем состоят взаимные выгоды от обмена результатами работы или ресурсами?) Как правило, все это должно быть сделано еще в стадии завязывания отношений (простейшей формой подобного соглашения является контракт). Должны быть выяснены интересы каждой из сторон и выработаны основы взаимоотношений, на которые можно будет сослаться, если в будущем возникнут конфликты и разногласия (именно соглашения в первую очередь способны свести подобные разногласия к минимуму). Но вместо предварительного соглашения, оно может быть заключено пост-фактум. Разрешить конфликт намного труднее при низком уровне доверия и доброжелательности, но это – единственный способ найти приемлемое решение.

Роли и четко определенные полномочия

Из занятий соревновательными видами спорта я извлек два урока. Во-первых, истинное доверие возникает лишь при встрече с трудностями и в процессе их преодоления. Только при проведении диспута, когда кто-то чем-то расстроен и вскрывается истина, возникает возможность укрепления взаимоотношений. Во-вторых, слаженная работа хорошей команды получается благодаря тому, что каждый знает свою роль не хуже, чем роли всех своих коллег. Когда каждый может положиться на вклад всех остальных и спокойно заниматься своим делом, все идет хорошо. Солист рок-группы не сможет выдать хорошего соло, если басист и ударник не зададут ему четкий ритмический рисунок. То же самое относится к нападающим и разыгрывающим в баскетболе, к форвардам и хавбекам в футболе. И разумеется, то же относится к программистам, тестировщикам и другим специалистам команды разработчиков.

По мере роста напряженности в команде возрастает возможность зависимости друг от друга. Все может сломаться, и люди, впервые столкнувшись с неудачей, испытывают страх или обвиняют во всем всех, кроме себя. В сложной работе часто складывается высокая степень взаимозависимости, означающая, что Фрэд знает, что он не сможет закончить свой тест, если Сара не сдаст к сроку свой фрагмент программного кода. Его волнения вполне обоснованы: у него нет достаточного опыта совместной работы, чтобы быть уверенным в ее способности справляться со своими обязательствами в сложных ситуациях.

Поэтому, когда возникает напряженность, в неопытных командах обычно наблюдается борьба ролей. Одни специалисты начинают ставить под сомнение способности других и предпринимают все доступные им меры защиты от чужих неудач (часто при этом тратя энергию впустую). Поступать подобным образом могут даже опытные люди, если они работают в команде, составленной из специалистов, не испытывающих особого доверия друг к другу.

Для руководителя проекта это означает, что укрепление ролевой структуры команды в тяжелые времена выдвигается на первый план. Нужно напомнить каждому, в какой степени от его работы зависят все остальные и какие результаты работы ему следует ожидать от других. Лидер должен выявить всех испуганных и напомнить им о том, что он вполне уверен в возможностях команды. Выясните, кто из сотрудников чувствует себя уязвленным, и займитесь изменением их восприятия. Сплочение команды не требует высокопарных речей и резких жестов. Нужно просто прийти к людям и вызвать у них чувство сопричастности к происходящему, вселить в них веру в способности внести свой вклад в успех общего дела.

Иногда для исполнения своих ролей люди нуждаются в поддержке и защите. Руководитель проекта должен поддержать тех людей, которые стараются выполнять свою работу, но получают несправедливые упреки от коллег. Зачастую подобное случается при ролевых разногласиях, к примеру, между программистами и тестировщиками, между разработчиками и специалистами по маркетингу. Поэтому случайно услышав какое-нибудь несправедливое замечание, вроде: «Боб, наверное, полный идиот, поскольку до сих пор не провел этот тест», вы должны выбрать момент и сказать: «Стив, Боб сейчас отстает, потому что команда разработчиков всю прошлую неделю топталась на месте. Не могли бы вы его выручить, ведь команда тестировщиков не раз вас выручала?» Станьте совестью команды и поддерживайте честные отношения между людьми, когда в этом возникает необходимость.

Если действительно в чем-нибудь проявится чья-то некомпетентность (например, Боб на самом деле окажется идиотом), руководитель проекта обязан нанять менеджеров и убедиться в том, что решение проблемы поручено тому, кто справится с ней наилучшим образом. (Основанием для вашей реакции должна стать та роль, с которой, как предполагается, данный человек не вполне справляется. Возможно, здесь дело не столько в компетентности, сколько в недопонимании ролей и обязанностей.) В большинстве случаев проблемы команд в стрессовой ситуации касаются вопросов общения, недобросовестности, недоверия и неразберихи в распределении ролей, а не глупости или неумения в чистом виде.

Все должны знать, кто принимает решения

В сложные времена не должно быть сомнений в том, кто имеет право принимать решения. Если команда зашла в тупик и в ближайшие пять минут нужно отдать какие-то жесткие распоряжения, от которых зависит судьба проекта, то кто должен это сделать? В военных организациях существует четкая иерархическая цепочка, поэтому там всегда есть точный ответ на данный вопрос. Поскольку решения должны приниматься в стрессовой ситуации и в кратчайшие сроки, нужна управляющая структура, не допускающая пререканий, рассчитанная на эффективные действия, независимо от степени запутанности ситуации. Большинство распоряжений, получаемых солдатами, основано на доверии командованию. А для проектов должно быть следующее правило: чем сильнее давление обстоятельств и выше ставки, тем меньше должно быть сомнений насчет того, в чьих руках находится власть.

При реализации проектов череда инстанций, задействованных в принятии сложных решений, должна определяться руководством, а точнее – руководством проекта. Если возникшие сложности касаются вопросов бизнеса, технологии и технических требований, никакой отдельный специалист (по маркетингу или разработке) не будет иметь нужный для этого всеобъемлющий кругозор. А руководитель проекта, учитывая степень его вовлеченности в проект, обладает самым точным пониманием различных взглядов и возможностью повлиять на принимаемые компромиссные решения. Если обязанности по руководству проектом возложены на несколько человек, должно быть абсолютно понятно, кто что решает и кто привлекается к выработке решения. Дискуссии по поводу распределения ролей, рассмотренные в главе 9, должны включать вопрос о полномочиях в принятии решений и могут использоваться для выяснения других вопросов, касающихся распределения властных полномочий.

При этом необходимо помнить, что человек, принимающий решение, кем бы он ни был, всегда имеет право передать свои полномочия или разделить их с кем-нибудь еще. Главное не в том, что все сложные решения принимаются Бобом, Майклом или самим господином вице-президентом, а в том, что в данной организации всем еще задолго до возникновения кризисной ситуации известно, кто из них чем займется, когда нужно будет принимать решение того или иного рода. Это позволит увеличить скорость принятия решений, влияющих на работу команды, и не допустить перерастания мелких угроз в крупные неприятности.

Арсенал эмоций – работа под давлением, чувства от чувств и комплекс героя

В этом последнем разделе главы рассматриваются темы, связанные с эмоциями. Эмоции существенно влияют на работу тех команд, чьи дела идут из рук вон плохо. Я не ставлю своей целью предоставить вам полный психологический трактат по кризисному управлению, а даю руководство по проблемам, с которыми вы можете столкнуться, и делюсь размышлениями по их преодолению.

Работа под давлением обстоятельств

Наиболее подходящим из найденных мной определений слову «давление» является следующее:

Давление (гл.) – принуждение, вынуждающее влияние или сила.

Ключевым здесь является слово принуждение. Быть под давлением означает, что существует неустранимое принуждение, с которым нельзя не считаться. Факторами принуждения может стать дефицит времени, ресурсов, непреодолимые сложности ситуации или все вместе взятое. Существование этих принуждающих обстоятельств означает, что сокращается число доступных вариантов и уменьшается время на разрешение проблемы независимо от степени ее сложности.

Но когда люди говорят, что находятся под давлением обстоятельств, они вкладывают в слово «давление» некоторое чувство опасения, что не смогут преодолеть существующее принуждение. Ситуации, при которых испытывается давление обстоятельств, к примеру, политические дебаты или вторая подача на брейке в теннисном матче, означают, что на кону стоит нечто важное, что легко и просто может быть утрачено (или, по крайней мере, так это представляется). Нередко к этому причастны и другие люди, которые могут пострадать в случае неудачи, что еще больше усиливает чувство давления обстоятельств.

В отношении давления обстоятельств важнее всего понять, что люди по-разному на него реагируют. Степень восприимчивости у всех людей разная, поэтому в различных ситуациях они страдают от этого состояния в большей или меньшей степени. Способы справиться с давлением обстоятельств у них тоже разные. Для одних избавиться от давления или стресса помогают физические нагрузки, другим больше помогает юмор. Но, как это ни печально, многие из нас просто не знают, как им справиться с подобным состоянием.

В сложной ситуации у руководителя проекта возникает еще одна дополнительная задача – обеспечить возможность ослабления стресса. Если команда увидит, что лидеры подшучивают над собственной реакцией на стресс («Доберусь до дома, возьму упаковку пива, бутылок шесть, и приму самую затяжную ванну в истории»), то им последуют и все остальные. Если ведущий программист, чтобы выпустить пар после работы, зовет всех своих ближайших коллег в гимнастический зал (или на пейнтбол), то им предоставляется возможность испытать это средство в качестве лекарства от стресса. Даже те, кто в этом не участвует, получат возможность определить силу собственного стресса и подобрать лучшее средство избавления от него. И наоборот, если лидеры склонны к репрессиям и не признаются в собственном стрессовом состоянии, делая вид, что они его не ощущают или что им не нужно никакого расслабления (наивно полагая, что поступают мужественно), они только усложняют всем жизнь. Не позволяйте команде думать, что потребность в снятии стресса является признаком слабости.

Не следует прибегать и к скрытым угрозам: «Если ваши стрессы настолько глубоки, что требуют снятия, возможно, вам не стоит работать в нашей команде». Старайтесь также избежать обезоруживающих насмешек: «Йога? Наверное, подходящее занятие, если вам нужна столь радикальная помощь». Так обычно высказываются руководители, не знающие, что бы им самим могло подойти в подобной ситуации. Снятие стресса обычно не требует больших расходов и не имеет побочных эффектов. Даже если выбранное занятие не поможет снятию стресса, сам факт, что людей поддержали в попытке избавиться от него (или дали им разрешение на это без ущемления их заработка), принесет моральную пользу. Я наблюдал, как находчивые руководители в трудной ситуации приглашали массажистку и проходили с ней по кабинетам, предлагая каждому работнику 10-минутный массаж. Эффект был поразительный: даже те, кто отказывался, еще долго об этом вспоминали.

Естественное и искусственное давление

Давление – это сила, подконтрольная руководству. Но чтобы воспользоваться некоторыми приемами изменения природы давления и управлять командой в кризисной ситуации, нужно иметь соответствующие представления. Существует четыре разновидности давления: естественное, искусственное, позитивное и негативное (рис. 11.1).

Я рассматриваю естественное давление как чувства, испытываемые людьми, когда взятое ими важное личное обязательство находится под угрозой срыва («Постой, я ведь сказал Сэму, что демо-версия будет у меня работать к 14 часам»). Если им дорого это обязательство и они вкладывают душу в качество своей работы, то они в ответ на давление совершенно самостоятельно соберутся и вложат в дело еще больше энергии. Я называю это естественным давлением, поскольку оно напрямую исходит из работы и из отношения человека к этой работе. В такой ситуации единственное, что нужно сделать руководителю, – это направить и защитить энергию людей, поддержать их в стремлении достичь своих целей. Эту разновидность давления следует в целом считать позитивной, поскольку личная мотивация идет во благо потребностям команды. Тем не менее оно может превратиться и в негативное, если люди чувствуют вину или стыд за невыполненные обязательства, особенно если из-за срыва обязательств проблемы возникают у других специалистов.

Рис. 11.1. Четыре разновидности давления

Искусственное давление представляет собой тактику действий лидеров по созданию и усилению чувства давления в команде. Оно может оказывать как позитивное, так и негативное влияние. Позитивная форма заключается в поощрительном стимулировании, когда людей отмечают за интенсивный труд и повышение личной производительности в критической ситуации (например, повышения, продвижения по службе, привилегии). Примером позитивной реакции может быть сверхурочная добровольная работа, после того как лидеры попросят (а не потребуют), чтобы команда работала интенсивнее (возможно, с применением стимулов в виде оплаченного ужина для тех, кто задерживается на работе допоздна, или разрешения сотрудникам работать на дому). Иногда искусственное давление может принимать форму воодушевляющих митингов, на которых подогревается позитивная атмосфера вокруг проекта (возможно, создающая для кого-то в команде моменты естественного давления) и подымается новый энергетический всплеск.

Негативные формы искусственного давления включают в себя ругань, обвинения или угрозы как способ заставить людей работать интенсивнее. Иногда лидеры начинают обвинять команду за допущенные промашки, требуют приложить все силы для устранения проблем, которые могут быть ими вызваны. Это (насколько я знаю армию) менталитет сержанта учебного подразделения: чтобы поддерживать дисциплину, лучше всего постоянно орать.

Чаще всего для поддержания рабочего тонуса команды руководители используют некую комбинацию из естественного, искусственного, позитивного и негативного давления. Сам я приверженец позитивного давления и пользуюсь негативными силами лишь изредка и с осторожностью с целью встряхнуть команду и заставить ее собраться. В целом должен соблюдаться тонкий баланс, не имеющий точных формул. Совершенствовать свои навыки применения различных видов давления вы сможете лишь по мере накопления опыта руководства командами и изучения свойств человеческого характера. Вы поймете, что теорию оказания давления разработали весьма опытные руководители. Но слишком часто используемые нами теории не оправдывают возлагаемых на них надежд, поскольку были выведены на основе слишком малого количества наблюдений.

Давайте оставим в покое формулировки, чтобы понять, что у команды существует предел, при достижении которого она вообще перестает воспринимать какое-либо давление. На рис. 11.2 показана диаграмма, позаимствованная из первого тома «Systems Thinking» книги Джеральда Вейнберга (Gerald Weinberg) «Quality Software Management» (Dorset House, 1996). На ней показана кривая производительности труда команды, работающей под давлением. Некоторое время при повышении степени давления большинство людей и команд показывают рост производительности, но через какое-то время рост прекращается, а затем и вовсе начинается падение. Когда команда достигает максимального уровня производительности (известного также как красная черта, или порог производительности), никакое дополнительное давление не заставит команду работать усерднее, лучше или быстрее. Если продолжать давить дальше, в конечном итоге команда (или человек) «сломается», и дела пойдут намного хуже.

Рис. 11.2. Существует лимит давления, оказываемого в целях повышения производительности труда

Итак, принимая в руководстве командой решение на оказание давления, учтите, что вам придется иметь дело с его предельными величинами. Если команда остается безучастной, то вам, возможно, следует применить иной вид давления, но это также может означать и то, что команда уже достигла своего порога производительности, и никакие действия руководства не заставят ее дать дополнительный прирост. Чтобы увидеть разницу между этими вещами, нужно обладать определенным опытом. Короче говоря, люди из команды, достигшей порога производительности, ходят с понурой головой по коридору без улыбок на лице. Они выглядят и взвинченными и усталыми одновременно. У них моментально опускаются руки, стоит только попросить их заняться решением другой задачи или внести незначительные изменения в уже сделанную работу. Вывести команду из такого «перегоревшего» состояния намного труднее, чем притормозить проект, поэтому лучше сделать последнее. Сбросьте давление, дайте людям день передышки, поиграйте с ними в мини-футбол на парковке или приведите рабочую нагрузку или график работ к какой-нибудь разумной норме.

Чувства от чувств

Прежде чем пропустить чтение этого раздела, предполагая, что его излишне чувственная направленность вас вряд ли коснется, ответьте мне на один вопрос. Приходилось ли вам когда-либо удивляться, почему люди в стрессовой ситуации ведут себя по-разному? Если вы на этот счет не задумывались или считаете, что это ни в коей мере к управлению проектами не относится, то дальше можете не читать. Но мне будет жаль тех, кто с вами работает. (По-видимому, система наказаний у вас отработана хорошо.)

Ладно, я был к вам несправедлив, но ведь сработало. В качестве компенсации позвольте преподнести вам драгоценный самородок из разряда описаний человеческого поведения. Вирджина Сатир (Virgina Satir), автор ряда книг по психологии и человеческому поведению, разработала простую модель, помогающую объяснить, почему люди иногда столь непредсказуемы. Попросту говоря, когда мы что-нибудь чувствуем (скажем, огорчение или обиду), у нас сразу же возникает какое-нибудь вторичное чувство о чувстве первичном, и именно это вторичное чувство и является побуждением к действию. Пусть, к примеру, я говорю вам, что от вас забавно пахнет. Тем самым я могу вас расстроить. Но то, что я вас расстроил, скорее всего, заставит вас разозлиться. Итак, вместо того чтобы продемонстрировать чувство досады, вы сможете выразить лишь вторичное чувство злости (простой пример такой ситуации показан на рис. 11.3). Чуть позже вы, наверное, сможете разобраться, что первичным было чувство досады, но буквально через миг все ваши чувства выражаются в ответной реакции на другие чувства.

В первом томе «Systems Thinking» книги «Quality Software Management» Вейнберг пошел еще дальше и объяснил, что у модели Сатир есть другое полезное следствие. Зачастую причиной вторичного чувства является вера в то, что нам преподавали, которая не совместима со здоровым эмоциональным поведением. Чувство злости, вызванное чувством досады, является не общим, а благоприобретенным поведением. На самом деле, согласно Вейнбергу, наши ответы на многие эмоции просто соответствуют тем проявлениям, которые сложились в процессе нашего собственного эмоционального развития.

Рис. 11.3. Модель Сатир объясняет, что первичные чувства не обязательно являются побуждением к действию

Забавной особенностью детского развития является то, что все мы перенимаем чью-нибудь веру и эмоциональную систему. Стиль поведения мы во многом перенимаем от своих родителей, а те, в свою очередь, перенимали его от своих и т. д. Пока кто-нибудь не остановится и не даст оценку своим поведению и эмоциональным проявлениям, независимо от того, у кого это все перенималось, ему трудно будет обрести эмоциональную зрелость и даже разобраться в эмоциональной зрелости и психическом здоровье окружающих. А что еще хуже, мы являемся потенциальными переносчиками вредного и неадекватного поведения (к примеру, передаем его нашим студентам, сотрудникам, друзьям, детям).

Некоторые из позаимствованных нами правил поведения могут быть хорошими, а некоторые – плохими. Но лишь то, что наша конкретная реакция на какие-то события сложилась исторически, еще не означает, что она полезна для нас и способствует прогрессу.

Руководителю проекта из всего этого следует уяснить, что те эмоции, которые порой на него выплескивают сотрудники, не всегда напрямую связаны с предпринятыми им действиями. Вы можете указать на ошибку в чьем-нибудь программном коде, а на вас обидятся, даже если вы сделаете все тактично и обратите внимание на что-нибудь достаточно существенное.

Вам следует предупреждать возникновение каскада подобных не связанных напрямую с вашими действиями чувств. Представьте себе, что в соответствии с диаграммой, изображенной на рис. 11.3, кто-то другой ответил на выражение чувства Б своим заявлением, выражающим чувство В, еще больше затеняя реальную причину исходной ситуации (чувство А). Такое вполне может случиться под занавес встречи пятерых спорщиков и крикунов, каждый из которых находится в собственном эмоциональном состоянии: все они выражают различные спектры чувств и откликов вокруг обсуждаемой темы (припомните, к примеру, последнюю встречу всех своих родственников).

Другие заметные писатели на тему человеческих эмоций, такие как Лео Ф. Баскалья (Leo F. Buscaglia) или Джон Брэдшоу (John Bradshaw), пришли к выводу, что чем крепче психическое здоровье и выше эмоциональная зрелость человека, тем глубже он осознает собственное эмоциональное состояние и состояние других людей, располагая более широким спектром возможностей реагирования на их эмоции.^[70] А это значит, что лидер, способный распознать эмоциональную модель поведения и воспользоваться различными способами управления ситуацией, получает больше шансов на успех.

Комплекс героя

Существует особый тип людей, проявляющих себя в критических ситуациях. Эти люди с комплексом могут провоцировать опасные ситуации только потому, что в состоянии с ними справляться. Их зависимость от острых ощущений и трудностей, присущих чрезвычайным ситуациям, настолько высока, что они в первую очередь не станут стараться препятствовать возникновению неприятностей. Людям с начальной формой комплекса героя просто нравится работать в критических ситуациях. Человек с крайней формой комплекса героя может завести проект в рискованную ситуацию или даже попытаться его саботировать.

Люди, страдающие комплексом героя, особо проявляют себя в трудные для проекта времена. В то время как другие теряют присутствие духа или остерегаются лезть в огонь, эти люди буквально запрыгивают в пламя, как будто кроме проекта для них больше ничего не существует. Прекрасно, когда в команде есть люди с умеренной формой этого комплекса, поскольку они выискивают очаги возгорания и гасят их, но при этом сами по себе редко являются причиной пожара. А крайние проявления комплекса героя нужно отслеживать, поскольку страдающие им люди могут вполне осознанно дестабилизировать проект. Или, что чаще бывает, они бьются насмерть против тех действий, которые позволяют не допустить появление рискованных ситуаций.

Комплекс героя чаще всего развивается у тех, кто начинал свою карьеру с только что организованных или с очень мелких (временных) фирм. Поскольку у таких организаций нередко наблюдается дефицит ресурсов на реализацию своих амбиций, завершение работы зачастую требует героических или сверхчеловеческих усилий.^[71] Если все получится, триумфаторы начинают считать героизм весьма значимым фактором своего успеха. В данном конкретном случае они будут правы. Но прикрываться такой логикой – довольно вредная привычка: если героизм был нужен в ситуации А, это еще не значит, что он понадобиться или будет полезен в ситуациях Б, В и Г.

В основу комплекса героя положено несколько мотивационных убеждений, которые объяснены или опровергнуты в следующем списке:

 Планирование ни к чему, я уже это доказал. Поскольку герой приобрел опыт успешной работы при отсутствии технических условий и рабочего графика, он уверовал в то, что в них нет никакой необходимости. Это неправильное представление, поскольку все проекты разные. Проект, реализуемый пятью специалистами в течение одного месяца, в корне отличается по своей напряженности и рискованности от проекта, в котором участвует двести человек, работающих над ним в течение года. Для этих проектов могут понадобиться различные подходы к управлению, планированию и разработке. Частью неверных представлений является мнение о том, что герой в области разработки программного обеспечения уже познал все, что только можно было познать. Подобная заносчивость не дает ему разглядеть специфические проблемы каждого проекта, для разработки которого требуется собственный баланс системы управления, организации производственного процесса и подбора структуры команды. Варианты всегда и никогда не могут быть правильными ответами на вопрос о необходимости организовывать производственный процесс: все зависит от особенностей конкретного проекта.

 Я работаю только на себя. Это самая эгоистичная мотивация героического поведения – герою просто нравится быть героем. Он настолько увлечен этим, что в процессе игры в героя совершенно не боится что-нибудь разрушить или поставить на грань риска. Признаками такого поведения могут стать бессмысленные состязания со своими коллегами или проявление безразличия к работе других (и даже к целям проекта). Герой может не понимать, что его стремление стать героем чревато любыми возможными последствиями (теми побочными явлениями, которые в значительной степени затрагивают других людей, а не его самого). Иногда он даже может не понимать, почему его героические усилия воспринимаются не так, как ему бы хотелось. («Неужели я не спас этих симпатичных, пушистых зверьков от огня, ворвавшись в горящее здание?» – «Да, но ты сам его и поджег».)

 Псевдогерой. Это явление я наблюдал всего несколько раз. Его суть состоит в том, чтобы обрисовать руководству ситуацию намного хуже, чем она есть на самом деле, а затем, как по мановению волшебной палочки, выставить ее в куда более привлекательном свете, чем она казалась до этого, приписав себе заслуги во всем случившемся (надо же, герой!). Чем более несведущими или безразличными будут руководители, тем проще проделать этот трюк. Он может сработать всего пару-тройку раз, пока коллеги или другие специалисты не схватят «героя» за руку. Подобное нельзя назвать комплексом героя в истом виде, поскольку человек, о котором идет речь, даже не пытался делать что-либо героическое, он просто хотел выглядеть героем.

 У героев есть свои глупые короли. Большинство ситуаций, способствующих проявлению героизма, вызваны просчетами руководства. Если недельное отставание работ над проектом или неудачные варианты выбранной стратегии вынуждают к существенным проектировочным изменениям, то ответственность за это ложится на руководство. Порой можно наблюдать взаимозависимые отношения между руководством и разработчиками, когда руководство зависит от героизма разработчиков, позволяющего прикрыть (или скрыть) его ошибки. То есть вместо того, чтобы признаться в своих просчетах, руководство попадает в зависимость от заслуживающей всяческих похвал героической работы команды разработчиков, которой лучше было бы избежать. Хотя, стоит заметить, что разработчикам нравится авральная обстановка и порой им не хочется, чтобы руководство слишком хорошо справлялось с планированием или управлением рисками, несмотря на частые недовольства с их стороны в адрес того же руководства. Создается целая взаимозависимая культура труда, полагающаяся на героев и поощряющая как создание рискованных ситуаций, так и их разрешение.

 Комплекс неудачника. Это, конечно, не комплекс героя, но их взаимосвязь позволяет включить его в этот список. Существуют люди, которые чувствуют себя дискомфортно, когда им не на что пожаловаться. Когда на их долю перепадают испытания, они чувствуют себя намного лучше, находя оправдания своим неудачам и убеждая окружающих в их закономерности, вместо того чтобы затратить свою энергию на достойную встречу этих трудностей и попытку добиться успеха. Они предпочитают обвинять, а не выигрывать. Эти люди сбиваются в группы, приходя из плохих команд (или семей), в которых обвинения и оправдания важнее всего остального. Им нужен кто-нибудь, кто сможет показать, что по жизни можно идти другой, более полезной дорогой.

Лучший способ свести к минимуму риски, связанные с проявлениями «героизма», – создать действенную команду управляющих. Если для кого-то это небезразлично, нетрудно отличить, когда 80-часовая рабочая неделя является результатом героической борьбы с кризисной ситуацией, а когда – следствием цепочки собственных непрофессиональных действий. Вам как руководителю проекта может не хватить своего влияния на то, чтобы уверить команду в ее склонности к героизму, но не попробовав, вы вряд ли это поймете (см. главу 16).

Возможность изменить подобное поведение представляется лишь в том случае, когда кто-либо привлекает к нему внимание. Как минимум, вам необходимо проводить строгий разбор каждого случая «героизма». Как только какой-нибудь герой себя проявит, вам следует провести публичное обсуждение первоочередных мероприятий, направленных на пресечение подобных проявлений. Герою можно воздать по заслугам, но следует также поощрять всех, кто ищет способы предотвращения подобных ситуаций в будущем.

Выводы

• Независимо от предпринимаемых вами действий, вы не гарантированы от неудач.

• Если вы сохраните спокойствие и разделите проблему на части, то сможете справиться с множеством трудных ситуаций. (Вспомните элементарные принципы руководства.)

• Существует ряд стандартных ожидаемых ситуаций, в число которых можно включить просчеты, принуждение к нерациональным действиям, дефицит ресурсов, низкое качество, изменение направленности проекта, проблемы личного характера, угроза мятежа.

• Возможности познаются в трудные времена. Постарайтесь выделить время для себя и своей команды на анализ всего случившегося и выработку мер, позволяющих избежать подобных трудностей в будущем.

• Возлагая на себя всю ответственность за происходящее, кто бы ни был его причиной, вы обязательно ускорите решение проблемы.

• В экстремальной ситуации вводите режим борьбы за живучесть. Делайте все возможное, чтобы стабилизировать и прояснить ситуацию с проектом.

• Переговоры ведутся не только в кризисных ситуациях, они входят в нормальную управленческую практику. Хорошие переговорщики исходят из интересов сторон, а не из их позиций.

• Всегда придерживайтесь четкого разграничения полномочий. Люди еще до возникновения кризисных ситуаций должны знать, кто имеет право принимать решения.

• Люди по-разному реагируют на давление обстоятельств. Помогая команде справиться с различными видами давления, действуйте осмотрительно и открыто.

Упражнения

1. Пройдитесь по офису и найдите пять дел, которые могут пойти не так, как надо. Опишите для каждого из них, как можно справиться с проблемой, когда дело дойдет до ее устранения. Чье присутствие понадобится для устранения проблемы? Что вы будете делать для ее устранения? Что бы вы сделали, если бы не обладали достаточными полномочиями?

2. Выберите один из своих прежних, сошедших с рельсов проект, которым вы не руководили. Кого нужно было привлечь для устранения проблем? Кого нужно было поставить в известность о том, как вы это собираетесь сделать? Кого нужно было поставить в известность после всего случившегося? Что удалось сделать? Как можно было лучше справиться с проблемой? Что бы вы могли изменить в своей организации для уменьшения шансов на повторение подобной ситуации?

3. Представьте, что вы – руководитель оговоренного контрактом, но не приветствующегося внутри вашей организации проекта по разработке какой-нибудь программы. Один из ваших ведущих разработчиков, использующий какой-нибудь замысловатый код, понятный немногим другим разработчикам, был уволен без вашего ведома. Рабочий график при этом не претерпел изменений. Как вы справитесь с возникшей ситуацией?

4. Вы – президент компании, входящей в число крупнейших 500 компаний. CNN сообщает вам, что через час в эфир выйдет видеозапись, на которой ряд вице-президентов вашей компании будут во всеуслышание давать нелицеприятные комментарии в адрес ваших работников, компании в целом и ваших руководящих способностей. Что бы вы сделали?

5. Вы являетесь руководителем проекта по созданию передовой игры Xbox, имеющего бюджет в 20 миллионов долларов, рассчитанный на работу 50 сотрудников в течение 12 месяцев. Чтобы ускорить завершение проекта, вы приняли решение закупать компоненты для проекта, а не разрабатывать их самому. На полпути проекта вы узнаете из достоверных источников, что поставщик компонентов, скорее всего, задержит их поставку на год, но сам поставщик еще не сообщил вам об этом, уверяя, что дела идут превосходно. На завтра намечен ваш доклад анализа хода проекта руководству. Как вы можете справиться с этой потенциально кризисной ситуацией?

6. Вы – директор Федерального агентства по чрезвычайным обстоятельствам. Один из крупных американских городов только что был затоплен в результате катастрофического разрушения дамбы, расположенной вверх по течению реки. Пятьдесят тысяч человек попали в бедственное положение внутри (и на крышах) домов и офисов, без электричества, без возможности восстановления энергоснабжения и с ограниченными запасами пищевых продуктов. Ваша система связи вышла из строя. Что вы сможете предпринять?

7. Спустя неделю после начала разработки на ваш офис напали космические пришельцы, и весь штат программистов попал под воздействие их излучения, снизившего талант разработчиков на 50 %. Вы стали лишь свидетелем события, в результате которого излучением была стерта память персонала обо всем происходившем. Что вы станете делать с календарным планом? Уволите ли вы сотрудников? Насколько честно вы доложите обстановку своим руководителям или заказчикам?

8. Какой была самая глубокая кризисная ситуация, происходившая на вашей работе или в вашей жизни? Какие чувства вы испытали и как они повлияли на то, как вы справились с ситуацией? Смогли ли вы оценить свои чувства сразу или только чуть позже? Какие из этого можно сделать предположения о вашей способности справляться с критическими ситуациями?

9. Рассмотрим гипотезу: если вы работаете над проектом, в котором еще ничего и никогда не шло наперекосяк, это означает одно из двух: либо вы заняты слишком легким для себя делом, либо что-то идет не так, но вы игнорируете подобные моменты. Как вы на это смотрите?

Часть 3. Управление

Глава 12. Почему лидерство должно быть основано на доверии

У меня в жизни было более десятка руководителей. Многие из них ничем особо не запомнились, а некоторые были просто ужасными, но те, которыми я восхищался, не жалели времени на то, чтобы завоевать мое доверие. Они хотели добиться от меня наибольшей отдачи и знали, что такое возможно лишь при условии, что я смогу всецело на них положиться. Это не означало, что они делали все, о чем я их просил, или безоговорочно соглашались с моим мнением, просто их поведение было предсказуемым. Почти всегда мне были абсолютно понятны их взгляды, мотивация, виды на будущее. Я знал, где мое место, в чем моя и их роль, насколько серьезной могла быть поддержка с их стороны в порученном мне деле.

Если вы играете роль лидера команды, то все зависит от того, какие предположения могут выстроить люди на ваш счет. Когда вы говорите: «Я сделаю это завтра» или «Я поговорю с Салли и заставлю ее согласиться с этим», все окружающие молча прикидывают, каковы шансы на то, что все сказанное вами окажется правдой. Со временем, если вы успешно будете работать на свою команду, эти шансы значительно возрастут. Люди начнут вам верить на слово, выдав вам кредит доверия.

Хотя в кино и на телевидении лидерство изображается с высокой степенью драматизма – герои врываются в горящие здания или в одиночку сражаются с ордами врагов, – настоящее лидерство заключается в весьма простых и практичных делах. Делайте то, о чем говорите, и говорите то, о чем думаете. Признавайте свою неправоту. Используйте мнения и идеи других людей в тех решениях, которые влияют на их работу. Если чаще всего у вас именно так и получается, вы непременно завоюете доверие людей, с которыми вместе работаете. Когда же настанет момент попросить их о том, что для них неприятно или с чем они не согласны, благодаря заработанному доверию вы и в такой непростой ситуации сможете остаться лидером.

Значит, чтобы быть хорошим лидером, не обязательно быть лучшим программистом, планировщиком, разработчиком архитектуры, передаточным звеном, шутником, проектировщиком или кем-то еще. Все, что от вас требуется, – завоевать доверие людей, не замыкаясь в себе и оставаясь открытым для окружающих. Поэтому, чтобы стать хорошим лидером, вы должны знать, как найти, построить, заработать, завоевать доверие других, а также как развить чувство веры в себя самого.

Обретение и утрата доверия

Доверие лежит в основе всех сколько-нибудь значимых отношений. Без доверия не может быть никаких уступок, никаких взаимных обязательств, никаких рискованных шагов.

Терри Мизрахи (Terry Mizrahi), директор центра ECCO (Education Center for Community Organizations)

Доверие (сущ.) – устойчивая уверенность в честности, способности или характеристике личности.

В качестве эксперимента я спросил некоторых знакомых, кому они доверяют на своей работе и почему. Все ответы были примерно одинаковы: доверием пользуются те, кто хорошо справляется с порученным делом, верен целям проекта, справедлив по отношению к людям и ведет себя в трудной обстановке соответствующим образом. Ни один человек не сказал, что в эту категорию входят люди, которые ему просто нравятся или которых он хотел бы пригласить к себе на обед. По-видимому, доверие заставляет забыть о других особенностях человеческой личности. Мы можем доверять даже тем людям, которые нам не нравятся или с которыми нам не хотелось бы проводить свое личное время.

В отличие от других характеристик личности, доверие имеет мало общего с личными предпочтениями. Мы не выбираем, кому нам доверять на основе внешних признаков. Вместо этого в отношении человека, от которого мы можем зависеть, мы выстраиваем более глубокую цепь предположений. Если я вас спрошу, с кем бы вы пошли в разведку, вы станете подбирать людей совсем не так, как если бы я спросил, с кем бы вы пошли в кино. Здесь не играет роли личная симпатия или надежные отношения, связывающие вас каким-то образом.

Но для того чтобы исследовать доверие в контексте проекта, нам нужно разбить общее представление о нем на поддающиеся осмыслению части. Одной из элементарных составляющих доверия является обязательность. Дать слово, или обещать, – это простейшая форма соглашения между двумя людьми, касающегося их общих дел.

Доверие строится на обязательности

Когда вы заводите нового друга, который назначает вам встречу, вы верите ему на слово, что он будет на месте вовремя. Но если два или три раза подряд он заставит вас ждать и вам придется пропустить киносеанс или сидеть в клубе в одиночестве, ваше доверие к нему ослабнет. По сути, он подорвет вашу веру в его обязательность. Если так будет продолжаться и дальше, то ваше представление о нем претерпит изменения. Вы больше не станете считать его надежным человеком и будете сомневаться, стоит ли ему довериться в важных делах.

Уоттс С. Хэмфри (Watts S. Humphrey) в своей книге «Managing the Software Process» (Addison Wesley, 1989) во главу угла удачного управления проектами поставил способность руководителя быть обязательным в своих делах и работать так, чтобы выполнять взятые на себя обязательства. Хэмфри настолько верит в важность этого положения, что дал строгое определение признаков действенности принятых обязательств. Вот предложенный им перечень в слегка скорректированном виде.

Признаки действенности обязательств

1. Человек, принимающий на себя обязательства, делает это по доброй воле.

2. Обязательство не даются просто так, за ними стоит тщательная оценка работы, ресурсов и рабочего графика.

3. Обязательства являются соглашением сторон о том, что, кем и когда будет сделано.

4. Обязательства принимаются открыто и публично.

5. Ответственный за выполнение обязательств стремится оправдать оказанное ему доверие, даже если ему для этого требуется помощь.

6. Если до назначенной даты произойдут какие-нибудь изменения, влияющие на действия любой из сторон, связанных обязательством, должно быть сделано предварительное заявление и заключено новое обязательство.

Здесь есть две интересные особенности. Во-первых, обязательство является двусторонним соглашением. Двое вовлеченных в него людей имеют еще и взаимные обязательства. Если Корнелиус обязался перед Рупертом выгуливать его собаку, пока того не будет в городе, то обе стороны должны уважать интересы друг друга. Корнелиус ни в коем случае не должен проезжать 25 кварталов до квартиры Руперта, намереваясь выгулять Ровера в центральном парке только затем, чтобы увидеть Руперта лежащим на диване у телевизора («О, извините, я хотел еще вчера вам позвонить и сказать, что моя поездка отменяется»). Доверие каждой из сторон предоставлено другой стороне на взаимной основе, с предположением, что отношение к нему будет почтительным и обязательства не будут сорваны или забыты. Пустая трата чужого времени или денег ведет к подрыву доверия.

Во-вторых, мы постоянно берем на себя какие-нибудь обязательства. Любой разговор, в котором мы просим или нас просят что-то сделать в согласованные сроки, является принятием обязательств. К обязательствам можно отнести простые утверждения: «Слушай, я позвоню тебе после обеда» или «Я прочту эти наброски к завтрашнему дню». У двоих людей могут быть разные представления о серьезности обязательства, но о том, что в том или ином виде оно все же принято, сомнения возникают довольно редко. Чем несерьезнее мы относимся к собственным обязательствам по отношению к другим, тем больше шансов на утрату доверия к нам с их стороны. Существуют разного рода обязательства (например, если вы однажды в обеденный перерыв забыли позвонить жене, она вряд ли подумает, что вы решили с ней развестись), но все они в совокупности формируют наше представление о степени доверия к другим людям.

Непоследовательность ведет к утрате доверия

Возвращаясь к проектам, можно отметить, что люди утрачивают доверие, когда ведут себя непредсказуемо. Когда кто-то постоянно действует вразрез со своими обязательствами, он создает беспокойную обстановку, мешающую работе всей команды. У людей, вынужденных работать (или страдать от работы) вместе с таким человеком, понапрасну тратится энергия. Вместо того чтобы пускать ее на завершение работы, они должны гадать, сделает он то, что собирался, или нет. Приходится изобретать планы выхода из непредвиденных ситуаций, подвергаясь дополнительным порциям стресса и неопределенности («Если Марла к исходу дня не проверит этот код, мы просто вылетим в трубу»). Чем выше чья-то безответственность, тем в большей степени проявляются разброд и шатания.

В одной интересной (хотя и неприятной для меня) истории об утраченном доверии фигурирует один из моих бывших начальников. Я был руководителем программы и работал с пятью программистами и тестировщиками, с которыми неплохо ладил. Джейк, лидер команды, был начальником надо мной и еще над несколькими руководителями программ. Проблема была в том, что Джейк имел скверную привычку менять свое мнение. К примеру, мы с ним, бывало, обсуждали принятые мной и требующие его одобрения важные решения и быстро соглашались о том, как все сделать наилучшим образом. Но стоило только нам прийти на совещание, где сильные мира сего, обладающие по сравнению с Джейком равными или более высокими полномочиями, выражали свое несогласие, как Джейк, заламывая руки, сдавался, соглашаясь с любым устраивающем всех решением (он так поступал в каждом третьем случае, но заранее угадать, когда это случится, было невозможно).

Помнится, я стоял во время совещания у доски, уже наполовину объяснив суть своего плана А, а он в это время согласился с чьими-то предложениями следовать плану Б. Я замолчал и удивленно уставился на него, думая о том, что он ведет себя не сообразуясь со складывающейся ситуацией. Неужели он все забыл? Неужели он сделал все это в угоду начальству? Понимал ли он, как со мной поступает? Или он играл роль флюгера (следуя преобладающим в зале веяниям) не в силах сопротивляться? В ту пору понять происходящее мне не позволяло отсутствие опыта, и я не считал себя вправе делиться с кем-нибудь тем, как со мной обходились, поэтому страдал молча. До этого случая я никогда так не выкладывался в гимнастическом зале.

Со временем я стал обсуждать с ним его поведение. Вдобавок я решил сразу же документировать принимавшиеся нами решения (для этого вполне подходила электронная почта), а затем ссылаться на них. Я даже пошел еще дальше и начал готовить его непосредственно перед совещаниями. Но все мои усилия были тщетными (теперь на совещаниях он уже не поддерживал план Б, но и не продвигал план А, он просто отмалчивался). Вскоре я поймал себя на мысли, что работаю за него. Я ввязывался не в свое дело, и воспользовавшись его бездействием, проталкивал решения вопросов, рассматриваемых на совещаниях. Надо отметить, что так работать было проще и эффективнее. В связи с этим в команде (и в моих взаимоотношениях с Джейком) возникли новые проблемы, но у меня появилась возможность управлять интересующими меня делами и добиваться желаемого результата.

Обиднее всего, что Джейк был неглупым парнем, с которым было весело работать. Но эти качества меркли на фоне возникшего к нему недоверия. Будь он поглупее, но понадежнее, от него, как от руководителя, было бы куда больше проку. Безусловно, наша продукция от этого бы только выиграла – мне не пришлось бы тратить столько сил на его обуздание и больше энергии можно было направить на помощь команде.

Явное выражение доверия (зеленый свет)

Хорошие руководители, с которыми мне приходилось работать, четко обозначали границы доверия. Они без устали твердили мне, что, пользуясь поддержкой команды, я могу самостоятельно принимать решения в пределах своей компетенции. При этом они (мои руководители) обозначали свою озабоченность по некоторым вопросам, которые просили согласовывать с ними. Они спрашивали о том, что мне от них надо, и мы вели переговоры, чтобы выяснить, смогут ли они мне все это предоставить. Иными словами, они предписывали мне сосредоточиться на конкретной работе, а не на поисках чьего-то одобрения. Облечь доверием, а значит, передать полномочия – довольно сильный прием. В некоторых видах спорта для этого есть специальные термины, к примеру «зеленый свет» в баскетболе.

Когда-то давно, еще в школе, я играл в баскетбол в команде «Samuel Field Y», в Дагластоне, штат Нью-Йорк, которую тренировал Роб Элкинс.^[72] Однажды во время тренировки он отозвал меня в сторону, что обычно не предвещало ничего хорошего. Я проштрафился тем, что стягивал вниз шорты у других игроков, мешая им вернуться в защиту. Когда я присел на скамью, то, на всякий случай, низко опустил голову. Но он так ничего мне и не сказал. Мы долго сидели, наблюдая за валкой вокруг мяча на площадке. Наконец, он произнес: «Скотт, я даю тебе зеленый свет». Я посмотрел на него и переспросил: «Зеленый свет?» Он, улыбаясь и не глядя на меня, ответил: «Да». «Хорошо, тренер», – сказал я и выбежал на площадку. Хотя эти слова услышали лишь несколько игроков, их значение каким-то образом стало понятно абсолютно всем. Обычно игроки действуют строго в соответствии с тренерскими установками, а зеленый свет означает исключение из правил. Я мог бросать мяч в корзину, когда мне заблагорассудится, мог играть на любом месте и брать игру на себя, когда считал это необходимым.

Такие слова говорят об огромном доверии к игроку, вот почему большинство игроков за всю свою карьеру так никогда их и не слышат. (Я продолжал играть в баскетбол и в школе, и в колледже, в команде «Division III», но таких слов ни раньше, ни потом мне слышать не приходилось.) Тренеры вообще остерегаются передачи полномочий. Так же, как и многие руководители, они ощущают хрупкость власти. Стоя у кромки площадки (или одиноко сидя в своем углу), они чувствуют себя беззащитными. Многие руководители и тренеры боятся последствий предоставления команде дополнительных свобод. Они забывают о том, что всегда вправе изменить степень доверия: не оправдай я доверия, оказанное мне тренером Элкинсом, ничто не помешало бы его вернуть все на круги своя (сменить зеленый свет на желтый). Вероятно, более важно то, что степень доверия, которую руководители боятся предоставить, зачастую составляет именно ту норму, которая необходима команде, чтобы следовать их руководящим установкам.

Можно с уверенностью сказать, что при тренере Элкинсе я играл намного старательнее, чем при других тренерах. Я инстинктивно чувствовал, что должен взять более высокую планку (хотя в одной из игр я семь раз смазал из-под кольца, и это, по моему убеждению, был своеобразный клубный рекорд по соотношению попыток и промахов). Я всегда более охотно работал с теми руководителями, которые мне доверяли, чем с теми, кто такого доверия мне не оказывал. Это происходило не потому, что они мне нравились (хотя и это помогало), а потому, что они давали мне развернуться. Подобная передача полномочий создает атмосферу истинной доверительности и предоставляет людям простор для работы с максимальной отдачей.

Если ваша задача – задействовать максимальный потенциал для достижения успеха, нужно изыскать возможность дать людям зеленый свет. Работа руководителя в том и состоит, чтобы предоставить команде средства достижения цели и помочь ей набраться сил и подготовиться к освоению этих средства.

Разновидности власти

В данной книге описываются две модели власти. Развернутую форму мы рассмотрим чуть позже, в главе 16. А здесь я остановлюсь на более простой, но действенной форме функциональной власти.

Функциональная власть бывает двух видов: предоставленная и заслуженная. Предоставленная власть исходит из иерархии или титулованности (иногда она зовется официальной властью). Например, тренер баскетбольной команды наделен властью решать, кого выпускать на игру, а кого держать на скамье запасных. Или босс скромного отдела продаж обладает властью нанять или уволить любого сотрудника по своему усмотрению. Но эта власть не имеет ничего общего ни с уважением, которое окружающие оказывают (или не оказывают) ее обладателю, ни даже с мнением окружающих относительного его производственных навыков и образованности. По сравнению с ней заслуженная власть приобретается в процессе активной деятельности. Заслуженная власть, или авторитет, выражается в том, что люди прислушиваются к ее обладателю не потому, что он кем-то облечен полномочиями, а потому, что они считают его умным или полезным человеком.

Не уповайте лишь на предоставленную вам власть

Я не доверяю систематизаторам и избегаю их: стремление к системе говорит об отсутствии цельности.

Ницше

Если на первый план в руководстве выходит власть предоставленная, взаимоотношения носят ограниченный характер. Эта власть исключает возможность обмена идеями и концентрируется на принуждении, а не на разумном подходе. Хотя бывают и такие ситуации, которые требуют применения авторитарной власти, хорошие лидеры до последнего держат этот меч в ножнах. Как только вы его достанете, слушаться будут уже не вас – главным аргументом станет этот меч. Хуже того, в ответ на это все ваши приближенные тоже достанут свои мечи (которые могут оказаться лучше вашего). Они не станут вам объяснять, почему вы не правы, а воспользуются предоставленной им властью, противопоставив ее вашей власти. В результате возникнет столкновение властных полномочий, не имеющее ничего общего с разумными началами или поиском лучших решений. Предоставленная власть (подобно неким «темным силам») привлекательна, поскольку ею легче воспользоваться: вам не нужно прилагать значительных усилий для достижения желаемого результата.

Однажды я столкнулся с ситуацией, поставившей меня на распутье между предоставленной и заслуженной властью. Было это во времена Internet Explorer 2.0, когда я получил свое первое назначение – пост руководителя программы по разработке серьезного программного продукта. В первый же день я был представлен двум программистам, с которыми я должен был вместе работать, Биллу и Джею. Джей вел себя приветливо, а Билл – молчаливо и угрюмо. В организации у него был очень высокий авторитет (уровень 13 на жаргоне Microsoft тех времен, выше уровня для программиста быть не могло). Я вспоминаю, что сидел в его кабинете и разглядывал его, сидящего за столом напротив. Я говорит минут десять, а он в ответ не промолвил ни слова. Он просто откинулся в кресле и уставился на меня.

Я вышел к доске в надежде, что это поможет разговорить Билла. Безрезультатно. Он бросал лишь саркастические или двусмысленные и нелицеприятные реплики, наподобие «Да неужели?» и «Ничего себе… и как вы только до такого додумались». Он просто играл со мной как кошка с полудохлой мышкой. Но я был самонадеянным 23-летним молодым человеком и понятия не имел, что мне делать, несмотря на всю мою убежденность в том, что я могу что-то из себя изобразить. Билл, со своей стороны, был закаленным ветераном, ранее прошедшим подобную процедуру с десяток раз. Я и вправду был уверен, что в его сознании проносятся лишь две мысли: «Зачем жизнь свела меня с этим парнем?» и «Какое место из всех, встречавшихся мне идиотов, он занимает, первое или второе?» Первая встреча закончилась моим бормотанием в стиле, позаимствованном прямиком из учебного видеокурса, о том, как здорово все сложилось, что мы будем работать вместе. (Уверен, этот пассаж убедил его в серьезности моих притязаний на первое место.)

Примерно тогда же мой друг (тоже руководитель программы) дал мне совет установить свои порядки. Я должен был сказать Биллу, что поскольку я – руководитель программы, а он – программист, он должен делать то, что я сказал, сообразуясь с решениями высокого уровня. Это вписывалось в мифологию Microsoft относительно руководителей программ («Либо вы делаете все по-моему, либо я вас просто уничтожу»), о которой я уже слышал, поэтому я набрался храбрости, чтобы попытать пойти и воплотить все это в жизнь. Но перед тем как обнажить свой меч и взобраться на гору, я переговорил со своим руководителем. Перемежая слова шутками, он сказал, что спешка тут ни к чему. Он напомнил мне, что Билл чрезвычайно силен и компетентен в своей области и мне надо найти способ воспользоваться этим. Он также добавил, что поработать с Биллом будет, как он выразился, «весьма полезно для меня». Поверив руководителю, несмотря на все его шуточки, я вложил меч в ножны и стал смотреть на ситуацию с той точки зрения, что мне нужно извлечь из работы с Биллом как можно больше выгоды.

Работа по приобретению заслуженной власти

Прошли недели, и я постепенно завоевал доверие Билла. Поначалу все протекало болезненно. Чтобы добиться его содействия, мне постоянно приходилось доказывать свою состоятельность, выстраивая отношения по кирпичикам, от малого к большому. Я понял, что он охотнее давал советы, когда я признавал его превосходство надо мной в каких-нибудь познаниях. Когда я брал на себя какие-нибудь обязательства и выполнял их, он становился щедрее. Мне требовалось принимать толковые решения и вполне аргументировано защищать свою точку зрения, но, в конце концов, у нас сложились прочные рабочие взаимоотношения. Билл признал мои полномочия в принятии даже тех решений, которые в значительной степени касались его самого. Ему просто нужно было, чтобы я сперва доказал, что заслуживаю его доверия.

А если бы я в эти первые дни воспользовался хоть малой толикой предоставленной мне власти, я потерял бы все шансы на власть заслуженную. Билл, возможно, и уступил бы мне в тот первый день, считаясь лишь с моей властью, но пройти через это, а потом выстроить более дружественные отношения было бы куда труднее. А если бы я стал постоянно прибегать к своим властным полномочиям (что, скорее всего, и случилось бы, стоило лишь начать), они со временем начали бы терять свою эффективность. Как только руководитель или лидер говорит: «Потому, что я так сказал» – на этом прекращаются все дискуссии и обрываются потенциальные возможности для высказывания лучших мнений. Все, находящиеся рядом с таким руководителем толковые или неравнодушные люди, теряют возможность внести в проект все самое лучшее, на что они способны, и, конечно же, не приходят в восторг от своих скромных ролей.

С организационной точки зрения авторитарное поведение отталкивает здравомыслящих людей. Одновременно оно потворствует расслабленности, предписывая повседневные рутинные действия. Тираны создают среду, терпимую лишь для их фаворитов, и наоборот. Хуже того, тираны создают других более мелких тиранов. Такая модель поведения (предоставленная власть и ничто другое) расползается по организациям сверху вниз, в конце концов, поражая их целиком.

Убеждение сильнее диктата

В процессе руководящей деятельности я понял, что убеждая людей перед тем, как заставлять их что-нибудь делать, можно извлечь намного больше пользы. Воспользоваться властью тирана и поставить всех на место может любой идиот – для этого не надо никакого мастерства. Но убедить умного человека (или группу людей) в том, что изначально нежелательная для него (или для них) работа является нужной, хорошей и даже, возможно, полезной для него (для них), намного сложнее. Когда люди потратят на работу не один час и начнут сомневаться в ее целесообразности, они не смогут предъявить вам никаких претензий. Чтобы понять, на что именно они тратят свое время, занимаясь текущей работой, они смогут воспользоваться собственными рассуждениями, подкрепленными вашей аргументацией.

В итоге люди прислушивались ко мне, поскольку были уверены в моих способностях подвести под свое мнение здравый смысл. Они задавали меньше вопросов и верили в то, что я обдумал все свои требования к ним, прежде чем их предъявлять. Они все меньше опасались обмана с моей стороны, поскольку были свидетелями многочисленных примеров, когда мое поведение мотивировалось интересами проекта и команды. Чем больше людей вам доверяет, тем проще их убеждать. Как и в истории с Биллом, спустя некоторое время я тратил все меньше и меньше сил на то, чтобы в чем-нибудь убедить людей, даже если мои взаимоотношения с ними только начинали складываться, при этом все больше и больше времени мне оставалось для непосредственной работы.

При необходимости покажите свою власть

Предоставленная власть тоже бывает востребована. Когда ситуация выходит из-под контроля, предоставленная власть может стать лучшим средством быстро навести порядок. Если совещание разваливается, нарушаются серьезные обязательства или возникают другие фундаментальные проблемы, доставайте свой меч. Если вы убеждены, что непосредственное использование власти – единственная реальная возможность добиться успешного исхода, то независимо от последствий и во что бы то ни стало воспользуйтесь ею. Вы должны двигать проект вперед, действуя открыто и прямолинейно, опираясь на свою исполнительную власть.

Тем не менее я убежден, что чем больше эта власть используется, тем больше прикрывается фундаментальных организационных проблем. Если в течение недели у вас не найдется другого способа действий, как только орать на совещаниях или в кабинетах, значит, концепция проекта, структура организации или ваши руководящие способности требуют пересмотра.

Оказание доверия

Чем больше становится организация, тем больше приходится опираться на предоставленную власть. Лидеры испытывают немалую озабоченность проблемами слаженной работы коллектива (или, возможно, проблемами предотвращения революционных взрывов), и здесь существует стойкое поверье, что на индивидуальные беседы и общение со всеми работниками организации, что подразумевает применение заслуженной власти, просто не хватит времени. Я знаю некоторых лидеров даже небольших команд, которые не верят, что у них хватит сил или времени на реализацию такого стиля руководства по отношению к своим ключевым разработчикам. Решить проблему можно с помощью другой разновидности доверия, называемой делегированием полномочий, когда людям доверяется самостоятельное принятие решений.

Полномочия и доверие часто аккумулируются вокруг различных задач или областей знаний. Джо может получить наибольшие полномочия, когда дело касается объектов C++, зато Салли лучше всех умеет работать с базами данных. В здоровой среде общения товарищей по команде уровень взаимного доверия вполне достаточен, чтобы признавать за кем-то более высокую степень мастерства или лучшее видение предмета и, не опасаясь столкновений с какими-нибудь препятствиями или чьими-то насмешками, просить у такого человека дельного совета. Хотя опасение и не лишено смысла, поскольку в инженерных дисциплинах в отношении запросов о помощи культивируется пассивно-агрессивное поведение (в ходу, например, аббревиатура rtfm^[73]). Даже в колледжах на отделениях информатики самостоятельность считается основой компетентности, и если студенты просят помощи у своих сокурсников, это рассматривается как признак слабости.

Если исходить из интересов проекта, авторитет Салли в разработке баз данных ценен лишь применительно к целям данного проекта. Если она сидит в своем офисе в полном одиночестве и ее авторитет никем не востребован для помощи в решении тех или иных проблем, то он пропадает зря, или, в лучшем случае, его польза ограничивается теми задачами, которые Салли решает самостоятельно. Ключевой обязанностью лидеров или руководителей проекта является создание условий для обмена опытом и знаниями внутри команды. Если они смогут все правильно организовать, то дела у команды пойдут намного лучше.

Передача полномочий

Традиционно передача полномочий служит для перепоручения отдельных заданий или обязанностей. Я считаю, что наиболее эффективная форма передачи полномочий заключается в распределении прав на принятие решений или прав на оказание влияния на принимаемые решения. Это можно сделать на совещаниях или дискуссиях в составе группы. Когда лидер или руководитель спрашивает: «Ну и как мы собираемся решать эту проблему?», у него есть шанс передать свою власть кому-нибудь другому. «Салли, вы ведь лучший разработчик баз данных. Как вы считаете, что нам делать?» Если это сказано в подходящий момент (а не в разгар напряженного подведения итогов под руководством вице-президента или во время неудачной демонстрации прототипа, когда Салли совершенно не готова отвечать на какие-либо вопросы), то тем самым будет установлена атмосфера нормального сотрудничества. Люди должны свободно признавать деловой опыт друг друга, тогда они, соответственно, согласятся с чьими-то полномочиями. Разумеется, руководитель проекта ничем не рискует. Если Салли не сможет предложить ничего хорошего, дискуссия продолжится. Но без этого первого вопроса дискуссии может и вовсе не получиться.

Разумеется, делегирование полномочий распространяется и на непосредственную передачу власти. Публично объявляя о том, что какая-то сфера деятельности или функция будет управляться конкретным человеком, руководитель передает этому человеку часть своих властных полномочий. Важно, чтобы эта передача происходила на глазах у всех, кто должен это видеть. Когда я перепоручал обязанности кому-нибудь, кто работал под моим руководством, я обязательно сообщал об этом всем программистам и тестировщикам, кого это могло касаться, чтобы они знали, какую часть имеющейся у меня власти и полномочий я передал другому. Конечно, порой людям не хочется, чтобы полномочия кому-то передавались, в таком случае руководителю следует применить власть и заставить их подчиниться.

Джон, руководитель проекта в моей команде, был готов к выполнению расширенных обязанностей. Поэтому когда подошло время перераспределения работы в команде, я решил передать ему тему, за которую до этого сам нес ответственность. После соответствующего обсуждения данного вопроса с Джоном и Стивом (программистами, занимавшимися этой темой), я возложил ответственность на Джона. Неделю спустя ко мне в офис за помощью по этой теме пришел Стив. Все время, пока он что-то говорил, я пытался понять, почему он говорит это мне, а не Джону. Я прервал его и спросил: «Стив, а почему ты говоришь все это мне?» «Понимаешь, Скотт, ведь для тебя это привычная тема». «Ну да, Стив, но теперь ведь ею занимается Джон. Ты что, к нему не обращался?» Он пожал плечами, а я сказал: «Стив, иди к Джону и поговори с ним. Он толковый и хороший парень, можешь ему доверять». Несколькими днями спустя Стив опять пришел ко мне, и все повторилось в несколько сокращенном варианте. Однако после этого я больше Стива не видел (по крайней мере, в связи с данным вопросом).

Судя по всему, Джон так и не узнал об этой истории, да ему и незачем было об этом знать. По каким-то причинам Стив предпочитал работать со мной и хотел бы продолжить наши взаимоотношения, несмотря на изменения в системе руководства. Но, передав полномочия, я обязан был самоустраниться от дискуссий. Я, возможно, и сам мог ответить на вопросы Стива, и он, скорее всего, остался бы этим доволен, но я бы тогда нарушил собственное решение о передаче полномочий. Пока у меня не было никаких оснований для вмешательства в данную тему проекта, я должен был доверять работе Джона и Стива и использовать доверие Стива ко мне, чтобы убедить его доверять Джону.

Многие руководители испытывают затруднения с передачей полномочий. Они выдвинулись в руководители благодаря своим способностям самостоятельно справляться с порученной работой, а руководство требует несколько иную сбалансированность навыков, чем у индивидуального работника (см. главу 1). Обычно таких руководителей сдерживает страх, что они со всем этим не справятся. Вот здесь то их и подстерегает ловушка, поскольку этот страх движет их решениями, они никогда не научатся доверять другим людям, а без доверия руководство невозможно.

Иногда решение представляет собой соглашение. Руководитель в момент передачи полномочий кому-то из своей команды должен обсудить с этим человеком, каких действий он от него ожидает. («Джон, меня волнует Стив. Он постоянно отстает по срокам. Обрати на это особое внимание, хорошо?») В ходе этих наставлений руководитель делится с назначаемым лицом своим опытом и дает ему больше шансов на успех.

Доверие – это гарантия от неприятностей

В предыдущей главе мы выяснили, что в любом проекте найдется что-нибудь, что идет не так, как надо. Конкуренты имеют привычку делать совершенно неожиданные для вас вещи (работа у них такая), технологии приходят и уходят, а начальство меняет свои намерения. Руководителю проектов остается только смириться с мыслью, что все будет развиваться по непредсказуемому и непредвиденному сценарию. В тяжелые или смутные времена больше чем когда-либо хочется, чтобы ваша команда или ваши соратники могли на вас положиться и доверять друг другу.

Если в команде постоянно взращивалась и поддерживалась атмосфера доверия и люди имеют опыт принятия совместных (а не разрозненных) решений, проект вполне способен устоять под натиском любых проблем. Когда люди верят в команду, они могут проявить такую уверенность и настойчивость, которые невозможно вызвать ничем другим. Каждый человек, как солдат в окопе, может опереться на кого-то другого, прикрывающего его с тыла и позволяющего ему тратить больше усилий на решение стоящей перед ним задачи.

Обстановка взаимного доверия дает руководителю проекта возможность сосредоточиться на решении первоочередных проблем, а не тратить время на то, чтобы успокаивать в холлах ударившихся в панику или расстроившихся сотрудников. Иногда лидеру нужно специально попросить команду о поддержке. Он должен продемонстрировать то отношение, которое хочет получить от команды, признав наличие проблемы и попросив, а не потребовав поддержки. (Крики «Помогите!» не сработают.) В целом речь идет о взаимоотношениях людей, складывающихся в нелегкие для всех времена, а эти отношения не зависят ни от уровня зарплат, ни от технологий, и конечно же, они не зависят от того, кто какими полномочиями обладает.

Поэтому мудрый лидер, как и капитан корабля, знает, что на морских просторах встречаются непредвиденные штормы и опасности, и вовсю готовится сам и готовит свою команду к встрече с тем явлением, которое невозможно предусмотреть заранее. Если неопределенность неизбежна, то лучшее, что может дать руководитель, это, скорее всего, крепкие узы доверия, связывающие его и всех участников проекта. В больших командах надо уделять больше времени выстраиванию доверительных взаимоотношений в главных звеньях проекта или там, где в стрессовых ситуациях возможно проявление слабости. Если технические условия, концептуальные документы и другие средства призваны помочь связать людей едиными целями и задачами, то вера в людей, стоящая за всем этим, несет в себе реальную движущую силу.

Модели поведения, вопросы и конфликты

Золотое правило – поступай с людьми так, как хочешь, чтобы они поступали с тобой – вполне подходит и к деятельности руководителей. Наиболее охотно выполняются те распоряжения руководителей, которым они сами неукоснительно следуют. Будучи существами социальными, мы в течение всей своей жизни изучаем манеры поведения преимущественно на основе поступков окружающих нас людей. Зачастую мы лучше учимся в процессе наблюдения за людьми, которых уважаем или чьи действия вызывают наше восхищение, а затем вольно или невольно пытаемся копировать их поведение. В интересах обретения доверия лидерам проекта следует быть примером того самого поведения, которого они добиваются или желают получить от других сотрудников. Майкл Джордан (Michael Jordan) среди прочих своих качеств создавал себе репутацию упорной работой над собой. Хотя он был самым высокооплачиваемым и наиболее известным баскетболистом NBA, немногие могли похвастаться такой же напряженной добросовестной работой. Глядя на него, игроки ниже классом отказывались от возможности отпроситься с тренировки или провести меньше времени в гимнастическом зале. Лидер задавал модель поведения, которой другие были вынуждены следовать.

Если вы будете работать с нарушениями этических норм, пренебрегая золотым законом лидера, гласящим, что вера в правоту собственных суждений должна заставлять лидера действовать по тем же правилам, которые установлены им для всех остальных (см. далее раздел «Доверяйте себе (уверенность в собственных силах)»), вы позволите другим, равным вам по положению или вашим подчиненным, усомниться в ваших установках или воспротивиться им. Власть предержащие должны иметь возможность оценить свои действия со стороны (например, кто-нибудь может сказать, что король голый?). Хорошие лидеры в достаточной мере доверяют своим товарищам по команде, чтобы при случае, возможно, с глазу на глаз, попросить отзыв о своем поведении и деятельности в целом. Естественно, лидера никто не заставляет специально добиваться каких-то отзывов или замечаний в ответ на свои действия, но без естественных и надежных каналов получения подобной информации трудно представить себе успешную деятельность по руководству проектом.

Лидер сам определяет реакцию

Люди слишком сдержаны в своих оценках деятельности руководства. Будучи руководителем, я взял за правило спрашивать людей, еженедельно приходящих ко мне с индивидуальными отчетами, не хотели бы они, чтобы я поразмыслил о чем-то, относящимся к моей работе, поведению или исполнению своих обязанностей. Они крайне редко высказывались на этот счет, хотя я знал, причина была не в том, что я был превосходным руководителем (таких руководителей просто не существует). Я понял, что все решает доверие и время. Я упорно добивался их доверия, необходимого для свободной критики моего поведения без опаски с их стороны, что я в ответ на их замечания приму какие-то защитные или репрессивные меры. В конечном итоге они допускали небольшую критику в мой адрес, и если я на нее нормально реагировал, то в следующий раз они выдавали уже больше критических замечаний.

Но как только я установил этот канал обратной связи, я понял, что их точка зрения куда полезнее для моего самосовершенствования, чем отзыв моего непосредственного начальника. Разумеется, подобные взаимоотношения у меня складывались далеко не со всеми подчиненными, но многие люди рано или поздно стали отвечать на мои вопросы весьма полезными отзывами. Предложения по изменению порядка совещаний, вопросы, связанные с принятыми мною решениями или какие-нибудь другие замечания позволяли улучшать атмосферу наших следующих обсуждений хода совместной работы.

Во время каждого обсуждения я старался отличить критическое отношение к идее как таковой от критического отношения к человеку, который ее выдвинул.^[74] То, что некто А согласился или не согласился с неким Б, еще не означает, что А критически относится к Б. Я хотел выработать в команде такое чувство взаимного уважения и доверия, которое позволило бы всем говорить то, что они думают, а также открыто, без обиняков, выражать свое несогласие. Этому в немалой степени способствует чувство юмора, а тон задает лидер, показывающий, когда уместно отпустить саркастическое замечание или над кем-то подшутить, а когда, может быть, обратить шутку на самого себя. Я твердо убежден, что лидер должен сам быть примером подобного поведения, останавливая тех, кто заходит слишком далеко, и предоставляя возможность всем желающим подключиться к этому процессу.

Это правило в полной мере распространяется и на конфликты и разногласия. Если сидеть в полном бездействии, не препятствуя развитию негативной ситуации, то вам не поможет никакая предоставленная или заслуженная власть. Вашей власти есть более достойное применение, чем прерывать глупые споры и не позволять высказываться тем, кто этим злоупотребляет. Когда несовпадение мнений превращается в личные нападки или для подкрепления решений в ход идут ложные аргументы, кому-то же надо прервать происходящее и поднять планку дискуссии. Если не относиться безучастно к подобному поведению, то всем сразу станет понятно: не стоит повторять подобное, поскольку мы этого не допустим.

Естественно, тут требуется задействовать еще одно золотое правило: настоящий лидер должен быть готов к тому, что другие могут оспорить его собственные неубедительные аргументы (и не преминут это сделать), как только он попытается воспользоваться ими. Лучшие из лидеров получают удовольствие от команды, которая связана интеллектуальными стандартами, позволяющими без опаски обсуждать даже их собственное поведение.

Доверие и ошибки

Легко доверять людям, когда они преуспевают в своих делах, разбираться в их ошибках куда сложнее. Как раз здесь-то руководитель и зарабатывает свой хлеб.

Когда в дверях моего офиса появлялся виновник какой-нибудь проблемы, я обычно пытался (правда, не всегда успешно) направить свою мысль по трем направлениям:

1. Я рад, что он пришел со всем этим именно ко мне. Лучше уж пусть он обращается ко мне, чем пытается все скрыть или разобраться с проблемой самостоятельно, усугубив ситуацию. Мне надо сразу же дать ему это понять.

2. Как мне определить характер проблемы? Можно ли вообще что-либо исправить? Каковы возможные варианты действий? Каким должно быть мое личное участие? Наверное, мне нужно дать ему все необходимые советы, но, по возможности, натолкнуть его на самостоятельное решение, как со всем этим справиться. И, конечно же, мне нужно убедиться в том, что он окончательно не потерял голову. Не стоит посылать его в бой, если вероятность гибели составляет 99 %, так руководители не поступают.

3. Мне нужно, чтобы он извлек соответствующий урок, если это действительно подходящий случай.^[75] На ошибках учатся, поскольку допустивший их человек переживает за случившееся и у него возникает острое желание их больше не повторять (особенно если он чувствует, что команда ему доверяет).

Если вы спросите у любых умудренных опытом специалистов из любой области знаний, в чем состоял главный вынесенный ими урок, они расскажут вам историю, как однажды они с чем-то там перемудрили, возможно, с чем-то особенно важным для них, и в конце концов нашли наилучший способ, как справляться с подобными вещами независимо от их конкретного характера. Из этого следует, чтобы стать классным руководителем, вам не только нужно время от времени совершать ошибки, но и нужен кто-то, кто позволит вам это делать. Руководителям платят не только за то, что они умеют справляться с проблемами, но и за то, что они превращают проблемы в уроки, извлекаемые командой.

Хорошее управление и лидерство заключается в предоставлении людям столько ответственности, сколько позволяют их способности, но при этом нужно каким-то образом не допустить, чтобы они чувствовали, что работают в одиночку или получают поддержку только в случае удачного развития событий. Смысл в том, что возможность допустить ошибку абсолютно такая же, как и возможность преуспеть и добиться успеха. А это значит, что несправедливо укорять людей за ошибки в суждениях или за проблемы, возникающие в результате принятых ими решений.

Идеальная творческая среда должна обеспечивать свободную реализацию амбиций, но также и признание допущенных ошибок с возложением ответственности на виновных. Степень оказываемого людям доверия должна вызывать у них стремление извлекать уроки из допущенных ошибок, чтобы не допускать их впредь. Если команда всецело разделяет подобную культуру отношений, то она становится способной на самостоятельную корректировку своих действий. Когда существует отлаженная система выявления ошибок, ответственности за их возникновение и извлечения соответствующих уроков, то со временем их количество снизится (или сократится время их исправления), а люди привыкшие в основном работать без ошибок, будут действовать намного решительнее.

Никогда не рубите с плеча

Нет ничего хуже, если руководители или лидеры, особенно в критических ситуациях, начинают ругать кого-нибудь еще до того, как возникшая проблема будет решена. Мало того, что тем самым ровным счетом ничего не решается, так они еще и мешают быстро справиться с возникшей проблемой, поскольку наиболее сведущий в ней человек (подвергшись порицанию со стороны руководителя) ставится в положение обвиняемого и вынужден оправдываться. Представьте себе, что кто-то, работающий рядом с вами, ворвется к вам в кабинет с криком: «Пожар! Мой кабинет горит!», а вы только и сможете, что ответить: «Ну, ты тупой! Как ты умудрился его поджечь? Этого я от тебя никак не ожидал». Руководители примерно так всегда и поступают, причем остается только удивляться, почему. Я подозреваю, и многие со мной согласны, что привычка начинать решение проблемы с поиска виновных пошла, скорее всего, от плохих руководителей или родителей. Разумеется, если вы испортите людям настроение, выяснив, кому из них должно быть хуже всех, то ситуация никоим образом не улучшится (то, что вы узнаете, кто поджигатель, не поможет бороться с пожаром). А вернуться к истокам проблемы, определить, что и почему произошло, извлечь уроки для отдельных людей, лидера и всей команды лучше, когда проблема уже будет решена, страсти улягутся и напряжение спадет.

Доверяйте себе (уверенность в собственных силах)

Будь верен самому себе, тогда наступит день, как дважды два-четыре, когда ни перед кем не будешь ты фальшивить.

Шекспир, Гамлет

Ничему не верьте, не важно, где вы это прочитали или от кого услышали, не верьте даже сказанному мной, пока это не согласуется с вашими представлениями и здравым смыслом.

Будда

Последней темой, касающейся взаимосвязи между лидерством и доверием, является тема веры руководителя в самого себя. Эту глубоко философскую тему невозможно полностью осветить в рамках данной книги, тем не менее я уверен, что смогу в этом небольшом разделе предложить вам некоторые наиболее важные положения.

Если взглянуть на учебную программу средней школы или колледжа в США, вы не найдете такого курса лекций, который бы отвечал на вопрос, как определить, кто вы есть на самом деле. Странно, не правда ли? Для нации, которая ставит на первое место важность личности и свободы, в США не слишком многое делается для обучения своих граждан самоопределению, а еще меньше – уверенности в собственных силах. Самоопределение представляет собой процесс изучения того, что вы представляете собой как личность, независимо от друзей, семьи, работодателя или государства. Уверенность в собственных силах – это способность проявить свою индивидуальность в окружающем мире на основе той эмоциональной, материальной и финансовой среды, в которой вы существуете. Это не означает, что вы должны жить отшельником в лесу, питаясь дарами природы. Из этого следует, что вы можете заглянуть в себя и найти внутреннюю силу, позволяющую сделать выбор, в который вы верите, даже если с ним не согласны другие.

Руководство людьми, в его традиционном понимании, нуждается в том, чтобы отдельные люди были уверены в собственных силах. Вы можете рисковать или делать нелегкий выбор только в том случае, если обладаете внутренней убежденностью, приводящей вас к выводу о правильности ваших суждений. Без уверенности в собственных силах все ваши решения во многом будут зависеть от мнения других людей или от желания понравиться им, при отсутствии какого-либо основополагающего смысла, позволяющего разобраться в стороннем влиянии. Том Петерс (Tom Peters), Джон П. Коттер (John P. Kotter) и другие авторы называют такой основополагающий смысл системой ценностей. Они считают, что система ценностей может выступать для вас или для организации в качестве той самой основы, с мыслью о которой вы преодолеваете все самые сложные ситуации. Такой подход может быть вполне работоспособен, но я предлагаю нечто более глубокое и личное.

Уверенность в собственных силах начинается с доверия собственному мнению, то есть с возможности быть уверенным в собственной правоте в отношении какого-то вопроса, даже если другие люди с этим не согласны. Иное мнение может опровергнуть ваше собственное лишь в том случае, если вы сами его рассмотрите и придете к выводу, что стоит передумать. Иначе нет никакого смысла отказываться от собственного мнения (вы можете согласиться с чьим-то решением, уступая свои полномочия, но это не требует от вас отказа от собственного мнения). Ваши убеждения должны основываться на уверенности в собственных силах. Если вы будете менять свое мнение только потому, что другие люди думают иначе, вы подорвете веру в себя самого. Утрата веры в собственные силы почти так же опасна, как и утрата веры в свою команду.

Для самых смелых самоутверждение этим не заканчивается. Нужно не только уверовать в собственное мнение, нужно иметь и достаточную веру в основы собственных представлений, что позволит менять свое мнение и даже признаваться в собственных ошибках. Без изменений и определенной внутренней борьбы вы не сможете чему-либо научиться или вырасти как личность. Но если у вас есть вера в себя, вы сможете понять, что не утратили собственное я, даже если допустите какие-то ошибки или начнете постигать какие-то новые идеи. Эмерсон (Emerson) писал: «Глупое упрямство – это пугающее недоумие». Он подразумевал, что придерживаться одних и тех же идей просто ради упрямства не имеет никакого смысла. Умный человек должен постоянно чему-то учиться, а это требует от него выработки новых идей и мнений, даже если они противоречат тому, во что он верил ранее. Если вы сторонник активного интеллектуального и эмоционального образа жизни, ваши идеи будут расти вместе с вами.

Это означает, что самоуверенный человек может верить в свои силы, изыскивая способы восприятия стороннего влияния и облегчения формирования собственного взгляда на будущее, не препятствуя любым позитивным переменам. Вы можете свободно допускать ошибки, признавать их, менять свое мнение и не терять при этом своей индивидуальности.

Итак, если вы научитесь верить в самого себя именно таким образом, то вы в роли лидера сможете помочь также и другим людям научиться верить в собственные силы. В сфере разработки проектов и человеческой психологии никакая передача полномочий не сможет столь же эффективно помочь людям поверить в способность в большей степени полагаться на собственные силы.

Я рекомендую почитать эссе «Self-Reliance» Ральфа Вальдо Эмерсона (Ralph Waldo Emerson). Его можно найти в большинстве изданных сборников этого автора, а также по адресу http://www.emersoncentral.com/selfreliance.htm. Лучшим фундаментальным трудом, посвященным самоопределению, я считаю книгу Рика Филдза (Rick Fields) «Chop Wood, Carry Water» (Jeremy P. Tarcher, 1984). Если вас увлекает философия, попробуйте почитать книгу Альберта Камю (Albert Camus) «The Myth of Sisyphus» (Vintage, 1991). А чтобы завершить тему веры в собственные силы, приведу цитату из упомянутого эссе «Self-Reliance»:

Я вижу человека сильным и способным к достижению поставленной цели только тогда, когда он остается один в отсутствие посторонней помощи… Он, зная о своих врожденных способностях, понимая, что слаб, поскольку ищет [лишь] внешние благоприятные условия и с подобным восприятием решительно полагаясь лишь на силу собственного разума, вдруг моментально приходит в себя, встает в полный рост, всецело берет себя в руки и творит чудеса; человек, твердо стоящий на своих ногах, сильнее человека, стоящего на голове.

Выводы

• Доверие строится на безусловном выполнении принятых обязательств.

• Непоследовательное поведение в решении важных вопросов ведет к утрате доверия.

• Передавайте свои полномочия и оказывайте доверие, чтобы дать людям возможность справиться с работой наилучшим образом.

• Предоставленная власть исходит из организационной иерархии. Заслуженная власть возникает лишь в качестве ответной реакции на ваши действия. Она намного полезнее предоставленной власти, хотя необходимы обе эти разновидности.

• Передача полномочий позволяет поддерживать в команде доверительные отношения и не дает событиям развиваться неблагоприятно.

• Берите на себя ответственность за возникшие проблемы, укрепляя тем самым доверие подчиненных. Поддерживайте их в критической ситуации, чтобы они шли к вам со своими проблемами, а не пытались их скрыть.

• Вера в себя – основополагающий принцип руководства. Самоопределение является способом узнать, кто вы есть на самом деле, и развить уверенность в собственных силах.

Упражнения

1. Составьте список из пяти сотрудников, с которыми вы работаете чаще всего. Кому из них и почему вы больше доверяете?

2. Существует ли надежный способ завоевать чье-то доверие? Можно ли избежать рискованных поступков в развитии отношений и в то же время сделать их глубокими и доверительными?

3. Кто из известных вам руководителей полагался на предоставленную власть, а кто на власть заслуженную? Как это сказывалось на их деятельности?

4. Подумайте о серьезных обязательствах, которые были вам даны, но не выполнены? Как это повлияло на отношения с людьми, которые их давали? Вы когда-нибудь обсуждали случившееся? С какими обязательствами перед специалистами команды вы сами не справились? Существует ли способ выправить ситуацию в случае несоблюдения обязательств?

5. Как реагировал ваш руководитель на последнюю, допущенную вами ошибку? Как эта реакция отличалась от той, которая была с вашей стороны на последнюю ошибку, допущенную кем-то из ваших подчиненных?

6. В качестве исследования степени уверенности в своих силах, ответьте на вопрос: за какое решение вы боролись, несмотря на его непопулярность? Можете ли вы думать о том, как все будет воспринято, когда чувствуете свою правоту в том, что делаете, и доводите дело до конца, даже если знаете, что попадете под огонь критики со стороны других людей?

7. Когда в последний раз вы меняли свое мнение о чем-нибудь важном? Задайтесь целью изменить свое мнение о чем-нибудь, касающемся вашей жизни. Пригласите команду или группу друзей на ужин и сообщите, что сами оплатите счет, если они заставят изменить ваше мнение о чем-нибудь.

8. Исследуйте стили правления каких-нибудь двух лидеров из следующего списка: Ганди, Авраам Линкольн, Александр Великий, Наполеон, Чингиз-хан, Королева Елизавета первая, Нельсон Мандела. На кого из них вы предпочли бы работать? Почему? Какие методы они использовали для завоевания доверия (или манипулирования доверием) своих последователей? Сколько предоставленной и заработанной власти было у этих правителей?

9. Можно ли научить лидерству или это природный дар? Составьте список черт характера, присущих хорошему лидеру (воспользуйтесь, чем хотите из этой книги, или начните с чистого листа). Присвойте каждой черте характера баллы от 1 до 9: 1 – природная одаренность, 9 – свойство, которому можно научить.

Глава 13. Как осуществить задуманное

Один из мифов о руководстве проектами гласит, что кому-то навыки даются с рождения, а кому-то – нет. Как только этот миф упоминался в разговоре с другими руководителями проектов, я неизменно просил их объяснить, в чем состоит суть таких способностей – как узнать, что человек наделен ими, в какой мере и можно ли их развить у других. После дебатов мы обычно приходили к единственному выводу – ко многим другим нужным качествам и навыкам, о которых рассказывается в этой книге, нужно добавить еще умение осуществлять задуманное. Одним людям удается в должной мере применить свое мастерство и талант на благо продвижения проекта, другим – нет, даже если они по своему индивидуальному мастерству ни в чем не уступают первым. Способность добиваться желаемого результата – это сплав знаний о том, как стать катализатором процесса и управлять им в различных ситуациях, и мужества, необходимого, чтобы справиться с этой ролью.

Эта способность настолько важна, что используется при найме руководителей проекта в качестве своеобразной лакмусовой бумажки. Даже если руководители проектов не в состоянии дать этой способности точного определения без упоминания других умений и навыков, они считают, что могут определить ее наличие у других. К примеру, многие кадровики задают в отношении кандидата следующий вопрос: «Если в какой-нибудь важной части проекта что-то не заладится, мог бы я со всей уверенностью послать этого человека разобраться с проблемой и организовать ее решение, верю ли я в то, что он найдет способ оздоровления ситуации, независимо от степени сложности возникшей проблемы?» Если после собеседования ответ на этот вопрос дается отрицательный, то кандидату нужно отказать.^[76] В соответствии со сложившимися представлениями, если у кандидата недостаточно гибкости, чтобы применить свои навыки к возникшей ситуации, то с типовым проектом он не справится. Эта глава посвящена способностям осуществлять задуманное.

Правильно расставляйте приоритеты

В качестве руководителя проекта большую часть своего времени я тратил на составление разнообразных списков приоритетов, расставляя задания по степени важности. Я был убежден, что несмотря на все знания, которые за мной числились, вся моя деятельность, фактически, сводилась к составлению этих списков. Я сгребал в кучу все, что нужно было сделать, включая требования, характеристики, ошибки, в общем, все, а затем расставлял все это по степени важности для проекта. Целыми днями я занимался правкой этих списков, включая в них новую информацию, затевая вокруг них обсуждения и споры с другими специалистами, и всегда доводил свои списки до полного совершенства. После этого я упорно вел команду в соответствии с указанным в них порядком следования заданий. Иногда в этих списках фигурировал мой ежедневный распорядок работы, иногда – прикидки, чем будут заниматься группы людей в течение ближайших месяцев. Но процесс и эффект от него оставались прежними.

Я уделял так много времени составлению списков, поскольку знал, что правильная расстановка приоритетов – это залог прогресса. От четкого определения понятий, что является главным, а что второстепенным, от влияния этих понятий на каждый шаг в работе команды зависит успешная реализация всего замысла. Расстановка приоритетов должна отражаться в каждом посланном вами электронном сообщении, в каждом заданном вопросе и на каждом проводимом совещании. Каждый программист или тестировщик должен вкладывать свою энергию в те дела, которые напрямую ведут к успеху. А кто-то должен определять, что это за дела, и заставлять команду ими заниматься.

Больше всего к пустой трате времени при работе над проектом приводит путаница в заданиях и в очередности их выполнения. Многие недоразумения и оплошности происходят из-за того, что некто А предполагает одни приоритеты (добиться результата как можно быстрее), а некто Б – другие (добиться стабильности в работе продукта). Такое случается с программистами, тестировщиками, маркетологами, как, впрочем, и со всеми остальными специалистами команды. Если подобных конфликтов удастся избежать, то останется больше времени на достижение реальных целей проекта.

Я не хочу тем самым сказать, что дебатов вокруг приоритетов вообще быть не должно, их просто не может не быть. Но они должны вестись на ранней стадии, еще в ходе планирования. Если одни и те же аргументы реанимируются в процессе разработки, значит, люди недостаточно усвоили суть решения или забыли все логические выкладки и нуждаются в напоминании, почему было принято именно такое решение. Дебаты можно поддержать, но начать следует с вопроса, что, собственно, изменилось с тех пор, как были сверстаны планы, и зачем пересматривать приоритеты. Если ничего не изменилось (конкурент не придумал ничего нового, цели групп не обновлялись, увеличения или сокращения ресурсов не происходило, новые крупные проблемы не возникали), твердо придерживайтесь ранее принятого решения.

Возражения вряд ли возникнут или окажутся кратковременными, если список приоритетов будет вывешен на стене, чтобы каждый мог познакомиться с согласованной очередностью действий. Списки приоритетов дают всем возможность усвоить общую логическую структуру, исходящую из принятых решений. Если приоритеты ясны и понятны, то не нужно тратить время на их тщательное разъяснение.

Итак, если в чем-то работа команды не ладилась и люди не могли сосредоточиться на главном, я знал, что это мой просчет: либо я неверно расставил все по местам, не сумев как следует довести до людей порядок действий, либо не сумел выдержать и добиться определенного ранее порядка. В данном случае работа над расстановкой приоритетов и составлением списка имеет главенствующее значение.

Типовые списки приоритетов

Постоянная работа со списком приоритетов облегчает внесение поправок и изменений. Если каким-то чудом в рабочем графике отыщутся дополнительные ресурсы или время, будет вполне понятно, что их нужно потратить на следующее по важности задание. К тому же если рабочий график нужно сократить, то всем понятно, работу по какому из следующих наименее важных заданий следует остановить. Все это крайне важно, поскольку независимо от хода событий гарантирует возможность выполнения наиболее важного задания и проведения быстрой корректировки без особых усилий и моральных издержек. Следует также заметить, что любые ошибки, допущенные вами при расстановке приоритетов, имеют относительный характер: в том, что задание под номером 10 оказалось важнее задания под номером 9, нет ничего страшного. Поскольку список упорядочен, допустить слишком грубую ошибку довольно трудно. Кроме того, имея в своем распоряжении столь явно расставленные приоритеты и заставляя команду их придерживаться, можно, в конечном итоге, легко выкроить время, необходимое и на выполнение задания, стоящего под номером 10.

Для большинства проектов используются три наиболее важных типовых списка, содержащих расставленные по приоритетам цели, характеристики и работы (рис. 13.1). Цели проекта обычно являются частью концептуального документа (см. главу 4) или вытекают из него. Списки характеристик и работ появляются в результате проектирования (см. главы 5–7). Поскольку каждый из данных перечней наследует структуру приоритетов своего предшественника, чтобы заново уточнить приоритет каждого уровня и сопоставить уровни, вызывающие сомнения, можно организовывать обсуждения. Хотя не все решается в спорах, они гарантируют, что все принятые решения действительно касаются важных вопросов.

Списки приоритетов могут также понадобиться и для других важных дел. Сюда могут быть включены работы по исправлению ошибок, по реализации предложений заказчика, по порядку премирования работников и распределения ресурсов команды. Они могут быть составлены по тому же принципу расстановки приоритетов в том порядке, который позволил бы принести наибольшую пользу проекту или организации. Независимо от того, насколько сложен используемый для этих целей инструментарий (скажем, для отслеживания ошибок), никогда не забывайте о том, что суть ваших действий заключается в расстановке приоритетов. Если используемые вами инструменты не помогают расположить все по порядку, найдите для этого другие инструменты. К примеру, процесс классификации ошибок, когда люди собираются, чтобы решить, к какому сроку какую ошибку нужно исправить (если это вообще представляется возможным), фактически и есть коллективное составление списка приоритетов, относящихся к исправлению ошибок. Ошибки могут классифицироваться не отдельно, а по группам, но сути дела это не меняет.

Рис. 13.1. Три наиболее важных списка приоритетов

Если применяются три наиболее распространенных списка приоритетов, проверьте их согласованность друг с другом. Каждая работа должна обеспечивать реализацию какой-нибудь характеристики, а каждая характеристика соответствовать какой-нибудь цели проекта. Если добавляется новая работа, она должна выполняться в русле определенных характеристик и целей. Это обязательное условие, препятствующее появлению случайных элементов. Если вице-президент или программист хочет вставить в перечень что-нибудь экстраординарное, нужно заставить его обосновать свое желание конечными целями проекта: «Босс, конечно, это сильная характеристика, но каких целей проекта она поможет нам достичь? Либо нам нужно скорректировать цели и учесть последствия, либо вообще не стоит тратить на нее силы». Если приучить команду к согласованному принятию решений на всех трех уровнях, то ее функционирование станет целенаправленнее, а время не будет тратиться понапрасну.

Первоочередные и все остальные приоритеты

Как правило, любой список приоритетов можно разделить на две части. В верхней части располагается все, что нужно сделать в первую очередь, то есть все дела, без которых достичь успеха невозможно. Во второй части располагается все остальное. Приоритеты второй и третьей очереди тоже существуют, но понятно, что они в корне отличаются от первоочередных. Превратить второстепенное задание в первоочередное крайне трудно.

К проведению черты, отделяющей первоочередные приоритеты, нужно подходить очень серьезно. Следует всеми силами бороться за то, чтобы верхняя часть перечня была как можно короче и компактнее (такое же правило применимо к любому перечню задач концептуального документа). Пункт списка, относящийся к первоочередным приоритетам, означает: «Без этого мы просто не сможем жить». Это не должны быть задания, которые неплохо было бы иметь в верхней части перечня или которые очень хотелось бы там иметь: подобный подход слишком слабо отвечал бы задачам проекта. К примеру, при сборке автомобиля к первоочередным приоритетам можно было бы отнести установку двигателя, колес, трансмиссии, тормозов, рулевого колеса и педалей, а к приоритетам второй очереди – установку дверей, ветрового стекла, системы вентиляции и радиоприемника, поскольку ездить на машине можно и без всего этого. Функциональность автомобиля сохраняется, эти элементы можно убрать, а то, что осталось, все равно будет называться автомобилем.

Определить, где провести эту черту, всегда было нелегко, дело не обходилось без продолжительных дебатов вокруг всего, без чего не может прожить заказчик, и это вполне естественно. Хотелось бы, чтобы все дебаты происходили и заканчивались еще на ранней стадии. Как бы ни было трудно, в итоге получался перечень, содержащий жизнеспособные мнения и взгляды команды. Изучив и запротоколировав все «за» и «против» относительно созданного перечня, можно двигаться вперед. Процесс споров и дебатов, направленный на совершенствование перечня, на 90 % готовит к ответам на обычные вопросы или возражения, возникающие впоследствии (например, почему мы оборудовали машину тормозами, а не кондиционером), и позволяет сразу же их отклонить, поскольку все эти возражения уже звучали и их несостоятельность была доказана.

Сложности в выборе приоритетов всегда носят больше эмоционально-психологический, чем прагматический характер, независимо от того, что говорят на этот счет люди. Исключение желательных (но не обязательных) вещей, как и при соблюдении диеты или экономии денег, требует дисциплинированности, выдержки и сосредоточенности на главном. Говорить: «Для нас важна стабильность» – это одно, а сопоставить стабильность с другими важными свойствами – совсем другое. Многие руководители перед этим пасуют. Они занимают выжидательную позицию, откладывают трудный выбор на потом или вовсе отказываются от него и в результате приводят проекты к краху. Без трудного выбора прогресс невозможен. Если подходить к нему отвлеченно, то слово «важный» ровным счетом ничего не означает. Поэтому составление списков приоритетов и определение места, где должна пройти черта, отделяющая первоочередные приоритеты, требует от руководителей, да и от всей команды принятия нелегких решений и ясности мышления.

Ясность представлений способствует осуществлению задуманного в процессе реализации проектов. При этом каждый сотрудник ежедневно занимается вполне осмысленной работой, зная, зачем он это делает и как его занятие согласуется с тем, что делают все остальные. Когда команда задает вопросы, почему одно дело важнее другого, у нее есть для этого ясные и разумные основания. Даже если что-то меняется и уточняется, все проходит в рамках все той же системы, основанной на списках приоритетов.

Приоритеты – это сила

Случалось ли вам участвовать в нелегком нескончаемом споре? Может быть, половина разработчиков всецело была за вариант А, а другая половина – за вариант Б. А затем появлялся мудрый руководитель, задавал несколько вопросов, переводил дискуссию в новую колею и быстро добивался всеобщего согласия. Со мной такое тоже не раз случалось. Когда я был помоложе, мне это казалось чем-то особенным: каким-то непостижимым образом руководитель или ведущий программист оказывался умнее всех остальных и замечал то, что до него никто из нас разглядеть не мог. Однако присмотревшись к подобным ситуациям и расспросив самих руководителей, как им это удавалось, я понял, что их секрет заключается в твердом следовании приоритетам. Они восстанавливали в памяти список приоритетов и заставляли всю команду вести дискуссию только в рамках существовавших приоритетов. Правильно расставленные приоритеты – это сила, исключающая из дискуссии все второстепенное и открывающая возможность сосредоточиться на решении возникших проблем.

Если есть четко выверенные приоритеты, то при проведении любой дискуссии всегда можно задать такие вопросы, которые переведут спор на обсуждение куда более полезных и безотлагательных вещей. В результате оказывается переосмысленным общее представление о том, как добиться успеха, и все четко разделяется на две части: на важное и хорошее, но не важное. Вот для примера несколько таких вопросов:

• Какую проблему мы пытаемся решить?

• Если проблем несколько, то какая из них представляет наибольшую важность?

• Как данная проблема соотносится с нашими целями или влияет на них?

• Каков простейший способ исправить ситуацию, позволяющий достичь наших целей?

Если этого окажется мало, можно перевести разговор на цели проекта, против которых никто не станет возражать. Лучший способ привести многочасовые дебаты к позитивному решению – найти для них общую почву.

Станьте генератором приоритетов

Разговаривая с программистами или тестировщиками и выслушивая их проблемы и трудности, я все больше убеждался в том, что моя основная задача – помочь им сосредоточиться на главном. Ее суть состояла в том, чтобы убрать из их сознания все второстепенное и третьестепенное, и помочь увидеть четкую последовательность дальнейших действий. Существуют тысячи способов реализации проекта создания конкретной веб-страницы или системы управления базами данных, но лишь их малая толика способна реально охватить все обозначенные цели. Зная об этом, я всегда приветствовал случаи, когда программисты искали меня, столкнувшись с решением, в сроках реализации которого они не были уверены.

Но вместо мелочной опеки («Делай это. Не делай то. Не делай так. Ты что, уже сделал? Ну, и что теперь делать?») я доводил до сознания подчиненных, что моя задача – в нужный момент помочь им расставить приоритеты. Поскольку они не имели такого же широкого взгляда на проект, какой был у меня, я должен был помочь им хотя бы на какое-то мгновенье увидеть, как все, чем они занимались, соотносится с проектом в целом. Когда весь день уходит на отладку модуля или на тестирование компонента программы, весьма полезно выслушать объяснение общих положений проекта и заверения в том, что находишься на правильном пути. Порой, чтобы убедиться, что все «держат руку на пульсе», хватало и полуминутного разговора.

Когда же поступала новая информация по проекту, то именно я должен был в ней разбираться (либо самостоятельно, либо в ходе коллективного обсуждения), чтобы найти ей место в перечне приоритетов. Рабочий список приоритетов приходилось пересматривать довольно часто, поскольку в него нужно было вносить изменения, связанные с поступавшей информацией. Могло измениться мнение вице-президента. При изучении потребительских качеств продукта могли вскрыться новые проблемы. Конкурент мог внести в свой продукт какие-нибудь неожиданные изменения. Наши приоритеты были похожи на живой организм, на состоянии которого моментально и непосредственно отражались любые изменения в целях или в направлении развития проекта.

Поскольку вся работа по расстановке приоритетов лежала на мне, я дал возможность команде сосредоточиться на главном и таким образом способствовал прогрессу в ее работе. Иногда можно было воспользоваться приоритетами, определенными моим руководством (в концептуальных документах, в целях группы); а иногда я должен был готовить их самостоятельно, реагируя на возникновение неоднозначных или непредвиденных обстоятельств. То есть в первую очередь я был тем самым механизмом, который генерировал приоритеты. Если когда-нибудь собирательному образу руководителя проекта поставят памятник, я думаю, что на нем будет такая надпись: «Ведите ко мне толпы заблудших, запутавшихся, обозленных и огорченных программистов, жаждущих просветления».

Все получится, если сказать «нет»

Побочным эффектом от наличия списка приоритетов является частое использование слова «нет», которое многим дается совсем не легко. Однако не научившись говорить «нет», невозможно следовать каким бы то ни было приоритетам. Мир велик, а перечень первоочередных приоритетов краток. Поэтому большая часть из того, что в мире (или в вашей команде) многим представляется грандиозным, должно быть отклонено из-за несоответствия целям проекта. Это совсем не означает, что идеи сами по себе плохи, суть в том, что они не способствуют реализации данного конкретного проекта. Итак, для руководителей проектов действует следующий основной закон: если вы не можете сказать «нет», значит, вы не в состоянии управлять проектом.^[77]

Употребление слова «нет» начинается с руководства. Когда именно специалисты могут сказать «нет» в ответ на какие-либо запросы, определяется старшим руководством. Если руководитель команды независимо от расставленных приоритетов все время говорят «да», его примеру последуют другие. Программисты начнут разрабатывать только то, что им нравится. Руководители проектов начнут добавлять (или убирать) требования по своему усмотрению. Даже если отдельные избранные ими действия окажутся удачными, потеря командой единых правил и работы в направлении установленных приоритетов приведет к возникновению конфликтов. Порой все это может выразиться в форме разногласий в среде программистов, но чаще всего результатом будет разлад в конечных намерениях. От этого пострадает буквально все, и стабильность, и производительность, и потребительские свойства продукта. Без следования приоритетам заставить команду согласованно работать над созданием единого продукта очень трудно. Лучшие ведущие специалисты и руководители команд знают, что всему не вписывающемуся в рамки приоритетов нужно говорить «нет», устанавливая ту же норму и для всей команды.

Когда вы говорите решительное «нет», проект получает положительный импульс. Исключение из чьих-то планов ненужных задач дает людям больше энергии и стремления заниматься порученным делом в полную силу. Число совещаний и стихийных дискуссий сокращается, а их эффективность возрастает. Слово «нет» вызывает цепную реакцию: все остальные тоже начинают им пользоваться в пределах своей компетенции. Бывало, я специально просил об этом своих сотрудников: «Стоит вам только почувствовать, что вас просят о чем-то, не согласующимся с нашими приоритетами, говорите «нет». Или сошлитесь на меня. И не тратьте свое время на пустые споры; если в ответ вам выразят недовольство, сразу посылайте всех ко мне». Я не хотел, чтобы специалисты впустую тратили свое время на дебаты вокруг приоритетов, поскольку это была не их, а моя прерогатива. Даже если им никогда не приходилось сталкиваться с подобной ситуацией, я все равно выигрывал от того, что внушал им серьезное отношение к приоритетам и выказывал свой решительный настрой на защиту их интересов.

Учитесь говорить «нет» по-разному

Иногда вам нужно сказать «нет» в ответ на требование придать продукту какое-нибудь новое свойство. А иногда возникает необходимость вмешаться в чей-то разговор или в работу какого-нибудь совещания и сказать решительное «нет» дискуссиям, если те грозят обернуться сменой приоритетов. Для того чтобы подготовиться к этому, вам нужно освоить ряд способов выразить свое несогласие.

 Нет, это не соответствует нашим приоритетам. Если проект находится на ранней стадии реализации, вам нужно аргументировано доказать, зачем придерживаться именно этих приоритетов, причем нужно выслушать и сторонников иных приоритетов. Возможно, у них есть какие-то толковые идеи или им нужно объяснить суть поставленных задач. Вести дискуссию нужно вокруг приоритетов проекта, а не абстрактных ценностей отдельных характеристик или исправления допущенных ошибок. Если проект находится в поздней стадии реализации, нужно объявить «реформаторам», что их предложения уже давно выпали из обоймы. Даже если приоритеты выстроены недостаточно умело, их не стоит менять ради новой идеи относительно той или иной характеристики. Чем в более поздней стадия находится разработка проекта, тем серьезнее должны быть стратегические просчеты, которые могут послужить причиной корректировки целей.

 Нет, на это может не хватить времени. В рамках любого проекта всегда предлагается масса очень неплохих идей. Если вы стремитесь сохранить список приоритетов компактным, отвечайте уклончиво: дайте понять, что рассматриваемая идея может быть и хороша, но по сравнению с другими задачами и приоритетами проекта ей все же чего-то не хватает. Если она включена в список приоритетов второй очереди, скажите, что ее реализация вполне возможна, но слишком больших ставок на это делать не стоит.

 Нет, если только вы не сделаете <вставьте сюда ваше условие>. Иногда есть возможность обратиться к человеку с ответной просьбой. Если ваш вице-президент попросил вас добавить поддержку новой характеристики, скажите ему, что вы сможете это сделать только при условии, что он уберет одно из своих требований, входящих в список первоочередных приоритетов. Таким образом, можно отвести удар от себя и заставить просителя реально взглянуть на вещи, хотя, может быть, и без особого успеха. Точно так же можно поступить из политических соображений или для создания благоприятного впечатления о собственной персоне: «Салли, если ты сможешь доказать, что идея стоит того, я готов ее рассмотреть». Но можно получить и обратный эффект. (А что если Салли действительно поверит в ваши слова? Или, хуже того, поймет, что вы, образно говоря, послали ее куда подальше?)

 Нет, только не сейчас. Предположим, вы разрабатываете веб-сайт или программный продукт, подлежащий дальнейшему обновлению. Предложите отложить рассмотрение просьбы до следующего выпуска продукта. Это же может касаться и всех приоритетов второго уровня. Подобный прием часто называют отсрочкой.

 Нет, никогда. Ни в коем случае. Некоторые запросы настолько не соответствуют долговременным целям, что впору стукнуть кулаком по столу. Немедленно рубите все концы и, экономя собственное время, делайте повторное рассмотрение этого предложения невозможным. Иногда для объяснения причин нужно приложить определенные усилия (чтобы ни у кого не возникло соблазна повторить попытку). Например: «Нет, Фрэд, поисковая машина нашего веб-сайта никогда не будет поддерживать Эсперанто. И хватит об этом».

Реально оценивайте ситуацию

Ощущение действительности у одних команд может быть развито значительно выше, чем у других. Можно найти массу историй о командах разработчиков проектов, которые смогли сбыть свою продукцию лишь спустя месяцы или годы после разработки или допустили бюджетный перерасход в миллионы долларов.^[78] Постепенно такие команды начинают понемногу приукрашивать действительность, скатываясь к опасной и крайне непродуктивной черте. Как правило, чем больше команда отрывается от реальности, тем труднее осуществить задуманное. В данном случае (имеется в виду потеря командой ощущения действительности, а не ее склонность к вранью) руководители должны стать воплощением честности и показать людям, что они выдумывают несуществующие вопросы, не видят проблемных ситуаций или опираются на неверные приоритеты.

Я припоминаю, как несколько лет назад присутствовал на совещании небольшой команды разработчиков, создававшей нечто, чем хотела воспользоваться моя команда. Их презентация была посвящена новым характеристикам и технологиям, которыми они собирались оснастить свой новый продукт. Я сидел в самом конце комнаты и чувствовал себя все более и более неуютно. В презентации не было упомянуто ни одного серьезного вопроса, их как бы вообще не существовало. И тогда я понял причину своего беспокойства: игнорируя важные вопросы, организаторы впустую тратили время всех присутствующих.

Я огляделся и понял, что ситуация еще сложней, чем кажется: в числе присутствующих кроме меня не было никого из руководства моей организации. Вообще-то, к этому времени кому-нибудь из руководителей проектов или ведущих программистов пора было задать пару острых вопросов, но я не знал, способен ли на такое кто-нибудь из присутствующих. В моей голове роилась тысяча вопросов, тогда я решительно поднял руку и выпалил часть самых простых из них: «Каков ваш график работы? Когда вы сможете предоставить нам работоспособный код? Кто ваши заказчики и в какой очередности вы реализуете их запросы по отношению к нашим? Стоит ли нам вообще надеяться на вас и вашу команду?» Они абсолютно не были готовы к этому и буквально рты поразевали.

Стало ясно, что ранее они подобных вопросов не рассматривали. Хуже того, они не ожидали, что на них придется отвечать потенциальным клиентам. Я вежливо разъяснил им, что совещание не подготовлено и извинился за то, что они не поняли, чего я от них ожидал, когда соглашался прийти на это совещание (я ведь думал, что они были в курсе дела заранее). Я сказал, что без ответов на эти вопросы совещание и для них самих прошло впустую, после чего предложил отложить встречу до тех пор, пока у них не будет достойных ответов на мои элементарные вопросы. Они смущенно согласились и закончили совещание.

На языке руководителя проектов все, чем я занимался в этой истории, называлось «не верю» по аналогии с карточной игрой «верю – не верю», где выигрывает тот, кто первым избавится от всех карт. Делая ход, игрок объявляет свои карты и кладет их в кучку рубашкой вверх. При этом говорить правду он не обязан. Если второй игрок думает, что первый его обманывает, он может сказать: «Не верю», и заставить первого игрока вскрыть карты. Если он угадает, то первый игрок забирает всю кучку себе (откатываясь далеко назад). Но если он ошибается, то вся кучка достается ему самому.

Высказывая свое «не верю», можно дать толчок развитию событий.^[79] Если люди будут ожидать от вас серьезных поставленных ребром вопросов, они подготовят ответы на них еще до встречи с вами. Тогда вам и вашей команде не придется тратить время впустую. Следует помнить, что все виды обмана, включая самообман, работают во вред проекту. Чем скорее вскроется правда, тем раньше вы сможете предпринять какие-нибудь действия. Поскольку многие предпочитают избегать конфликтов и притворяться, что все идет хорошо (даже если совершенно очевидно, что это не так), кто-то должен раскрыть людям глаза. Чем правдивее будут отношения, тем реальнее ваша команда будет смотреть на вещи, двигаясь с высокой скоростью к намеченной цели.

Прямые вопросы могут быть неприятны людям или организациям и восприниматься как оскорбление или недоверие. Попытки вывести ситуацию на чистую воду могут рассматриваться не как стремление установить истину, а как личные нападки. Возможно, к ситуации, аналогичной той, о которой я рассказал, следует подходить более официально. Составьте перечень вопросов, ответы на которые ожидаете получить, и передайте его организаторам накануне совещания. Или подготовьте перечень вопросов, которые любой специалист организации может задать любому другому человеку (включая вице-президентов и руководителей проектов) в любое время, и вывесите его на стене конференц-зала. Тогда все потенциальные «не верю» станут публичным достоянием, что можно будет ввести в норму, не вызывая обид. Естественно, руководителям время от времени все равно придется говорить «не верю», демонстрируя команде свою решительность в борьбе за правду.

Определите критический путь

Согласно терминологии руководителя проекта, критический путь – это наикратчайшая последовательность действий, ведущая к завершению проекта. При исследовании критического пути анализируются диаграммы или блок-схемы, сделанные на основе всех работ и отражающие зависимость каждой работы от остальных. Правильно составленная блок-схема показывает, где могут быть узкие места. К примеру, если работы Б, и В не могут быть завершены, пока не будет доделана работа А, значит, именно через работу А проходит критический путь данной части проекта. Его значение заключается в том, что срыв сроков или некачественное выполнение работы А серьезно повлияет на завершение работ Б и В. Поэтому для руководителя проектов важно уметь спланировать критический путь и расположить его работы по приоритетам. Иногда относительно второстепенный компонент сам по себе может оказаться в критически важной зависимости, которая препятствует завершению по-настоящему первоочередной работы. Без анализа критического пути об этом можно не узнать до тех пор, пока не станет поздно что-либо предпринимать.^[80]

Исходя из общей точки зрения, критический путь есть ко всем ситуациям. Для них не требуется таких же детально проработанных блок-схем и расчетов, но рассуждения при оценке тех или иных ситуаций, с которыми приходится сталкиваться руководителям проектов, строятся сходным образом: проблему нужно рассматривать как взаимосвязанную цепь элементов и оценивать при этом все узкие места и критические моменты. Нужно ответить на вопрос, какие именно действия и решения зависят от других решений и действий, а затем подумать, достаточно ли им уделено внимания, не упущены ли в ходе обсуждений какие-нибудь реально существующие проблемы. Процесс разработки проекта можно значительно ускорить, если обратить внимание команды непосредственно на те элементы, факторы и решения, которые оказывают основное влияние на ход работ.

Нужно всегда иметь представление о критическом пути:

• Разработки проекта (об этом ранее уже упоминалось).

• Человеческих взаимоотношений (какие взаимоотношения между людьми подвержены высокой степени риска?).

• Процесса принятия проектных решений высокого уровня (кто тормозит работу всей команды?).

• Процесса создания программного кода и классификации ошибок (нет ли каких-нибудь бесполезных форм, совещаний или согласований?).

• Процесса информационного наполнения Интернета или корпоративной сети.

• Любых совещаний, ситуаций или процессов, влияющих на выполнение целей проекта.

Для того чтобы добиться желаемого результата, нужно иметь обостренное чувство критического пути. Мысль о нем должна присутствовать всегда, когда вы входите в кабинет, просматриваете электронную почту или участвуете в принятии решения. Действительно ли проблема является ключевой? Может ли она быть решена в ходе этого обсуждения или размышления? Сконцентрируйте свою энергию (или энергию всех присутствующих) в первую очередь на подобных рассуждениях и определите, что нужно сделать, чтобы сократить критический путь или выделить достаточно ресурсов и не допустить задержек в работе. Если удастся обнаружить критический путь, то расставить по местам менее значимые вопросы станет намного легче.

В некоторых организациях одним их методов оптимизации критических путей (не относящихся к сфере разработки) может стать распределение полномочий внутри команды. Вместо того чтобы согласовывать все подряд, дайте возможность отдельным специалистам принимать самим соответствующие решения и определять необходимость подобных согласований. Ту же самую практику введите и в отношении различного рода санкционирований, документирований, оформлений и других возможных бюрократических издержек (см. главу 10). Зачастую наилучшим способом оптимизации критического пути в организационной сфере является упразднение каких-нибудь процессов и передача полномочий в низшие звенья и самим командам, а не порождение новых процессов или иерархических структур.

Будьте непреклонны

Мир реагирует на поступки и ни на что другое.

Скотт Адамс

Увидеть проблему по силам многим достаточно умным людям, но далеко не всем из них захочется потратить силы и энергию на поиск ее решения, а затем набраться мужества для его реализации. Всегда найдутся более простые выходы из ситуации: оставить все, как есть, принять половинчатое решение, переждать, пока проблема не исчезнет сама по себе (скрестив пальцы на удачу), или обвинить во всем других людей. Куда труднее встретить проблему во всеоружии и противиться тем способам ее разрешения, которые идут вразрез с поставленными целями. Настоящие руководители проекта так просто не сдаются. Если речь идет о чем-то важном для проекта, они проявят настойчивость, применив любые средства для поиска ответа или решения проблемы. Для этого может понадобиться реорганизация неэффективно работающей команды, принуждение строптивой аудитории к признанию поставленных целей, поиск ответов на вопросы или улаживание существующих разногласий.

Иногда придется просить людей делать то, что им не нравится, или поднимать такие вопросы, на которые им не хочется отвечать. Без подобного принуждения вас будут склонять к более легкому выходу из положения. Ко многим проектам привлекаются люди, играющие специфические роли и не желающие отвечать за то, что лежит за пределами их ограниченной области (или на стыке их и чьих-то еще интересов). Возможно, еще большую сложность создает стремление большинства из нас избегать любых конфликтных ситуаций. Часто именно руководителю проекта приходится задавать неудобные вопросы, предъявлять претензии и добиваться истины, невзирая на доставляемые другим неприятности (хотя его задача – преподнести все как можно мягче). Ничего другого руководителю проекта просто не остается.

Зачастую те ситуации, которые изначально представлялись невозможными или безвыходными, рушатся под натиском психологических усилий непреклонного руководителя проекта. В этом отношении классическим примером может послужить миссия «Аполлона-13». Гин Кранз (Gene Kranz) в своей книге «Failure Is Not an Option» (Berkeley Publishing, 2001) описал, какие усилия были предприняты для ремонта системы жизнеобеспечения поврежденного космического корабля. Инженерная задача, с которой пришлось столкнуться команде, была из разряда сложнейших, и даже самые опытные специалисты сильно сомневались, что в сложившейся ситуации можно хоть что-нибудь сделать. Причем нужно было не только отыскать выход, но и сделать это в условиях острого дефицита времени. Кранз отказался от всех облегченных способов выхода из ситуации и нацелил команду на исследование всех возможных вариантов, подытоживая проводимые диспуты и направляя энергию в нужное русло. Все три версии этой истории, фильм «Аполлон-13», книга Кранза и книга «Lost Moon» (Pocket, 1995), написанная капитаном корабля Джимом Ловеллом (Jim Lovell) и Джеффри Клуджером (Jeffrey Kluger), дали самые превосходные оценки одному из величайших в истории примеру успешного управления проектом и решения сложнейшей проблемы.

Удачливые руководители проектов, прежде чем окончательно опустить руки, просто рассматривают намного больше всевозможных вариантов, чем обычные люди. Они исследуют те предположения, которые были безоговорочно отвергнуты другими, поскольку на их счет были высказаны какие-то опасения со стороны высшего руководства или они были забракованы экспертизой, в результатах которой никто не посчитал нужным усомниться. Вопрос: «Как вам удалось добыть эти сведения?» – самый простой способ разузнать, что является мнимым, а что действительным, хотя многие просто боятся или забывают его задать. Непреклонность основана на уверенности, что независимо от того, кто выступает в роли оппонента, в 99 % случаев решение проблемы может быть найдено (включая и те случаи, когда изменению подвергается сама формулировка проблемы), а если его все-таки не удастся найти, оперируя доступной информацией, значит, нужно глубже исследовать проблему. Всегда в первую очередь нужно думать об успехе проекта.

Когда я работал в подразделении Microsoft, занимавшемся разработкой Windows, моим руководителем был Хиллел Куперман (Hillel Cooperman), возможно, самый страстный и преданный делу руководитель за всю мою практику. Мне запомнилось, как однажды я пришел к нему в кабинет с одной дилеммой. Моя команда застряла на решении довольно сложной проблемы, имевшей отношение как к разработке, так и к политике. Для создания одного важного для нас компонента нам нужно было привлечь другую организацию, которая не хотела этим заниматься. Я обсудил вопрос со всеми заинтересованными лицами, заручился поддержкой влиятельных людей, но ничего так и не сдвинулось с места. Казалось, никакого разумного решения просто не существует, хотя вопрос по-прежнему оставался для нашего проекта важным, и я знал, что отступать некуда. После того как я обрисовал сложившуюся ситуацию, произошел следующий диалог: «И что ты успел перепробовать?» – я опрометчиво ответил: «Да все, что можно». Он посмеялся надо мной: «Неужели все? И как же тебе это удалось? Да если бы ты все перепробовал, то наверняка нашел бы приемлемое решение, которого у тебя до сих пор почему-то нет». Сложилась забавная ситуация, поскольку мы оба отлично знали, куда дальше зайдет разговор.

Затем он спросил, не нуждаюсь ли я в совете. Разумеется, я ответил утвердительно. Он несколько минут походил взад-вперед по комнате, бормоча что-то в такт своим шагам, и придумал массу новых вещей, над которыми следовало бы задуматься. «Так, кому ты еще не звонил? Электронная почта для этих дел не подходит. Да, с кем из тех, кто с тобой не согласен, у тебя хорошие отношения? Достаточно ли убедительно ты уговаривал их откликнуться на свою просьбу? Может быть, мне тоже следует вмешаться и обработать кого-нибудь на более высоком уровне? Сможет ли это сработать? Что если обратиться к нашему вице-президенту? Проявил ли ты достаточную настойчивость, подталкивая своих разработчиков к поиску обходного решения? Сколько раз ты пытался это сделать, пару раз? Неоднократно? Сделал все, что мог? Предлагал ли ты им напитки за счет фирмы? Или пообедать? Как ты с ними разговаривал, с каждым с глазу на глаз или со всеми сразу? Прояви настойчивость. Выход обязательно найдется. Я верю, ты решишь эту проблему. Только ни за что не сдавайся».

В результате он оказал мне двойную поддержку: напомнил, что мною еще не все перепробовано, но при этом дал понять, что принимать решение – это по-прежнему только моя прерогатива. Я, конечно, устал от всего этого, но его кабинет покидал с убеждением, что запас неисследованных путей еще не исчерпан, и мне следовало этим воспользоваться. Он подтвердил то, что кроме меня решать этот вопрос некому, и это придало мне дополнительные силы для проявления своей непреклонности. Решение крылось в одном из этих путей, мне просто нужно было его отыскать. Я в конце концов нашел решение этой проблемы (оно заключалось в организации обходного пути), как, впрочем, и десятка других, накопившихся к тому времени, но это произошло лишь потому, что я был нацелен на решение, оно не пришло ко мне само по себе.

Среди всего прочего, я научился у Хиллела тому, что битвы выигрываются усердным трудом. Если вы поймете, что окончательно измотаны, но будете биться над конкретной проблемой до конца, вы найдете новые возможности для ее решения. Если вы останетесь непреклонным достаточно долго, то люди усомнятся в собственных предположениях. Вы подтолкнете их к рассмотрению ранее упущенных возможностей, в которых зачастую и кроется ответ на нужный вопрос. Даже если возникнут трения и понадобятся переговоры, сознание собственной правоты и ваша настойчивость, скорее всего, заставят людей уступить. Иногда они могут сдаться только затем, чтобы вы оставили их в покое. Настойчивость при условии, что вы не перейдете на оскорбления, сама по себе может стать весьма эффективным приемом.

Непреклонность лежит в основе способностей добиваться желаемого результата. Существует масса способов пустить проект под откос, поэтому если за ним не стоит хотя бы одна заряженная на победу сила, толкающая его вперед, выискивающая альтернативные варианты его развития, хранящая веру в то, что из любой проблемы и западни всегда можно найти достойный выход, – проект обречен на провал. Эту силу представляют хорошие руководители проекта. Они двигают проект, находятся в постоянном поиске каких-то лучших, более быстрых и разумных путей его развития. Они выискивают все хаотичное и превращают его в нечто вполне разумное. Руководитель проекта при всем скептическом отношении к окружающему миру, необходимом в его работе, проявляет оптимизм, считая, что все проблемы могут быть решены при достаточной настойчивости и сосредоточенности. По причинам, которые они сами не вполне могут объяснить, руководители проектов неизменно выискивают всевозможные неоднозначные и сомнительные моменты и не сдаются до тех пор, пока не исследуют все возможные варианты выхода из возникшей ситуации. Они верят в то, что мысль непобедима, а чтобы отыскать хорошие мысли, следует немало потрудиться.

Оставайтесь в рамках здравого смысла

Непреклонность не означает, что следует стучаться во все двери подряд, отлавливать людей на проходной или торчать на работе до обморочного состояния. Может быть, работать с полным напряжением сил и неплохо, но работать всегда лучше с умом, а не только с усердием. Будьте непреклонны в силе духа, но в поступках лучше полагаться на сообразительность и здравый смысл. Отказ сдаваться не должен означать, что нужно страдать от бессмысленных, глупых или бесполезных поступков (хотя иногда избежать их не удается). Нужно искать разумные обходные пути или наиболее быстрые способы решения проблемы. Воспользуйтесь помощью окружающих вас людей и не думайте, что вы все должны делать самостоятельно. Но важнее всего быть восприимчивым ко всему, что происходит вокруг вас, вокруг отдельных сотрудников и всей команды.

Основная ошибка многих руководителей проектов заключается в том, что они забывают изучить тех, с кем работают, и соответствующим образом скорректировать свои подходы к ним. «Морские котики» и армейские рейнджеры тренируются в выполнении заданий в различных условиях местности: в пустынях, болотах, джунглях, тундре. Без этих тренировок эффективность их действий окажется ограниченной: им придется выживать на незнакомой местности, поскольку у них не будут выработаны соответствующие навыки (представьте, что солдат в зелено-оливковом камуфляже пытается остаться незамеченным на заснеженном поле). Перво-наперво на основе имеющихся навыков они учатся, как оценивать обстановку и продумывать тактику и стратегию применительно к создавшейся обстановке. Этот же прием вполне подойдет руководителям проектов. Вместо окружающей местности руководителям проектов следует уделить внимание изучению различной социальной, политической и организационной обстановки, в которую они попали, и воспользоваться правильными подходами применительно к создавшейся ситуации.

Придерживаться здравого смысла и оценивать окружающую обстановку особенно важно в следующих ситуациях:

• Настраивая и побуждая людей к действию.

• Организуя работу команды и планируя действия.

• Улаживая споры или отыскивая выходы из тупиковых ситуаций.

• Проводя переговоры с представителями других организаций или учреждений.

• Требуя дополнительные ресурсы.

• Убеждая людей в чем-нибудь.

• Разбираясь с отчетами (с персоналом).

Далее приводится краткое руководство для руководителей проектов по использованию здравого смысла при оценке обстановки. Данный перечень вопросов пригоден как при общении с отдельными сотрудниками, так и в работе с большой командой или группой людей.

 Какой стиль общения был использован? Прямой или опосредованный? Каким было это общение, открытым или сдержанным? Применялись ли общепринятые приемы доказательства отдельных положений? Было ли общение по электронной почте более эффективным? Или эффективнее оказалось проведение совещаний? Как принимались решения, в открытом обсуждении или кулуарно? Выберите такие подходы к общению, которые будут эффективными независимо от того, с кем именно вы беседуете.

 Насколько развито у сотрудников коллективное чувство юмора? Какие темы закрыты для шуток или вопросов? Как другие справляются деликатными (сложными, спорными) темами или решениями?

 Можно ли выиграть спор, оперируя данными? С помощью логических доводов, высказанных в ходе дискуссии? Строго придерживаясь целей проекта? Кто громче всех кричит? Кто откровеннее всех скучает? Продумайте, как использовать аргументы, которые можно изложить в подходящих для данной аудитории стиле, формате или тоне, кто бы это ни был: тестировщик, которого вы остановили в коридоре, или полный зал разработчиков.

 Кто хорошо справляется с <вставьте то, что вы пытаетесь сделать>, и смогу ли я научиться этому у него или повторить его действия? Обращайте внимание на эффективные приемы работы. Кто в них преуспел больше всех? Кто завоевал наибольшее уважение? Как они сумели этого добиться? Кто потерпел неудачу, пытаясь это сделать? По каким причинам?

 Что в моем поведении ценится этим человеком или группой больше всего? Сообразительность? Смелость? Расторопность? Ясность высказываний? Терпеливость? Покорность? Какая манера поведения ценится меньше всего или порицается? Программисты и управленцы могут сильно расходиться в оценке. Поэтому перед тем как кого-то в чем-то убеждать, следует изучить его шкалу ценностей.

 В чем заключаются особенности организационной культуры? В каждом университете, в каждой корпорации или команде существуют различные взгляды на культурные ценности. Если вы думаете, что в вашей организации в этом смысле нет ничего особенного, значит, длительный срок пребывания в ее стенах наложил на вас свой отпечаток, и вы утратили способность замечать эти особенности (а может быть, вы изначально не были способны к этому). В одних организациях ценится лояльность и уважительное отношение к интеллектуалам, обладающим яркой индивидуальностью. В других организациях упор делается на производственную этику и строгое выполнение возложенных обязанностей.

Руководитель проекта должен корректировать стиль своей работы, основываясь на ответах на данные вопросы. Входя в чей-то кабинет или на чье-нибудь совещание, всегда нужно действовать по обстановке. Надо брать пример с морских пехотинцев: сначала оценить сложившуюся обстановку, а потом уже делать выводы о том, каким должен быть путь к достижению целей проекта. Не стоит выбирать трудный путь, если есть более разумный подход к решению поставленных задач.

Партизанская тактика

Придерживаться здравого смысла означает быть в постоянном поиске разумного подхода и стремиться применять его как можно чаще. В приводимом далее перечне собраны тактические приемы, когда-то успешно примененные мною или кем-то в отношении меня самого. Не знаю, насколько полезными окажутся для вас некоторые из этих приемов, но в целом я уверен, что этот перечень заставит вас задуматься о поисках разумного подхода к достижению поставленных целей. Некоторые приемы достаточно рискованны (о чем вы будете предупреждены), поэтому их следует применять с осторожностью. Даже если вам из этого перечня ничего не подойдет, узнав о нем, вы станете более осмысленно оценивать окружающую вас обстановку.

 Ищите тех, кто обладает реальными полномочиями. Не тратьте попусту время на споры с людьми, которые не имеют никакого влияния на проблемный вопрос. Серьезный подход к делу требует разузнать, кто принимает решения или может повлиять на возникшую проблему или ситуацию. Отыщите этих людей (ими могут оказаться и не самые главные из присутствующих, в зависимости от характера проблемы это могут быть разные люди), поговорите ними с глазу на глаз и сделайте выводы. Или, по крайней мере, выясните суть их возражений. Если вы не можете заручиться поддержкой наиболее влиятельного человека (скажем, Салли или вице-президента), найдите того, кто может в большей степени повлиять на него самого (лучший специалист из команды Салли). Проберитесь как можно выше к верхним ступеням этой лестницы. Но будьте осторожны: не пытайтесь ввести людей в заблуждение. Добейтесь поддержки влиятельных людей, но при этом, если потребуется, привлеките и сторонников противоположной точки зрения или раскройте перед ними свои карты. «Послушайте, при всем нашем несогласии у нас не вызывает сомнения, что это решение принадлежит Салли. Я собираюсь поговорить с ней об этом завтра и хочу, чтобы вы присутствовали при этом разговоре». (См. главу 16.)

 Обращайтесь к первоисточнику. Если информация имеет сложный характер, не тратьте зря время, выслушивая ее в чьем-то пересказе или пользуясь лишь письменными отчетами или сообщениями электронной почты. Найдите автора этой информации и поговорите с ним непосредственно. Никакие отчеты или сообщения не смогут ответить вам на возникшие вопросы, а кроме того, в общении могут вскрыться некоторые важные моменты, не нашедшие письменного отражения. Обращаться к первоисточнику всегда надежнее и ценнее, чем получать информацию по другим каналам, и ваши усилия в этом направлении будут вполне оправданы. К примеру, если два программиста спорят о том, что именно сказал третий, то лучше сходить к этому третьему или уточнить все по телефону. Всегда стремитесь добыть истинную информацию и настраивайте на то же самое других.

 Меняйте способ общения. Если общение не складывается, нужно изменить его способ. Вместо обмена сообщениями по электронной почте позвоните по телефону. Вместо звонка заявитесь прямо в офис. Каждый чувствует себя более комфортно, пользуясь теми или иными способами общения. (Вообще-то, предпочтительнее всего личное общение у классной доски. Если общение по электронной почте по каким-то причинам приобретает неуправляемый характер, соберите людей в комнате, оборудованной классной доской.) Не допускайте, чтобы ограничения, накладываемые конкретными технологиями общения, становились на вашем пути. Иногда смена способа общения приводит к разным ответам на одни и те же вопросы, поскольку восприимчивость людей меняется в зависимости от избранного способа. Если речь идет об улучшении динамики общения между вами и вашими сотрудниками, играющими важную роль в каком-нибудь серьезном деле, придется потратить время и деньги на авиаперелет или на поездку в их офис.

 Оставайтесь с людьми наедине. Когда вы разговариваете с человеком без свидетелей, его отношение к вам отличается о того, которое складывается при разговоре в присутствии большой группы людей. На совещаниях выступающие должны приспосабливать свою речь, чтобы она как можно лучше воспринималась всеми присутствующими в зале. Иногда, в зависимости от состава слушателей, можно услышать совершенно разные вещи. Если вы хотите добиться откровенного мнения или провести с кем-то задушевную беседу, нужно остаться с человеком наедине. Следует учесть и влияние людей друг на друга: если Джим прислушивается к мнению Бет, а вы хотите в чем-нибудь убедить Джима, то вам сначала следует в приватной беседе убедить в этом Бет. Не заманивайте никого в западню, но и не уклоняйтесь от выяснения всего, что может ускорить прогресс.

 Устраивайте охоту на людей. Если появилось срочное дело, времени на которое явно не хватает, нужно выкроить его из вашего рабочего графика и взять в осаду офис или то место, где работает нужный вам специалист. Подобные вещи мне приходилось проделывать неоднократно. Если сотрудник не отвечал на мои звонки и сообщения электронной почты, то, вернувшись с какого-нибудь совещания, он заставал меня сидящим возле его двери. В порядке вещей было и то, что его останавливала заранее предупрежденная мною охрана. В том, что вам придется бегать за кем-то, в ком вы остро нуждаетесь, нет ничего зазорного. Ищите этого человека в буфете. Обойдите во время обеденного перерыва все близлежащие забегаловки. Спрашивайте у секретарей, на каком совещании он может присутствовать, и ждите его за дверью. Не нарушая этикета, ведите решительную охоту и всегда добивайтесь своего. (В личную жизнь постарайтесь не вмешиваться. Если вы охотитесь за информацией, переступать эту грань нельзя ни при каких обстоятельствах.)

 Прячьтесь. Если накапливается много работы и вам нужно выиграть время, чтобы нагнать упущенное, превращайтесь в невидимку. Время от времени я занимал конференц-зал (в соседнем здании) и сообщал об этом только узкому кругу людей, которым полагалось знать, где я находился. Там без каких-либо помех я разбирал электронную почту, вел корректуру технических условий, оценивал работу подчиненных или подчищал какие-нибудь другие важные «хвосты». В небольших организациях такого же эффекта можно добиться, работая дома или в ближайшем кафе (что стало намного проще с появлением беспроводных сетей). Я всегда именно так и поступал, когда чувствовал в этом необходимость. У руководителя проекта редко бывает время, когда его никто не отвлекает, поэтому приходится предоставлять такое время самому себе.

 Пользуйтесь советами. Не совершайте невынужденных «слепых полетов». В каждой конкретной ситуации считайтесь с тем, что кто-то продумал ее глубже вас и может дать дельный совет, как добиться нужного результата. Воспользуйтесь любыми доступными знаниями или опытом других людей. Отведите их в сторонку и попросите поделиться своим опытом с вами, неважно, к чему это относится, к общению с конкретным человеком, к решению, к плану и т. д. «Послушай, Боб, я хотел бы услышать от тебя совет по поводу этого бюджета. У тебя не найдется пара минут?» Или: «Джейн, я пытаюсь поработать над этой проблемой вместе с Сэмом. Посоветуй, как его убедить отказаться вот от этой характеристики?» Для многих людей просьба дать совет только повысит их доверие к вам, поскольку если вы просите человека поделиться с вами его мнением, значит, вы оказываете ему уважение.

 Просите оказать любезность, умоляйте, идите на подкуп. Воспользуйтесь своей репутацией, чтобы извлечь выгоду из оказываемого вам доверия и великодушного отношения. Если вам нужно, чтобы разработчик выполнял сверхурочную работу, возникшую из-за ваших просчетов или связанную с задержкой требований, попросите его об одолжении. Выйдите за рамки жестких рабочих взаимоотношений и просто попросите его об этом. Предложите ему пообедать за ваш счет (двадцать долларов тоже кое-что значат независимо от степени его расположенности к вам) или скажите, что один обед будет за вами (и потом обязательно сдержите обещание). Худшее из всего, что может быть, это отрицательный ответ на вашу просьбу. Чем благосклоннее вы были по отношению к другим, тем больше сможете поставить на кон в этом деле. Можно пойти и дальше. Нет ничего зазорного в том, чтобы что-то предлагать людям, убеждая их оказать вам помощь в выполнении работы, которую нужно сделать во что бы то ни стало.

 Сталкивайте людей лбами. Если делать все предельно осторожно, то в этом нет ничего плохого. Если Сэм оценивает продолжительность работы в 10 дней, а вы думаете, что он лукавит, обратитесь к Бобу. Если Боб определил меньший срок, вернитесь вместе с ним к Сэму. В разговоре сразу выяснится, каким должен быть реальный срок выполнения работы. Если вы однажды так и сделаете, то никто из разработчиков больше не отважится лукавить относительно сроков работы (поскольку вы сказали «не верю»). Однако у Сэма может быть такой характер, что вы испортите с ним отношения, поэтому делать все нужно как можно тактичнее и только в случае острой необходимости. Хорошие ведущие программисты сами должны заставить всех раскрыть карты, но если они этого не делают, все придется решать вам.

 Подготавливайте почву. Никогда не ходите на важное совещание, не имея никакого представления о мнениях наиболее влиятельных из участвующих в нем людей. Всегда приходите на него, заранее зная, кто готов поддержать ваше мнение, а кто, скорее всего, будет против, и имея готовую стратегиею, разработанную для того, чтобы справиться с ситуацией (см. главу 16). Если под угрозой находится что-то важное, предпримите необходимые меры, чтобы до начала совещания поколебать позицию противников или сплотить сторонников. Не прибегайте ко лжи и манипуляциям, не вводите людей в заблуждение, лучше как следует подготовьтесь и разберитесь со всеми подходящими доводами и возражениями.

 Покупайте людям кофе и что-нибудь вкусное. Как бы глупо это ни звучало, но я понял, что люди, с которыми я вел многодневные споры, в конце концов, становятся более покладистыми после чашки хорошего кофе, выпитой в ближайшем кафе. Измените динамику взаимоотношений: неважно, нравится вам этот человек или нет, потратьте буквально двадцать секунд на приглашение. Даже если он скажет: «Нет, лучше поговорить именно здесь?» – вы ничего не потеряете. Перенос разговора в другую, может быть, менее формальную обстановку поможет ему допустить возможность вариантов, которые раньше он не принимал во внимание. С точки зрения биологии, после того как люди попробовали что-нибудь вкусное или побывали в более приятной обстановке, их настроение улучшается. Я знавал руководителей проектов, которые специально для таких случаев держали в кабинете пончики и пирожные (а также ром и шотландское виски). Можно ли считать это проявлением доброжелательности? Да, но на первый план выходят психологические выгоды от того, что люди, с которыми вы работаете, неплохо перекусят и станут ассоциировать вас с чем-то хорошим.

Выводы

• В списке приоритетов можно отразить все, что угодно. Значительную часть своего времени руководитель проекта затрачивает на правильную расстановку приоритетов и руководство командой в соответствии с ними.

• Тремя типичными списками приоритетов являются список целей (концепция), список характеристик (функциональная спецификация) и перечень работ. Их необходимо согласовать друг с другом. Каждая работа должна обеспечивать реализацию заданной характеристики, а каждая характеристика следовать определенной цели.

• Между первоочередными и всеми остальными приоритетами нужно провести жирную черту.

• Все задуманное будет осуществлено, если вы научитесь говорить «нет». Если вы не можете сказать «нет», значит, у вас фактически нет никаких приоритетов.

• Руководитель проекта должен быть воплощением честности в команде и постоянно держать ее в курсе реального состояния дел.

• Знание критического пути в процессах разработки и управления командой позволяет повысить эффективность работы над проектом.

• Чтобы осуществить задуманное, вы должны проявлять непреклонность и оставаться в рамках здравого смысла.

Упражнения

1. Подумайте о нерабочей ситуации, в которой не было заранее определенного лидера, может быть о каком-то общественном событии или учебном проекте. Кто вызвался стать лидером и почему? Этот человек открыто попросил об этом или сам взял на себя управление ситуацией?

2. Добровольно согласитесь вести какое-нибудь дело, в котором никто не обязан на вас работать и добиться желаемого можно только через убеждение и влияние. Создайте какую-нибудь социальную группу на веб-сайте Meetup (www.meetup.com) или запись о команде из спортивной лиги в вашем сетевом окружении. Используйте это в чисто исследовательских целях, чтобы проверить свою способность добиваться желаемого.

3. Кто в вашей организации имеет репутацию человека, который всегда осуществляет задуманное? Как такие люди этого добиваются? Есть ли в организации люди, которых считают не способными осуществлять задуманное? Есть ли какая-нибудь взаимосвязь между их положением в команде и способностью осуществлять задуманное?

4. Для каждой имеющейся задачи определите одного, наиболее важного человека, способного добиться ее осуществления (чаще всего это какой-нибудь программист или руководитель команды). Удостоверьтесь в том, что ему известна важность его роли в выполнении задачи и ваша готовность всячески содействовать его успеху.

5. Как вы следите за приоритетами своей команды? Как вы обеспечиваете их наглядность и ясность для всех сотрудников? Попросите своих специалистов высказаться насчет способов, позволяющих сделать приоритеты более запоминаемыми.

6. Представьте себе проект, где критический путь для большинства работ проходит через работу одного-единственного специалиста. Какие «за» и «против» можно высказать по поводу подобной ситуации? Каков диапазон возможных действий, которые можно предпринять либо для сокращения рисков, либо для повышения шансов на успех?

7. Приходилось ли вам работать под руководством человека, постоянно меняющего свое мнение? Как это обстоятельство влияло на ваши возможности осуществления задуманного? А что вы можете сказать о ком-то, кто никогда не менял своего мнения?

8. Если здравомыслие является частью способности добиваться задуманного, то как это может отразиться на процессе найма на работу руководителей проектов и лидеров? Как во время собеседования можно оценить чью-то возможность проявлять убедительность?

9. Вы решили стать неутомимым руководителем проекта. Вы изо всех сил стараетесь добиться задуманного и никогда не сдаетесь. Ваш начальник и другие руководители команды заметили это и явно насторожились в ответ на ваше новое отношение к работе. Как добиться желаемого, не раскачивая лодку и не расстраивая других лидеров?

10. Как выбрать подходящий момент для визита к начальнику или к начальнику своего начальника, чтобы добиться задуманного? Как проявить благоразумие, проталкивая нужный вопрос вверх по цепочке управления?

11. Если говорить: «Мы не должны смириться с провалом», то это будет пустым звуком. Многие используют высказывания из кинофильмов в надежде на то, что произнесенные фразы дадут все необходимое для достижения успеха. Пригласите в рабочее время свою команду посмотреть фильм «Аполлон-13». Обсудите с ней, какими качествами, позволяющими добиться успеха, обладали Кранз и его команда. И чем от них отличается ваша команда?

Глава 14. Стратегия миттельшпиля

Название главы позаимствовано из шахматной терминологии. Шахматная игра делится на три части: дебют, миттельшпиль и эндшпиль. В ходах, которые игроки делают в миттельшпиле, раскрывается их основная стратегия. Именно в этой части игры делается основная часть всех ходов. Игра завершается эндшпилем, когда ресурсы уже на исходе и каждый ход на счету. Эндшпиль проекта рассматривается в следующей главе, а данную главу, которая посвящена миттельшпилю, хочется начать цитатой Луи Пастера: «Открытия приходят лишь к тем, кто подготовлен к их пониманию».

Миттельшпиль проекта находится в середине общего рабочего графика. Он наступает, когда часть компонентов уже работает, а часть – нет, некоторые вопросы изучены и решены, а другие еще ничем не проявились. В миттельшпиле множество событий происходит одновременно, затрудняя ясное представление о том, насколько благополучно они развиваются. Термин туман войны, введенный Клаузевицем^[81] для характеристики впечатлений о хаотичности военных действий, как нельзя лучше подходит к миттельшпилю. Такой же туман неизбежно окутывает и команду, всецело занятую разработкой, поэтому неопытным специалистам в нем легко затеряться. Провести команду через неопределенность миттельшпиля и вывести ее к эндшпилю, где все снова становится на свои места, – основная обязанность руководителей команды.

В простейшем представлении миттельшпиль, как и эндшпиль, целиком относится к проектному сопровождению высокого уровня:^[82]

4. Если к концу дня все в проекте идет хорошо, значит, ваша цель на следующей день – сохранение этой тенденции.

5. Если в какой-то из дней в проекте начинаются проблемы, ваша цель – найти причину, а затем предпринять необходимые действия для того, чтобы проект снова вошел в нужную колею. На это может уйти несколько часов, дней или недель.

6. Повторяйте предыдущие действия, пока проект не будет завершен.

Очевидная сложность заключается в бесчисленном количестве причин, по которым работа над проектом может не заладиться. Хуже того, на выявление этих причин отводится весьма краткий срок, а на их устранение, возможно, и того меньше. Не считая тех усилий, которые нужно приложить, чтобы защитить от всяческих напастей благополучно развивающиеся части проекта.

По этим и другим причинам в миттельшпиле и эндшпиле уровень прилагаемых усилий и испытываемых стрессов очень высок. Команда работает ускоренными темпами, и право на ошибку тает с каждым днем. А по мере приближения к последней стадии проекта кому-то нужно понять, что для благополучного завершения правильнее не просто «нажать на тормоза», а притормаживать постепенно.

В данной главе и далее я буду придерживаться тех же предположений о методах работы, которые использовались в главе 2, поэтому перед тем, как двигаться дальше, имеет смысл еще раз просмотреть раздел «Решающие факторы и методологии» в главе 2.

Хотя материалы данной главы в основном посвящены миттельшпилю, а следующей – эндшпилю, эти главы во многом перекликаются в том, как и когда должны применяться описываемые технологии (например, эндшпиль одного из этапов может рассматриваться как часть миттельшпиля всего проекта). Поэтому не удивляйтесь, если иногда при изложении материала я буду совершать экскурсы вперед и назад по этим казалось бы разным темами.

ПРИМЕЧАНИЕ

Описание механизмов управления миттельшпилем и эндшпилем, приводимое в этой и следующей главах, дано в масштабе довольно крупного производства. Если вам встретятся ситуации, не подходящие к масштабу вашего проекта, то вы их можете пропустить. Я не думаю, что предлагаемые здесь рекомендации можно целиком применить к какому-нибудь отдельно взятому проекту. Тем не менее я пытаюсь предложить вам наиболее ценные сведения, применимые не только к вашему текущему проекту, но и к любым другим проектам, которыми вам, возможно, еще предстоит заниматься.

Бежать впереди паровоза

Управление большими и весьма опасными объектами требует не только твердой руки. Чем больше управляемый объект и чем больше в нем людей, тем сильнее его инерционность. Новички, как в руководстве проектами, так и в управлении тяжелыми машинами (грузовиками, аэробусами, авианосцами и т. д.), недооценивают время реакции объекта на изменение положений органов управления. На рис. 14.1 показана траектория автомобиля или проекта, заметно изменяющаяся в зависимости от количества вовлеченной в процесс кинетической энергии и других сил. Многим людям не удается правильно выстроить свои предположения относительно последствий собственных действий. Причина часто кроется в том, что они не понимают, какие силы оказывают влияние на динамику тех объектов, с которыми им приходится иметь дело. Они напоминают ученика автошколы, впервые попавшего в занос на снежной дороге из-за того, что слишком много непонятных сил помешало ему справиться с управлением.

Рис. 14.1. Одни и те же действия могут привести к различным результатам в зависимости от инерционности проекта

При потере управления люди, призванные контролировать ход событий, обычно впадают в панику. Они могут не осознавать этого (утратившие самообладание крайне редко признаются в своем состоянии), но факт остается фактом. Первой реакцией на происходящее обычно становятся решительные действия, направленные на выправление возникшей ситуации. Но поскольку люди так и не поняли, какие силы участвуют в данном процессе, эти корректирующие действия, как правило, оказываются чрезмерными (рис. 14.2). К тому времени, когда они понимают, что наделали, требуются новые корректирующие действия, которые не заставляют себя ждать. А поскольку они руководствуются той же самой логикой, которая уже привела их к столь забавной ситуации, возникают все новые и новые проблемы.

Рис. 14.2. К ужасу тех, кто обязан контролировать ситуацию, корректирующие действия в ответ на влияние неизвестных сил могут иметь непредсказуемые (и зачастую неприятные) последствия

Когда движение самолета, автомобиля или проекта становится нестабильным, резкие управляющие действия становятся опасными, даже для тех, кто обладает завидным мастерством и опытом. (Разумеется, небольшие проекты более податливы и управляемы, но у них также имеется некоторая инерционность.) Нестабильность делает непредсказуемыми результаты многих действий, потому что слишком часто и слишком быстро происходят разного рода изменения. В такой обстановке хорошее управление проектом во многом заключается в том, чтобы быть на один-два шага впереди самого проекта, прикладывая все усилия, необходимые в первую очередь для того, чтобы не попасть в подобную ситуацию.

У летчиков-истребителей есть одно образное выражение, прекрасно описывающее состояние пилота, у которого нет дара предвидения: он летит позади самолета. Это значит, что пилоту не удается быть хотя бы на шаг впереди того, что происходит с его самолетом, и он становится жертвой совокупности сил, воздействующих на его истребитель. Проекты, как и полеты на мощных самолетах, требуют управления множеством взаимодействующих сил. Все они относятся к нелинейным системам, а значит, изменение одного из параметров (скорости, угла, режима, цели) может привести не к одному, а к множеству эффектов или повлиять на систему более существенно, чем ожидалось, поскольку воздействию параллельно подвергается множество различных факторов или людей. Отсюда следует предостережение: даже при работе над стабильным, но скоротечным проектом непростая природа, присущая как программной среде, так и самой команде разработчиков, предполагает непредвиденность последствий любых управляющих действий. Иногда эти последствия ничем себя не проявляют в течение нескольких дней или даже недель. Когда же отложенные последствия наконец проявятся, то легко можно предположить, что их проявления были вызваны какими-то другими совсем недавними причинами, и тогда эффективное решение проблемы будет затруднено.

Мыслите здраво

Для руководителей проектов наиболее эффективным способом бежать впереди паровоза может стать ежедневный контроль логики собственных действий. Программисты называют проверку правильности важных блоков кода санитарным контролем (в терминологии языка С можно вспомнить о функции assert()). Если учесть, что предположения – вещь крайне опасная, то ценность этой идеи не вызывает сомнений. Когда одна из санитарных проверок программного кода закончится неудачей, можно будет не искать черную кошку в темной комнате (несуществующую проблему), а задаться более существенным вопросом: почему в систему было введено абсурдное условие?

Если вы захотите бежать впереди паровоза, то вам следует постоянно проверять состоятельность ожидаемых вами условий. Как только вы обнаружите какую-нибудь фальшь, то сразу поймете, на что следует обратить внимание.

Сложность в том, что существует множество других аспектов, доступных проверке на разумность подходов. Одновременно проверять цели, рабочие графики, технологические решения, моральный климат, позиции конкурентов, бюджет и политику просто невозможно (хотя подобное утверждение для некоторых не вполне адекватных руководителей сдерживающим фактором не является). Подвергать команду ежедневным пыткам, заставляя подтверждать состоятельность десятков случайных предположений, – роковая ошибка. Чем больше вы подталкиваете свою команду к подтверждению предположений, состоятельность которых, в общем-то, не вызывает сомнений, тем меньше вы ей доверяете и тем больше вы тратите ее рабочее время понапрасну. Желание узнать о состоянии проекта нужно удовлетворять, не нанося вреда самому этому состоянию.

Для этого существует три способа: тактические вопросы, стратегические вопросы и прозрачные для команды показатели прогресса. Все, что касается измерений, рассматривается в следующей главе, а здесь давайте сосредоточимся на тактических и стратегических вопросах, касающихся контроля разумности подходов.

Процесс довольно прост: заведите себе краткий перечень вопросов, которые помогут вам бежать впереди паровоза, и задавайте их, совершая своеобразный ритуал. Тактические вопросы задавайте раз в день, стратегические – раз в неделю. Вы можете задавать их самому себе или привлекать к ответам конкретных специалистов своей команды. Следует также поощрять специалистов, у которых имеется опыт и способности к самостоятельному общему анализу ситуации, и сопоставлять их результаты с вашими.

Я делал это так: включал в свой рабочий график еженедельное получасовое совещание с самим собой (кому как не мне распоряжаться собственным временем?). Я запирался в кабинете, настраивался и просматривал свой перечень вопросов. Часто на это уходило всего несколько минут. После этого я мог соответственно скорректировать приоритеты своего рабочего дня или рабочего дня своей команды. Некоторые команды я подталкивал к тому, чтобы подобный опрос стал частью их производственной культуры, а сам проводил лишь сокращенный вариант такого опроса и оглашал ответы в ходе совещаний.

Тактические (ежедневные) вопросы, позволяющие бежать впереди паровоза

 Каковы наши цели и обязательства? Не нуждаются ли они в уточнении? Большая загруженность повседневной работой неизбежно приводит к тому, что вы и ваши сотрудники теряют из виду цели проекта. Простой ежедневный просмотр этих целей восстанавливает целенаправленность и приоритетность действий. Для команды более важным является несовпадение официальных целей с реальными (скажем, по прихоти вице-президента) или командными (когда команда искренне считает, что работает над чем-то совершенно выдающимся), в таком случае цели требуют уточнения. Если цели не уточнены, в команде возникает конфликтная ситуация, последствия которой обязательно проявятся. Не стоит дожидаться явных признаков, если конфликт очевиден, они неминуемо проявятся. Опережайте события, особенно в вопросах, которые непосредственно касаются целей проекта.

 Является ли наша сегодняшняя работа вкладом в стоящие перед нами цели? Посмотрите, чем занимались ваши программисты сегодня, вчера, на этой неделе. Можно ли явно проследить их вклад в достижение целей или в выполнение требований? Если нет, значит, ваш лайнер сбился с курса. Нужно поработать с конкретными программистами (или программистом) и освежить представление каждого из них о целях и о ценности работы, направленной на их достижение. Затем следует уточнить одно из трех: цели, работы или все вместе. Иногда это называется корректировкой направления работ. Аналогично схождению колес на автомобиле вам нужно проводить периодические проверки и убеждаться, что все колеса имеют единое направление.

 Соответствуют ли уже выполненные работы существующим требованиям и сценариям функционирования конечного продукта? Есть тысяча способов завершить какую-нибудь работу, так и не добившись полного соответствия духу и букве проектного замысла. Любой хороший замысел или технические условия должны определять все необходимое для того, чтобы работы соответствовали сценариям реальных действий пользователя. Тем не менее программист, занятый выполнением, скажем, пятнадцати работ, зачастую забывает о тонкостях потребительских качеств, деловых требованиях, интеграции компонентов и визуальных решениях. Если же работать под наблюдением специалиста по дизайну интерфейса (или других специалистов), то специалист ежедневно сможет просматривать контрольные показатели и убеждаться в том, что работы удовлетворяют не только отдельным, но и общим требованиям.

Стратегические (еженедельные или ежемесячные) вопросы, позволяющие бежать впереди паровоза

Стратегические вопросы часто ставятся на совещаниях руководящего состава. Если у вас проводятся еженедельные или ежемесячные обсуждения состояния проекта, вопросы такого рода вполне достойны быть в центре внимания руководства. Но они подойдут и отдельному руководителю проекта, работающему в какой-нибудь узкой сфере.

 Какова текущая вероятность уложиться в сроки к очередной дате (контрольной точке, сроку поставки), обеспечив приемлемый уровень качества? С тех пор как были сделаны расчеты трудозатрат, многое изменилось. Как теперь в процессе самой работы люди ощущают ее объем? Задайте вопрос себе и ключевым представителям своей команды, какова вероятность успешного соблюдения очередного срока. 100 %? 90 %? 50 %? Высокая? Средняя? Низкая? Постарайтесь честно ответить на этот вопрос и попросите об этом же других. Проявите лояльность к команде: не превращайте все в обвинения и упреки, пытаясь доказать несостоятельность их оценок или необходимость более интенсивной работы. Лучше дайте всем понять, что вам нужны честные ответы на вопросы о реальном состоянии дел. (Выяснение причин неуверенности или поиск виновных не устранит факт сомнений. Нужно стремиться познать, в чем суть этих сомнений.)

 Какие коррективы следует внести для повышения этой вероятности? Вряд ли можно добиться от психически нормального и честного человека стопроцентной веры в соблюдение очередного срока. Следом за вопросами о вероятности неизменно должны идти вопросы о том, как добиться ее повышения. Сократить количество совещаний и перерывов? Ускорить выработку решений? Урезать функциональность? Найти лучшие решения? Прояснить цели? Улучшить анализ создаваемого кода? Что еще? Спросите об этом людей, имеющих непосредственное отношение к решению повседневных первоочередных задач. Вмените себе и команде в обязанность активное участие в проработке этих вопросов и поиске ответов на них.

 Как провести более точную и адресную корректировку? Ваше мышление должно быть в первую очередь хирургическим. Что нужно сделать по минимуму для решения проблемы и повышения вероятности успеха? Позвонить по телефону? Послать сообщение по электронной почте? Рассекретить важное решение? Кого-нибудь уволить? Не бойтесь идти на решительные меры, если ничего другого не остается. Если хирургические методы недоступны, нужно мыслить шире. Может быть, стоит скорректировать цели? Изменить контрольные показатели? Какие системные процессы или позиции можно скорректировать для устранения причин и следствий? (См. следующий раздел.)

 Каковы на данный момент (на следующую неделю, месяц) наиболее значимые или вероятные риски? Могут ли они застать нас врасплох? Если вам удастся определить, в чем могут заключаться хотя бы три-четыре наиболее опасные и наиболее вероятные рискованные ситуации, вы уже сделаете большой шаг навстречу их предупреждению; вы сможете настроиться на их отслеживание и станете обращать внимание на любые признаки их наступления. Если тратить на составление перечня возможных рисков и возможных ответных шагов всего 5–10 минут в неделю, это уже будет означать, что вы начинаете бежать впереди паровоза. Этот вид подстраховки зачастую не требует особых затрат: каких-то несколько минут в неделю позволят приобрести довольно мощную защиту от неприятностей.

 Как без моего ведома может измениться ситуация? Держит ли руку на пульсе мой вице-президент или куратор? Не изменились ли его цели? Нет ли чего-нибудь такого, чем озабочены ключевые игроки моей команды, о чем я не знаю и что, окажись они правы, может повлиять на проект? Что такого сделал наш конкурент, на что следовало бы ответить? Выполняется ли мониторинг наших отношений с партнерами и смежниками? Чего не удалось сделать сегодня, что я могу не заметить до завтра? Обычно, чтобы получить ответ на этот вопрос, нужно сделать пару коротких телефонных звонков или походить по коридору. Только не вздумайте при этом заниматься мелочной опекой, впадать в паранойю или нагонять страх на окружающих. Наводите справки от случая к случаю, не создавая лишнего ажиотажа. Более того, поощряйте и вознаграждайте тех людей, кто заранее собирает для вас эту информацию (выполняя свои или чужие обязанности).

Независимо от уровня вашего опыта, подготовленности или интеллекта, настанут дни, когда вы перестанете болтаться позади проекта. Научитесь отличать навалившуюся на вас рутину от бега вслед за уходящим составом – это не одно и то же. Есть вполне реальные шансы на то, что ощущение нехватки времени на выполнение существующего объема работ будет вашим частым спутником. Но если вы подготовили списки приоритетов (см. главу 13), то всегда будете знать, какая работа ожидает своего (то есть вашего) часа. Но если вы не успеваете и плететесь в хвосте проекта, вас неизменно охватит чувство безысходности, подавленности и даже апатии. Вы уверуете в то, что никакая сверхурочная работа не сможет вернуть вам контроль над проектом.

И, напоследок, еще три важных замечания:

1. Вы должны осознать тот факт, что плететесь в хвосте. Следует помнить, что рабочие графики носят вероятностный характер. Какова ваша уверенность в том, что с недельным объемом работы удастся справиться своевременно? 80 %? 50 %? Если шансы на то, что вы справитесь, составляют пятьдесят на пятьдесят (или хуже), значит, вы плететесь в хвосте, у вас слишком мал предел возможных ошибок и вы их обязательно наделаете, если уже не наделали.

2. Если вы видите, что в хвосте плетется кто-то другой, предложите свою помощь. Не стоит делать вид, что проблемы не существует: признайтесь в том, что она для вас очевидна, и попытайтесь оказать помощь. Не позволяйте тем, кто находится в сфере вашего влияния, колебаться или паниковать. Сохраняйте спокойствие, помогайте сохранять его другим и совместно работайте над тем, чтобы снова оказаться впереди.

3. Не стесняйтесь принимать помощь коллег или кураторов. Возможно, сторонняя помощь будет единственным средством снова обогнать паровоз. Пусть вам помогут разобраться с распределением вашего рабочего времени и определить, на что лучше потратить время команды, пусть заберут часть вашей работы или просто послушают, как вы будете «выпускать пар». Примите протянутую руку. Если вам ее не предложили, то попросите людей о помощи.

Чтобы больше узнать о том, как справиться с кризисной ситуацией, обратитесь к главе 11.

Действуйте осмотрительно

В миттельшпиле деятельность теряет свою масштабность, все самое трудное руководитель проекта уже сделал в период планирования или проектирования. Если какое-нибудь требование было упущено и его нужно включить в проект, то процесс его определения и документирования является повторением действий, предпринятых в период подготовки всего набора требований (осознать потребности, рассмотреть все «за» и «против», сформулировать требование и определить его приоритет). А если что-то было упущено в технических условиях, то решение этой проблемы представляет собой двойное или тройное повторение процесса выработки технических условий. В миттельшпиле применяется и ряд новых приемов, которые обычно являются упрощенными и приблизительными версиями уже применявшихся приемов. Проблема в том, что ускоренная работа порождает риск. В миттельшпиле осмотрительность (стремление максимально обезопасить свои действия) означает, что в результате предпринимаемых действий не должна быть случайно нарушена целостность проекта.

Из-за того что в миттельшпиле возникают различные обстоятельства, способные привести проект к краху, безопасность действий дается нелегко. Все находится в движении, многие решения уже приняты и вполне могут вступить в противоречие с любыми новыми действиями. Например, если при строительстве дома вы в самой середине процесса решили изменить план крыши со стандартного треугольного на куполообразный, вам придется пожертвовать затраченными на строительство материалами и усилиями и возможно приступить к новой работе под более высоким давлением. Чтобы научиться вносить изменения в требования, урезать функциональность или модифицировать замысел, оказывая существенное влияние как на ядро уже созданного программного кода, так и на команду разработчиков, требуется немалый опыт.

Осмотрительность должна стать целью любого руководителя проекта. Он должен действовать и вести себя так, чтобы с минимально возможным ущербом удерживать направление проекта в условиях изменяющихся целей. Обойтись вообще без ущерба невозможно, поэтому к нему следует быть готовым. Но чем эффективнее действия руководителя, тем слабее будет негативное воздействие на проект.

На рис. 14.3 показано, что чем дальше продвигается реализация проекта, тем труднее становится действовать осмотрительно. Причина кроется в том, что со временем вероятность удорожания последствий изменений возрастает: повышаются шансы на то, что уже готовые компоненты придется либо модифицировать, либо просто выбросить. Эти затраты неизбежны, но осмотрительность означает, что накануне принятия решения должно сложиться представлением о том, во что оно может вылиться.

Рис. 14.3. Проявить осмотрительность при внесении корректировок тем труднее, чем они масштабнее и(или) чем позже они предпринимаются

При рассмотрении корректировок в период миттельшпиля (при внесении изменений в характеристики, цели или требования) нужно ответить на следующие пять вопросов:

1. Какую проблему мы пытаемся решить? Нужно ли ее решать для успешного продвижения проекта? Нужно ли решать эту проблему именно на данном этапе работы? Нельзя ли мириться с ней и дальше?

2. Что представляет собой эта проблема, чем она является, симптомами или болезнью? Может быть, можно ограничиться устранением симптомов?

3. Достаточно ли имеющегося представления о состоянии программного кода или команды разработчиков, чтобы предсказать, как на них скажется корректировка?

4. Стоят ли затраты на корректировку (включая время на оценку состояния кода и команды, на рассмотрение альтернативных вариантов, на обеспечение политической поддержки решения) получаемой от нее выгоды? Поиск болезни и выработка решений по ее лечению может обойтись значительно дороже, чем мирное сосуществование с болезнью при условии минимизации внешних проявлений ее симптомов.

5. Может ли риск возникновения новых потенциальных проблем свести «на нет» весь выигрыш от вносимых изменений?

Решение о том, стоит ли предпринимать какие-либо действия, принимается в соответствии с той же стратегией принятия решений, которая была рассмотрена в главе 8. Любые действия, касающиеся проектирования, технических условий, общения или политики, требуют применения тактики, рассмотренной соответственно в главах 6, 7, 9 и 16. Подходы и позиции те же, а отпущенное время и право на ошибку значительно меньше. Дефицит времени на обдумывание возможных вариантов вынуждает поступать особым образом. Во-первых, нужно полагаться на данные, полученные ранее при изучении прототипов и конструкторских проработок. Часть рассматриваемых наработок берется именно оттуда, а имеющиеся у команды знания помогают провести анализ текущей обстановки. Во-вторых, нужно проявлять консерватизм. Чем меньше вы знаете, тем больше рисков остаются незамеченными. Чем дальше продвинулся ваш проект, тем выше должна быть планка предпринимаемых действий.

Нарушение обязательств

Неотъемлемым атрибутом осмотрительности является учет обязательств, которые руководитель проекта имеет перед командой. В главе 12 мы уже говорили, что доверие к руководителю со стороны команды определяется его способностью придерживаться своих обязательств. Формами обязательств между руководством, руководителями команд, программистами и заказчиками являются концептуальные документы, требования и календарный план. Любые предпринятые вами в миттельшпиле действия могут нарушить ранее взятые обязательства.

Чтобы сохранить доверие команды при внесения каких-нибудь изменений, вы должны уважительно относиться ко всем предыдущим обязательствам. Вот что по этому поводу говорит Уоттс С. Хэмфри (Watts S. Humphrey): «Если изменяется что-нибудь, влияющее на обязательства обеих сторон, об этом дается предварительное уведомление, и стороны договариваются о новых обязательствах^[83]». Вносить изменения никто не запрещает, но они должны следовать за переговорным процессом, аналогичном тому, в котором создавался первый пакет обязательств (концепция, требования, календарный план). При этом не следует готовить проекты документов или собирать расширенные совещания, но поставить людей в известность об изменении обязательств и привлечь их к процессу принятия решения о характере предстоящих изменений нужно обязательно.

Если вы просите команду выбросить результаты двухнедельного труда, нужно быть уверенным, что цена этого шага учтена в принятом решении. Нужно объяснить команде все причины, по которым вносимые изменения считаются правильными, и раскрыть факторы, подкрепляющие это убеждение. Пригласите, по возможности, кого-нибудь из команды поучаствовать в обсуждении, проводимом перед принятием окончательного решения.

Не бойтесь вносить изменения. Перемены ведут к улучшению, и они неизбежны. Однако существует множество различных вариантов изменений и много различных способов для руководителя по их внедрению в работу команды. Если раньше проект шел на запад, а теперь вдруг понадобилось, чтобы он пошел на север, для поворота команды на север от вас потребуются те же навыки, которые применялись для того, чтобы заставить команду двигаться на запад (хотя придется вдвое увеличить скорость и наполовину избавиться от формализма). Вернитесь к главам 3, 4, 11 и 12 и почитайте изложенные в них инструкции по руководству в условиях перемен.

Производственный конвейер по созданию программного кода

Прагматичный взгляд на миттельшпиль фокусируется на работе программистов, создающих код. Единственный способ поступательного движения связан с тем, что с каждой написанной строкой программного кода проект приближается к своему завершению (бесконечная возня с любимой функцией, ненужная оптимизация и тому подобное прогрессу не способствуют). До того как программисты приступят к созданию кода, либо они сами, либо кто-то другой затрачивает усилия на планирование и проектирование, целиком направленные на подготовку для них эффективной последовательности работ, выполняемых до тех пор, пока тикают часы проекта. Это называется производственным конвейером по созданию программного кода, для управления которым существует масса различных технологий.^[84]

Следить за слаженным функционированием конвейера входит в обязанность руководителя проекта. Программисты и сами могут управлять работой конвейера, решая, кто чем должен заниматься,^[85] но руководитель проекта все равно будет отвечать за то, чтобы команда программистов в процессе выполнения работ получала всю необходимую поддержку. Он может отслеживать ход процесса, проводить совещания, надоедать всем своими требованиями о выполнении принятых решений или в отдельных случаях заниматься устранением оставшихся проблем, касающихся замысла проекта^[86] (рис. 14.4). Руководителю проекта, вероятно, придется действовать, опережая на несколько дней программиста, завершая подготовку замысла и «подпитывая» производственный конвейер. Если руководитель проекта отвечает за нескольких разработчиков, ему понадобится тщательнее распределять свое рабочее время, чтобы успеть справляться с запросами нескольких конвейеров (вот почему ведущий программист должен хотя бы часть этих функций взять на себя).

В книге «Web Project Management: Delivering Successful Commercial Web Sites» (Morgan Kaufmann, 2001) ее автор Эшли Фридлейн (Ashley Friedlein) назвал это краткое совещание с командой и детализацию следующей части предстоящей работы инструктажем. Он писал: «Для достижения максимальной эффективности и скорости разработки ваши инструктажи должны быть построены так, чтобы всегда опережать текущее состояние дел. Как только часть работы будет завершена, у вас должен быть наготове инструктаж, относящийся к следующей части». Эти инструктажи готовятся на основе технических условий (не утративших своей актуальности), но включают в себя все новое или измененное, о чем должны знать программисты. Без активного инструктирования программистов в ходе миттельшпиля может возникать любое количество факторов, препятствующих завершению работ и замедляющих движение конвейера; к этим факторам относятся проблемы потребительских качеств, проработка внешнего дизайна, работы, выполняемые другими программистами, проблемы рыночного характера, технические проблемы или какие-то внешние зависимости. Поскольку руководители проектов зачастую обладают самым разнообразным набором навыков, никто лучше их не справится с запуском конвейера, с частичным или полным решением проблем и со сглаживанием шероховатостей прежде, чем с ними придется иметь дело программистам. (Сюда же относят и выявление несостоятельных программистов, находящихся в состоянии ступора и либо не признающихся в этом, либо еще не разобравшихся в своем состоянии.)

Рис. 14.4. Окончательная детализация технических условий (замысла) может проверяться или завершаться параллельно руководителем проекта или проектировщиком. Это придает смысл понятию производственного конвейера по созданию программного кода

Успех этих дел определяется ответами на следующие четыре вопроса:

 Какие работы находятся в стадии выполнения? Существуют ли проблемы, не позволяющие программистам завершить текущие работы? Если они существуют, их надо устранить (естественно, проблемы, а не работы). Для проекта это авральное состояние. Если программист не может активно создавать программный код, проект останавливается. Нет ничего более важного, чем решение проблемы, застопорившей работу программиста. Задайте ему простой вопрос: «Как я могу помочь тебе решить проблему?» Если вы можете помочь, программисты обязательно поставят вас в известность Если блокирующая работу проблема заключается в какой-то зависимости (например, Фрэд должен завершить работу 6, прежде чем Боб приступит к работе 7), рассмотрите возможность загрузить программиста другой работой, пока проблема не будет снята.

 Обладает ли программист всеми знаниями и понятиями, необходимыми для того, чтобы текущая работа шла в русле технических условий? Всегда есть такие вопросы и пробелы, которые проявляются только в процессе выполнения работы. Способности к самостоятельному устранению таких пробелов у программистов развиты по-разному, у кого-то лучше, у кого-то хуже. Руководитель проекта или проектировщик должен быть способен сам или с чьей-нибудь помощью обнаружить и устранить эти пробелы. Иногда их можно предвидеть, к примеру, если в процессе обсуждения технических условий проблемы, касающиеся данной работы, так и остались нерешенными.

 Какова следующая группа выполняемых работ? Вот тут-то и начинается настоящее управление конвейером: нужно всегда идти на шаг впереди программистов (см. рис. 14.4). Если текущие работы оформлены хорошо, нужно перенести внимание на следующие работы производственного конвейера. Эти следующие работы должны рассматриваться в качестве очередного наиболее важного этапа реализации проекта. Нужно всегда стараться сделать самую ответственную работу в первую очередь, даже если она окажется самой трудной. Для каждой ставящейся на конвейер работы нужно учесть возможность проблем, которые могут замедлить или застопорить работу программиста, когда он к ней приступит. Эти проблемы нужно выявить и разрешить.

 Была ли реально завершена последняя работа? Этот вопрос касается выполненных работ. Кому-то нужно следить за результатами контрольной проверки работы и удостовериться в том, что она отвечает всем ожиданиям заказчика. Действительно ли последняя из выполненных работ наделила продукт требуемыми функциональностью и поведением? Согласна ли с этим команда тестировщиков? Прошли ли все блочные тесты? Занимается ли кто-нибудь элементарным обнаружением ошибок, чтобы отследить все упущения? Ежедневные сборки (которые будут рассмотрены в следующей главе) представляют собой простой способ отслеживания всех этих вопросов, поскольку всегда можно проверить текущее состояние проекта, обнаружить пробелы в законченном продукте и понять, что необходимо доработать. Чем сложнее работа, тем важнее становятся эти обстоятельства.

У одних программистов чувство ответственности за свой конвейер больше, у других – меньше. Многие будут тщательнее выискивать проблемы одного рода (технические) и стараться игнорировать или откладывать до поры до времени проблемы другого рода (относящиеся к бизнесу и политике). Частью ваших взаимоотношений с каждым программистом должно стать понимание, сколько сил вам нужно приложить, чтобы управлять его конвейером. Кем именно это будет сделано, не так уж и важно. Активно проверять качество работ может кто-то другой. (Это относится к назначению ролей, о чем рассказывалось в главе 9.)

Агрессивный и консервативный варианты производственного конвейера

Иногда конвейеру разработки кода нужно опережать команду программистов всего лишь на три работы (если на каждую работу требуется два дня, то на выполнение трех таких работ понадобится больше недели). Чтобы прийти к согласию по поводу следующей логической последовательности работ, вполне может хватить и свободной дискуссии между руководителем проекта и программистами. (Или, если есть главный критический путь или график Гантта, в котором отражены не только прошлые недели, конвейер можно загрузить с его помощью.) Таким образом, создается вполне достаточный по объему буфер, позволяющий программисту и руководителю проекта своевременно подобрать подходящую работу вместо той, которая застопорилась из-за той или иной не решенной своевременно проблемы, и продолжить выполнение, пока проблема не будет решена.

Команда с агрессивной позицией в выборе приоритетов может в большей степени полагаться на конвейер по разработке кода. Вместо проведения сложной структурной декомпозиции всех работ команда делает ставку на внесение изменений и на способности руководителя проекта или ведущего программиста управлять конвейером. При этом возникает весьма рискованная ситуация: если конвейер даст задний ход или не сможет быть выстроен заранее, с опережением хода работ, это приведет к принятию далеко не самых лучших решений и к ненужной потере времени. Подробную информацию о качественном проведении структурной декомпозиции работ (WBS) при планировании проекта вы найдете в книге Стивена Дево (Stephen Devaux) «Total Project Control» (Wiley, 1999) или в любых традиционных информационных источниках, касающихся руководства проектами.

Для команд с более консервативными подходами управление конвейером представляет собой спокойное выполнение работ согласно их первоначальному перечню, созданному в процессе планирования. Конвейер может быть составлен на недели или месяцы с использованием в качестве источника первоначального плана при организации конвейера для каждого программиста. Не исключая возможности небольших поправок, ожидается, что первоначальный план останется жизнеспособным, по крайней мере, до следующей контрольной точки. С началом следующего контролируемого этапа составляется новый перечень работ как часть общего плана, и процесс повторяется. Итак, в зависимости от того, насколько коротким должен быть контролируемый рабочий этап или насколько стабильным должен быть проект, можно выполнять предварительное планирование конвейера.

Однако для конвейера способ организации – не самое главное. Альтернативные способы предлагаются чуть ли не в каждой методологии. Главное, чтобы конвейер эффективно управлялся, все необходимые работы производились должным образом и не тратилось лишнее время на выяснение того, какая работа должна выполняться следующей.

Превращение конвейера по созданию кода в конвейер по исправлению ошибок

На поздних стадиях проекта, когда завершены все работы, производственный конвейер продолжает функционировать. Изменяется характер работ: вместо программ на конвейер ставятся ошибки и дефекты, требующие исправления. В главе 15 мы еще поговорим об этом, когда будем рассматривать установку очередности – процесс принятия решений по обработке ошибок.

Отслеживание хода процесса

Простейшим табло для отслеживания хода миттельшпиля является перечень работ: пока все запланированные работы не будут завершены (с приемлемым уровнем качества), миттельшпиль не закончится (рис. 14.5). Все стратегии миттельшпиля включают определение состояния проекта, поддержание правильного курса в действиях команды и настройку проекта на успешный эндшпиль. Количество завершенных работ – наиболее существенная информация для подобного определения.

Рис. 14.5. Миттельшпиль не закончится до тех пор, пока не будут завершены все запланированные работы. Эндшпиль начнется только после их завершения. Приоритет всего, что не является показателем хода завершения работ, должен быть ниже

Я рекомендую использовать самое простое представление о состоянии проекта, один из вариантов которого показан на рис. 14.5, и выставить его на всеобщее обозрение (в крупных проектах следует показывать также процент завершения работ по разделам). Если у команды есть обычный веб– или wiki-сайт, на нем ежедневно и на видном месте нужно публиковать итоги выполнения работ. Также нужно повесить в центральном проходе большую классную доску и нарисовать на ней точно такую же диаграмму. Все еженедельные подведения итогов или крупные совещания команды должны открываться кратким обзором состояния работ всей команды. Поскольку работы могут завершиться за один-три дня, диаграмма вроде той, что изображена на рис. 14.5, должна отображать ход работ практически на ежедневной основе. Нужно приучить людей регулярно обращаться к диаграмме и отслеживать все самые последние и намечающиеся отметки о выполненных работах.

Разумеется, на диаграмме должны прослеживаться и вторичные данные, относящиеся к состоянию работы, к примеру, количество дней, оставшихся до ее завершения, количество оставшихся рабочих дней каждого задействованного в ее выполнении программиста и т. п. Но они должны отображаться не в ущерб наглядности. В миттельшпиле намного важнее предоставить команде возможность получить общее представление о ходе проекта. У отдельных программистов зачастую имеется представление о собственных локальных областях и о всех областях, с которыми им повседневно приходится соприкасаться.

Существует, конечно, немало того, что следует знать об эффективном отслеживании хода проекта. Более глубоко эта тема рассмотрена в следующей главе, в которой особое внимание уделено ошибкам и дефектам.

Работа в условиях смещения целей

Ни одна из битв не была выиграна в точном соответствии с планом, но не было и ни одной битвы, выигранной без него.

Дуайт Д. Эйзенхауэр

Постоянная смена направлений, в которых движется проект, стала одним из самых сильных аргументов в пользу коротких циклов и других элементов экстремального программирования (Extreme Programming, XP). Использование коротких циклов разработки позволяет проекту реагировать на существенные изменения направлений без потери предыдущих наработок, а все усилия по планированию и проектированию могли быть сосредоточены на вполне осязаемом коротком отрезке времени. Все это, по-моему, имеет глубокий смысл, поскольку дает возможность нацелиться на достижение череды краткосрочных побед. Но есть еще одна истина, о которой следует помнить: долгосрочные планы, даже самые приблизительные, облегчают внесение краткосрочных и среднесрочных изменений.

Смысл в том, что в момент изменения целей, требований или замысла, первоначальный план редко отбрасывается полностью. А все изменения делаются в соответствии с некоторой основной идеей, которой проект соответствовал до этого. Чем тщательнее разработан первоначальный план, пусть даже он носил весьма приблизительный характер, тем больше можно на него ориентироваться и тем быстрее могут быть внесены соответствующие поправки. Из этого следует, что с самого начала лучшей гарантией против непостоянства, связанного с изменениями, послужит вполне реальный план, поправки в который можно будет вносить уже в ходе реализации проекта. Вот что думает по этому поводу генерал-майор Дэн Лэйнер (Dan Laner), командующий израильскими силами обороны:

Я считаю, что сражение никогда не развивается по плану. План является лишь общей базой для внесения изменений. Очень важно, чтобы план был известен всем, тогда в него легче будет вносить изменения… современное сражение слишком изменчиво, и решения нужно принимать очень быстро, далеко не всегда сообразуясь с планом. Но, по крайней мере, все будут знать, каким было исходное состояние, и [тогда] более-менее поймут, к чему вы все ведете.

Особенность использования планов в условиях ожидаемого смещения целей состоит в том, чтобы не допускать слишком долгой работы без обновления плана. Если подобрать подходящие интервалы, смещение целей реально не отражается сразу на всем: просто наблюдается направление их движения с конкретной скоростью за определенное время. Если в проекте намечено несколько контрольных точек, или этапов (см. главу 2), они станут естественными интервалами для внесения поправок (а если на каждом этапе запланировано время на проектирование, то вы сможете вернуться к первому этапу, в который нужно внести поправки). Даже внутри трех– или шестинедельных этапов вы сможете отыскать одну-две промежуточные точки для вычисления новой траектории движения проекта относительно любых возможных изменений целей или требований. Поэтому продолжительность этапов должна соответствовать степени изменчивости проекта: чем чаще меняется его направление, тем короче должен быть этап.

На рис. 14.6 показан простой пример внесения изменений, связанных с корректировкой маршрута в направлении смещающейся цели. Проект стартовал в точке А и закончится, предположительно, в точке Б. Если через две недели после начала проекта (возможно, к завершению короткого этапа) руководители команды решат, что цели для Б изменились, направление проекта тоже должно сместиться, чтобы выровняться по точке Б. Еще через две недели будут внесены новые поправки и произойдет новая коррекция курса. Какая-то часть работ пропадет, но чем раньше будет изменено направление движения, тем меньше окажутся потери. Если перемещения совпадут с концом одного и началом другого этапа, у команды будет время, чтобы заняться проектированием, компенсирующим возникшие изменения, добавить работы, необходимые для модификации сделанного, и внести поправки в продолжительность этапов.

Рис. 14.6. Цели, требования и ограничения могут меняться, но если понятны скорость и направление этих изменений и вслед за ними предприняты соответствующие промежуточные шаги, процесс изменений будет управляемым

Даже если перемещения не совпадут с границами этапов, производственный конвейер по созданию программного кода поможет команде разработчиков придать этим промежуточным коррективам управляемый характер. Поскольку смены курса происходят на выходе из конвейера, опережая ход работ команды программистов, для происходящих изменений имеется некий буфер. Чем больше в конвейере заложено опережение по времени (рис. 14.7), тем больше объем этого буфера. Конечно, если предположить, что существует человек (руководитель проекта или ведущий программист), который уделяет достаточно времени управлению конвейером, то чтобы изменить направление, команде не обязательно полностью останавливаться. Для этого нужно, чтобы в конвейере (в его правой части) был предусмотрен достаточный объем предстоящей работы.

Рис. 14.7. В каждом плане имеется область охвата, определяющая количество допустимых изменений. Чем продуманнее план (и чем лучше в нем предусмотренывозможные изменения), тем больше область охвата

Однако тем самым предполагается, что изменения не будут радикально расходиться с первоначальным планом: в нем предусмотрен лишь вполне определенный диапазон возможных перемещений, то есть область охвата (см. рис. 14.7). Если новые требования или цели противоречат конкретному плану, нужно проводить новые серьезные проектные работы и исследования независимо от опережения, заложенного в конвейер (или, в отдельных случаях, от времени, выделенного на проектирование следующего этапа). Например, если первоначальный план предусматривал изготовление тостера, то в миттельшпиле вполне возможно скорректировать проект на изготовление духовки средних размеров, но никак не ускорителя элементарных частиц или нефтеналивного танкера.

На рис. 14.7 изображена приблизительная модель, отражающая число изменений проекта; в очерченной области представлено предусмотренное планом пространство изменений, которые команда может выдержать без новой серьезной работы. Такая же диаграмма может быть составлена на микроуровне для каждой работы. В зависимости от подходов, примененных программистом, его план будет иметь различные уровни охвата изменений требований или замысла, относящихся к данной работе.

У диаграммы, изображенной на рис. 14.7, есть одна странная, хотя и незначительная особенность. Хронологическая последовательность представлена на ней вертикально, подразумевая, что область охвата со временем может предоставить больше возможностей для передвижений, что в корне неверно. Более точным будет представление, что область охвата изменяется, расширяясь и сужаясь в зависимости от того, в какой стадии проект находится. Обычно эта область сужается по мере близости работы к завершению. Но каждое перемещение вносит коррективы в действующий план, а вместе с ним и в возможности охвата будущих перемещений.

Тайные механизмы управления

Благополучные организации, успешно работающие над проектами, планируют большинство изменений высокого уровня таким образом, чтобы они совпадали по времени с границами этапов (поскольку, опять же, протяженность этапов у них приблизительно соизмеряется со степенью изменчивости проекта или организации). Руководство проявляет терпеливость и зрелость, чтобы дождаться окончания этапа и только после этого заставить команду перестроиться и скорректировать свои действия. Но даже в таких организациях могут быть указания, предписывающие вносить изменения на ходу, без выделения времени на подготовку.

Часто такие коррекции курса вызваны не существующими решениями, а «разборками» в управленческих структурах, требованиями заказчика или результатами конкурентной борьбы. Временами вы сами вправе потребовать изменения направления, а иной раз вы просто должны дождаться чьего-нибудь решения. Так или иначе, у вас всегда должен быть наготове примерный план на тот случай, если потенциальные изменения станут реальностью. Если постоянно быть начеку, то можно заранее, за несколько дней или недель, увидеть предзнаменования грядущих перемен, еще до того как от руководства поступят серьезные решения или конкуренты изменят свой курс в верном направлении. Добыча информации, необходимой для защиты проекта от внезапных атак, зависит от сложившихся взаимоотношений и вашего искусства политика. Тогда можно будет избежать эффекта неожиданности, правда, такое удается далеко не всегда.

Используя имеющуюся информацию, старайтесь периодически выстраивать правильные предположения о возможных изменениях в направлении работ (Поддержка конкретной технологии? Новая характеристика? Новая цель?) и представлять, хотя бы в общих чертах, какие поправки потребуется внести для достижения цели. Эти представления могут быть весьма приблизительными, полученными, к примеру, в ходе разговора с ведущим программистом о том, что такие изменения моли бы повлечь за собой: «Фрэд, что нам нужно будет сделать для поддержки набора API версии 2.0 вдобавок к тем функциям, которые мы уже используем?» Ваша цель заключается не в составлении нового плана битвы, а в получении представления о том, как будет выглядеть дорога, по которой, возможно, придется идти вам и вашей команде. Еще раз просмотрите перечень работ (см. главу 13) и выясните, как в него впишется новая работа, которой, возможно, придется заняться.

Исследование влияния изменений

Если вероятность изменений возрастает, вы можете скорректировать работу в конвейере, чтобы подготовиться к ним наилучшим образом. В шахматной стратегии существуют, по крайней мере, два различных подхода к планированию ходов:

 Консервативный. Ищите такие ходы, которые откроют наибольшее количество последующих ходов и сохранят возможность выбора вариантов.

 Агрессивный. Целиком придерживайтесь одной стратегической линии, не вызывающей у вас сомнений, и навязывайте противнику свою игру.

При работе над проектами (как и при игре в шахматы), когда вы чувствуете превосходство над противником (например, над тайнами руководства или над конкурентами) нужно придерживаться агрессивной политики. Когда вы не чувствуете своего превосходства, лучше придерживаться консервативной политики. Нацеливание команды на консервативные действия может незначительно снизить темп работ, но такова будет цена получаемой страховки. Иногда агрессивная политика вынуждает других людей принимать определенные решения, и если вам любой ценой нужно добиться их быстрого принятия, агрессивное поведение пойдет вам на пользу, даже если ваши политические позиции будут ослаблены.

Но учтите, что рассматриваемые поправки не всегда предполагают выделение дополнительного времени на разработку программного кода. Они могут выражаться в альтернативном алгоритме, таком же надежном, но при каких-то важных обстоятельствах более гибком. Нужно задать программисту или команде простой вопрос: «Послушайте, ребята. Я подозреваю, что наш заказчик (или вице-президент) собирается заставить нас ввести поддержку совсем другой схемы использования базы данных. Просмотрите все, над чем вы работаете, и если есть разумные способы подготовиться к этим изменениям в ходе работы, займитесь их реализацией. Но не вносите ради этого существенных изменений и не жертвуйте качеством. Понятно?»

Иногда это сделать невозможно, поскольку ответ на подобный вопрос может отнять немало времени на исследования. Но бывает и так, что все оказывается намного проще. Например, программист может заранее предвидеть такое развитие событий или иметь разумные взгляды, основанные на его понимании программного кода. Подготовка команды в этом направлении может стоить вам всего лишь простого пятиминутного разговора. Может быть, более важным будет следующее обстоятельство: чем лучше вы понимаете цену возможных изменений, тем весомее будут ваши аргументы, чтобы наложить на них вето (или в подходящем случае выступить в их поддержку).

Потенциальная удаленность изменения

Также следует заметить, что чем ближе проект подходит к достижению первоначального (или последнего актуального) набора целей, тем дальше он оказывается от возможности успешной реализации любых поправок или успешного изменения направления. На рис. 14.8 проект формально движется по направлению к точке Б, хотя ходят упорные слухи об изменении направления (показанного в предстоящем будущем знаком вопроса). Руководитель проекта предполагает, какими будут эти изменения, и вносит соответствующие поправки. Он со своими программистами набрасывает несложный план возможных ответных действий.

Рис. 14.8. Если вы знаете о предстоящих изменениях, но не знаете, когда они наступят, вы можете наметить курс в соответствии со своими предположениями о том, какими они будут

В ходе реализации проекта эти таинственные изменения по-прежнему остаются на уровне слухов. По мере продвижения проекта к точке Б сложность реализации возможных изменений растет. С каждой новой строкой программного кода остается все меньше возможностей для поддержки возможного альтернативного направления. Чем ближе подбирается проект к финальной точке Б, тем отдаленнее становится таинственное изменение (на рис. 14.8 это названо удаленностью изменения) по отношению к оставшемуся расстоянию до точки Б. Чем дольше в процессе продвижения проекта команда ждет изменений, тем больше становятся затраты.

Если изменение происходит, а ваши упреждающие усилия себя не оправдали, то выбора нет: придется заново выстраивать работу команды. Если этим изменениям не сопутствует выделение дополнительного рабочего времени, нужно вернуться к спискам приоритетов и отыскать в них те пункты, от которых можно отказаться, выиграв за счет этого время, которое, на ваш взгляд, необходимо для адаптации (см. главу 11).

Контроль изменений

Некоторые команды активно контролируют и отслеживают любые изменения замысла, в результате которых появляются новые или исчезают имевшиеся работы. Такие команды начинают контролировать ситуацию, как только технические условия проходят формальное обсуждение. Они опасаются, что если изменения будут вноситься в замысел без проведения соответствующих процедур, то может получиться, что какие-нибудь существенные и совершенно неудачные, а может быть даже вредные решения окажутся принятыми без ведома компетентных специалистов. В зависимости от сложившейся культуры и целей вашей команды вы можете вводить, а можете и не вводить практику контроля изменений. Как отмечал Фридлейн (Friedlein): «Метод управления изменениями в проекте зависит от… масштабов и сути проекта. Как правило, чем проект крупнее и сложнее и чем жестче заданы технические условия, тем тверже нужно управлять изменениями^[87]». Если ваша команда не уделяла достаточного внимания процессу выработки технических условий, то она, скорее всего, не станет противиться и изменениям, ей просто нечем будет возразить.

Тем не менее даже для команды, участвующей в ряде формальных процессов, изменения становятся тем чувствительнее, чем ближе проект к завершению. Без организации процесса, направленного на поддержание связей, отслеживание и контроль изменений, беспрепятственно закрыть проект будет очень непросто. Чем опытнее команда, тем раньше она позаботится о контроле изменений. Этот процесс не обязательно должен иметь отношение к периоду эндшпиля: по мере приближения к нему риски, равно как и желание справиться с ними, возрастают.

Простейший путь управления изменениями представляет собой значительно упрощенную версию процесса выработки технических условий. NASA и Microsoft называют его запросом на изменение замысла (Design Change Request, DCR). Другие распространенные названия: запрос на изменение разработки (Engineering Change Request, ECR), заказ на изменение разработки (Engineering Change Order, ECO) или просто запрос на изменение (Change Request, CR).

В упрощенном виде все происходит следующим образом:

1. Кто-нибудь (скажем, руководитель проекта) составляет краткое изложение сути изменения, включая его взаимосвязь с целями или требованиями проекта, обоснование и разъяснение замысла предстоящего изменения. (Поощряется также включение в документ оценки возможных рисков, связанных с воздействием изменения на проект.) Все это редко занимает больше одной-двух страниц. Для сопровождения запроса на изменение замысла, к которому прикладывается этот документ, должен быть назначен ответственный исполнитель (или все это должно быть сделано в рамках существующего метода сопровождения возникающих проблем).

2. Программист, тестировщик или любой другой специалист, на работу которого изменение окажет существенное влияние, должен внести свой вклад в краткое изложение, прилагаемое к запросу, и согласиться с тем, что необходимость изменения обоснована, а его замысел приемлем. Программист предоставляет свои расчеты по разработке, тестировщик – по тестированию (или составляет приблизительный план тестирования).

3. Запрос на изменение замысла выносится на рассмотрение небольшой группы руководителей команд (см. главу 15) или руководителя группы, который дает или не дает «добро» на изменение. Если изменение принимается, то оно рассматривается как дополнительная работа, запрос доводится до команды (а сама работа поручается соответствующему программисту). Рабочие графики и другая проектная документация должны быть обновлены с учетом произведенного изменения. Если изменение отклоняется, то запрос без сожаления выбрасывается в ближайшую урну и навсегда исчезает из проекта.

Последний шаг может быть пропущен, если команда невелика по составу и имеет четкое распределение ролей. Тогда все можно свести к встрече соответствующих людей, обсуждению мнений и принятию решения на внесение изменения. Но если изменение вводит проект в ступор, влияет на работу других программистов или требует выделения дополнительных ресурсов, к решению нужно привлекать руководителей команды.

Изменения всегда обходятся дороже, чем их оценки, проведенные программистами и тестировщиками. Они сопровождаются неожиданными побочными эффектами, воздействующими на остальных специалистов команды разработчиков, и могут отвлечь руководителя проекта от управления конвейером и от других не менее важных дел. Поскольку выработка замысла предстоящего изменения ведется в ускоренном режиме, вероятность ошибок и неудач возрастает. Не редко одно изменение влечет за собой необходимость в других изменениях. Мое обобщенное отношение к изменениям выражается в следующем: лучше использовать короткие этапы разработки с хорошо продуманным замыслом и возможностью некоторых изменений, чем запланировать рабочий график, в котором ожидается множество изменений. Чтобы не сталкиваться с запросами на изменение, люди в команде должны быть всецело настроены на разрешение всех связанных с замыслом проекта проблем уже на самой ранней стадии.

Выводы

• Миттельшпиль и эндшпиль соответствуют середине и завершению проекта.

• Если однажды работа над проектом не заладится, то определение причин случившегося и их устранение всецело ложится на вас. Повторяйте эту мысль на всем протяжении миттельшпиля.

• Проект представляет собой сложную нелинейную систему и обладает значительной инерционностью. Если выжидать обострения проблем перед тем, как предпринять какие-то меры, можно опоздать и тем самым значительно ухудшить ситуацию.

• Когда проект выходит из-под контроля, это означает, что вы начинаете бежать позади своего паровоза, что крайне нежелательно. Контроль здравомыслия – простейший способ оставаться впереди. Существуют как тактические, так и стратегические вопросы, помогающие контролировать логику действий.

• Подумайте, что можно сделать для выправления ситуации наиболее безопасным образом. Чем масштабнее эти действия и чем ближе проект к своему завершению, тем они опаснее.

• Производственный конвейер по разработке программного кода представляет собой механизм управления работами в ходе реализации проекта. Существуют агрессивные и консервативные методы управления конвейером.

• Планирование отдельных этапов и применение конвейера по разработке программного кода предоставляют возможности для безопасной коррекции курса проекта.

• Механизм контроля изменений (с использованием запросов на изменение замысла) позволяет регулировать внесение в проект изменений среднего и низкого уровня.

Упражнения

1. Если проект находится в миттельшпиле, отберите случайным образом пять человек из вашей команды и попросите их выразить в процентах, насколько они уверены в выдерживании календарного плана. Сделайте то же самое с пятью менеджерами. Сравните результаты и доведите их на совещании команды. Если такая практика окажется полезной, повторяйте этот процесс еженедельно. Чтобы добиться искренности ответов, сохраняйте анонимность всех отобранных вами людей.

2. Руководители проектов часто вынуждены бежать позади своего паровоза, поскольку не в состоянии контролировать график работ, бюджет или иные факторы, выводящие проект из-под контроля. Какие подконтрольные факторы могут помочь вернуться на авангардные позиции? Что можно сделать, чтобы проинформировать босса и команду о тех факторах, которые оказывают на вас влияние, но вышли из-под вашего контроля?

3. Когда в последний раз вы признавались, что впадали в отчаяние? Составьте список, за что вы больше всего переживаете в текущем проекте. Выберите свое самое большое опасение и поговорите с кем-нибудь о нем. Даже если вы поговорите об этом с другом за пивом, это поможет вам справиться с ситуацией.

4. Какие следующие три пункта той работы, которой вы занимаетесь, готовы для передачи кому-нибудь другому или наоборот, готовы для того, чтобы забрать их у кого-то? Что можно сделать именно с этими тремя пунктами на передачу, чтобы повысить их шансы на успешную реализацию?

5. Создайте визуальное представление вашего командного конвейера разработки программного кода по состоянию на сегодняшний день. Можно просто подойти к доске и на одной оси составить список всех программистов, а на другой проставить временные отметки. Перечислите следующие три работы, которыми, по утверждению программистов, они заняты, чтобы каждая из них заняла столько места, сколько она должна занять согласно рабочему графику. Как такая визуализация изменит ваши размышления об управлении проектом?

6. Если вас настораживают тайные механизмы управления, как можно обеспечить получение сведений о возможных изменениях на самой ранней стадии? Кого вы можете сделать своим разведчиком?

7. Многие не любят, когда следят за продвижением их работы. Какие стимулы можно предусмотреть для людей, чтобы они сами отслеживали состояние собственной работы? Почему спортсменам нравится вести статистику своих достижений, а людям, занятым в производстве, это не нравится?

8. Когда вы начинаете настаивать на официальном изменении технических требований, команда игнорирует ваши запросы и продолжает работать во вчерашнем режиме. Какой должна быть ваша реакция? Каков лучший способ перевода команды на новый режим работы?

Глава 15. Стратегия эндшпиля

В продолжение темы предыдущей главы, посвященной стратегии миттельшпиля, в данной главе я сделаю основной акцент на соблюдении сроков и на инструментарии, необходимом для своевременного доведения проектов до финишной черты.

Не забывайте, что у всех проектов, как правило, более одного крайнего срока. У каждого проекта есть промежутки времени, ведущие к концу какого-нибудь этапа или к завершению всего проекта. При этом возникает скрытая опасность, что команду станут усиленно подгонять, чтобы уложиться в срок, хотя она и так прилагает к этому запредельные усилия, понимая, что следующий срок тоже не за горами. Если команда полностью выложится и подойдет к началу следующего этапа в состоянии усталости, депрессии и стресса, то вероятность соблюдения очередного срока резко снизится. Винс Ломбарди (Vince Lombardi) однажды сказал, что накопленная усталость делает всех нас трусливыми. Когда мы измотаны, вернуть нас в работоспособное состояние не сможет никакое количество выпитого крепкого кофе. Как говорит Генри Кайзер (Henry Kaiser), то, как сыграна нота, столь же важно, как и то, какая это нота.

Если команда похожа на загнанную лошадь, то на восстановление интенсивности ее работы до расчетного уровня могут пройти дни или даже недели (рис. 15.1). Хуже того, чем чаще команде устраивают подобные гонки, тем меньше она на них реагирует. Существует некий предел, преодолев который команда перегорает, теряя способность к восстановлению сил в приемлемые сроки.

Рис. 15.1. Ценой аврала, затеянного, чтобы соблюсти один срок, является снижение вероятности соблюдения следующего. Чрезмерные усилия по своевременному выполнению этапа 1 ведут к задержке начала этапа 2

При реализации проекта продуктивность команды лучше рассматривать как ресурс с нулевой суммой:^[88] если для соблюдения назначенного срока нужно прикладывать чрезмерные усилия, значит, вы крадете силы, которые вам потребуются в начальной стадии следующего этапа. (Однако если в команде существует специализация ролей, негативные последствия можно снизить за счет перераспределения обязанностей. Чаще всего в процессе работы над проектом у проектировщиков, плановиков, руководителей проекта, тестировщиков и программистов аврал случается в разное время. При правильном распределении работы аврал не может быть сразу у всей команды, поскольку ролевая нагрузка в разное время разная.)

Хуже того, за всем этим следует неравнозначная расплата, поскольку соотношение времени на восстановление сил и на работу в условиях аврала не равно 1:1. На восстановление уйдет намного больше времени, чем на сам аврал (к примеру, если на то, чтобы догнать уходящий поезд, нужно секунд 20, то на то, чтобы отдышаться после этого, может потребоваться несколько минут). Иногда в жертву приносится личная или семейная жизнь, а это уже никак не вяжется с постоянными интересами людей, команды или организации (см. рис. 15.1).

Из этого следует, что хорошее руководство должно обходиться без авралов. Конечно, в серьезных проектах острых углов не избежать, но руководство должно быть заинтересовано в том, чтобы иметь над ними полный контроль, работать преимущественно над тем, чтобы свести их количество к минимуму, и давать реальную оценку их последствиям (не стоит, к примеру, в течение двух недель после начала следующего этапа осыпать команду упреками за вялость и пассивность). Чем продолжительнее работа над проектом, тем больше сил команда теряет на подобные пики активности и тем труднее становится организовать нормальную работу в эндшпиле многоэтапного проекта.

Долгие сроки – это просто сумма нескольких коротких

Чтобы обсудить важные аспекты стратегий миттельшпиля и эндшпиля, мы должны определить в проекте несколько промежуточных сроков. Наиболее важная тройка таких сроков, фигурирующая в простом унифицированном графике работ, относится к переходам между элементами правила трех частей, рассмотренного в главе 2 (рис. 15.2). Каждый переход означает смену области приложения сил команды и должен иметь для этого собственные критерии прохождения.

Рис. 15.2. Внутри этапов имеются ключевые даты, которые нужно отследить, наметить и наделить критериями выхода

Эти критерии представляют собой перечень всего, что предполагается выполнить к концу этапа. В них описывается то состояние проекта, которое он должен приобрести, чтобы этап считался завершенным. Чем раньше определены критерии выхода этапа, тем выше будут шансы на его своевременное завершение.

В каждом этапе есть три основных перехода:

 Завершение проектирования (завершение подготовки технических условий). Команда готова к созданию программного кода изделия. Сделано все необходимое для начала реализации проекта: выработаны технические условия, созданы прототипы, составлено краткое изложение замысла. (При этом совсем не обязательно иметь окончательно выработанные технические условия, достаточно иметь в готовности лишь тот объем, который считается необходимым для начала работы, скажем, 20 или 90 %.) Работы по проектированию могут продолжаться (см. раздел «Конвейер по созданию программного кода» главы 14), что-то может переделываться и пересматриваться, но основы в необходимом объеме должны быть заложены.

 Завершение реализации заданных характеристик. Команда готова приступить к оптимизации и проверке качества кода. Это означает, что вся функциональность, предусмотренная индивидуальными работами, реализована, выполнено все необходимое, чтобы поведение продукта и его внешний вид отвечали техническим требованиям. Могут оставаться какие-нибудь качественные пробелы или проблемы, но при условии, что руководство их отследило и оценило (ошибки выявлены), основную созидательную работу можно читать завершенной. Все контрольные и качественные показатели, являющиеся частью технических условий, должны быть в пределах допустимых. К этому времени все остающиеся нерешенными проблемы должны быть переведены в разряд ошибок, а база данных, содержащая перечень ошибок, – стать основным (если не единственным) средством отслеживания хода всей оставшейся работы.

 Завершение тестирования или этапа в целом. Этап завешен. Качество и оптимизация достигли приемлемого уровня. Начинается работа по плану следующего этапа и (или) поставки программного продукта. Поскольку это последняя фаза этапа, ее иногда называют завершением этапа. Если данный этап бы единственным или последним, то завершается весь проект.

Если не принимать во внимание качество подготовки технических условий, качество оценки работ и способности самой команды, то для соблюдения намеченных сроков будет действовать следующее простое правило: чем точнее определены критерии выхода, тем больше шансов на своевременное завершение.^[89] Предполагается, что команда продолжает работать до тех пор, пока критерии выхода не будут соблюдены. Набор критериев выхода должен быть у любой мало-мальски значимой контрольной даты рабочего графика.

Определение набора критериев выхода

Критерии выхода не должны быть слишком сложными (хотя и могут быть таковыми). Тем не менее в наборе критериев выхода должны содержаться следующие элементы:

• Перечень завершаемых работ.

• Показатели качества, с которым должны быть завершены эти работы (взятые, возможно, из параметров тестовых испытаний, планов тестирования^[90] и технических условий).

• Перечень необязательных дел, о которых у некоторых сотрудников сложилось мнение, что их обязательно нужно сделать.

• Перечень всего, что не нужно делать, даже если у кого-то сложилось иное мнение (проверка на здравый смысл).

Определять набор критериев выхода, доводить их до всей команды и отслеживать соблюдение можно различными способами. Детали здесь не имеют особого значения (предложите набор критериев команде, соберите отзывы, затем завершите его разработку и доведите результаты до всей команды). Важно, чтобы этот набор был определен как можно раньше, легко воспринимался и использовался открыто для отслеживания хода процесса и реализации принятых решений. Критерии выхода должны соответствовать концептуальному документу и целям проекта, стать наиболее удобными инструментами применения концепции и целей в разрешении всех вопросов и сложностей, возникающих в середине и на завершающей стадии любого этапа.

Обычно критерии выхода означают, что сделано следующее:

 Составлены списки технических условий, проектных решений, работ. Как правило, эти списки полезны только как критерии завершения проектирования. Этапы проектирования должны иметь соответствующие критерии выхода независимо от того, какие инструменты или процессы применялись для их выполнения. Возможно, условием выхода из этой стадии станет принятие 90 % общего объема технических условий или создание прототипа с определенной функциональностью.

 Выполнены текущие работы. Имеется в виду перечень работ, определенный в начале этапа или фазы проекта. Как только работы будут выполнены в соответствии с требованиями технических условий, этап (фаза) завершится.

 Подсчитаны все ошибки по уровням их значимости. Ранее уже шла речь о том, что для выявления и оценки значимости ошибок (дефектов) применяется множество различных способов. Обычно критерии выхода включают создание детального описания обнаруженных ошибок конкретного типа.

 Пройден определенный набор тестов. Определение факта завершения этапа может быть обусловлено прохождением некоторых тестов. Если результаты тестирования используются в качестве критерия, на их основе принимаются решения о том, какие ошибки или дефекты подлежат устранению до завершения этапа. Возможно, будет вполне достаточно использовать критерии выхода на основе определенного порога прохождения тестовых испытаний, к примеру: «должны быть пройдены 80 % тестовых испытаний по сценариям, относящимся к приоритетам первой очереди».

 Достигнуты определенные показатели производительности или надежности. Если команда производит замеры производительности определенных компонентов (скажем, базы данных или поисковой машины), то критерии выхода должны быть основаны на ее показателях. Если критерии выхода заключаются в увеличении скорости на 10 % по сравнению с показателями предыдущей версии, значит, этап не может считаться завершенным до тех пор, пока не будет достигнуто 10-процентное увеличение.

 Потрачено определенное время или деньги. Время является самым простым в мире критерием выхода. Этап завершается по прошествии определенного времени. И все. Лучше всего измерять этап месяцами, тогда не будет никаких сомнений насчет времени его начала, времени окончания и продолжительности. (Ведь меряют же люди остаток своей жизни месяцами и неделями, так почему же не построить на той же основе график разработки проекта?) Все наполовину или частично реализованные характеристики отбрасываются, чтобы учитываться уже на следующем этапе (если он предусмотрен). Деньги также могут стать критерием выхода: когда бюджет исчерпан, энергия иссякает, и работа останавливается.

В отсутствие критериев выхода команда должна придерживаться субъективных мнений относительно того, что для проекта является «вполне достаточным», а что считать бесполезной тратой времени. У каждого на этот счет может быть собственное мнение. Даже если решение принимается единолично, оно все равно будет считаться спорным, пока не созданы некие письменные нормативы. Отсутствие критериев скажется впоследствии вынужденными нелегкими дебатами, в которые команды позже будут втянуты, как только возрастут риски и опасения за судьбу проекта. Не ставьте команду в такие условия, при которых она должна в конце этапа тратить свою энергию на споры вокруг критериев выхода, а лучше спланируйте все так, чтобы она в конце этапа тратила всю свою энергию на реальное достижение этих критериев.

Запомните, что цель заключается не только в том, чтобы уложиться в указанный срок, но и в том, чтобы подвести проект к определенной дате в определенном состоянии. Чем скорее команда поймет, в чем заключается это состояние, тем выше будут шансы на успех. Если критерии известны на ранней стадии, они отражаются на всех решениях, принимаемых в ходе выполнения этапа. Даже если в процессе работы критерии претерпят какие-то изменения, команда будет перестраивать свою работу в едином направлении, дружно подводя проект к легкому эндшпилю.

К примеру, перечень критериев выхода для какого-нибудь этапа реализации проекта по созданию небольшого веб-сайта может быть следующим:

• Выполнить в соответствии с заданными техническими условиями все работы с первой по десятую.

• Достичь 80-процентных показателей потребительских качеств, относящихся к приоритетам первой очереди.

• Пройти все тесты первой очереди в автоматическом и ручном режимах.

• Пройти 80 % тестов второй очереди в автоматическом режиме.

• Классифицировать все найденные ошибки.

• Исправить все ошибки, относящиеся к приоритетам первой и второй очереди.

• Получить разрешение на завершение этапа от команды по маркетингу и развитию бизнеса.

Почему соблюдение сроков напоминает посадку самолета

Цель промежуточных этапов не только в том, чтобы выдержать определенный срок, но и в том, чтобы настроить команду на следующий этап (или на выпуск следующего варианта). Соблюдение сроков – это не только вопрос хронологии: риск, которому подвергается надежность программного кода и выполнение следующего этапа (если таковой имеется), зависит от плавности движения к контрольной дате.

Представьте себе посадку самолета. Удачное приземление облегчает повторный взлет самолета: крылья на месте, шасси исправно, экипаж жив. Все, что нужно – это дозаправка, план полета и сэндвич для пилота. Завершение этапа должно рассматриваться в этом же ключе. Чем круче закладывается вираж для завершения этапа, тем вероятнее, что по его окончании проект окажется не в самом лучшем состоянии.

Угол снижения

Типовые графики разработки проектов могут быть сведены к простой диаграмме, наподобие показанной на рис. 15.3. Диаграмма составлена с предположением, что показатель прогресса проекта является постоянной величиной, а проект завершится точно по графику при соблюдении постоянного темпа работы. Разумеется, все это из области фантастики. Эта диаграмма никогда не станет отражением реальных событий, поскольку темпы работы команды и ее продуктивность никогда не будут постоянными величинами (по многим рассмотренным ранее причинам).

Рис. 15.3. Характерный пример графика выполнения этапа с неправдоподобными допущениями

Скорее всего, большинство проектов могут оказаться в ситуации, воспроизведенной на рис. 15.4. В какой-то точке пути по направлению к конечной дате команда поймет, что работа идет не так быстро, как ожидалось. Такое может случиться из-за того, что команде поставили дополнительную задачу (см. раздел «Контроль изменений» в главе 14) или не оправдались сделанные ею оценки. Неважно, по какой причине это произошло, но теперь команда оказалась перед выбором: как преодолеть расстояние, оставшееся до конечной даты? Есть только три варианта:

1. Сдвинуть график. Отодвинуть чуть дальше конечную дату в соответствии с новым пониманием угла наклона линии, отражающей ход выполнения проекта.

2. Изменить угол наклона. Поверить в то, что команду каким-то образом удастся заставить работать быстрее и производительнее, чтобы своевременно компенсировать возникшее отставание (например, приготовиться к аварийной посадке). Можете, конечно, попробовать этот вариант, но чем-то все равно придется пожертвовать. Например, возросшим риском наделать ошибок, вялостью и усталостью команды к началу следующего этапа.

3. Подойти к окончанию этапа, ничего не меняя. Определите те характеристики или работы, на которые придется потратить больше усилий или которые являются более рискованными. Затем либо прекратите ими заниматься, отложив до следующего этапа (если он предвидится), либо снизьте к ним качественные требования и оставьте все как есть.

Рис. 15.4. Реализация графика зачастую расходится с планом. Как с этим справиться – целиком зависит от критериев выхода

На чем остановить свой выбор – полностью зависит от критериев выхода. Это именно та ситуация, в которой наибольший выигрыш складывается из четкого понимания того, что именно подразумевается под окончанием этапа. Вместо того чтобы изобретать критерии на ходу, в состоянии стресса, вызванного трудной посадкой, лучше просто оглянуться назад и внести поправки в критерии, определенные несколькими неделями ранее. Принятие решения в сложной ситуации эндшпиля значительно облегчится, если есть уже знакомые команде критерии, на которые всегда можно сослаться.

Почему не срабатывает изменение угла снижения

Если опять обратиться к аналогии с самолетом, то изменение угла снижения, чтобы попасть на полосу, делает заход на посадку нестабильным. Проекты во многом подобны самолетам – при увеличении скорости снижения (завершения) становятся плохо управляемыми. Чтобы стабилизировать скорость снижения, нужно одновременно проделывать слишком много манипуляций. Если пилот, сидя за штурвалом приземляющегося самолета, видит, что самолет сносит мимо полосы, он заходит на посадку заново (переместить посадочную полосу, в отличие о графика, невозможно). В сложных погодных условиях пассажирские самолеты часто заходят на второй круг. В проектах же такая возможность предоставляется крайне редко. Они подобны самолетам, у которых топливо на исходе: ресурсов хватает только на одну попытку. Имея в запасе единственную попытку, здравомыслящие пилоты будут снижаться очень осторожно и по хорошо продуманному плану. Благоразумные руководители проекта обязательно последуют их примеру. Если дата или набор характеристик должны быть неизменными (как посадочная полоса), вы должны начать готовиться к посадке как можно раньше.

Почему все становится хуже

При расстановке приоритетов в работе действует основной психологический принцип. При прочих равных условиях люди склонны уклоняться от того, что им не хочется делать.^[91] А значит, в процессе выполнения графика все оставшиеся работы и неисправленные ошибки становятся неприятной обузой текущего этапа. Пусть даже недоделаны какие-то пустяки, если команда поощряется за определенное количество исправленных за день или за неделю ошибок, у нее появляется естественное стремление выбирать ошибки попроще, чтобы выполнить квоту.

К концу этапа люди становятся усталыми, унылыми и раздражительными, что отрицательно сказывается на производительности труда. Сложные ошибки имеют особенность появляться максимально близко к концу этапа. Программист смотрит на одну из таких ошибок, понимает, что она не из легких, и под гнетом других навалившихся на него забот сваливает ее на кого-нибудь другого, кого можно назначить ответственным за ее устранение. Как писал Вейнберг (Weinberg): «… проблемы не решаются, а просто переходят их рук в руки». Этому естественному искушению поддаются время от времени даже самые лучшие программисты.

Элементарная склонность к затягиванию сложной работы проявляется и в обнаружении ошибок, хотя причины этого кроются уже не в психологии. Дефекты, которые выявляются дольше всех или проявляются под конец этапа, обычно (как и следовало ожидать) оказываются самыми непростыми^[92] (рис. 15.5). Если тенденция касается сложных, но низкоприоритетных ошибок, ей не стоит придавать особого значения, но если речь идет о высокоприоритетных ошибках, то такая тенденция становится серьезной проблемой. Подобные ошибки не только выявляются дольше среднестатистических, но и исправляются намного дольше. Обе прямые линии проектного пути, показанные на рис. 15.4, нельзя считать правильными: на самом деле линия приближения проекта к контрольной дате является близкой к асимптоте (кривой) и выглядит примерно так, как на рис. 15.6. Команда может работать с прежней интенсивностью, но результативность – в смысле приближения к целям – падает. Чем ближе контрольная дата, тем справедливее это утверждение.

Рис. 15.5. Самые сложные ошибки почему-то обнаруживаются и устраняются ближе к концу этапа. А это значит, что подход к конечной дате не выглядит прямолинейным – скорее это кривая линия на шкале прогресса (см. рис. 15.6)

Рис. 15.6. Обобщенная, но реалистичная диаграмма угла сближения, в которой предполагается, что работа идет с равномерным напряжением сил

Примерное руководство по достижению нужного угла сближения

Угол сближения этапа или всего проекта с точкой завершения работы не является какой-то тайной за семью печатями. Как и в любой связанной с планированием задачей (см. главу 2), есть определенные размышления о том, как повысить точность предсказания угла.

 Обратите внимание на предыдущие показатели производительности команды и на направленность проекта. Чтобы спланировать, каким должен быть этот угол, проанализируйте, как команда справилась с эндшпилем предыдущего проекта сходной направленности. В проектах, выстроенных из множества этапов, посмотрите на кривые предыдущего этапа, сравните запланированную кривую с реальной (здесь не стоит лукавить: нужно взять первоначальный план и самую последнюю версию рабочего графика). Следует исходить из того, что планируемый этап может оказаться сложнее предыдущего независимо от того, что вы о нем думаете. Если у вас нет данных, на основе которых можно определить угол, почему бы не пофантазировать на этот счет? Если остается лишь догадываться, нужно исходить из консервативных взглядов.

 Займитесь оценками. Определение угла – всего лишь разновидность задачи по оценке рабочего графика. Соберите нужных людей, разбейте оставшийся объем работы по задачам, обсудите все риски и предположения и перейдите к оценкам. По крайней мере, это позволит общими усилиями найти подходы к завершению этапа; люди, к тому же, почувствуют свою причастность к процессу совместного определения угла. Тогда общий настрой будет работать в поддержку этого процесса, а не против него.

 Планируйте получить постепенно искривляющуюся, а не прямую линию. Даже при отсутствии исходных данных нужно планировать замедление темпов прогресса, принимая во внимание снижение производительности, вызванное появлением ошибок (см. рис. 15.6). Исходите из предположения, что работа по мере приближения к концу этапа будет усложняться. Вычерчивайте графики и диаграммы, используя кривые, а не прямые линии.

 Не пейте Kool-Aid. Вычертить диаграмму совсем не трудно. Вы можете начертить линию где угодно, не сообразуясь с реальным положением вещей, и вполне вероятно, что вам даже удастся убедить других в том, что в форме линий, которые вы нарисовали, присутствует некая логика. Поставьте себя на место пилота нашего самолета: смогли бы вы полететь под этим углом, исходя из имеющихся у вас сведений? Подымите красный флаг; признайтесь в ошибках. Защитите свою команду от крушения при посадке. Если ваш подход излишне консервативен, то самое страшное, что может случиться, – это преждевременное завершение этапа, в то же время при слишком агрессивном подходе может произойти масса неприятностей.

 Создайте свой черный ящик. Если не остается ничего другого, то обеспечьте хотя бы регистрацию объективных данных о производительности труда (см. следующий раздел). Тогда после аварийной посадки у вас хотя бы останутся свидетельства о том, что пошло не так, как надо, и вы сможете оперировать крепкими доводами при согласовании работ над следующим проектом или этапом.

Измерительные инструменты

В периоды миттельшпиля и эндшпиля отслеживание хода работы приобретает особую важность. Чем многочисленнее команда, тем труднее добиться внятной информации о состоянии проекта. Для того чтобы вносить поправки в курс (см. главу 14), необходимо иметь достаточно ясное представление о состоянии проекта, чтобы не только диагностировать те или иные тревожные симптомы, но и прогнозировать реакцию проекта на вносимые изменения.

Независимо от того, какой системе показателей будет отдано предпочтение, процесс должен быть наглядным для всей команды. В главе 14 я говорил о том, что работы являются наиболее важными инструментами для отслеживания прогресса в стадии миттельшпиля. Теперь мы углубимся в иные показатели, подходящие и для миттельшпиля, но особенно удобные для отслеживания прогресса в эндшпиле.

Для эндшпиля можно еще раз воспользоваться любыми ранее использовавшимися показателями, служащими для отражения результатов выполнения проекта; нужно только убедиться, что важные показатели не теряются среди другой информации (опустите те показатели, которые уже утратили свою значимость, например работы). Соответствующее табло нужно вывесить в общем коридоре, а в его роли может выступить простая классная доска с периодически обновляемой информацией или какое-нибудь необычное приспособление наподобие полноэкранного терминала, на который по сети выводятся самые свежие данные (полезно расположить его возле туалета, курилки или другого часто посещаемого места).

Ежедневная сборка

Ежедневная сборка проекта вынуждает разбираться с множеством различных проблемных вопросов в реальном времени, не откладывая их на будущее. Любой может просмотреть текущую сборку и сразу же определить, насколько продвинулся проект. При этом снижается зависимость от людей, работающих над отчетами о состоянии проекта или другой какой-нибудь канцелярщиной. Взамен всегда можно составить примерное представление, загрузив текущую сборку и проверив конкретную функцию или характеристику. Как бы дорого не обходилась ежедневная сборка (и необходимый для этого инструментарий^[93]), ею все же стоит заниматься.

Ежедневные сборки позволяют программистам (да и всей команде) сразу же находить те компоненты, работа которых отрицательно сказывается на других компонентах, что помогает сохранить высокий качественный уровень сборки. Назначьте конкретное время для ежедневной сборки проекта, настроив людей на подготовку стабильной кодовой основы, позволяющей запускать тесты по проверке качества сборки. (Такие тесты часто называют «проверками на отсутствие дыма» по аналогии с тестами электронных компонентов, при которых монтажные платы подключаются к напряжению, а окружающие внимательно смотрят, не пойдет ли из плат дым.) После назначенного часа все проверки, касающиеся ключевых ветвей кода, просто переносятся на следующую сборку.

Каждой сборке нужен набор тестов для определения ее качества. Все, что вам нужно, – это три градации качества: хорошее (все тесты пройдены), среднее (пройдено несколько тестов) и плохое (пройдены лишь некоторые тесты или не пройдено ни одного теста). Любая отдельная ошибка, ставшая причиной провала любого теста, должна получить высокий приоритет и быть зарегистрирована вместе с информацией о сборке.

Подобные тесты на качество, известные также как проверочные тесты сборки (Build-Verification Tests, BVT), должны быть включены в набор критериев завершения этапа. На ранних стадиях этапа эти критерии могут быть более мягкими, чем критерии выхода; например, вполне приемлемым может быть получение всего лишь одной «хорошей» сборки в неделю. Однако по мере приближения команды к завершению работы над какой-нибудь функцией или характеристикой критерии должны становиться все более жесткими. Ежедневные сборки и тесты на качество всегда позволят вам иметь и показатели качества, и инструменты управления его уровнем.

Устранение ошибок и дефектов

При завершении реализации той или иной характеристики любые оставшиеся работы, которые должны быть выполнены до окончательной готовности этой характеристики, заносятся в базу данных ошибок. Это должно обеспечить проекту единую систему контроля и показателей. Система отслеживания ошибок должна быть простой, единой и использоваться всеми без исключения. Если некоторые программисты предпочитают собственные системы отслеживания своей работы и все они отличаются друг от друга, то отразить какие-либо контрольные показатели хода проекта будет невозможно. Зачастую когда команда завершает реализацию характеристики, кто-то начинает всем надоедать, требуя, чтобы показатели, отслеженные кем-то самостоятельно, были сведены в единую систему.

Возьмите себе в привычку задавать в подобной ситуации следующий вопрос: «Какой номер присвоен данной ошибке?» Если услышите в ответ, что пока никакой, прервите разговор до тех пор, пока ошибка не получит свой номер. Возможно, кому-то это покажется самодурством, но в данном случае такой шаг продиктован интересами проекта. С данной точки зрения те две минуты, которые потребуются для присвоения ошибке собственного номера, будут потрачены не зря. Если самостоятельное отслеживание процесса не влияет на сборку или на основу программного кода, в нем нет ничего плохого; просто не нужно, чтобы система мониторинга ошибок захламлялась чем-нибудь из разряда личных памяток или тривиальных списков предстоящих дел. (Или, если вы такое позволяете, нужно убедиться, что подобные вольности относятся к особому типу ошибки и могут быть отфильтрованы в отчетах и запросах.)

Чтобы на них можно было ссылаться, все ошибки должны сопровождаться определенными сведениями. Если у вас есть собственная система, которой вы вполне довольны, можете пропустить этот раздел. В системе мониторинга ошибок можно указывать самые разнообразные сведения, но исходя из собственного опыта я считаю, что для эффективной работы над ошибками необходимы следующие ключевые атрибуты:

 Приоритетность. Все должно быть проще простого. Приоритет 1 – ошибка должна быть устранена; приоритет 2 – ошибка по возможности должна быть устранена; приоритет 3 – устранение ошибка желательно, но не обязательно; приоритет 4 – ошибка вряд ли будет устранена.

 Серьезность. Насколько серьезно влияние данной ошибки? Серьезность 1 – потеря данных, крах системы, проблемы безопасности; серьезность 2 – основная функция не работает так, как ожидалось (предписывалось); серьезность 3 – неосновная функция не работает так, как ожидалось (предписывалось). Серьезность отличается от приоритетности. Например, может быть серьезная ошибка сценария, приводящая к отказу в работе браузера (серьезность 1), но поскольку она проявляется лишь при семикратном наборе слова «PAPAYA!» одними заглавными буквами в поле ввода электронного адреса на странице регистрации, у нее низкий приоритет (серьезность 1, но приоритет 4).

 Данные о том, кто исправит ошибку. Работа над всеми ошибками должна быть поручена конкретным людям. Распределение новых ошибок может быть отложено, но одной из задач классификации ошибок (которую мы вкратце уже рассматривали) является как можно быстрее назначить конкретных ответственных за их устранение. Чтобы показать, что ошибка может проявляться в альфа– и бета-версиях, создайте для нее атрибут под названием «действующая» или «отложенная». Ошибки с таким атрибутом позже должны быть классифицированы и их устранение поручено конкретным людям.

 Воспроизведение. Это последовательность действий, позволяющая кому-то вызвать проявление ошибки. В классификации ошибок это, пожалуй, самая важная графа. Сложные случаи воспроизведения отнимают у команды время, заставляя программистов тратить больше энергии, чем необходимо на простое определение природы ошибки. «Хорошие» ошибки воспроизводятся простыми и короткими действиями.^[94]

 Область действия. Для крупных проектов ошибки должны быть классифицированы по месту их проявления (по области действия). Тогда их можно будет отслеживать не только по исполнителям, которым поручено их устранение, но и по компонентам проекта.

 Данные о том, кто обнаружил ошибку. Имя человека, обнаружившего ошибку, с указанием контактной информации.

 Статус. Ошибка может иметь только четыре состояния: активна, исправлена, решена или закрыта. Активной считается ошибка, которая еще не исправлена и требует внимания. Исправленной ошибка становится, когда программист решает, что она исправлена. Решенной ошибка становится лишь тогда, когда обнаруживший ее человек согласится с тем, что она исправлена, или с тем, что ее исправление можно отложить. Статус закрытой свидетельствует о том, что ошибки больше нет и команда тестировщиков данный факт подтвердила.

 Решение. Если по ошибке принято решение, значит, она лишается статуса активной. Решение по ошибке может иметь несколько разновидностей: она может быть исправлена, отложена до следующего этапа или версии, объявлена двойником другой существующей ошибки или признана неустранимой.

 Тип. Ошибки делятся на два основных типа: дефекты и рецидивы. Дефекты – это обыкновенные, хорошо всем известные ошибки. Рецидивы – это ошибки, которые, будучи однажды исправлены, проявляются снова в виде негативных побочных эффектов или каким-нибудь иным образом.

 Классификация. Этот атрибут показывает, была ли ошибка классифицирована и каков результат классификации. Иногда единственными ошибками, подлежащими устранению, являются те ошибки, которые были классифицированы и помечены как принятые. Поэтому данная графа может иметь три варианта заполнения: принята, отклонена, исследуется.

 Наименование. Все ошибки должны иметь короткое имя, описывающее их таким образом, чтобы суть проблемы была понятна любому человеку.

В большинстве систем мониторинга ошибок предусматривается регистрация каждой ошибки. Она позволяет отследить, кто какие изменения внес в отношении той или иной ошибки и когда он это сделал. Эта регистрация пригодится при обсуждении решений, принятых по конкретным ошибкам. Она также позволяет развеять заблуждения относительно работы над ошибками.

Диаграмма активности

На уровне проекта самое полезное, что могут принести ошибки, – это отслеживание существующих тенденций в процессе их обнаружения, оценки и разрешения. Изучая присущие проекту тенденции, вы можете сделать для себя три полезные вещи: оценить ход выполнения проекта, узнать о том, какие проблемы, относящиеся к проекту в целом, могут иметь место, и осознать, какие действия могут привести к устранению этих проблем.

Даже при наличии самой простой базы данных по учету ошибок можно опрометчиво решить, что на ее основе предельно просто составлять различные виды диаграмм и делать сложные аналитические выкладки.^[95] Не стоит слишком увлекаться, имеет смысл составить только самые основные виды диаграмм. Более сложные запросы зачастую носят отвлеченный характер («Гляньте-ка! Наш уровень исправленных ошибок соответствует уровню дождливых дней в Испании!»). Прежде чем тратить свое время впустую на выдумывание новых видов детальных отчетов, задайтесь следующими вопросами:

1. На какие вопросы можно ответить, взглянув на данную диаграмму?

2. Как ответы на эти вопрос могут помочь нам выдержать нужные сроки или достичь нужного качества? Как эти ответы помогут нам достичь определенного критерия выхода или целей проекта?

3. Если числа растут, что это реально означает? Ухудшение? Прежнее состояние?

4. Поможет ли это в конце каждого дня (недели) понять, насколько мы приблизились к завершению?

Стремитесь к простоте

С помощью диаграммы активности могут быть отслежены простейшие и наиболее важные тенденции. Для каждого дня работы над проектом из базы извлекаются и отражаются в виде линейного графика следующие данные об ошибках:

 Активные. Общее количество активных, то есть не исправленных или не решенных ошибок.

 Поступившие. Общее количество обнаруженных на данный момент ошибок (до классификации).

 Исправленные. Общее количество исправленных на данный момент ошибок.

Рис. 15.7. Основная диаграмма активности по устранению ошибок

На рис. 15.7 можно увидеть диаграмму, отражающую тенденции основной деятельности при реализации среднего по сложности проекта на начальном периоде эндшпиля. Этот период характеризуется большим количеством активных ошибок и сравнительно высоким темпом обнаружения ошибок. Ближе к середине диаграммы (слева направо) начинают проводиться основные тесты, и темп обнаружения ошибок значительно возрастает (как и количество активных ошибок). В конечном счете, когда пройдены все тесты, кривая количества исправленных ошибок пересекается с кривой темпа обнаружения ошибок, а количество активных ошибок начинает падать. На этой простой диаграмме прослеживаются основные взаимосвязи: соотношение обнаруживаемых и исправленных ошибок определяет основную тенденцию завершения работы.

Оценка тенденций

Все диаграммы или аналитические технологии могут указывать на одну из двух вещей: осталась большая часть работы или осталась меньшая ее часть. Например, если количество активных ошибок продолжает возрастать, это означает, что проблемы накапливаются быстрее, чем убывают, и новые проблемы обнаруживаются в неизменно высоком темпе. И наоборот, если количество активных ошибок снижается, работа идет на убыль быстрее, чем обнаруживаются новые проблемы. В любом случае цель анализа тенденций заключается в том, чтобы для любой качественной характеристики понять, в каком из трех состояний она находится.

 Ситуация ухудшается. На ранних фазах тестирования проекта подобная ситуация вполне приемлема и даже желательна. Если основные тестовые испытания идут полным ходом или недавно завершились, вполне естественно, что количество ошибок растет намного быстрее по сравнению с тем количеством, которое команда программистов в состоянии исправить.^[96] Порой встраиваемые компоненты могут прийти позже запланированного срока, что приводит к обнаружению ошибок чуть позже, чем это ожидалось в ходе процесса. Важно понять причину ухудшения ситуации, степень этого ухудшения и то, что нужно сделать (по возможности), чтобы изменить тенденцию к лучшему.

 Ситуация остается прежней. Поскольку одновременно идет процесс исправления старых и обнаружения новых ошибок, вполне возможно, что команда будет топтаться на месте. Темпы выполнения работ могут быть прежними, даже если программисты будут выкручиваться наизнанку. Если когда-либо ключевые показатели застревают на месте, то чтобы понять, что должно случиться, чтобы дело сдвинулось с мертвой точки, нужно исследовать, какие входящие и исходящие факторы влияют на показатели. Нужно обязательно сообщить об этом команде. Многие программисты склонны ударяться в панику, если работают вхолостую, поскольку они не понимают, почему проект стоит на месте (или хуже того, почему он медленно тонет).

 Ситуация улучшается. Когда тенденции становятся благоприятными, важно оценить темпы ускорения и развития тенденции к концу этапа. Позитивная тенденция может быть недостаточно позитивной для соответствия критериям выхода. Если тенденция приобрела позитивный характер на начальных стадиях, следует насторожиться. Все ли контрольные тесты пройдены? Есть ли неклассифицированные ошибки? Достаточно ли высоко качество исправления ошибок? Прежде чем воспринять это явление как хорошую новость, убедитесь в том, что полностью осознаете причины, вызвавшие такое улучшение ситуации.

Полезные показатели при работе над ошибками

Существует несколько общих показателей, польза от которых при отслеживании хода эндшпиля выдержала проверку временем. Стоит поискать способы генерации этих статистических данных в автоматическом режиме, чтобы в нужный момент, когда они понадобятся для принятия того или иного решения, не тратить время на построение нового запроса к базе данных.

 Темп исправления ошибок. Это скорость, с которой команда исправляет ошибки. Поскольку не все ошибки равнозначны, эта скорость представляет собой время, затрачиваемое на исправление ошибки средней сложности. Если темп исправления ошибок ниже темпа их обнаружения, а все обнаруживаемые ошибки требуют исправления, проект никогда не завершится: количество ошибок будет неизменно возрастать.

 Соотношение обнаруженных ошибок к принятым. Сколько новых только что обнаруженных ошибок требуется исправить, не являются ли они дубликатами других ошибок? Не относятся ли они к ошибкам с приоритетами 3 и 4? Знание соотношения обнаруженных и классифицированных ошибок помогает сделать грубые прикидки относительно неклассифицированных ошибок. Как правило, «качество» ошибок со временем должно снижаться: соотношение «хороших» ошибок, имеющих приоритеты 1 и 2, должно уменьшиться. Примерный темп поступления обнаруживаемых ошибок не сможет подсказать, когда именно это сможет произойти.

 Время существования активной ошибки. Среднее время пребывания ошибки в активном статусе. Этот показатель свидетельствует об активности команды и о том, как она справляется с текущей рабочей нагрузкой. По мере приближения к контрольной дате время реакции должно увеличиваться, потому что команда должна справляться с меньшим количеством ошибок и быть более агрессивной в классификации и воздействии на обнаруживаемые проблемы. Если время реакции увеличивается, значит, люди чем-то заняты.

 Количество ошибок, приходящихся на одного разработчика. Соблюдение сбалансированности нагрузки в команде разработчиков требует следить за количеством активных ошибок, над которыми в данный момент работает каждый разработчик. Стоит также отметить, какой процент активных ошибок на данный момент поручен тестировщикам, разработчикам или руководителям проекта. Ошибки, порученные руководителям проекта или тестировщикам, не попадают на текущий производственный конвейер для исправления и их следует периодически классифицировать.

 Коэффициент ответных отказов. Вейнберг (Weinberg) называет темп рецидивов, вызванных исправлением ошибок, коэффициентом ответных отказов (Fault Feedback Ratio, FFR).^[97] Если каждая исправленная ошибка вызывает появление двух дополнительных ошибок, коэффициент FFR равен 2,0. Согласно утверждениям Вейнберга, приемлемым коэффициентом является число от 0,1 до 0,3. Если это число больше, значит, качество работы должно быть повышено (и/или снижен темп работы). Многие базы данных ошибок дают возможность связать новые ошибки с уже существующими, позволяя отслеживать показатель FFR. Но я никогда не сталкивался с автоматизацией этого процесса, все строилось на субъективных оценках тех, кто занимался классификацией в масштабе всего проекта. (Учтите, что иногда исправление одной ошибки просто вскрывает существование других ошибок. К FFR это не имеет никакого отношения.)

Элементы управления

Управлять проектом куда сложнее, чем отслеживать ход его выполнения. Оценка качественной информации относится к разряду дедукции, а понимание, каким образом отреагировать на существующие тенденции, требует проявления интуиции. У проектов есть собственная инерция, особенно в эндшпиле, и они не могут менять направление пропорционально оказываемому воздействию. Когда вся деятельность направлена на исправление ошибок, в команде принимается множество индивидуальных решений, что требует постоянного контакта с людьми и напоминаний о том, что, принимая эти решения, они должны придерживаться единых позиций, предположений и целей.

Лучший способ подумать об элементах управления – это рассмотреть частоту их применения. Некоторые высокоуровневые действия, такие как анализ методов управления, нужны не чаще одного раза в месяц. Для других действий, скажем, классификации, эта необходимость возникает ежедневно или ежечасно. В зависимости от необходимого уровня контроля важнее всего рассмотреть интервалы контролирующих действий.

Аналитические совещания

Аналитические совещания главным образом относятся к периоду миттельшпиля. На этих совещаниях руководитель команды должен предоставить сведения о состоянии проекта, сверив его с целями, указаниями старшего руководства, пожеланиями заказчика и самой команды. Аналитические совещания должны настроить всех на обсуждение удачных и неудачных дел и что вокруг этих дел происходило. Формат совещания может быть самым простым. Лучшие совещания, на которых и бывал, были обращены только к главным вопросам. Присутствующим на них хватало зрелости на то, чтобы открыто вскрывать (а не прятать) просчеты, приветствовать (а не осмеивать) просьбу о помощи и обращать внимание на самые главные вещи (а не на те, которые улучшают самочувствие и повышают настроение).

Аналитические совещания должны настраивать людей на реалистическую оценку целей, календарных планов, технологий и ролей. На совещании ничего не нужно оставлять на потом. Любая влияющая на проект проблема должна быть открыта для обсуждения. По этой причине аналитическое совещание является не только элементом отслеживания хода процесса, но и элементом управления, потому что оно предоставляет возможность руководителю и старшему руководству провести открытое обсуждение тех поправок, которые необходимо внести в любой из аспектов проекта. Независимо от масштабов совещания, выводы проведенных дискуссий и слайды, использованные на презентации, должны быть чуть позже предоставлены всей команде на отдельной встрече.

Команды должны планировать периодическое проведение анализа в рабочем графике в течение каждого рабочего этапа. Все должны быть оповещены о времени проведения анализа, поскольку за ним должно следовать совещание в составе всей команды. Многомесячные проекты должны включать ежемесячные аналитические совещания. Для проектов, реализуемых в течение нескольких недель, такие совещания нужно проводить один раз в одну-две недели. Чем чаще они проводятся, тем информативнее и быстрее они должны проходить.

Аналитические совещания с участием заказчиков или клиентов

Если ваша команда работает по контракту или имеет какого-нибудь внутреннего заказчика, аналитические совещания могут послужить одним из механизмов прямого получения отзывов от ваших заказчиков. К ним применимо большинство из уже изложенных советов. Важно также отметить, что не стоит рассматривать эти совещания в качестве единственного источника отзывов от заказчика. Периоды между совещаниями бывают слишком длительными, а формат их проведения может осложнить углубленное рассмотрение или обсуждение сложных проблем.

Один из важных аспектов экстремального программирования (XP) заключается в содействии участию представителя заказчика в самом процессе разработки программного обеспечения.^[98] Этот человек должен использовать ежедневные сборки и развивать отношения с программистами и их руководителями. Тогда вы и ваша команда смогут получать отзывы о существующих проблемах ежедневно или ежечасно, а не еженедельно или ежемесячно. По началу эти отношения могут быть непростыми (см. раздел «Распределение ролей» в главе 9), но затраты всегда окупятся более разумными проектными решениями и удовлетворением заказчиков готовым продуктом.

Классификация

Любой процесс, в котором берется перечень проблем и проводится их расстановка по приоритетам, является, по сути дела, классификацией. Реальный процесс классификации отличается от других видов приоритетной расстановки тем, что связан с постоянным поступлением новых проблем, которые требуют осмысления и назначения приоритетности их решения по отношению к другим существующим проблемам. Классификация проводится в период миттельшпиля, когда есть некий промежуточный срок, который нужно соблюсти, и качественные показатели, относящиеся к критериям выхода. Но в период эндшпиля классификация становится для команды первостепенной задачей, часто занимая существенную часть ежедневного рабочего времени руководителей проекта и других специалистов.

Задачей классификации является управление производственным конвейером (рассмотренном в главе 14) с целью максимально увеличить степень важности работ, направленных на достижение критериев выхода из этапа. Чтобы достичь успеха, требуются три вещи:

 Первичная обработка. Обнаруживаемые ошибки всегда отличаются по важности. Кому-то надо просматривать новые ошибки и делать квалифицированное заключение об их качественном уровне, чтобы их можно было поручить конкретному программисту, а он мог провести исследование и заняться их исправлением. Некоторые ошибки требуют исследований программиста, но фильтрация большинства из них представляет собой вполне обычные процедуры: заполняются поля (серьезность, приоритет и т. п.), уточняются возможности ее рецидива, подтверждается факт, что у нее нет двойника среди существующих ошибок и т. д. Зачастую это чисто канцелярская работа: звонки по телефону, обмен сообщениями по электронной почте и работа с конкретной сборкой для отслеживания нужной информации.

 Исследование. После того как ошибки пройдут первичную обработку, начинается исследование. Нужно ли их исправлять? Нарушают ли они общий характер требований (технических условий)? Какие компоненты вызывают данную проблему и какие силы и средства нужно привлечь для их переделки? Прежде чем принять правильное решение, возможно, придется ответить на ряд вопросов как технического, так и другого характера.

 Расстановка приоритетов. После первичной обработки и исследований ошибки могут быть расставлены по приоритетам и отправлены на конвейер в соответствии со степенью их важности.

Процесс классификации осложняется тем, что для выполнения любой из этих трех операций знаний какого-то одного человека может не хватить. Чем крупнее проект, тем меньше вероятность, что эффективная классификация окажется по силам одному человеку. Поэтому для большинства команд и большинства проектов классификация является коллективной работой. На ранней стадии классификация силами отдельных специалистов их собственных ошибок вполне допустима, но чуть позже эта работа должна поручаться небольшим группам и подгруппам. Это связано с тем, что ошибки должны быть классифицированы по принадлежности к различным областям проекта (см. ранее радел «Устранение ошибок и дефектов»). Небольшим группам, ответственным за определенную область, проще собираться вместе и классифицировать ошибки независимо от остальной команды.

Чуть позже, ближе к концу эндшпиля, когда каждые решения по ошибкам тщательно анализируются, классификация должна быть централизована в масштабе всего проекта и проводиться основной группой руководителей проекта (мы рассмотрим этот вопрос в разделе «Военный совет»). Теперь важно разобраться с двумя основными разновидностями классификации: ежедневной и целенаправленной.

Рис. 15.8. По мере развития эндшпиля классификация все более централизуется

Ежедневная или еженедельная классификация

Ежедневная классификация – это обычный процесс ежедневной обработки обнаруживаемых и активных ошибок. В зависимости от времени, прошедшего с начала этапа, могут потребоваться еженедельные, ежедневные или почасовые классификации. Чем больше времени прошло с начала эндшпиля, тем чаще требуется проводить классификацию.

Цель ежедневной классификации проста – поддерживать порядок. Критический путь эндшпиля проекта проходит через работу программистов, и классификация является единственным способом обеспечить эффективность конвейера. Желательно до того, как каждая новая ошибка попадет на рабочий стол программиста, провести ее первичную обработку и сравнение с существующим фондом ошибок.

Иногда лучше (в интересах эффективной работы команды) в каждой области иметь по одному человеку, занимающемуся ежедневной классификацией ошибок. Предполагая, что программисты и тестировщики согласовали критерии, этот человек должен отвечать за первичную обработку новых ошибок, пометку ошибок-двойников и расстановку обнаруживаемых ошибок по приоритетам. Предполагая, что технических знаний руководителя проекта вполне достаточно для осмысления проблемы и принятия основных решений по ошибке, он является весьма неплохой кандидатурой на эту роль.

Впрочем, классификация может проводиться и на небольшом совещании в присутствии руководителя проекта и представителей от разработчиков и тестировщиков. Если понадобятся другие специалисты из состава команды, скажем, маркетологи, проектировщики или специалисты по потребительским качествам продукта, то их можно пригласить дополнительно. Совещание должно проводиться накоротке. Все, что не может быть решено за пару минут, должно передаваться программисту на исследование.

Как только ошибки будут классифицированы, для них должно быть заполнено поле классификации. Тогда в проекте появятся дополнительные условия для представления данных об ошибках и можно будет отделить количество классифицированных ошибок (в достаточной мере распознанных) от общего количества активных ошибок (еще не прошедших оценку).

Целенаправленная классификация

При целенаправленной классификации усилия сосредоточиваются на решении конкретных задач. Целенаправленная классификация проводится в дополнение к ежедневным классификациям. Это – одно из средств управления проектного уровня, призванное помочь придать проекту новый импульс и повысить ценность диаграмм работ по устранению ошибок и анализа текущих тенденций. Рассмотрим несколько общих причин проведения целенаправленной классификации:

 Низкое соотношение числа классифицированных ошибок к числу активных. Если на 500 активных ошибок приходится лишь 200 классифицированных, то невозможно узнать серьезность оставшихся 300 ошибок. Кто знает, все они могут оказаться ошибками с приоритетом первой очереди, вызывающими полный крах системы, или двойниками уже существующих ошибок. Целенаправленная классификация может иметь особую задачу по ликвидации всех неклассифицированных ошибок к определенному сроку (к завтрашнему полудню). Ели эта проблема приобрела для команды хронический характер, задачей может стать не оставить ни одной активной неклассифицированной ошибки старше определенного количества часов (например, 24 часов).

 Изменились критерии выхода. Если руководство команды решило, что критерии выхода должны претерпеть изменения, то классификация станет единственным способом вывести проект на путь этих изменений. Обычно новые критерии выхода используются для изменения угла снижения, исключая определенные классы ошибок из рассмотрения для повышения безопасности этого угла (но при этом жертвуя качеством процесса).

 Слишком много незакрытых ошибок. Когда ошибка исправлена, нужно присвоить ей статус решенной и отправить сообщение назад, тому, кто ее открыл, чтобы убедить его в том, что она действительно исправлена. Определенный процент таких ошибок может быть исправлен не так, как следовало бы. Если подобные ошибки числятся незакрытыми, то набирается множество ошибок, требующих исправления, но не попадающих в отчете в число активных. В зависимости от применяемой системы мониторинга ошибок могут быть и другие места, где могут скрываться ошибки. Периодически команду нужно нацеливать на то, чтобы она извлекала их из этих закутков.

Военный совет

Ближе к завершению проекта распределенная до этого власть должна централизовываться. В отличие от проектировки функций и программирования, которые могут быть разумно распределены внутри команды, к концу проекта возможности для распределения ошибок уменьшаются. Решения становятся более критичными, представляя собой кропотливое занятие, а не создание какой-нибудь конструкции. В терминах Microsoft такое централизованное управление называется военным советом (что, по-моему, берет начало от термина военная комната, означавшего то место, где лидеры встречались для решения важных проблем). Доминирующей ветвью исполнительной власти становится небольшая группа руководителей команды. В небольших командах подобное смещение властных полномочий может быть и ни к чему, но для средних и больших команд оно просто необходимо. Оно поднимает планку всех принимаемых решений и реализует функцию принуждения в отношении команды, завершающей игру.

Настоящий военный совет не представляет собой ничего сложного. Все, что нужно для его проведения, – это конференц-зал, старший представитель от каждой штатной структуры (от программистов, от тестировщиков, руководитель проекта или другие равные ему руководители и, возможно, старшие групп) и компьютер, подключенный к большому экрану, чтобы всем присутствующим была видна обсуждаемая ошибка или проблема. Чтобы проблема прошла рассмотрение военного совета, должно быть получено согласие всех старших представителей (в некоторых командах достаточно большинства в две трети, а в некоторых члены военного совета получают право вето). Решение о повестке дня военного совета принимается каждое утро, а в саму повестку может быть внесено рассмотрение любой проблемы. Подобно суду, действующему по нормам общего права, все, что принимается или отклоняется на заседании совета, становится нормой для всей остальной команды. Заседания военного совета должны быть открытыми для команды, приоритет должен отдаваться тем людям, которые вносят конкретные запросы на изменение замысла (DCR, см. предыдущую главу) или предлагают на рассмотрение какие-нибудь ошибки.

Военный совет должен установить очень высокую планку. Любому, кто продемонстрирует военному совету свою неподготовленность или неумение ответить на основные вопросы (Каким выходным критериям это соответствует? К каким рецидивам это может привести? Согласны ли и программисты и тестировщики с тем, что это должно быть исправлено?), должно быть указано на дверь и запрещено возвращаться до тех пор, пока он не подготовится. Время военного совета следует ценить, поскольку драгоценно время всей команды. Каждый руководитель проекта и программист должен иметь четкую мотивацию на приведение своего заявления в строго обоснованный и окончательно сформированный вид, прежде чем выносить его на рассмотрение военного совета. Оказываемое давление создает естественный стимул для всей команды основательно продумать проблему своими силами, прежде чем принимать решение о выносе ее на рассмотрение военного совета. (Здесь нужно проявить осторожность: заседания военного совета могут стать слишком загруженным, а возможностей для пустой траты времени на чью-то рисовку или проявления эгоцентризма существует великое множество. Руководитель группы должен пресечь подобные проявления на самой ранней стадии.)

Команда должна быть честно предупреждена о том, когда и в связи с чем будет созван военный совет. На рис. 15.9 показаны некоторые основные этапы, на которых возникают дела, требующие вмешательства военного совета. Задача состоит в том, чтобы вести постепенную централизацию власти с объявлением дат, когда произойдут подобные подвижки. Рассмотрение DCR-запросов чаще всего становится первым использованием заседаний военного совета, поскольку может произойти на ранних стадиях в ходе миттельшпиля. Позже, когда потребности в оценке и мониторинге ошибок возрастают, в компетенцию военного совета переходит санкционирование помещения ошибок на производственный конвейер (на котором уже должны быть ранее санкционированные ошибки). И наконец, в ходе заключительных недель или дней военный совет рассматривает все обнаруживаемые ошибки, и управление проектом осуществляется полностью в централизованном режиме.

Рис. 15.9. Власть военного совета в ходе эндшпиля постепенно усиливается

Сначала заседания военного совета должны проводиться еженедельно, постепенно переходя в ежедневные получасовые или часовые встречи. В задачи военного совета входит своевременное начало и окончание заседаний (кто-то должен перед началом заседания разъяснить суть повестки дня). Если на заседании должны быть приняты выверенные решения, соответствующие критериям выхода и целям проекта, то за 60 (если не за 30) минут вполне реально рассмотреть множество DCR-запросов и классифицировать множество ошибок. Секрет в том, что в период эндшпиля надо избегать мелочной опеки.

Военный совет не должен заботиться о работе над каждой ошибкой или проблемой. Напротив, ему нужно обеспечить, чтобы решения принимались исключительно в интересах проекта, убедиться в том, что на правильные, внятно заданные вопросы даны хорошие ответы, а для использования оставшегося времени планка установлена на правильной высоте. Военные советы не смогут решать возложенных на них задач, если руководители не доверяют своим командам. Если проблема действительно серьезна, она должна быть обсуждена в рабочем порядке с одним из членов военного совета, а затем уже представлена в улучшенном виде.

В вопросах целей проекта, критериев выхода, решений о распределении ошибок по приоритетам и общения внутри команды существует множество возможностей переложить решения на плечи команды. Иногда процесс рассмотрения на военном совете может быть автоматизирован путем создания веб-форм, позволяющих членам совета рассматривать вопросы дистанционно в удобное для них время. Будьте благоразумны. Найдите способы, позволяющие не превращать военный совет в бесполезную или невольную обузу.

Вообще-то, чем меньше проблем приходится выносить на рассмотрение военного совета, тем лучше высшее руководство на пути реализации проекта справляется с планированием, с выполнением намеченного плана и с руководством командой. Если заседания военного совета постоянно проводятся в виде жестокого трехчасового марафона, это означает, что руководство терпит неудачу в одном или нескольких направлениях и из этого должны быть извлечены уроки для следующего проекта.

Окончание игры

Заключительный период разработки программного продукта – сложный и утомительный процесс. Джим МакКарти (Jim McCarthy) в книге «Dynamics of Software Development» (Microsoft Press, 1995) ссылается на него как на работу с желеобразной массой. При каждом исправлении ошибки вы как будто бы снова и снова прикасаетесь к большому кубу из желе, после чего некоторое время ожидаете, пока он перестанет трястись. Чем больше вы к нему прикасаетесь, тем больше различных вариаций его сотрясений и тем сложнее наложение колебаний, возникающих от этих сотрясений. Веб-сайт или программный продукт – это, по существу, сложнейший набор взаимосвязанных частей, и при каждом изменении одной из них вы вызываете всевозможные новые волны в его поведении. Но в отличие от желе в программном продукте не так то легко понять, когда закончатся эти сотрясения. Код не обладает прозрачностью. Понять, к чему приведет даже одно небольшое изменение, можно только после проверки качества и тщательного ручного исследования сборки.^[99]

Это означает, что реально процедура завершения проекта по большей части проходит в ожидании. Час за часом тратится на просмотр и тщательное исследование новых отчетов об ошибках или проблемах, чтобы понять, не будет ли пересечена та грань, за которой желе снова начнет трястись. В больших командах эту ношу взваливает на себя военный совет. Хотя остальная часть команды должна активно выявлять новые проблемы и работать с самыми последними сборками, каждый из них может внести какой-нибудь собственный вклад в политику выжидания.

Но когда ошибка достаточно серьезна, чтобы заставить желе трястись, все опять начинают работать в полную силу. Военный совет берет на себя бремя руководства командой (или, если быть точнее, программистом), пытаясь разобраться с проблемой до такой степени, чтобы можно было применить хирургическую операцию. Затем набор тестов при разных условиях выполняется заново, чтобы гарантировать, что все пришло в прежнее состояние, за исключением той самой маленькой вещицы, которую нужно было изменить. Это очень напряженный процесс. В отличие от масштабных изменений, проводимых в период миттельшпиля, или выявлению ошибок в начале эндшпиля, в завершающие дни уже нет возможности отложить что-либо масштабное на потом. Здесь все очень маленькое, и выплеснуться напряжению некуда.

В этом процессе иные измерения и приоритеты, но они не приводят к существенным изменениям характера работы. Это просто промежуточные этапы на пути к выпуску продукта. Но, по крайней мере, они позволяют скрасить напряженную монотонность поздней стадии эндшпиля.

 Баланс нуля ошибок. Когда количество активных и санкционированных (военным советом) к исправлению ошибок становится нулевым, говорят, что команда дошла до баланса нуля ошибок (Zero Bug Bounce, ZBB). Балансом это состояние называется потому, что как только обнаружится очередная ошибка, у команды уже не будет «нуля ошибок». Есть несколько симпатичных теорий относительно дистанции, разделяющей ZBB и текущий выпуск продукта, но ни одна из них не проработана в достаточной степени, чтобы попасть на страницы этой книги.

 Нулевое количество решенных ошибок. Решенные ошибки могут представлять собой скрытые проблемы, о которых команда ничего не знает. Пока такая ошибка не будет закрыта (с подтверждением), полной уверенности в том, что ошибка действительно исправлена именно так, как это и предполагалось, быть не может. Достижение нулевого количества решенных ошибок означает, что проект действительно пришел в состояние возможного завершения.

Обнаруживаемыми и активными ошибками в данном случае мы пренебрегаем, поскольку они находятся ниже рассматриваемых критериев. Даже если команда занимается исследованием таких ошибок, пока они не вынесены на рассмотрение военного совета, они в действительности не влияют на продвижение проекта.

Кандидат на выпуск

Первая сборка проекта, которая отвечает всем критериям выхода, называется кандидатом на выпуск (Release Candidate, RC). Как только появится такая сборка, должен быть добавлен новый критерий выхода: какие из найденных в этой RC-сборке проблем могут стать основанием для создания второго кандидата на выпуск? Если такого критерия не существует, следует предположить, что RC-сборка прошла все проверочные тесты и тесты на качество и может быть выложена в Интернете или помещена на компакт-диск и доставлена заказчикам.

Если такой критерий существует, эндшпиль повторяется. Военный совет решает, какие исследования, проектные решения или разработки должны быть проведены, изменения утверждаются и вносятся, и процесс уходит на второй круг.

В мире программных продуктов, особенно продуктов в коробочном исполнении, RC-сборки стоят дорого. Часто применяются дополнительные тесты и процедуры, через которые должна пройти сборка для подтверждения ее прав относительно установки на компьютер, локализации, соответствия торговой марке и т. п. Что касается Интернета, то тут все зависит от того, как проект интегрируется в другие проекты. Этот механизм может напоминать сложное дерево зависимостей, которыми нужно управлять.

Процесс обкатки и связанные с ним действия

Когда завершается работа над финальной RC-сборкой, праздник в команде наступает далеко не для всех. В зависимости от природы проекта финальная RC-сборка может дать толчок для целой серии новых работ. Возможно, для команды тестировщиков и аналитиков качественного состояния продукта работа будет в самом разгаре, им потребуется оценить загруженность сервера или иные разновидности проблем совместимости, которые могут быть протестированы только при наличии финальной RC-сборки. Конечно, решение этих вопросов можно запланировать, но испытания нельзя начать до тех пор, пока все биты не окажутся на своих местах.

Большинство веб-сайтов или веб-продуктов при публикации проходят через последовательность тестовых серверов, в которых задаются различные условия и сопутствующие нагрузки для окончательного тестового охвата. Чем больше платформ или языков должен охватить проект, тем сложнее процесс обкатки. Разумеется, время, требующееся для надлежащей обкатки, может быть примерно определено на этапе первоначального планирования. В зависимости от организации процесса нагрузка по проведению обкатки может лечь на одну подгруппу или разделена на всю команду разработчиков проекта.

Проектная постпрограмма

Поскольку приближается завершение этапа или всего проекта, кто-то должен настроить команду на извлечение уроков из всего только что сделанного. Эту работу часто называют описанием ретроспективы проекта, или постпрограммой. На эти действия наталкивает желание зафиксировать информацию, пока она еще свежа в памяти людей, а когда люди соберутся отпраздновать успех и отложить все дела, им вряд ли захочется возвращаться назад и вспоминать обо всех проблемах, с которыми они недавно имели дело. Многие хотят двигаться вперед, оставляя позади свое прошлое.

И тут снова на первый план выступает руководитель. Руководитель команды должен внести свой вклад в процесс выполнения постпрограммы. Поскольку дел становится все меньше, руководитель должен попросить людей подумать над тем, что удалось, а что нет, и оформить это хотя бы в виде списков на отдельных листках бумаги. Руководитель проекта должен составить план по сбору этих записей и созданию постпрограммного отчета. В отчете должны быть отражены две вещи: анализ и резюме всех извлеченных уроков и обязательство учесть в следующем проекте самую незначительную часть этих уроков (если подборка окажется слишком большой, чтобы попасть в следующий проект, расставьте приоритеты и выберите самое главное).

Возможно, для выполнения постпрограммы имеет смысл нанять профессионала^[100] (или взять кого-нибудь не из команды, а из организации). Исполнители, потратив неделю на расспросы всех специалистов команды, на основе изученного материала составят отчет, который должен пройти экспертизу консультанта. Преимущества такого подхода заключаются в объективности взгляда, поскольку сторонний наблюдатель подметит и озвучит то, что ускользает от взгляда других людей.^[101] Возможно, более важным станет то, что они принесут в организацию стороннюю оценку, обращенную к нуждам конкретного проекта и команды.

Время устраивать вечеринку

Когда будет утвержден выход финальной RC-сборки, и она пройдет свой путь сквозь процесс становления во внешний мир, настанет время отпраздновать это событие. Спустя многие недели, месяцы или даже годы, то, что вы предполагали создать, наконец-то завершено. Завершение проекта довольно редкое и специфическое событие – в технической сфере многие проекты никогда даже и близко не подходят к такому результату. Руководитель проекта должен проследить, чтобы у каждого, кто участвовал в проекте, была возможность вместе со всеми отпраздновать его завершение. Избегайте корпоративных стереотипов (этот праздник невозможно провести в конференц-зале). Лучше пойдите в ближайший бар, закажите огромный стол в любимом ресторане или пригласите всех ребят к себе домой. Когда в запасе много времени, то питье и еда кажутся вкуснее (а пить и есть нужно побольше). Если вы не способны зажечь и развеселить людей, отыщите такого человека в команде, сговоритесь с ним и организуйте что-нибудь необычное.

У большинства из нас за всю карьеру набирается не так уж много завершенных проектов. Невероятно трудно создать достаточно хорошую вещь, чтобы люди могли использовать ее в своей повседневной жизни. А раз уж вам повезло, и время для грандиозного праздника настало, покажите, что умеете прожигать жизнь.

Выводы

• Долгие сроки – это просто сумма нескольких коротких.

• Каждый этап содержит три коротких срока: завершение проектирования (когда закончена работа по выработке технических условий), реализация заданных характеристик (закончена фаза разработки) и завершение всего этапа (закончены проверка качественных показателей и оптимизация).

• Определение критериев выхода в самом начале этапа повышает возможности команды на его своевременное завершение.

• Своевременное завершение этапа подобно приземлению самолета: то и другое требует приближаться к финишу долго и медленно. При этом нужно быть готовым к внезапному повторному взлету, чтобы не пришлось заниматься серьезным ремонтом.

• Для мониторинга хода проекта нужны оценочные инструменты. Обычно к ним относят ежедневную сборку, работу над ошибками и диаграмму активности.

• Для внесения корректив на уровне проекта нужны элементы управления. Традиционно для управления используют аналитические совещания, классификацию ошибок и военный совет.

• Завершение проекта представляет собой медленный и утомительный процесс. Сложность состоит в том, что пределы возможных изменений сужаются до тех пор, пока не остается достаточно удовлетворительная версия продукта.

• После завершения проекта настает время постпрограммы. Обеспечьте себе и своей команде возможность проанализировать все победы и поражения, имевшие место в ходе реализации проекта, и извлечь пользу из этого анализа.

• Если фортуна смилостивилась над вами и проект все же вышел в свет, порадуйтесь этому событию. Почувствуйте себя счастливым. Многие и не по своей вине никогда не достигают подобного успеха. Спланируйте грандиозную вечеринку. Веселитесь, не боясь экстравагантных поступков (включая приглашение к себе автора этой книги). Пусть будет о чем вспомнить.

Упражнения

1. Когда вы в следующий раз будете работать над проектом в стадии эндшпиля, начните вести список отслеживаемых данных, которые вы хотели бы получить при реализации проекта. Возьмите обязательство вести запись этих данных с начала следующего проекта.

2. В следующий раз при составлении критериев выхода в качестве эксперимента потребуйте от авторов критериев, чтобы они, используя эти критерии, приняли участие в первом совещании по классификации ошибок. Это должно заставить их выдерживать критерии в практическом русле, предоставляя больше возможностей для их усовершенствования в самом начале эндшпиля.

3. При классификации один из программистов настаивает на том, чтобы решать судьбу каждой ошибки. Он грубит, насмехается и делает все возможное, чтобы навязать свое мнение. Проблема в том, что в большинстве случаев он оказывается прав. Что вы должны предпринять?

4. В начале эндшпиля ваша команда взбудоражена тем, что перешла к последней стадии, но вы уже перегорели. Проекту уже отданы все силы. Признаетесь ли вы в этом своей команде или попытаетесь все от них скрыть? Как можно восстановить свои силы?

5. Выберите какую-нибудь другую отрасль: как в ней управляют завершающей частью календарного плана проекта? К интересным примерам можно отнести кинопроизводство, действия любой из групп спецопераций вооруженных сил (Морских котиков, Ниндзя, Спартанцев) или работу ваших любимых ресторанов, выполняющих заказы с доставкой на дом. Подготовьте небольшую презентацию для своей команды, демонстрирующую ваши методы в сравнении с методами, использующимися в этих областях.

6. До выпуска главного обновления вашего веб-сайта новостей, имеющего миллионную аудиторию, осталось два дня. Уже заготовлено шампанское. Но разработчик обнаруживает серьезную проблему, на устранение которой требуется три дня. Сложность в том, что ко дню запуска приурочена реклама стоимостью 10 миллионов долларов, за которую уже заплатили. Что вы сделаете?

7. Представьте, что вы один из пяти лидеров, участвующих в военном совете. На каждой встрече в присутствии множества подчиненных между пятью лидерами вспыхивают жаркие споры, продолжающиеся иногда более десяти минут. Как это повлияет на команду? Составьте перечень различных подходов, которые можно было бы применить как на самих встречах, так и после них.

8. Представьте, что вы только что выпустили самую грандиозную программу за всю историю человечества. Ваша команда попала на обложку журнала «Time», вы все прославились. Как вы отпразднуете это событие? Сколько средств выделите на торжество? Где все это устроите? А теперь подумайте о своем текущем проекте. Он может претендовать на выпуск лучшей программы, когда либо создававшейся в рамках подобных проектов. Неужели команда не заслуживает того, чтобы отметить ее достижения каким-то особым образом?

Глава 16. Власть и политика

Любая попытка организовать людей на какие-нибудь действия, от обыкновенной вечеринки и до открытия новой компании, вынуждает считаться с различными позициями, желаниями или навыками участников. Из этого следует, что, сколько бы таланта ни проявил лидер при реализации проекта, всегда найдутся те, кому чего-то не хватает. Поэтому деятельные и амбициозные натуры обладают природным даром требовать и добиваться желаемого, воздействуя на людей, обладающих достаточными полномочиями для удовлетворения их потребностей. Я не нашел другого более простого объяснения, которое могло бы уложиться в пару фраз, чтобы определить истоки политики. Все трудности и неприятности политических ситуаций, возникающих при совместной работе в составе группы, можно отнести на счет побочных проявлений человеческой натуры. Аристотель сказал: «Человек по природе своей есть существо политическое», отчасти имея в виду именно это. В доказательство можно привести также цитату из книги Ричарда Фарсона (Richard Farson) «Management of the Absurd: Paradoxes in Leadership»:

Любой поступок руководства является политическим действием. Тем самым я хочу сказать, что каждое руководящее действие в некотором роде перераспределяет или укрепляет власть.

Движущей силой политики является власть. Проще говоря, власть – это способность личности оказывать влияние на других людей или управлять ими. Хотя мы привыкли разбираться в принадлежности властных полномочий на основе организационной иерархии, структура власти далеко не всегда полностью совпадает с официальным распределением ролей (в главе 12 мы уже говорили, чем отличается заслуженная власть от предоставленной). Человек, способный убедить нужных людей в нужное время и воспользоваться их знаниями для разрешения ко всеобщему удовлетворению какой-нибудь неблагоприятной ситуации, может иметь большее влияние в организации, чем его начальство, которое порой, в отсутствие этого человека, чувствует, что его явно не хватает.

Поэтому организационная политика еще больше усложняется: отдельные личности запросто могут укрепить свою власть, игнорируя существующую иерархию. Дополнительные сложности возникают из-за того, что в зависимости от конкретного характера проблемы или решения властные полномочия распределяются внутри команды различным образом. Харольд может оказывать больше влияния на решение инженерных проблем, а Мод – проблем бизнеса. Если все это принять во внимание, можно прийти к выводу, что сложность типичной организации, занимающейся разработкой проектов, дает возможность проведения определенной политики, но та же сложность неизбежно создает конкуренцию во власти и в воздействии на людей.

Это значит, что руководители проектов должны учитывать две вещи. Во-первых, независимо от степени предоставленной власти и культуры поведения, вы все равно будете испытывать чье-нибудь политическое влияние. Во-вторых, власть и политика – неотъемлемые атрибуты лидерства и руководства. Если вы хотите снизить негативное влияние власти и политики и усилить позитивное, нужно, по крайней мере, знать, как работает политическая система. В этой главе предлагаются основные уроки по применению политики в сфере разработки проектов. Здесь рассказано, как оценить политическую обстановку, в которой вы оказались, рассматриваются типичные ситуации и причины их возникновения, а также методы решения проблем, связанных с политикой и властью.

День, когда я стал политиком

В 1997 году Крис Джоунс (Chris Jones), работавший в то время руководителем группы программистов Internet Explorer, преподал мне первый серьезный урок по организационной политике. Группа только что пережила двухмесячный хаос, претерпев несколько реорганизаций и смен руководства, и еще не успела войти в нормальный ритм. Команде была отведена одна особо важная роль – отвечать за разработку так называемых каналов (части той самой злополучной «технологии доставки контента», по которой все сходили с ума во времена войны браузеров, но из которой так толком ничего и не вышло). Решающий характер, отводившийся этой роли в наших планах, и слишком слабая ее проработка воздействовали на команду крайне негативно. Многие специалисты моего круга, включая и меня самого, совершенно не понимали, как с этим справиться. Чувствуя собственное бессилие, мы частенько во всем обвиняли политику, проводимую нашим руководством. Усугубляя ситуацию, я выработал к тому времени самое что ни на есть циничное представление об организационной политике. Мои взгляды чем-то напоминали следующее представление.

Политика (сущ.) – это то, чем заняты озлобленные, слабые и корыстные люди.

Я ничего толком не знал ни о сути политики, ни о том, как она делается, но был уверен, что ею в команде занимаются совершенно никчемные люди (кем бы они ни были). Я не мог в точности установить, кто это был, поскольку в то время я давал людям оценку, исходя всего из двух понятий: умный и глупый. Я был невежественным и высокомерным типом (интересно все же, как часто эти два свойства сочетаются в одном человеке). Спасли меня очень высокое мнение о Крисе и то обстоятельство, что наши кабинеты были рядом.^[102] Однажды, пребывая в унынии и расстройстве по поводу всего, что творилось вокруг меня, я зашел к нему и выказал свою озабоченность по поводу состояния дел в группе. Он терпеливо выслушал меня и предложил поговорить об этом за обедом.

Во время обеда он сказал мне гораздо больше, чем я от него ожидал услышать, чем несказанно меня удивил. Он, не ущемляя интересов других своих подчиненных, изложил всю ситуацию со своей точки зрения, сообщив мне столько подробностей, что я смог понять суть первичных проблем. Он дал проблеме свою общую оценку, раскрыв передо мной три имевшихся у него в запасе разумных варианта ее решения. Я понял, что он также был ограничен в действиях и вынужден считаться с потребностями, желаниями и целями как его коллег-руководителей, так и вышестоящего начальства, включая вице-президентов. Его подпирали и сроки календарного плана, и стратегическая конкуренция (со стороны компании Netscape). С моей колокольни его мир представлялся мне более свободным, чем мой (разве власть не дает свободу?), но, как только он разложил мне все по полочкам, я понял, что ему приходится куда труднее, чем мне.

Он вторично удивил меня тем, что спросил моего мнения, предоставив мне возможность изложить свою логику и точку зрения на решение, которое он должен был принять. Вот тогда-то у меня и наступило мое первое политическое прозрение: насколько же, в действительности, тяжела эта ноша. Своим вопросом о том, что я думаю (и тем, что выслушал меня до конца), он лишил меня всей враждебности и стремления потыкать пальцем по сторонам, которыми я обычно сопровождал свои попытки поразмыслить насчет проводимой политики. Он поставил меня на место ответственного за проблему и за тех людей, которых она касалась. И как только я вошел в эту роль, то тут же остыл. Словно выброшенный на встречную полосу движения, я не знал, с чего начать: все вдруг показалось мне ужасным. Я до сих пор помню, как уставился на свой недоеденный бутерброд не в состоянии найти хоть какой-то не слишком глупый ответ. Разговор продолжался, пока обед не закончился, и я вернулся к своей работе. Хотя с тех пор мне стало известно очень многое о работе организаций, я часто оглядываюсь назад, возвращаясь к тому самому дню, который перевернул все мои представления. С того памятного дня я усвоил несколько ключевых понятий:

 Политика – это отнюдь не ругательство. Во многих словарях в качестве первого определения слова политика вы увидите примерно следующее:

Политика (сущ.) – искусство или наука руководства или управления, в особенности, управления политическими организациями, такими как государство, а также администрирования и управления их внутренними и внешними делами.

Пересмотрев четыре или пять определений, приведенных в большинстве имеющихся словарей, вы не найдете ни в одном из них ничего похожего на мое прежнее циничное определение этого слова. Политика – это искусство управления людьми и организациями. Эффективную политику можно выстроить, не делая ничего неэтичного или низменного.

 Все лидеры сталкиваются с политическими и властными ограничениями. Нам хочется верить в то, что представители власти – вроде вице-президентов мощных корпораций или президента Соединенных Штатов – обладают огромными полномочиями. Да, они обладают властными полномочиями, но большая часть их власти находится под чьим-то влиянием. Например, президент США представляет одну из ветвей власти (в данном случае исполнительной), и его власть находится под контролем, она сбалансирована двумя другими ветвями. Многие официальные акты президента могут попасть под вето. Большинство корпоративных вице-президентов имеют в своем подчинении старших менеджеров, которые докладывают им обстановку и не желают, чтобы им подсказывали, что именно надо делать, требуя передачи им существенной части властных полномочий. Такая же цепочка тянется вниз по инстанции. Поэтому, глядя на людей, у которых больше власти, чем у вас, не спешите считать их всемогущими.

 Соотношение власти и ответственности есть число постоянное. Власть можно рассматривать сквозь призму сложностей, с которыми вы можете столкнуться, если ею воспользуетесь. Предположим, что будучи генеральным директором какой-нибудь корпорации, я дал вам 5 долларов, чтобы получить чашку кофе. Власть, которой вы обладаете, ничтожно мала (если вообще имеет место), но точно такой же является и степень ответственности. В то же время, если я дал вам 2,5 миллиона долларов и выделил штат своих лучших сотрудников, то, вероятно, это было сопровождено просьбой спланировать, выстроить и возглавить какой-нибудь бизнес. С ростом масштабов предоставленной вам власти возрастает ответственность, напряженность и количество возникающих проблем. По этой причине обладание большей властью вряд ли облегчает чью-то жизнь, поскольку расширение области полномочий ведет лишь к росту трудностей.

 Политика – это средство решения проблем. Каким бы ни был характер организационных трудностей, с которыми пришлось столкнуться, и степень расстройства по этому поводу, все это – не более чем новая разновидность проблем, требующих своего решения. Люди, повсюду сующие свой нос, непредсказуемые личности и льстецы сами по себе являются в некотором роде препятствиями, которые нужно преодолеть или обойти. При всем многообразии хороших или плохих вариантов развития событий, вероятно, есть конечное число практичных вариантов действий, которые облеченный властью человек может предпринять в любой определенной ситуации, и все эти варианты будут иметь определенные политические последствия. Если подходить к организационным проблемам с такой же дисциплинированностью и творчеством, как и при подходах к решению проблем проектирования или разработки, можно найти нужные варианты выбора и принять действенные решения (или, по крайней мере, иметь возможность их принять).

Со временем я понял, что обвинение «политики» в проблемах, с которыми я сталкивался, было наивным и удобным способом избежать неприятных, но неизбежных трудностей, связанных с необходимостью работать с другими людьми. С таким же успехом я мог бы указать на «руководство», «разработку» или «маркетинг» и заявить о той глупости или неэффективности, с которыми они ведутся. Если на что-то указать пальцем, оно от этого не станет менее глупым или неэффективным. (Если вообще проблема именно в этом. Вполне возможно, что все не так уж и глупо, но так же, как и ваша деятельность, подвержено политическим ограничениям.)

То же самое относится к указаниям на любого конкретного программиста, управленца или предполагаемого виновника. Обвинение просто не способно что-либо изменить, к тому же зачастую оно не позволяет разглядеть реальных причин и возможных средств оздоровления ситуации. Любые предпринимаемые политические или руководящие действия, какими бы глупыми или плохими они ни казались, всегда являются одним из вариантов, выбранных из того ограниченного числа, которое имелось на тот момент в распоряжении руководителя. Оставшиеся могут иметь еще худшее влияние на проект, чем избранные. Без понимания существующих ограничений суждения всегда будут в большей мере выражать имеющиеся отрицательные эмоции, чем реально отражать сложившуюся ситуацию.

Источники власти

Власть (сущ.) – способность к действию или поступку; потенциальная возможность что-нибудь сделать или совершить.^[103]

Чтобы влиять на развитие событий, нужно понимать динамику политической власти. Власть в организации сосредоточивается на том, какие решения могут быть приняты кем-то единолично или под его влиянием. Задумайтесь над тем, как в вашей организации принимаются решения: если для этого нужно чье-то настоятельное требование, то от кого оно исходит? Кому позволено находиться в комнате при обсуждении решения? К чьему мнению прислушиваются? Именно эти люди в той или иной степени и обладают властью. Владение неоспоримыми властными полномочиями по принятию решений является самой основной формой власти, а доступ к процессу принятия этих решений, право задавать вопросы или предлагать идеи является альтернативной формой власти. Как уже говорилось в главе 12, предоставленная власть является наиболее очевидной формой, поскольку она дается сверху, согласно существующей иерархии. Она выражается в наименованиях должностей или в других символах старшинства. Как правило, предоставленной властью человек наделяется кем-нибудь из высших эшелонов. Вице-президент предоставляет власть кому-нибудь, кто работает непосредственно на него, а эти люди предоставляют власть тем, кто работает на них. Одним людям вице-президент может дать больше власти, другим – меньше, исходя из наибольшей пользы для достижения своих целей.

Заслуженная власть предоставляется вполне естественным образом. Поскольку репутация и способности являются субъективными понятиями (по сравнению с должностями и служебным положением), то в определении, кому эта власть достанется, играет роль мнение каждого участника проекта. Допустим, к примеру, что Тайлер работает в команде программистом. Марла и Джек высоко оценивают его мнение, а вот Хлоя – не очень. Если в команде возникнет спор, Марла и Джек, в отличие от Хлои, будут больше доверять аргументам Тайлера. В некотором смысле, Марла и Джек будут склонны к передаче части их собственной власти Тайлеру в поддержку его аргументов. Таким образом, заслуженная власть зачастую передается индивидууму посредством поведения окружающих его людей. В таком случае заслуженная власть может распределяться независимо от иерархической структуры. Например, старший менеджер одной организации может быть высокого мнения о рядовом работнике другой организации.

Хотя обычно кто-то по сравнению с другими обладает большим заслуженным доверием и властью, это оценка всегда имеет субъективный и относительный характер. В зависимости от области, в которой принимается решение, состава присутствующих в комнате людей и той власти, которой они обладают, результаты могут быть разными. Кто-то может сказать, что этим-то и интересна политика: власть постоянно мигрирует в команде, меняя свои направления, и работает в разное время за или против тех или иных людей. Поскольку власть не всегда обладает ясными очертаниями до тех пор, пока она не будет применена, разобраться в том, кто и какой властью обладает, порой очень нелегко.

Для полноты картины рассмотрим следующий список, в котором даны конкретные определения разновидностям проявления власти (данный список представляет собой упрощенную интерпретацию списка, найденного в книге Томаса Куика (Thomas Quick) «Power Plays: A Guide to Maximizing Performance and Success in Business» [F. Watt, 1985]). Я не собираюсь часто ссылаться на эти определения, но вам все же стоит разобраться, кто в организации какой властью обладает и как он этим пользуется.

 Поощрение. Возможность раздавать награды, повышения по службе, какие-то «лакомые кусочки» или любые другие явно выраженные привилегии. Поскольку люди знают о подобных властных полномочиях и стремятся попасть в число награжденных, они будут стараться как-то по-особому выстроить свои отношения с их обладателями.

 Принуждение. Управление системой штрафов и возможность угрожать наказаниями. В отличие от награждений для этой разновидности властных проявлений зачастую достаточно лишь угрозы применения, поскольку она заключается не в том, что человек получает что-то хорошее, а в том, что он не получает ничего плохого. Принуждение может выражаться в том, что человек будет просто поставлен в неловкое положение перед другими («Ты что, действительно такой глупый?»), или в каких-то сугубо официальных проявлениях – понижением в должности, ограничением обязанностей или снижением зарплаты.

 Осведомленность. Данный атрибут власти возникает из познаний в какой-то определенной области или из обладания конкретной информацией, относящейся к принимаемому решению. Человек может проявить данную разновидность власти, решая, как ему применить свои познания или как и когда довести до окружающих имеющуюся у него информацию. В простейших формах эта власть предоставляется тем, кто проявляет сообразительность, знание и способность справляться с решением проблем в любой сфере деятельности, поскольку к таким людям прислушиваются, их мнение уважают. В более сложных формах эта власть проявляется у тех, чье видение окружающего мира глубже и точнее, чем у остальных. И если вы чувствуете чью-то подвластность, то можете изменять чужое восприятие состояния проекта или общей складывающейся обстановки.

 Сложившиеся отношения. В данном случае имеется в виду, кто и в каком качестве вам знаком. Если людям известно, что вы пользуетесь поддержкой или дружескими отношениями с обладателем властных полномочий, то часть этой власти будет отражаться и на вас. Например, если вы представляетесь: «Я Стив, работаю на Билла», вы полагаетесь на власть Билла и его репутацию как на средство достижения собственных целей. Власть через отношения может также исходить от партнеров или от людей, предлагающих вам поддержку.

 Влияние. Некоторые люди обладают способностью к убеждению, которая может быть и не связана с их знанием рассматриваемой проблемы. Способность оказывать влияние на других складывается из умения общаться, самоуверенного поведения, знания эмоциональных тонкостей поведения людей и наблюдательности. Влияние может подпитываться уважением людей к вашим познаниям, основываться на доверии или просто на вашей привлекательности, уме или интересе к вам, как к личности. Влияние может быть следствием долга: кто-то, может быть, считает себя вам обязанным и полагает, что повлияв на принимаемое решение, он, таким образом, сможет расплатиться. Учтите, что влияние одних может перекрываться влиянием других, эта форма власти имеет сугубо относительный, а не абсолютный характер.

Злоупотребление властью

Если вы не представляете, что делаете, не понимаете, что, для кого и какую ценность представляет, а также как можно обеспечить функционирование этой системы ценностей, проект сам переориентируется на какую-нибудь другую цель или цели. Политические столкновения в некотором роде подобны извержению. Такая ситуация неизбежно ведет к потере ориентиров.

Джеймс Баллок (James Bullock)^[104]

Когда речь заходит о политике как о злой силе, то на самом деле чаще всего имеется в виду злоупотребление властью. Я определяю это понятие как любое действие, которое идет во вред проекту и людям, в нем участвующим.^[105] Поскольку источник власти имеет естественный характер, а ее использование в целях влияния на принятие решений и управления этим процессом является побочным продуктом общекомандной работы, такое проявление власти в принципе не может иметь вредный характер. Нельзя работать над проектом без таких личностей, которые пытаются влиять на других людей и пользуются собственной властью на благо проекта. (Фактически, как показано далее, открытые дискуссии вокруг идей снижают потребность в проведении какой-либо политики.)

Злоупотребление властью возникает на почве преследования личных интересов. Например, на рис. 16.1 индивидуальные цели лишь в малой степени совпадают с целями проекта. Большая часть энергии обладателя властных полномочий в этом случае тратится на то, что хорошо для него, а не на то, что хорошо для проекта в целом. Здесь явно виден просчет руководства и аппарата управления в увязывании индивидуальных и командных целей (и системы поощрений) с целями проекта. Ради справедливости по отношению к руководителям, следует отметить, что некоторые нестыковки в этом деле просто неизбежны. Люди живут не одним лишь проектом. У них имеются собственные побуждения, которые могут не иметь к работе никакого отношения, но которые движут людьми на этой самой работе. Роль руководства как раз и заключается в том, чтобы выявлять подобные нестыковки и находить пути минимизации их воздействия. По крайней мере, руководители должны помочь рядовым работникам так реализовать свои побуждения, чтобы это не оказывало негативного влияния на проект. В конечном счете, если значительные нестыковки все же существуют, значит, в вопросах применения властных полномочий создалась определенная натянутость. У людей возник большой соблазн работать не на проект, а на самих себя.

Рис. 16.1. Личная мотивация должна соответствовать целям проекта. Чем меньше будет соответствий, тем пагубнее окажется воздействие проводимой политики

Возможно также, что кажущиеся эгоистические проявления – это не что иное, как расхождение во мнениях о том, какие действия представляют для проекта наибольшую пользу. На рис. 16.2 показано, что у двух людей могут быть разные представления о том, как наилучшим образом достичь целей проекта. Разобраться в различиях между двумя рассмотренными случаями может быть весьма нелегко, поскольку часто бывает так, что лучшее для проекта может оказаться лучшим для одного человека в большей степени, чем для другого. Чтобы понять, когда мотивация носит чисто корыстный характер, требуется хорошее знание людей, работающих над проектом, наличие ясно выраженных целей проекта и налаженная система общения, проведения дебатов и обсуждения проблем.

Рис. 16.2. Споры о власти могут возникать из альтруистических побуждений. Два равных по положению человека могут иметь элементарные разногласияпо поводу наилучшего применения властных полномочий

Когда над проектом работает ряд небольших команд, проблемы усложняются. Как показано на рис. 16.3, если у каждой команды в отдельности имеется мотивация на какие-либо действия, не отвечающие интересам проекта, то все они будут тратить значительную часть своей энергии на то, что не ведет к общему успеху проекта. Эту структуру одинаково хорошо можно спроецировать как на индивидуальных разработчиков, так и на целые команды. Когда цели расходятся, шансы на злоупотребления властью возрастают. Такое (опять-таки) возможно, если человек, управляющий работой всех этих специалистов или команд, не будет активно работать над тем, чтобы заставить их сотрудничать и открыто улаживать конфликты интересов.

Рис. 16.3. Чем больше расхождение интересов, тем выше вероятность злоупотребления властью

Процессуальные причины злоупотребления властью

Если задуматься о злоупотреблении властью, то причины этого явления можно разделить на две группы: все, что связано с процессом, и все, что связано с мотивацией. Причины, связанные с процессом, возникают на почве ошибочных способов структурирования команды или организации и относятся к разновидностям нестыковок в управлении или руководстве. Причины, связанные с мотивацией, напрямую исходят от отдельных людей, их персональных потребностей и устремлений. Чаще всего злоупотребления властью возникают на почве некой комбинации процессуальных и мотивационных проблем.

Процессуальные причины намного опаснее мотивационных, поскольку они не изолируются в поведении отдельной личности. Напротив, процессуальные проблемы являются системными и наталкивают каждого в команде на злоупотребление властью или на ее применение в сугубо корыстных целях.

 Скрытность процесса принятия решений. Если команда знает, когда и на основании каких критериев будут приняты важные решения, а также кто будет участвовать в процессе их принятия, то вряд ли возникнет необходимость в проведении какой-нибудь хитрой политики. Каждый, кто имеет собственное мнение, будет знать, на каком форуме можно изложить свои предложения, и какие аргументы может возыметь действие. Но если процесс пойдет скрытно, будет отличаться чрезмерной сложностью или окажется непонятно, кому принадлежат решения, то каждый, кто переживает за конечные результаты, получит мотивацию к втягиванию в политическую игру. Поэтому тот, кто связан с принятием решений, влияющих на работу других людей, должен разъяснить, как они будут приниматься, кто должен быть привлечен к их принятию, какие критерии будут иметь решающее значение.

 Недостатки во взаимопонимании или общении. В командах с хорошо поставленной системой общения люди удостоверяются в том, что информация не только доведена, но и правильно воспринята, а по возможности, и согласована (см. главу 9). Чем хуже в команде развито общение, тем чаще власть употребляется во вред проекту. Если некто А и некто Б по-разному думают о целях проекта, но полагают, что у других такие же представления о целях, как и у них самих, они будут работать, мешая друг другу, даже толком не осознавая этого.

 Неявное распределение ресурсов. Если процесс распределения бюджетных средств, людей и оборудования конкретно не определен или не проводится публично, для доступа к этим ресурсам будут использоваться самые разные приемы. Все, кто обладает соответствующей властью, должны объяснять команде, по каким критериям проводится распределение ресурсов или как и когда можно вносить заявки на их предоставление.

 Недостаток ответственности. Когда людям позволяется совершать ошибки и просчеты и не нести за это никакой ответственности, применение политических методов неизбежно. Безответственность в выполнении принятых обязательств приводит к потере взаимного доверия. Без доверия люди станут применять свою власть, чтобы защититься от влияния других или избежать влияния тех, кому они не доверяют (см. раздел «Доверие строится на обязательности» в главе 12).

 Слабые или невыразительные задачи. Почти в каждом из упомянутых мною случаев злоупотребления властью имелись ссылки на желание следовать целям проекта. Подобные злоупотребления вполне возможны, если не гарантированы, при слабовыраженных (или несущественных) целях проекта. Без центра тяжести, находящегося в области целей проекта, нечего выяснять, не о чем договариваться и спорить, нечего объяснять. Даже если есть четко поставленные цели, руководитель команды должен придать им выразительность: активно их отстаивать, обновлять и пересматривать, сохраняя точность постановки, и обеспечивать направленность всех решений на их достижение.

Мотивационные причины злоупотребления властью

Независимо от того, какой философии вы придерживаетесь в отношении человеческой натуры, вполне разумно предположить, что люди мотивируют свое поведение самостоятельно. Даже совершая какие-то альтруистические действия, мы придерживаемся собственной системы ценностей при определении того, что хорошо, а что плохо в окружающем нас мире. Вдобавок ко всему мы наделены эмоциями, и нашим поведением управляют разные известные нам и не очень физиологические факторы. Мотивационные причины основаны на элементарных психологических проявлениях:

 Защита других людей. Если я позволю состояться данному решению, то люди в моей команде или мои коллеги пострадают.

 Личная выгода. Я хочу получить это повышение, поощрение или испытать чувство гордости за то, что мне удастся сделать нечто важное для меня или хорошо справиться со своими делами.

 Эгоизм. Я хочу доказать самому себе или любому другому, насколько я умен, и, возможно, удостовериться в бесспорности и полной очевидности моего интеллектуального превосходства над остальными. Этот проект должен быть, по крайней мере, не менее совершенен, чем я сам, или же он должен мне помочь скрыть чувство собственной неполноценности.

 Неприязнь или месть. Я не хочу работать с Фрэдом или я пытаюсь отомстить Фрэду за то, что «он мне сделал», работая над предыдущим проектом.

Вряд ли стоит безоговорочно считать, что все эти мотивы вредны. Проблемы возникают лишь тогда, когда вызванное ими поведение не отвечает в полной мере целям проекта. Если этой мотивацией можно управлять, не нанося вреда другим участникам проекта, то ее можно считать еще одним подспорьем в продвижении проекта. Взгляните еще раз на рис. 16.1: если два круга накладываются друг на друга не менее, чем на 90 %, значит, личная мотивация действительно в большей мере совпадает с целями проекта. Сложность работы руководителя заключается в том, что ему постоянно нужно удерживать под контролем эгоистические и корыстные проявления. Руководитель должен направлять энергию своих и командных действий на пользу всему проекту и тех, кто работает на проект, а не против него.

Предотвращение злоупотреблений властью

Лучший способ сократить проявление негативных симптомов – применять власть, увязывая эти действия с целями проекта. Если каждый обращается к одним и тем же основным целям и выстраивает собственные цели, пользуясь единым источником (см. главу 4), то любые политические напряженности будут сведены к минимуму. Хотя в отношении средств достижения этих целей могут вестись споры, все будут бороться за достижение единых результатов. Чтобы усилить эти позиции на любой стадии проекта, каждый должен быть в состоянии открыто задать следующие вопросы:

• Каковы наши цели на данную неделю, месяц, на проект в целом?

• Существует ли какой-нибудь конфликт между общими целями и целями подгруппы? Как мы можем с ним справиться или полностью его разрешить?

• Как и кем будет приниматься это конкретное решение?

• Способствует ли способ применения ваших и моих властных полномочий для решения наших общих задач или задач команды?

Даже если люди разойдутся в своих ответах на эти вопросы, их разногласия будут иметь здоровый характер. Станут очевидны истинные причины конфликта, что поможет руководству внести ясность, уточнить цели или выбрать новые (возможно, более четкие) ориентиры в присутствии людей, которых все это непосредственно касается. И наоборот, злоупотреблений властью не избежать, если цели в значительной мере устарели или у разных команд и исполнителей они радикально расходятся.

Иногда руководители сознательно ставят команды в положение соревнующихся, полагая, что дух состязания, вносимый в работу, пойдет ей на пользу. В отдельных случаях соревнование действительно может сработать на пользу делу, но оно вносит в работу организации дополнительную нестабильность, требуя более сильного и активного руководства для удержания ситуации под контролем. В этом нет ничего особенного. К примеру, у каждой спортивной команды есть стартовый и резервный составы. В ходе каждой тренировки тренер пытается устроить внутреннее соревнование за место в стартовом составе, одновременно поддерживая единый командный дух. Хорошие руководители активно укрепляют правильные взаимоотношения и следят за правильным поведением участников процесса, сохраняя при этом разумный баланс сил.

Однако в условиях бесконтрольности у отдельных личностей, имеющих конкурирующие интересы, будет больше поводов для применения политической власти в достижении корыстных целей. Вместо того чтобы соревновательный порыв ориентировался на чувство реальной деловой конкуренции, он будет направлен на коллег и подчиненных из собственной команды. С точки зрения целостности проекта такая обстановка носит разлагающий характер. Власть не будет направлена непосредственно на успешное завершение проекта. Без решительных руководящих усилий по перенацеливанию команды и оздоровлению рабочей обстановки, команда может скатиться вниз. Любые не пресеченные (или проигнорированные руководством) разлагающие или корыстные проявления подталкивают на подобные действия и других. Вскоре от былого доверия, способствующего эффективной работе, не останется и следа, поскольку повсеместно будут возникать подозрения относительно скрытых мотивов, имеющихся у руководителей и коллег по команде.

Способы решения политических проблем

В данном разделе я воспользуюсь двумя предположениями: во-первых, что у проекта имеются ясные цели, во-вторых, что эти цели служат мотивацией для того, что вы пытаетесь достичь. Если состоятельность обоих предположений или хотя бы одного из них для вас сомнительна, значит, этот раздел вам еще пригодится, а от вас потребуются дополнительные усилия, поскольку на данный момент у вас недостаточно средств для достижения успеха.

Описываемый здесь процесс в большей мере касается серьезных проблем с применением властных полномочий и таких ситуаций, в которых вам требуется больше власти, чем имеется на данный момент. Чем серьезнее проблема, тем тщательнее нужно продумать вопросы применения власти. Чем она менее серьезна, тем больше предлагаемых здесь шагов можно бегло просмотреть или вовсе пропустить.

Выясните, что вам нужно

Единственный способ успешного решения политических проблем заключается в выяснении своих потребностей и в разработке плана по их удовлетворению. Обычно потребности выглядят следующим образом:

• ресурсы (деньги, время, персонал);

• полномочия в принятии решений;

• возможность повлиять на решение, находящееся в чьей-то компетенции;

• корректировка чьих-то целей в поддержку ваших или приведение в соответствие с вашими целями;

• корректировка ваших собственных целей для их лучшей согласованности с целями других участников процесса;

• консультации, обмен опытом или поддержка.

Несмотря на то что вы определили круг своих потребностей, готовьтесь проявить гибкость. Даже если вы решили, что вам необходимы дополнительные ресурсы, в процессе их изыскания не отвергайте советы тех, кто сумел справиться с решением своих задач без привлечения дополнительных ресурсов. Стремясь к увеличению бюджета или сроков работы, вы можете додуматься до какой-нибудь новой идеи, позволяющей достичь поставленных целей и без дополнительных ресурсов. Поэтому не следует зацикливаться на потребностях как таковых: они представляют собой всего лишь средства к достижению целей проекта.

Управление руководством

Наиболее подходящим временем для анализа этой разновидности политических потребностей является тот самый момент, когда цели уже определены. Когда вы сидите за одним столом со своим руководителем и согласовываете свои обязательства на следующую неделю или месяц, самое время рассмотреть вопрос о достаточности властных полномочий для выполнения намеченной работы. Должны быть выявлены любые средства обеспечения, в которых вы нуждаетесь, но не имеете на данный момент, а ваш руководитель должен наметить план, как помочь вам с их получением. В некоторых организациях это называется управлением руководством, поскольку вы должны направлять управляющие усилия не вниз, а вверх по иерархической лестнице. Выяснение своих потребностей, которые должны быть удовлетворены вашим руководством, и является первым шагом на пути успешного управления своими руководителями.

Последующие шаги управления руководством большей частью заключаются в повторении этого процесса по необходимости через определенные интервалы времени. Если вы сможете синхронизировать усилия со своим руководителем и с руководителем своего руководителя во всех своих делах и в получении всего необходимого для этого, обеспечив при этом решение единых задач, значит, вы на правильном пути.

Самый простой способ управления руководством заключается в вовлечении своего руководителя в дискуссию, во время которой нужно предложить конкретизировать следующие моменты.

• Каких действий в моих интересах мне следует ожидать от вас, моего руководителя (например, распоряжений, предупреждений о том, что я должен знать, поддержки моих решений, указаний на те области, в которых я должен совершенствоваться).

• Какие ресурсы мне понадобятся для достижения поставленных целей и у кого мне нужно их требовать.

• На каком уровне и с какой периодичностью мне требуется ваше участие (Вообще не требуется? Ежеквартальное подведение итогов? Ежедневный доклад о состоянии дел? Еженедельные встречи с глазу на глаз? Все это требует уточнения.)

Выяснив все как можно раньше, вы точно узнаете, на какую поддержку следует рассчитывать и откуда, скорее всего, следует ожидать проблем. Вы должны забить тревогу, если ваш руководитель проявляет безразличие, неопределенность или сопротивляется передаче любых ваших запросов. Это означает, что вам либо придется показать все, на что вы сами способны, либо настроиться на неудачный исход, смирившись с тем, что ваш руководитель не очень-то заботится о ваших взаимных интересах.

Кто обладает полномочиями на то, чтобы удовлетворить все ваши потребности?

Для каждого вида требуемых властных полномочий следует определить человека, который может вам их предоставить. Для начала вполне подойдет иерархическая или организационно-штатная структура, но ее следует использовать лишь для освежения памяти обо всех действующих лицах и исполнителях (рис. 16.4). Затем следует поспрашивать окружающих и выяснить, кто в наибольшей степени отвечает за те или иные разновидности решений (в небольших командах все намного очевиднее, но если вы не уверены, то лучше у кого-нибудь спросить). Привлеките людей, которые обязаны помочь вам во всем разобраться: своего руководителя, коллег или подчиненных. Чтобы определить нужных вам людей, несколькими разговорами, пожалуй, не обойдешься. Иногда лучше поискать информацию такого рода на стороне, поскольку вам вряд ли захочется внепланово беспокоить нужных людей. (Избегайте странных поступков, приводящих, к примеру, к такому диалогу: «Привет, Фрэд, это ты отвечаешь за распределение новых ноутбуков?» – «Да, а что?» – «Да нет, мне просто интересно. Пока».)

Рис. 16.4. Кто является обладателем соответствующих властных полномочий – зависит от ситуации. При этом не обязательно отдавать приоритет иерархии организационно-штатной структуры. Сотрудник среднего звена может обладать большими полномочиями в конкретном вопросе, чем его непосредственный начальник

Восприятие их точки зрения

Начните изучение человека, который обладает нужными вам полномочиями, с определения его целей. В слаженной команде это сделать проще, поскольку его цели действительно совпадают с целями проекта и соответствуют тому руководящему положению, которое он занимает. Учтите его наклонности, мнения и предпочитаемые им способы принятия решений. Чем лучше ваши взаимоотношения и больше опыт совместной работы, тем проще это сделать.

Взгляните на ситуацию с его точки зрения, постарайтесь понять, насколько в его взгляды вписываются ваши потребности и цели. Свяжите ваш запрос с высокоуровневым проектным требованием или целью, с которой он обязан считаться. Поймите, что вместо того чтобы сказать: «Мне нужен другой программист», вы можете со всей ответственностью заявить: «Для достижения целей X и Y моей команде нужен другой программист. В нашем проектном плане не предусмотрены три требования, пришедшие на прошлой неделе, в результате чего наши цели теперь находятся под угрозой». Не стоит лгать или вводить человека в заблуждение. Будьте готовы к тому, чтобы пересмотреть свои потребности, если требуемым ресурсам в проекте есть лучшее применение. (Но в таком случае у вас могут спросить, какие цели и устремления должны подвергнуться корректировке в свете лучшего варианта использования этих ресурсов. «Я полагаю, что наши цели должны претерпеть изменения. Теперь цель X утратила свою актуальность. Данные ресурсы лучше направить на достижение цели Z». Мудрый начальник должен вас отметить за столь проектно-ориентированное мышление.)

К чьему мнению они прислушиваются и кому доверяют?

Если вы поняли, что Фрэд обладает нужными вам полномочиями, постарайтесь понять, кто может оказать на него влияние. Возможно, это будет человек, равный ему по положению, какая-нибудь выдающаяся личность в его команде или его собственный начальник. Возможно, в некоторых определенных решениях в этой роли можете выступить вы сами. Подумайте, как использовать влияние этих людей в вашем случае. Если у вас с влиятельными людьми сложились хорошие отношения, поделитесь с ними своими размышлениями и спросите их мнение.

Не прибегайте к хитрости, обману и сомнительным поступкам. Лучше выставьте свои аргументы, как будто общаетесь с Фрэдом, и попросите их оценить. Этим людям могут быть известны факты, о которых вы и не подозреваете, у них может быть своя точка зрения, которая наведет вас на новые размышления (включая перемену мнения), или они просто могут дать совет, как в вашем случае следует вести разговор. Даже если у вас не сложились хорошие отношения с влиятельными людьми, вы все равно можете спросить их мнение или понаблюдать, как им удается убеждать Фрэда или предлагать ему что-то.

Иллюзия коллективной власти

Иногда создается впечатление, что необходимые вам ресурсы распределяются группой людей. Соответствующие решения могут приниматься на каких-нибудь встречах или в процессе работы какого-нибудь комитета. Никогда не фокусируйте свое внимание на группе: всегда делите ее на отдельные личности и разбирайтесь, кто в этой группе каким влиянием обладает. Независимо от того, как все происходит, на встречах редко что-нибудь решается. Зачастую люди приходят на подобные обсуждения, имея вполне определенное мнение и союзников, готовых его поддержать, а на самой встрече выполняется последовательность вполне предсказуемых манипуляций. Непосвященным эти встречи могут показаться вполне живыми и активными, но для тех, в чьих руках находится власть, многие аргументы абсолютно предсказуемы как по своей природе, так и по конечным результатам. Чтобы завершить дискуссию, заранее готовятся вполне ожидаемые результаты (возможно, так, как описывается в этом разделе) и хорошие контрдоводы.

Чем выше важность и спорность решаемого вопроса, тем больше сил нужно приложить для обработки нужных людей. Всей группе подбрасывать идеи вслепую можно только в том случае, если есть уверенность в собственной логике, влиянии и искусстве общения, причем всего этого достаточно для того, чтобы повести в направлении, которое, по вашему мнению, наилучшим образом отвечает интересам проекта, всю аудиторию, полную людей, наделенных властными полномочиями и имеющих разные мнения.

Оценка обстановки

Объединяя все, чему вы научились при чтении данной книги, нужно оценить шансы на успех в удовлетворении ваших потребностей. Вполне вероятно, что при данной структуре власти удовлетворить конкретные потребности будет невозможно. Причем вряд ли чей-то отказ будет играть большую роль, чем ограничения, связанные непосредственно с процессом разработки или деловыми интересами. В процессе оценки обстановки вы должны уяснить, что властные и иные структуры имеют ряд ограничений.

 Обладает ли кто-нибудь нужными вам полномочиями? Может быть, запрашиваемые ресурсы просто недоступны. Возможно, все они брошены на решение другой задачи (и не могут быть перераспределены), или же организация вообще не располагает подобными ресурсами. Если вы запрашиваете что-либо, что не вписывается в возможности организации, будьте готовы привести абсолютно неотразимые доводы. Разделите один крупный запрос на ряд мелких и расположите их по приоритетам. Возможно, эти мелкие запросы будут удовлетворены решениями разных людей или последовательно, в течение некоторого времени.

 Удавалось ли ранее получать подобную поддержку? Обратитесь к уже имеющемуся опыту в получении подобных полномочий. Что было в предыдущих случаях? Чего удалось добиться, а чего нет? Если опыт ведения подобной политической игры отсутствует, нужно найти кого-нибудь, у кого он есть, и попросить дать дельный совет. В противном случае шансы на успех не будут стопроцентными: кто бы ни обладал искомой властью, он мог уже пообщаться с людьми, которые добиваются того же самого, что и вы, что заранее ставит вас в невыгодное положение.

 Насколько удачными были попытки других заручиться такого же рода поддержкой у этого человека? Если никому еще не удавалось убедить руководителя команды изменить методологию разработки продукта, готовьтесь к тому, что вам придется быть первопроходцем. И наоборот, если вы пытаетесь пойти по чьим-то стопам, выясните, как им это удалось, и изучите их опыт.

 Насколько сильны ваши доводы? Бывали времена, когда на чашу весов приходилось класть всю свою репутацию. Я был настолько убежден в своей правоте, что использовал всю меру своей ответственности, чтобы убедить людей в значимости своего запроса. А иной раз я не был столь же уверен в важности своего запроса и выстраивал свои доводы под более подходящим углом. Разберитесь со своей позицией и реальным отношением к запрашиваемым ресурсам. Приведите в порядок имеющиеся доводы, расположив их по убедительности, сделайте упор на самые сильные из них.

 Какие подходы или приемы общения могут сработать наилучшим образом? Может быть, ворвавшись в чей-то офис и заявив: «Мне надо то-то и то-то», вы скорее добьетесь желаемого результата, чем накатав справку на десяти страницах или подготовив какую-нибудь презентацию? Здесь не существует строгих правил: следует учесть порядки, установившиеся в команде и личности участников событий. Что вы подметили за предыдущий период работы?

 Кто еще претендует на получение тех же ресурсов? Иногда совершенно ясно, кто будет претендовать на те же ресурсы. Бюджетные средства всегда ограничены и распределяются вашим начальством между равными вам по положению. Если у вас сложились хорошие взаимоотношения, то можно собраться всем коллегам и обсудить различные мнения и доводы, постаравшись совместными усилиями выбрать лучший для команды вариант (вообще-то вести подобный разговор должен ваш общий руководитель, но если он этого не делает, возьмите все на себя). Если взаимоотношения оставляют желать лучшего, нужно рассчитывать на собственные силы. Подумайте, какими могут быть доводы ваших конкурентов, и как можно объективнее оцените их в сравнении с вашими. И, наконец подумайте, как другие будут воспринимать ваш образ действий. Ими овладеет чувство расстройства? Злости? Они почувствуют, что вы их обскакали? Пресекайте подобные явления на корню. Переговорите, по возможности, со всеми заинтересованными людьми или выставьте свои доводы таким образом, чтобы свести к минимуму негативную реакцию.

 Стоит ли вообще ломать копья? Признайтесь себе в том, что нужные ресурсы у вас уже есть. Использование собственного влияния и других приемов политической борьбы будут стоить вам времени, достойного лучшего применения. Поймите, что ваша задача – максимально эффективно использовать имеющиеся ресурсы. Вы можете, к примеру, знать, что существует куда более важный запрос, необходимость в удовлетворении которого появится в ближайшем будущем, и может быть стоит приберечь свою энергию до лучших времен.

 Вам может навредить ваша неосведомленность. Всегда нужно понимать, что существуют такие уровни власти и политики, которые не видны с вашей колокольни. Чем крупнее организация, тем актуальнее это утверждение. Выше вас на два или три уровня (при многоуровневой системе управления) может вестись целый ряд сражений и споров вокруг проблем, о которых вы даже не подозреваете. Ваши коллеги, перед которыми поставлены другие цели, используют собственное влияние на тех же обладателей властных полномочий, что и вы. Подумайте, что может твориться выше и вокруг вас, и поищите такие источники информации, которые могут расширить ваш кругозор.

Тактика влияния на власть предержащих

После всесторонней оценки обстановки наступает время действовать. Для подхода к организационной политике и использования в своих целях властных полномочий, принадлежащих другим людям, существуют весьма простые тактические приемы. Описываемая здесь тактика является наипростейшей и наиболее распространенной; затем последуют ссылки и на другие политические методы.

Непосредственный запрос

Непосредственный запрос – это самое простое из всех возможных действий: вы обращаетесь к обладателю необходимых вам властных полномочий и высказываете ему свою просьбу. В зависимости от избранного вами подхода и приема общения (вернитесь к предыдущему перечню) вы можете обставить все в форме простого разговора, послать запрос по электронной почте или высказать все на совещании, собранном по этому поводу. Чем формальнее вы подойдете к запросу, тем больше шансов на то, что в его обсуждении будут участвовать другие. Чем меньше будет формализма, тем прямее может быть как разговор, так и сам запрос. На рис. 16.5 буквой А обозначен человек, обладающий необходимой вам властью, а буквами Б, В и Г – другие люди из вашей команды.

Рис. 16.5. Непосредственный запрос

Неформальная беседа

Неформальная беседа – это общий вариант непосредственного запроса. Если вы и ваш коллега Б претендуете на одни и те же ресурсы и ведете общее обсуждение данного вопроса, вы просите А встретиться с вами обоими и решить вопрос коллективно. Команда, имеющая четко поставленные цели и хорошо организованное взаимодействие, решает подобные вопросы естественным и неформальным образом. Люди доверяют друг другу, работая над воплощением в жизнь общих проектных планов, и охотно идут на справедливые уступки, даже если при этом приходится поступаться собственной властью или полномочиями. Сильные лидеры и руководители поощряют подобное поведение, поскольку оно сокращает потребности в их вмешательстве. Команда со временем привыкает к решению проблем собственными силами (например, привыкает воспроизводить точку зрения руководителя А даже в его отсутствие) и привлекает А только в том случае, если сложность решения действительно требует участия руководителя.

Использование влияния (атака с флангов)

Вместо того чтобы убедить А, полагаясь лишь на собственное влияние, заручитесь поддержкой других людей из вашей организации, чтобы они озвучили те же доводы и мнения. Тщательно подберите тех, кто имеет наибольшее влияние на А. Если вы чувствуете слабость собственного влияния, возможно, нужно привлечь на помощь сразу нескольких людей.

В военной терминологии это называется атакой с фланга. Вместо удара в лоб, добейтесь преимущества, зайдя на цель со стороны. Тогда А придется считаться не только с вашими доводами, но и с аргументами, поступившими от одной или нескольких других влиятельных личностей. Когда подобные доводы поступят от людей, имеющих равное с А или более высокое положение, отклонить их будет намного сложнее. (Тем не менее будьте осмотрительны, заручаясь мнением людей, которые занимают более высокое положение, чем А, в его отсутствие. Это может быть воспринято как нарушение субординации и попытка подорвать авторитет А. Все зависит от порядков, сложившихся в организации, и от характера самого А.)

Дополнительно эти действия могут сочетаться с непосредственным запросом (как показано на рис. 16.6.). Другие возможные варианты включают способы использования требуемого вами влияния. Возможно, в присутствии Б, В и Г не возникнет необходимости или даже вообще не придется вести с А разговор по рассматриваемому вопросу. Поскольку вы пользуетесь их благоприятным мнением, можете переговорить с ними и обратиться к А со следующей фразой: «Я думаю, нам нужно исключить данную функцию. Я поговорил с Б, В и Г, и все они согласны со мной по этому вопросу». Конечно же, следует как можно точнее передать все ими сказанное и всегда стараться уладить вопрос в присутствии этих людей (намеренно возвращаясь к предыдущему разговору).

Рис. 16.6. Атака с флангов

Многоступенчатое влияние

Когда вы можете вступить в контакт с нужными людьми, опуститесь на одну ступень вниз по цепочке влияния или по иерархической лестнице. Если В – единственный, к кому может прислушаться А, но вы не в состоянии добиться аудиенции В, найдите людей, имеющих наибольшее влияние на В. Затем вступите в контакт с ними и изложите суть своего вопроса. С этой позиции вы можете двинуться дальше, до тех пор, пока ваше влияние не достигнет нужной цели (рис. 16.7).

Рис. 16.7. Многоступенчатое влияние

Косвенное влияние

В некоторых случаях лучше всего оказать влияние на власть предержащих путем запуска какого-то механизма, оставаясь при этом за сценой. Возможно, А находится двумя и более ступенями выше в вашей организационно-штатной структуре, и он может негативно отреагировать на прямое обращение к нему людей вашего уровня. Или же вы просто не нравитесь А, или он в данный момент на вас за что-то обижен (и вы думаете, что он не сможет отнестись к вам объективно).

В подобной ситуации следует заручиться поддержкой другого человека, чтобы он сделал запрос за вас. В этой роли может выступить ваш непосредственный начальник, коллега по команде или работающий на А человек, которому случается оказывать влияние на А в подобных вопросах.

Наименее изощренным способом решения задачи является проведение переговоров. Поговорите с В и посмотрите, согласится ли он с вами. Если согласится, спросите, не смог бы он поговорить об этом с А (рис. 16.8). Когда он пойдет к А, он не должен вводить А в заблуждение или лгать: он должен привести доводы, исходя из собственных позиций, поскольку он и в самом деле согласился с вами и с правомерностью вашего запроса. Если затем А потребует переговоров с вами или вы сами чуть позже попросите его аудиенции, ваши доводы будут полновеснее за счет влияния, оказанного В.

Рис. 16.8. Косвенное влияние

Совещания

На совещаниях создается довольно сложная политическая ситуация. Любой присутствующий может высказаться и задать вопросы, оказывая тем самым такое политическое влияние на дискуссию, которое может осложнить ситуацию. Если предстоит принимать какие-нибудь сложные решения, то до начала совещания нужно обязательно оценить, кто на нем будет присутствовать. Перед совещанием подумайте о том, какие вопросы на нем, скорее всего, будут подняты и какие варианты ответов захочется услышать каждому из присутствующих. Хорошее знание участников позволит дать неплохую оценку ожидаемому развитию событий и самостоятельно ко всему подготовиться. Если такой возможности нет, нужно навести справки. Попросите влиятельных людей, чье присутствие ожидается, поделиться своим мнением до начала совещания. Изучите заранее их отношение к обсуждаемым проблемам и самые важные вопросы, которые могут быть заданы, а затем либо внесите изменения, если это возможно, либо выстройте линию защиты существующего у вас плана. Если вы сами готовите повестку дня, внесите в нее соответствующие изменения.

Иногда инициатива собрать совещание может быть единственным средством поднять вопрос применения властных полномочий. Электронная почта для решения сложных и острых проблем вряд ли подойдет. Поводом для совещания может стать определение, что Салли нужно одновременно услышать мнение Боба и Майка, дабы убедиться, что к вашим рекомендациям стоит прислушаться. Эффективное проведение совещаний является своего рода искусством (см. главу 10), но в данный момент нужно уяснить, что чем лучше вы подготовитесь к ответам на возможные вопросы и к предстоящим дебатам, тем легче будет вести совещание без эксцессов и в нужном для вас направлении (рис. 16.9).

Рис. 16.9. На совещании может возникнуть непредсказуемая политическая ситуация

Пускай они думают, что это их идея

Изредка бывает так, что на почве чьего-то эгоизма вы можете высадить и прорастить свое собственное зерно. Все происходит примерно так: вы полагаете, что напрямую ваш запрос вряд ли пройдет. Поэтому, как только обнаружится проблема, вы затеваете дискуссию и запрашиваете помощь в поиске решения. Собственных ответов на поставленный вопрос вы не предлагаете, а вместо этого задаете вопросы и расставляете вехи, постепенно подводящие присутствующих к нужному для вас результату. Этот прием, как и всякая подтасовка, легко может привести к неприятным последствиям, тут требуются деликатность и мастерство импровизации, которыми обладают далеко не все. И все же я допускаю, что иногда этот номер вполне может пройти, в особенности с теми начальниками, которые любят считать, что они всегда правы.

Дополнительные источники

В предыдущий перечень попали лишь основные тактические приемы. Книгами по политической тактике забито множество книжных полок. Лучшим унифицированным средством на эту тему я считаю книгу Роберта Грина (Robert Greene) «The 48 Laws of Power» (Penguin 2001), но должен предостеречь: после прочтения книг Дейла Карнеги вроде «How to Win Friends and Influence People» (Pocket, 1990) вы почувствуете позывы применить все усвоенное на практике. Книга Роберта Сайолдини (Robert Cialdini) «Influence» (Perrenial, 1998) больше относится к маркетингу, чем к офисной политике, но некоторые изложенные в ней физиологические принципы могут быть применены и в этой сфере.

Знание игрового поля

Последние рассуждения о руководстве проектом касаются игрового поля для проведения политических игр. Правила игры, которым будет следовать команда (как приобретается власть, как она применяется и распределяется), определяются теми людьми, в чьих руках сосредоточено больше власти. Неэтичные поступки, вроде различного рода подтасовок и введения окружающих в заблуждение, должны выявляться и наказываться теми, кто контролирует ход политического процесса. В сферу их интересов должно входить поддержание относительно честной ситуации на игровой площадке, когда нужные люди могут пользоваться политической системой в целях благополучного завершения проекта.

Однако если власть предержащие не заботятся о создании справедливой обстановки на игровом поле, то постижение правил игры и наведение порядка должно лечь на плечи одного из игроков. Вы должны либо предпринять попытку изменить правила игры, либо принять их в существующем виде. Если практика ввода в заблуждение и ведения нечестной игры является обычным делом, никакой закон не запрещает вам подыскать другую работу. Если вы хотите остаться в этой жесткой среде, то не стоит полагаться на чей-то необоснованный альтруизм. Я также не рекомендую следовать самым низменным стандартам и копировать чужое поведение: вы должны выбрать собственные морально-этические нормы. Но я хочу сказать, что вам обязательно нужно знать, какую игру и с кем вы ведете.

Создайте собственное игровое поле

Независимо от всех политических неприятностей, вы, как руководитель проекта, должны контролировать свое собственное игровое поле (рис. 16.10). Под вашим контролем находится также распределение властных полномочий в команде. У вас на выбор есть два основных варианта: превратить свое игровое поле в площадку для безопасной и честной игры, в которой участвуют самые умные люди, или позволить влиять на ваши дела проблемам и симптомам, характерным для большой команды. Последний вариант проще: можно вообще ничего не делать. А первый требует твердого руководства и применения множества тактических приемов, рассмотренных в данной книге.

Рис. 16.10. У вас всегда есть полномочия на определение собственного игрового поля

Хорошие руководители всегда находят способ защиты своей команды. Наряду с той истиной, что росту команды способствует опыт преодоления трудных ситуаций, хороший руководитель обеспечивает достаточную степень защиты людей, позволяя им эффективно работать без сложных испытаний и поиска возможных путей выхода. Кроме того, если и у вас имеется толковый руководитель, то он уберегает вас от проблем и ситуаций, активно работает в ваших интересах, создавая среду, в которой вам легче трудиться. Для осуществления подобного упреждающего руководства на любом иерархическом уровне требуется более интенсивный и зрелый подход к своей работе, но в этом и заключается суть хорошего руководства.

Поэтому если ваш руководитель не удостаивает вас частыми обращениями, то не стоит всем об этом сообщать. Только руководитель вправе решать, как управлять собственной командой. Не стоит переносить в свою работу отношения, привычки или тактику действий, которые вы считаете вредными. Объясните своей команде различия в стиле работы или в позициях, но не следуйте тому поведению, которое считаете непроизводительным.

Большинство советов, приведенных в этой главе и книге, применимы к любому уровню организационной иерархии. Если на вашем уровне цели не имеют достаточно четкого определения, вы всегда сможете определить их для своей команды. Если на вашем и на вышестоящем организационных уровнях отсутствует четко определенный порядок распределения ресурсов, вы можете установить собственный порядок на порученном вам участке работы. То же самое относится к планированию проекта, общению или приему решений. Если от предпринятых усилий вы сами не всегда будете получать прямую выгоду, то они, безусловно, положительно отразятся на работе всей команды. Ей будет легче работать продуктивнее, поскольку вы обеспечите эффективную структуру, отсутствующую во всей остальной организации.^[106]

В конечном счете, упреждающее руководство в вашей собственной сфере влияния является наилучшим способом укрепления собственного источника властных полномочий. Первоначально отличие ваших методов работы от методов вашего руководства может привести к утрате благосклонности с их стороны. Но со временем людям придется по вкусу созданное вами игровое поле. Они более охотно и продуктивно, чем с другими руководителями, будут работать с вами и на вас. В отличие от фактического положения всей остальной организации, качество работы вашей команды будет неуклонно расти.

Выводы

• Политика является естественным следствием человеческой природы. Когда люди работают в единой группе, существует некоторый вполне определенный объем властных полномочий, который должен быть распределен между разными людьми, имеющими разные устремления и побуждения.

• У всех руководителей есть политические ограничения. У каждого руководителя, генерального директора или президента есть коллеги и начальники, которые ограничивают его возможности по принятию решений. Вообще-то, чем больше власть человека, тем сложнее по структуре являются ограничения, в условиях которых ему приходится работать.

• Существует множество разновидностей политической власти, включая поощрения, принуждения, манипулирование осведомленностью, сложившимися отношениями и влиянием.

• Злоупотребления властью возникают, когда она применяется не по назначению, то есть не служит достижению целей проекта. Свой вклад в злоупотребления властью вносят отсутствие ясности в определении целей, неразбериха в распределении ресурсов, неопределенность процесса принятия решений, отсутствие взаимопонимания.

• Для решения политических проблем нужно выяснить имеющиеся потребности. Определите тех, кто обладает необходимыми ресурсами, а затем оцените свои возможности по их востребованию.

• Если вы участвуете в управлении проектом, значит, вы определяете вокруг себя поле политической игры. И вам решать, насколько проводимые на нем игры будут разумными и справедливыми.

Упражнения

1. Возможно ли работать с другими людьми и не проводить абсолютно никакой политики? Подумайте о рабочей среде с самой благоприятной политической обстановкой. Что предопределило возможность ее создания?

2. Какой разновидностью власти вы больше всего пользуетесь? А какой разновидностью пользуетесь меньше всего?

3. В своей книге «Profiles in Courage» Джон Ф. Кеннеди (John F. Kennedy) приводит истории о мужественных сенаторах, которые принимали решения, в которых были уверены, несмотря на политические последствия (например, низкие шансы на переизбрание). Что лучше, попытаться и приобрести власть, делая то, во что веришь, или делая то, что будет нравиться другим обладателям властных полномочий? Есть ли здесь некая середина? Как руководитель проекта, как вы можете повлиять на приобретение власти вашими подчиненными?

4. Когда вы возвращаетесь домой, к семье на время отпуска, то как выглядит структура власти? Как люди реагируют на происходящие политические события? Каким бы советом из этой главы вы могли бы воспользоваться применительно к вашей семье? Чему можно научиться в своей семье и применить в рабочей обстановке?

5. Кого вы считаете политическими союзниками в своей организации? Как у вас возникли такие отношения? Можете ли вы найти способ применения уроков, извлеченных из создания таких союзнических отношений к формированию отношений с новым людьми, присоединившимися к вашей команде? Есть ли люди, которых на данный момент можно считать вашими врагами?

6. В этой главе приведен ряд тактических приемов влияния на власть. Какие еще тактические приемы могут прийти вам в голову? Распределите все известные вам тактические приемы по степени их рискованности и действенности.

7. Просмотрите как можно больше соревновательных реалити-шоу по телевидению, таких как, к примеру, «Остаться в живых». Как правила игры влияют на характер используемой людьми политики и власти?

8. Придумайте свое собственное реалити-шоу, где правила игры способствуют проявлению более позитивной политики.

Приложение. Руководство по работе дискуссионных групп

Независимо от того, насколько у вас развито воображение, вы не можете вести живую дискуссию с неодушевленным предметом (а если можете, то следует обратиться к психиатру). Книги, конечно, обладают волшебной силой, но ни одна из них не может вести диалог. Если вы собираетесь что-нибудь изучить, то лучше всего найти людей, интересующихся той же темой, и изучать ее вместе. Для осуществления этой затеи я составил для вас следующее удобное руководство.

Представление дискуссионной группы по управлению проектами

Самый простой путь принять участие в дискуссии – присоединиться к работе одной из уже существующих групп. Если вы ищете бесплатный вариант, то позвольте мне рассказать о дискуссионной группе по управлению проектами PM Clinic. Несколько лет назад я учредил форум для руководителей проектов под названием pmclinic. Нам удалось избежать основных неприятностей, связанных с ведением дискуссии по электронной почте (перебранок, пустых советов, слишком интенсивного или слишком скудного потока сообщений), предоставив довольно простую структуру. Каждый понедельник я рассылаю по электронной почте описание какой-нибудь ситуации – реальной проблемы, обрисованной одним из участников форума, – и мы в течение недели обсуждаем эту ситуацию. Люди предлагают свои советы, дают рекомендации, делятся полезными историями о былых сражениях и стараются как можно больше преуспеть во взаимном обучении. Форум стабильно работает вот уже около пяти лет, обзавелся 1000-ю участников и до сих пор имеет невероятно высокое соотношение полезной и бесполезной информации.

Чтобы присоединиться к PM Clinic, просто перейдите по этому адресу:

http://www.scottberkun.com/forums/pmclinic

Любой из вас может предложить ситуацию для дискуссии, равно как и внести свой вклад в ее разрешение. Если вы понаблюдаете за форумом в течение двух недель, то почувствуете атмосферу его работы. Если вы посылаете вполне продуманные сообщения, относитесь к форуму с уважением и обладаете чувством юмора, то сможете легко вписаться в наш формат. (А если не впишитесь, то мы вас выгоним быстрее, чем вы сможете произнести слова «руководство проектами».)

Как организовать свою собственную дискуссионную группу

Можно, конечно, принимать участие в работе крупных дискуссионных групп, вроде PM Clinic, но учиться лучше в составе небольших групп. Лучше всего воспринимаются разговоры за круглым столом, поскольку в них достаточно небольшое число участников, чтобы знать всех лично, и достаточно большое, чтобы имелись разнообразные мнения и поддерживалась оживленная беседа. И самое лучшее заключается в том, что небольшие группы проще организовать.

С другой стороны, у вас могут быть специфические интересы, скажем веб-разработка или определенный стиль управления, и желание сосредоточить внимание группы в одном направлении. В таком случае вы можете организовать многочисленную дискуссионную группу наподобие PM Clinic, но сконцентрировать ее работу на определенных взглядах на ведение руководства, даже на том стиле руководства, который укоренился конкретно в вашей компании.

В любом случае для начала понадобятся три вещи:

• Час или более в неделю.

• Книга или ряд тем для обсуждения.

• Другой заинтересованный человек.

Поскольку вы держите в руках эту книгу, то вы уже на правильном пути. Все, что осталось – найти время и людей.

Поиск людей

Интернет упрощает эту задачу. Если составить приглашение, внушающее доверие, и послать его в нужное место, то людей будет хоть отбавляй. Безусловно, проще всего найти людей, заинтересованных участием в работе дискуссионной группы, на работе или учебе. Если вы читаете эту книгу, чтобы преуспеть в своей работе или в освоении учебного курса, то оглядитесь вокруг. Проведите опрос своих знакомых и определите круг заинтересованных людей.

В качестве других мест поиска можно рассматривать:

 Вашу компанию. Если исключить вашу команду, есть ли в организации какая-нибудь общая рассылка, которую можно использовать для привлечения людей? Если есть учебная организация или знакомый кадровик, они могут быть заинтересованы в распространении объявления о вашей дискуссионной группе.

 PM-clinic. Довольно большой процент участников дискуссионной группы PM Clinic прочитали эту книгу или заинтересованы в ее прочтении. Вам, вероятно, придется вместо личного общения создать виртуальную группу, но для пробы своих сил – это место одно из самых доступных.

 Блоги, посвященные управлению и программному обеспечению. Простой поиск в Интернете поможет вам найти множество людей, уже создавших сообщества, которыми вы можете воспользоваться. Нужно вежливо сообщить им о ваших намерениях и спросить, не могли бы они разместить у себя ваше объявление.

 Группы по изучению процессов управления и разработки программного обеспечения. В большинстве крупных городов есть сообщества, организующие группы подготовки, нацеленные на изучение менеджмента, управления проектами или разработки программного обеспечения. Институт руководства проектами – PMI (project management institute), имеет местные отделения в большинстве городов и может посодействовать в распространении вашего объявления по электронной рассылке. Сообщество Personal MBA group (http://personalmba.com/) включило книгу «Making Things Happen» в список рекомендуемой литературы и располагает обширной социальной сетью.

Набор группы

От того как вы начнете свое объявление, будет зависеть и то, кто зарегистрируется для работы в вашей дискуссионной группе, и то, кто останется работать в ней дальше. Как бы тривиально это ни звучало, но ваше объявление сообщает людям, насколько хорошо вы умеете общаться, какой из вас организатор и стоит ли на это объявление откликаться. Нужно составить короткое объявление, разумное, забавное и понятное. Можете свободно воспользоваться следующим вариантом:

Хотите быстро освоить искусство лидерства и руководства командами? Мы набираем небольшую группу заинтересованных в совершенствовании навыков руководства командами и менеджмента. Предполагается, что будут проводиться еженедельные встречи в местном кафе (или виртуальное общение по электронной почте) с обсуждением одной из глав изучаемой книги, обменом опытом «военных действий» на этом поприще и задушевным разговором, что позволит всем нам набраться ума-разума в данной области. Если вы заинтересовались, то откликнитесь кратким сообщением по электронной почте, при этом укажите уровень своего образования и опыт работы, продемонстрируйте легкость характера и присутствие чувства юмора и выскажите свои предложения насчет книги или статьи, достойной для разбора в дискуссионной группе.

На подобное объявление откликнется немало людей, и вы сможете отфильтровать неподходящие ответы. Составьте рассылку, предложите время и место первой встречи и организуйте ее. Если выбор пал на личное общение, то снимите место в известном и удобном для общения кафе или баре, которое не будет на тот момент слишком заполнено посетителями (в шумных кафе трудно вести беседу), и выберите подходящее для этого время. Если будут затруднения, то многие публичные библиотеки предоставляют для общего пользования свои конференц-залы. Если вы набираете группу на работе, воспользуйтесь рабочим конференц-залом.

Если вы выбрали виртуальное общение, воспользуйтесь любым из инструментальных средств, позволяющих организовать работу дискуссионной группы, таким как Google Groups (http://groups.google.com/) или Yahoo! Groups (http://groups.yahoo.com/), которые могут взять на себя все административные заботы о списке участников. Веб-сайты Meetup.com и Ning.com располагают другими полезными свойствами для организации групп.

Последующие действия

Что из всего этого получилось, покажет первая же встреча или дискуссия. На первой встрече нужно определить повестку дня, предложить основной формат проведения встреч и дать возможность людям высказать свои суждения. Если все согласились с тем, что вы наметили, переходите к дискуссии. Вам, как организатору, нужно всегда появляться на встрече со списком своих собственных вопросов для группы и одной-двумя историями, которыми вы хотели бы поделиться с людьми, если они не спешат добровольно поделиться своими собственными историями. Улыбнитесь, представьте людей по мере их появления и делайте все возможное для формирования той самой дружественной атмосферы, которую вы хотите создать в группе. Когда найдется какой-нибудь желающий помочь в руководстве группой, сделайте этого человека соорганизатором.

Для успешного проведения первой встречи есть один прием – предварительно устроить с несколькими участниками встречу с глазу на глаз. Закажите для них кофе, познакомьтесь и попросите поддержки при проведении первой общей встречи. Такая предварительная подготовка почвы для взаимопонимания в дискуссионной группе снизит вашу нервозность при проведении первой дискуссии, а заодно создаст предпосылки для создания дружественной атмосферы для всех присутствующих, поскольку на встрече будут присутствовать как минимум двое знакомых друг другу людей. Разумеется, такую же роль может сыграть и какой-нибудь ваш друг, заинтересовавшийся работой дискуссионной группы.

Но независимо от того, насколько вы сможете произвести впечатление на присутствующих, некоторые покинут дискуссионную группу после первой же встречи. Это нормальное явление. Они проявили любопытство, захотели посмотреть, что это такое, но после первого же посещения их любопытство иссякло. Остаются именно те, кто вам нужен. Даже если у вас остался только один заинтересованный человек, вы можете попросить его помочь в расширении группы или же сохранить этот минимальный состав группы.

Обычные темы для обсуждения

Простейшим форматом работы дискуссионной группы будет следование главам книги. Каждую неделю люди читают очередную главу и собираются, чтобы обсудить свои мысли, поделиться историями или выполнить упражнения к этой главе. Когда книга подойдет к концу, нужно подобрать другую книгу. Или нужно менять ответственных за проведение дискуссий каждую неделю, при этом каждый участник должен подбирать публикацию на блоге или веб-статью для чтения и обсуждения. В качестве дополнения хочу предложить вам несколько типовых тем для обсуждения, позаимствованных из материалов работы упомянутой ранее дискуссионной группы PM Clinic.

Баланс личного времени и времени, уделяемого команде

Одна из моих обязанностей в качестве руководителя проекта – защита разработчиков моей команды от постоянных отвлечений и выстраивание структуры их работы таким образом, чтобы у них были отрезки времени, позволяющие сконцентрироваться на выполняемой работе. Моя проблема в том, что я тоже нуждаюсь в каком-то соглашении, позволяющем мне выделить время для того, чтобы сосредоточиться на решаемых вопросах. Я понял, что, пытаясь уладить дела своей команды и своих клиентов, я частенько выкраивал «часы для концентрации» только после работы или на выходные. Мне нужен совет других руководителей проектов, как им удается выдержать баланс времени для уединенной работы, чтобы отвечать на запросы и нужды заказчиков и специалистов команды, и в то же время прерываться на организацию работ из их текущего перечня.

Заказчики и их отношения с командой

Как руководитель я отвечаю также и за владение обстановкой в части взаимоотношений с внешним заказчиком. Проблема в том, что по крайней мере четверо из моей команды взаимодействуют с командой заказчика (работают с четырьмя различными ее представителями) как минимум раз в неделю. Я понимаю, что практически невозможно быть в курсе всех проблем, с которыми сталкивается заказчик, чтобы обеспечить его удовлетворенность нашей работой. Как мне отследить все контакты с заказчиком и обеспечить полную информированность всей команды без негативной реакции всех участников событий? Самыми ценными были бы советы тактической и стратегической направленности.

Стоит ли следовать инновациям?

У команд разработчиков довольно узкое окно предложений чего-либо отличного или инновационного по сравнению с теми организационными или производственными нормами, которых они придерживаются. С другой стороны, прокладывать маршрут, исходя из обнаруженных ошибок, функциональных запросов заказчика, прихоти вице-президента или функциональных возможностей, реализованных конкурентами, сродни возврату к каторжному труду, где разработчики скованы одной, но уже цифровой цепью. Как команде лучше всего подготовиться, а затем справиться с реализацией тех скромных возможностей отступления от общепринятых норм? Как найти баланс между инновационными вкладами и другими делами, такими как выполнение текущей работы?

Мой босс – любитель покрасоваться

Руководитель всего проекта, мой босс – большой любитель покрасоваться. Когда проводятся командные совещания, он тратит все время на пустую болтовню (рассказывает разные истории о своих подвигах, о том, кто и когда наступил ему на любимую мозоль, отпускает какие-то пошлые шутки). Похоже, что он считает себя интересным человеком, но его точку зрения мало кто разделяет. Поэтому наши еженедельные совещания превратились в сплошную муку. Он не придерживается собственной повестки дня и не понимает, что попусту тратит время многих людей. Как с этим бороться?

Соблюдение краткости совещаний

Когда я пытаюсь проводить краткие совещания со своей собственной подгруппой, мне трудно добиться их посещаемости. Все полагают, что любые проводимые совещания будут во многом похожи на совещания, созываемые моим боссом (то есть будут затянутыми, скучными, раздражающими и проходящими под его доминирующим влиянием). Поэтому я изо всех сил пытаюсь убедить людей в том, что мои совещания будут проходить по-другому, и как только они соберутся, я прилагаю все усилия, чтобы изменить ситуацию, но люди ведут себя так, будто находятся на общекомандном совещании (хранят молчание в надежде, что все вскоре закончится). Что мне делать?

Смерть в результате несчастного случая

Недавно моя команда, занимающаяся разработкой веб-приложений, упражнялась в планировании преодоления нештатных ситуаций. Мы собрались всей группой за столом, составили краткий перечень всевозможных неурядиц, а затем попытались провести мозговую атаку, чтобы понять, как на них реагировать. (Это было настолько забавно, что всем вам нужно как-нибудь попробовать заняться тем же самым.) Одна из придуманных нами ситуаций вызвала наибольшее количество споров: «За три недели до наступления очередного контрольного срока вашего лучшего программиста сбил автобус, и он впал в кому. По дороге из больницы в офис вы пытаетесь понять, что же делать дальше. Чтобы вы сделали и как бы преподнесли свои решения своей команде?»

Наш поезд идет под откос

Наша сравнительно небольшая команда разработчиков (около 15-ти человек, включая тестировщиков и других специалистов) работает уже 5 недель над 30-недельным проектом. У некоторых из нас в ходе начального планирования возникла серьезная обеспокоенность, которая так и не была снята (не была достигнута всеобщая удовлетворенность). А теперь мы поняли, что подходим к краю пропасти: было выбрано ошибочное направление развития архитектуры, бизнес-план страдает бессмыслицей, а команда слишком разобщена и не сфокусирована на достижении единой цели (хотя некоторые в отличие от меня так не думают). Но проект уже приобрел существенный импульс, и руководство не видит опасности или не испытывает озабоченности по поводу имеющихся проблем (хотя уже проявляются тревожные симптомы в виде низкого качества, непрекращающихся споров и нечетко выраженных требований). Как я в качестве руководителя проекта, находящегося в середине процесса разработки, должен действовать, чтобы предотвратить те явления, которые ведут наш поезд под откос? Как защитить команду разработчиков и весь проект от того, что, по моему мнению, приведет к существенным и весьма болезненным изменениям (и к тому, что придется выбросить часть работы в корзину) в течение следующих четырех или пяти недель? Как мне уберечь уже реализуемый проект от схода с рельс?

Борьба с излишней функциональностью

Мы имеем дело с программным продуктом для ведения бухгалтерского учета версии 3.0. Продукт уже обладает многими общепринятыми и важными функциями, и его конструкция приобретает вполне зрелые очертания. Но возникает ситуация, при которой вся команда (специалисты по бизнесу, маркетингу, а заодно с ними и разработчики) поддается общему настроению по продвижению эффектных по виду, но второстепенных по назначению функций, которыми люди, возможно, если и воспользуются, то не более одного-двух раз. Мне уже приходилось наблюдать подобное «раздувание» функций в других проектах, и в данном случае на лицо все те же признаки. Мы превращаемся из организации по разработке программных продуктов в некую «ферму» по разведению новых функций. И всем видится в перспективе история, как в фильме «Ганг Хо». Как мне добиться того, чтобы в версиях 3.0 и 4.0 вся хорошая работа, сделанная в предыдущих версиях, не были похоронена под грудой функций и прочего хлама, родившегося в силу чьих-то предпочтений или продиктованного какими-то маркетинговыми ходами? Как проектирование может и дальше содействовать основному бизнесу, не превращая кодирование продукта и разработку его потребительских свойств в некую зону бедствия?

Стиль совещания, напоминающий чемпионат по борьбе

Я – единственный руководитель проекта в команде из пяти программистов, трех тестировщиков и нескольких других специалистов (составителей документации, специалистов по локализации и т. п.). Процесс решения большинства основных задач проходит в нормальной обстановке, в духе продуктивной совместной работы. Но как только дело доходит до проектирования, все выпускают во все стороны огромные колючки. При определении функциональных особенностей продукта и характера его работы сдержанность куда-то исчезает, и все становится похожим на чемпионат мира по борьбе. Мы спорим, ссоримся, мешаем друг другу и боремся за различные конструкторские решения. Иногда споры идут вокруг конструкции пользовательского интерфейса, иногда вокруг выбора, касающегося общих подходов к программированию (объектных моделей, интерфейса прикладного программирования, а не самой реализации), а иногда они возникают даже вокруг самих технических требований. В нашей организации в порядке вещей ввязывание в подобные дебаты руководителей и менеджеров всех мастей (устройство своеобразных королевских турниров).

Итак, вопрос заключается в следующем: какую роль должен играть руководитель проекта при выборе основных проектных направлений? Что должны делать руководители проектов, отслеживать ход реализации проекта и всячески содействовать этому процессу или возглавить весь процесс? А если они его возглавят, то в какой степени они должны быть причастны к проектированию программного продукта или веб-сайта?

Самодельный или готовый продукт

Перед моей командой встал выбор, покупать дорогой готовый продукт или создать подобный продукт собственными силами; мы выбрали последнее, так как для нас этот продукт был важным инструментальным средством (анализатором производительности программ), мы владели этой тематикой и собирались перенастраивать это средство в будущем. После 5-ти месяцев разработки (с месячным отставанием от первоначального графика работ) продукт так должным образом и не заработал и был весьма далек от завершения (еще 8 недель по текущим прикидкам). Стоимость собственной разработки уже превысила стоимость продукта, имеющегося в продаже. Когда именно руководитель проекта должен трезво оценить реальное положение вещей и убедить руководство купить продукт? Или должны ли мы, несмотря на неудачу, потратить солидные средства и довести свой собственный продукт до завершения?

Все и сразу

Мне приснился классический ночной кошмар руководителя проекта: слабые технические требования, скудная спецификация, небольшой срок выполнения заказа, отсутствие дополнительного времени или ресурсов и настоящая западня: проект ориентирован на запросы клиента, и если продукт не будет поставлен в срок и не удовлетворит заказчика, то моя компания понесет весьма существенные потери. Сгустим краски:

• Клиент настаивает на том, что каждую проблему следует считать первостепенной, и отказывается расположить проблемы по приоритетности.

• Клиент все еще проявляет активность по добавлению новых функциональных особенностей.

• Ко всему прочему, клиент сильно раздражен, поскольку не считает, что наша компания в состоянии успешно справиться с этим проектом.

• Внутренняя обстановка усугубляется тем, что руководитель группы разработчиков на грани снятия с должности, тестировщик – на грани увольнения (а замены ему нет), а я, единственный руководитель проекта, заменяю того, кто не справился с работой, но остался в компании и не горит желанием помочь мне войти в курс дела.

Меня призвали разобраться во всей этой неразберихе только вчера. Есть отправная точка – 15 апреля. Мне нужна весьма изощренная стратегия, чтобы выстроить свой путь через всю внутреннюю и клиентскую политику, успокоить раздраженного клиента и поставить ему качественный программный продукт через четыре недели!

Примечания

1

Сознание начинающего является начальным понятием дзен-буддизма. В канонической притче фигурирует пустая чаша: если сконцентрироваться на том, чем заполнена ваша чаша, в ней никогда не будет места для новых знаний. См. книгу Сюнрю Судзуки (Shunryu Suzuki) «Zen Mind, Beginner’s Mind» (Weatherhill, 1972).

(обратно)

2

Об этом свидетельствует отчет «CHAOS Report» (The Standish Group) – документ о бюджете, календарном плане и общих провалах проектов разработки программного обеспечения. Публикуется по адресу http://standishgroup.com/sample_research/.

(обратно)

3

Карл Поппер был одним из видных философов ХХ века. (См. http://en.wikipedia.org/wiki/Karl_Popper).

(обратно)

4

Из книги Джеймса Чайлза (James R. Chiles) «Inviting Disaster: Lessons from the Edge of Technology» (HarperBusiness, 2002).

(обратно)

5

Хорошее описание как матричного, так и других типов организации можно найти в книге Стивена Силбигера (Steven A. Silbiger) «The Ten-Day MBA» (William Morrow and Company, 1993) на с. 139–145. Впрочем, эту информацию можно найти практически в любой книге, посвященной теории управления.

(обратно)

6

Опубликована по адресу http://www.tompeters.com/col_entries.php?note=005297&year=1991.

(обратно)

7

Как-то в Питтсбурге мы с приятелями зашли пообедать в пиццерию и получили заверение, что столик будет готов через десять минут. Ровно через десять минут мой друг Чад МакДаниел поинтересовался готовностью столика и получил ответ распорядителя, что все будет готово через десять минут. Тогда он спросил: «Это те же десять минут или другие десять минут?» – но его шутку должным образом так и не оценили.

(обратно)

8

В оригинале «Feature-driven development». – Примеч. ред.

(обратно)

9

Сравнительное обсуждение традиционных и гибких методов разработки программных средств вы сможете найти в книге Барри Боэма (Barry Boehm) и Ричарда Тернера (Richard Turner) «Balancing Agility and Discipline: A Guide for the Perplexed» (Addison Wesley, 2003).

(обратно)

10

Информацию об определениях и понятиях изменений процесса разработки программного обеспечения, а также об управлении этими изменениями можно найти в книге Уоттса С. Хамфри (Watts S. Humphrey) «Managing the Software Process» (Addison Wesley Professional, January 1989).

(обратно)

11

«Understanding and Controlling Software Costs», IEEE Transactions on Software Engineering, т. 14, № 10, октябрь 1988, стр. 1462–77; а также книга «Software Engineering Economics» (Prentice Hall, 1991).

(обратно)

12

Календарные планы, основанные на имеющихся работах, называются восходящими, потому что они создаются командой, а календарные планы, основанные на потребностях управления, – нисходящими. Обычно разногласия между ними согласовываются.

(обратно)

13

В зависимости от характера непредвиденных обстоятельств (просчеты проектантов, политические революции, нашествия пришельцев и т. д.), заложенных в календарный план, рабочий график может быть разным. Если возможные провалы не рассматривались, календарный план не может вызывать доверия. Его создатель не проявил должного творческого подхода или скепсиса.

(обратно)

14

Процесс проведения структурной декомпозиции работ описан во многих книгах. К этой теме я вернусь в главе 14, но если вы хотите изучить ее более обстоятельно, начните с материалов, размещенных по адресу http://en.wikipedia.org/wiki/Work_breakdown_structure, или с книги Стефана Дево (Stephen Devaux) «Total Project Control» (Wiley, 1999).

(обратно)

15

В книге Кента Бека (Kent Beck) «Extreme Programming Explained» (Addison Wesley, 1999) предлагается программно-ориентированная модель распределения работ, при которой программисты сами выбирают себе работы. В идеале должен быть выдержан компромисс между тем, что лучше для проекта, и тем, что лучше для отдельных специалистов команды.

(обратно)

16

См. книгу Кента Бека (Kent Beck) и Мартина Фоулера (Martin Fowler) «Planning Extreme Programming» (Addison Wesley, 2002), стр. 60–62.

(обратно)

17

Стандартная формула для метода PERT: лучший расчет + (4 x наиболее вероятный расчет) + худший расчет/6. Имейте в виду, что существует огромное количество разновидностей и теорий наилучших взвешенных расчетов.

(обратно)

18

Сравнить другие типы проектов вы сможете, обратившись по адресу http://www.joelonsoftware.com/articles/FiveWorlds.html.

(обратно)

19

Эндрю Стеллман (Andrew Stellman), один из научных редакторов данной книги, несколько раз угрожал мне физической расправой, если я не расскажу о качестве программного продукта, но эта глубокая тема так и не вписалась в рамки моей книги. Для начала порекомендую вам две другие книги: «Out of the Crisis» (MIT Press, 2000) У. Эдвардса Дэминга (W. Edwards Deming) и «Quality Is Free» (Signet Books, 1992) Филиппа Кросби (Philip Crosby).

(обратно)

20

Файзал Джафдат (Faisal Jawdat), один из научных редакторов данной книги, угрожал мне изощренными пытками, если я не отмечу всю иронию ситуации, в которой после всего сказанного я продолжал работать на Microsoft.

(обратно)

21

Эта сноска дана специально, чтобы заставить читателя обращать на сноски хоть какое-то внимание. А если серьезно: когда проектировщики работают на себя, они имеют склонность многократно переделывать сделанное, возможно, расслабляясь в отсутствие образа потребителя, на которого надо работать.

(обратно)

22

Обратите внимание на замечательную книгу Дональда Гауса (Donald Gause) и Джералда Вейнберга (Gerald Weinberg) «Exploring Requirements: Quality Before Design» (Dorset House, 1989).

(обратно)

23

Этот метод описан в книге Алистера Кокборна (Alistair Cockburn) «Writing Eff ective Use Cases» (Addison Wesley, 2000).

(обратно)

24

Прочтите книгу Дэниела Шактера (Daniel Schacter) «The Seven Sins of Memory» (Mariner Books, 2002) или посмотрите замечательный фильм «Помни» («Memento»). Это поможет вам осознать, сколь ограничена и ненадежна человеческая память.

(обратно)

25

Из книги «Piloting Palm: The Inside Story of Palm, Handspring and the Birth of the Billion-Dollar-Handheld Industry» авторов Андреа Баттера (Andrea Butter) и Дэвида Поги (David Pogue) (Wiley, 2002), стр. 72.

(обратно)

26

Если команда получает заказ на прорывную разработку, но подходит к планированию как к рутинной рядовой работе, нужно быть настороже. Это похоже на нейрохирургическую операцию, проводимую с использованием бытовой аптечки. Если планирование не отвечает сложности задач, так или иначе готовьтесь к провалу.

(обратно)

27

Дополнительный материал можно найти в книге Дональда Гауса (Donald Gause) и Джеральда Вейнберга (Gerald Weinberg) «Exploring Requirements: Quality Before Design» (Dorset House, 1989).

(обратно)

28

См. статью «How to give and receive criticism» по адресу http://www.scottberkun.com/essays/35-how-to-give-and-receive-criticism/.

(обратно)

29

Тем не менее изобретатель простой формулы добычи воды или создания компаса из песка получит первый приз в конкурсе на лучшую идею года при проведении соревнований «Затерявшийся в пустыне». Это пример четко обозначенной проблемы с невероятно сложным решением (простая, но трудноразрешимая). Когда люди жалуются, что требования настолько сложны, что проблему решить невозможно, значит, голова у них забита всякой чепухой. В формулировках проблем указано, на какую гору следует забраться, но там ничего не говорится о том, как взобраться на вершину.

(обратно)

30

В качестве одного из примеров можно привести миноксидин, лекарственный препарат для лечения повышенного кровяного давления. Оказалось, он эффективен в решении совершенно иной проблемы – облысения. По одному из критериев формула миноксидина может оцениваться отрицательно, по другому – положительно. Так была эта формула хорошей идеей или нет? Все зависит от того, в каком контексте ее рассматривать.

(обратно)

31

Во многом эта картина похожа на описанную в книге «Peopleware» Тома Демарко (Tom DeMarco) и Тимоти Листера (Timothy Lister) (Dorset House, 1999) или в книге «Planning Extreme Programming» Кента Бека (Kent Beck) и Мартина Фоулера (Martin Fowler) (Addison-Wesley Professional, 2000).

(обратно)

32

Выпуск 4.02, февраль 1996 г.

(обратно)

33

ThinkPak можно заказать на веб-сайте www.amazon.com.

(обратно)

34

Основные принципы веб-дизайна изложены в книге Стива Крага (Steve Krug) «Don’t Make Me Think» (New Riders Press, 2005), а типовые ошибки, допускаемые при разработке пользовательского интерфейса, рассмотрены в книге Джефа Джонсона (Jeff Johnson) «GUI Bloopers». Нанять консультанта по потребительским свойствам или дизайну можно на веб-сайте http://www.upassoc.org/people_pages/consultants_directory/index.html или обратиться к автору через веб-сайт www.scottberkun.com/services.

(обратно)

35

Чувство обреченности оказавшегося в плену у времени хорошо передано в песне группы They Might Be Giants под названием «Older»: «This day will soon be at an end, and now it's even sooner, and now it's even sooner. And now it’s sooner still». («День скоро подойдет к концу, и времени все меньше, меньше. И вот его почти что не осталось».)

(обратно)

36

Не так важны сами эти точки, как создаваемый ими эффект. Пусть лучше их предлагает сама команда, тогда она станет больше в них верить и строже соблюдать.

(обратно)

37

Неплохой список вариантов можно найти по адресу http://www.ms.lt/ms/projects/toolkinds/organize.html.

(обратно)

38

По поводу споров вокруг программирования до выработки замысла рассказывается в книге Алана Купера (Alan Cooper) «The Inmates Are Running the Asylum» (Sams, 2004).

(обратно)

39

См. статью «The Art of UI Prototyping» по адресу http://www.scottberkun.com/essays/12-theart-of-ui-prototyping/.

(обратно)

40

Заметьте, что даже если ваша команда не несет прямой ответственности за интересы пользователей, рано или поздно созданный ею алгоритм или база данных попадет в руки живых людей и начнет сказываться на их работе.

(обратно)

41

По этому поводу у меня возникали споры с другими руководителями. Они не могут себе представить, что их выдающиеся разработчики все это время не занимаются программированием в полную силу. Здесь они, конечно, лукавят: если время программиста ценится столь высоко, его работа должна быть четко спланирована. Они меня спрашивали: «А чем же тогда заняться программистам?» – а я отвечал: «Ждать плана, на который не жалко потратить их время, или помогать команде в подготовке этого плана».

(обратно)

42

Поэтому некоторые команды держат технические условия в режиме управляемой блокировки входящей и исходящей информации. Это позволяет разным людям вносить поправки, не мешая друг другу. (Такое же поведение имитируется веб-приложением Google Docs.) Также следует заметить, что ничто так не раздражает, как блуждание по документу в поисках отличий от предыдущей версии. Какое бы средство для этого не использовалось, авторы должны регистрировать вносимые изменения, например, «В раздел 6 этот пункт был добавлен 20.07.2008».

(обратно)

43

Не стоит относиться к этому с сарказмом. На самом деле концепция управления знаниями базируется, в частности, на понятии документирования, без которого некоторые вещи просто исчезли бы, если кому-то, скажем, при подготовке следующего варианта, они показались бы лишними.

(обратно)

44

Меня всегда настораживали красиво разрисованные и объемистые технические условия. Это явный намек на то, что руководителя проекта больше волнуют сами технические условия, а не то, что будет получено на выходе, или то, что он не доверяет своей команде. Хуже того, слишком пространное изложение технических условий свидетельствует о том, что сами условия, в конечном счете, так никто и не читал (исключение составляют условия создания ядерных реакторов или высокотехнологичного хирургического инструмента).

(обратно)

45

Упражнения по моделированию ситуации – это лучшее, что придумано для развития навыков принятия решений. Моделирование ситуации намного лучше самого преподавателя погружает студентов в гущу событий. Почитайте книгу Кларка Эбта (Clark Abt) «Serious Games» (Viking, 1970).

(обратно)

46

В книгу «The Ten-Day MBA» (Quill, 1999) Стивена Силбиджера (Steven Silbiger) включена небольшая глава, посвященная теории типового дерева решений. Книга весьма полезна тем, что охватывает основные темы большинства MBA-программ.

(обратно)

47

Изначально фраза звучала как «смерть от тысячи вырезок» и означала газетные вырезки. Шучу.

(обратно)

48

Зачастую это относится к соревновательной ситуации. Быстрота действий помогает преодолеть то, что в военной терминологии называется бременем неопределенности. Упреждающими действиями вы передаете ход сопернику (или партнеру) и вынуждаете его на ответные действия. Часто инициативу берет на себя тот, кто чувствует превосходство (в ресурсах, мастерстве, территории, здравомыслии).

(обратно)

49

Краткую историю о списке аргументов «за» и «против» можно найти в памфлете «How to Make a Decision» (Who’s There, Inc., 2003), который можно приобрести по адресу http://www.knockknock.biz. На 32-х занимательных страницах под этим названием скрываются описания способов, вроде подбрасывания монетки, игры в «камень-ножницы-бумагу» и т. п.

(обратно)

50

Слабым местом принципа бритвы Оккама является его уязвимость от локальных максимумов. Например, если вы стоите на холме и в поле вашего зрения нет ни одной точки выше той, на которой вы стоите, простейшим заключением может стать то, что вы побывали на самой высокой точке Земли. Однако вполне возможно, что существует некая недоступная вам в данный момент информация, обладая которой вы посчитали бы свое простое заключение несостоятельным.

(обратно)

51

Был ли я прав? На следующий день после того, как я принял это решение, наш ведущий разработчик, Чи Чу (Chee Chew), решил сделать все самостоятельно. Не говоря об этом ни мне, ни кому-либо другому, он работал сутками за счет своего личного времени. Первоначальный пятидневный расчет был сделан кем-то менее опытным, а он справился с разработкой основных элементов примерно за половину срока. На другой день я случайно зашел в его офис и обнаружил там сюрприз. Он, улыбаясь, продемонстрировал новую версию браузера с внесенными им изменениями. Я просто онемел.

(обратно)

52

Фламандский живописец 16 века, известный своими пейзажами и картинами из сельской жизни. Увидеть картину «Вавилонская башня» и прочитать полную биографию художника вы сможете по адресу http://en.wikipedia.org/wiki/Pieter_Brueghel_the_Elder.

(обратно)

53

Как выразился Петерс: «Если вы не привыкли странствовать [по чужим офисам], то поначалу вы испытаете настоящий ужас…». Для выстраивания подобных взаимоотношений с людьми нужно время, особенно если у людей нет причин относиться к вам с опаской.

(обратно)

54

Мне не удалось найти никаких ссылок на данную модель. Я слышал о первых трех уровнях, но не смог найти источника. Другой удачной моделью является модель Сатир, которую Вейнберг (Weinberg) использовал в своих книгах. См., например, книгу «The Satir Model: Family Therapy and Beyond», Вирджиния Сатир (Virginia Satir) и др. (Science and Behavior Books, 1991). Да, это книга по терапии. Но если вас беспокоит данное обстоятельство, это именно та книга, которую вам следует прочитать.

(обратно)

55

Иногда согласие может достигаться так же просто, как и выбор человека, который будет принимать конкретное решение. Вместо обсуждения проблемы, обсудите, кто будет принимать по ней решение (см. главу 8).

(обратно)

56

Обширный список словесных нападок, разбитый на категории и сопровождаемый примерами, вы можете найти по адресу http://www.vandruff.com/art_converse.html. Только, пожалуйста, не используйте его как руководство к действию.

(обратно)

57

Каждая система измерений, используемая при оценке трудового вклада, имеет свои недостатки. Строки кода подразумевают количество, а не качество. Человеко-часы подразумевают продолжительность, а не интенсивность.

(обратно)

58

Задумано хитро, но втайне нужно предусмотреть приглашение обеих команд, независимо от того, кто выиграет. Но сообщать об этом до самого конца соревнования нельзя.

(обратно)

59

Мне неловко, но я всегда помню об этих небольших знаках признательности, присланных по электронной почте, возможно, потому, что не избалован проявлениями похвалы от высшего руководства. У систем мгновенного обмена сообщениями и электронной почты нет возможности воспроизводить кивки головой или улыбки, обеспечивающие вторичную обратную связь в процессе общения. Возможно, личные электронные сообщения некоторым образом компенсируют такое положение вещей.

(обратно)

60

Прекрасный пример краткости в общении дает одна невероятная история из жизни Виктора Гюго. Когда была издана книга «Les Mise rables», Гюго послал своему издателю телеграмму с вопросом о первых отзывах. Его телеграмма была предельно краткой и состояла из одного знака: «?». Полученный им ответ также состоял из одного знака: «!». Очевидно, объем начальных продаж был впечатляющим. Поучительным в этой истории может быть то, что два человека, хорошо знающие и понимающие друг друга, могут общаться куда эффективнее, чем те, кто друг друга не знает. Этим еще раз подтверждается важность развития взаимоотношений с сотрудниками.

(обратно)

61

Возможно, существует некий закон общения, утверждающий, что господствующее в данный момент средство связи (электронная почта) зависит от ранее доминировавшего средства (телефонной связи) по ниспадающей: мгновенные сообщения -> электронная почта -> телефон -> обычная почта -> дымовые сигналы -> непосредственное общение -> и т. п.

(обратно)

62

Лучше всего начать с книг «The Facilitator's Fieldbook» Тома Джастиса (Tom Justice) (American Management Association, 1999) и «Mining Group Gold» Томаса А. Кейзера (Thomas A. Kayser) (McGraw-Hill, 1991).

(обратно)

63

Дополнительную информацию о SCRUM можно найти по адресам http://c2.com/cgi/wiki?ScrumMeetings или http://www.controlchaos.com/.

(обратно)

64

Есть весьма распространенная, особенно среди мужчин, пагубная привычка делать вид, что их абсолютно ничего не беспокоит. Это называют сдержанностью. Однако на эмоциональном уровне нас задевает буквально все. Осведомленные люди считают это – не удивляйтесь – полезным для здоровья. Нужно чувствовать и уметь выражать свои чувства. Вам же самим станет от этого легче.

(обратно)

65

Это вопрос культуры общения. Я бывал в командах с очень высоким уровнем культуры общения. Положение дел, в том числе по весьма спорной тематике, не разглашалось, даже если в комнате присутствовало семь-восемь человек. Однако не все команды умеют также хранить конфиденциальную информацию. Чтобы быстро прощупать почву, на первом этапе нужно приступить к работе с маленькой группой, дать начальный импульс, а затем привлечь других.

(обратно)

66

Несколько упрощая закон Брука, можно констатировать, что дополнительное привлечение работников приводит к двум негативным последствиям: во-первых, им требуется время, чтобы набрать нужный темп работы, во-вторых, усиливается нагрузка на руководство. Поэтому даже в благоприятной ситуации привлечение дополнительных сил не имеет особой ценности. Правда, бывают исключения.

(обратно)

67

Это часть закона Брэнда называется «Pace Law». Взято из вопроса, ежегодного задаваемого редакцией журнала «Edge», который в 2004 году звучал так: «По каким законам вы живете?» (см. http://www.edge.org/q2004/page6.html#brand).

(обратно)

68

Можете также почитать книгу Ричарда Шелла (Richard Shell) «Bargaining for Advantage» (Penguin Books, 2000). В ней приводится больше тактических приемов и технологий, чем в книге «Getting to Yes», и она очень хорошо подойдет для углубленного изучения данного вопроса.

(обратно)

69

Именно здесь переговоры могут усложниться. Если Фрэд не верит в то, что вы готовы воспользоваться вашими возможностями, он станет рассматривать ваш вариант BANTA по-другому. Он может сказать вам следующее: «Вы же не хотите, чтобы я здесь сидел и умирал?» Переговоры становятся сложнее, когда люди блефуют, вводят в заблуждение относительно их интересов или не испытывают особого доверия к другой стороне. В менее надуманных ситуациях все становится на свои места, как только реализуются варианты BANTA. Если бизнесмен действительно способен на лучшую сделку, то он в конечном счете ее добьется. А если не способен, то он уступит.

(обратно)

70

Неформальное введение в основы эмоциональной динамики вы найдете в замечательной книге Лео Ф. Баскалья (Leo F. Buscaglia) «Living, Loving & Learning» (Ballantine Books, 1985). Более формализованное введение изложено в книге Джона Брэдшоу (John Bradshaw) «Bradshaw On: The Family» (Health Communications, 1990).

(обратно)

71

Лучше всего рассматривать начинающие фирмы как созидательные силы, стремящиеся к новшествам. Обычно они представляют собой небольшие тесно сплоченные и усердно работающие группы людей. Здесь желателен именно «дефицит» людских ресурсов, поскольку только он придает всем особую независимость. Довольно интересные аргументы о пользе и рисках новаторских работ приведены в книге Поля Грехема (Paul Graham) «Hackers and Painters» (O’Reilly, 2004).

(обратно)

72

Роб и Эрик из команды «Samuel Field Y» Дагластон, штат Нью-Йорк, дали мне в области тренерских и руководящих навыков намного больше, чем все последующие тренеры по баскетболу в школе и колледже. Если вы знаете этих людей, передайте им, пожалуйста, чтобы они связались со мной.

(обратно)

73

Эта аббревиатура расшифровывается как «read the fucking manual», то есть «прочти эту чертову инструкцию!» или (в армейском варианте) «учи матчасть!» – Примеч. ред.

(обратно)

74

См. статью «How to give and receive criticism» по адресу http://www.scottberkun.com/essays/35-how-to-give-and-receive-criticism/.

(обратно)

75

Во многих военных организациях разбору подвергаются только инциденты или результаты достижения поставленных целей. Поэтому если случаются какие-то неприятности, последствия которых незначительны и винить в которых по сути некого, то уроки из них не извлекаются, на них попросту не обращается особого внимания. Фактически лучшей реакцией может быть высказывание, что впредь вы даже не станете обращать внимание на подобные мелочи.

(обратно)

76

Вопрос заключается не только в том, способен ли человек на все это, вопрос ставится следующим образом: «Сможет ли этот человек понять, когда ситуация начнет выходить из-под его контроля и своевременно запросить помощь?». Он должен уметь справляться еще и с такой ситуацией.

(обратно)

77

Дополнительное обсуждение вопроса о том, когда говорить «да», а когда «нет», можно найти в эссе Ричарда Бреннерса (Richard Brenners) «Saying No: A Short Course» по адресу http://www.ayeconference.com/Articles/Sayingno.html.

(обратно)

78

См. книгу Роберта Гласса (Robert Glass) «Software Runaways» (Prentice Hall, 1997).

(обратно)

79

См. статью «How to detect bullshit» по адресу http://www.scottberkun.com/essays/53-how-todetect-bullshit/.

(обратно)

80

Анализ критического пути детально расписан во многих учебниках по управлению проектами. Краткое изложение можно найти по адресу http://en.wikipedia.org/wiki/Critical_path. Более глубоко эта тема изложена в книге Стефана Дево (Stephen Devaux) «Total Project Control» (Wiley, 1999).

(обратно)

81

Карл фон Клаузевиц был известным прусским военным мыслителем 19 века (см. http://en.wikipedia.org/wiki/Clausewitz).

(обратно)

82

Модель зрелости производственного процесса (Capacity maturity model, CMM), предложенная институтом по разработке программного обеспечения (Software Engineering Institute), определяет ряд очень хороших приемов управления IT-проектом в стадии миттельшпиля (см. http://www2.umassd.edu/SWPI/sei/tr25f/tr25.html и http://www.sei.cmu.edu/cmm/).

(обратно)

83

Из книги «Managing the Software Process» (Addison-Wesley Professional, 1989).

(обратно)

84

При применении некоторых гибких методов используются доски планирования, на которых отслеживаются карточки историй для каждой из работ. Есть команды, использующие электронную таблицу или базу данных для отслеживания, кто над чем работает и какие работы последуют за этим.

(обратно)

85

У этого подхода есть свои формальные методы. Некоторые команды проводят еженедельные совещания, на которых кратко обсуждается место каждого программиста у конвейера: до всех доводится содержание работ, которыми на следующей неделе будет занята команда в целом и все специалисты по отдельности. Присутствие руководителя проекта необходимо. Это позволяет удостовериться, что все временные нормативы вписываются в конвейер.

(обратно)

86

При разработке пользовательского интерфейса наш конвейер по созданию программного кода был организован таким образом, что мы могли перерабатывать замысел. Мы настраивали конвейер на выполнение части работы А, забирали полученный код в лабораторию по исследованию потребительских качеств, проводили массу разнообразных исследований, уточняли замысел, а затем выполняли оставшуюся часть работы А. С целью сохранения загруженности конвейера и соблюдения отпущенного рабочим графиком времени проектировщики параллельно с командой программистов могли осуществлять среднюю и глубокую детализацию замысла пользовательского интерфейса.

(обратно)

87

Из книги «Web Project Management: Delivering Successful Commercial Web Sites».

(обратно)

88

Нулевая сумма – это термин теории игр, означающий конечный набор ресурсов. Разрезание шоколадного торта на куски – это игра с нулевой суммой: если я возьму больший кусок, то вам достанется меньший. Конечно, если мы пойдем в кафе с неограниченными запасами и начнем заказывать кусочки торта, то игры с нулевой суммой уже не будет: каждый сможет получить столько, сколько захочет.

(обратно)

89

И наоборот, чем хуже определены критерии выхода, тем меньше шансов на соблюдение сроков. Наихудший вариант – вообще не иметь критериев выхода и зависеть в определении сроков завершения от мнения и прихоти руководства.

(обратно)

90

О планах тестирования и общих методиках контроля качества можно узнать из книги Рэкса Блэка (Rex Black) «Managing the Test Process» (Microsoft Press, 1999). Если вы серьезно заинтересованы вопросами качества, их надо сделать частью концептуального документа и учитывать в процессе планирования.

(обратно)

91

Из первого тома «System Thinking» книги Вейнберга (Weinberg) «Quality Software Management» (Dorset House, 1991), стр. 272–273.

(обратно)

92

Из первого тома «System Thinking» книги Вейнберга (Weinberg) «Quality Software Management» (Dorset House, 1991), стр. 272–273.

(обратно)

93

Неплохую подборку полезных инструментов и процессов вы найдете по адресу http://www.martinfowler.com/articles/continuousIntegration.html.

(обратно)

94

См. эссе Джоула Сполски (Joel Spolsky) «Painless Bug Tracking» по адресу http://www.joelonsoftware.com/articles/fog0000000029.html.

(обратно)

95

Если вас интересуют подробности на эту тему, наибольшую ценность могут представить следующие два источника: книга Тома Демарко (Tom Demarco) «Controlling software projects» (Prentice Hall, 1986) и том 1 «Systems thinking» книги Джеральда Вейнберга (Gerald Weinberg) «Quality Software Management» (Dorset House 1991).

(обратно)

96

Разработка на основе тестирования может стать одним из действенных подходов к решению задач качества разработки на ранних этапах и уберечь от больших наплывов обнаруживаемых ошибок. Обратите внимание на следующий материал: http://en.wikipedia.org/wiki/Test_driven_development.

(обратно)

97

Из первого тома «Systems thinking» книги Вейнберга (Weinberg) «Quality Software Management», стр. 250

(обратно)

98

См. книгу Кента Бека (Kent Beck) «Extreme Programming Explained» (Addison-Wesley, 1999), стр. 69.

(обратно)

99

Разумеется, чем выше качество разработки программного продукта, тем проще предсказать, как скажутся на нем вносимые изменения.

(обратно)

100

Советы по поводу качественного выполнения постпрограммы можно найти по адресу http://www.scottberkun.com/essays/.

(обратно)

101

Руководители проекта придают всему сильную эмоциональную окраску и поэтому испытывают проблему с объективностью. А у стороннего эксперта эмоциональная составляющая или причастность к этим событиям отсутствует, поэтому у него будет больше шансов на успешное изучение, осмысление, составление отчета и выдачу рекомендаций по проекту.

(обратно)

102

Не стоит недооценивать значение удачно расположенного рабочего места. Благодаря этому обстоятельству все, что происходило вокруг меня, давало возможность многому научиться в деле руководства проектами. Мне доводилось неформально общаться со многими людьми, разыскивавшими Криса, я невольно подслушивал важные кулуарные разговоры. Обратной стороной медали было то, что буквально у меня за стеной работал большой начальник. Если бы это был менеджер, склонный к постоянному контролю или мелочной опеке, то такое расположение рабочего места вылилось бы в немалую проблему.

(обратно)

103

Из словаря «Random House College dictionary» (1999).

(обратно)

104

Из книги «Roundtable on Project Management».

(обратно)

105

Я сознательно избегаю этических споров о безнравственном поведении или даже о тех видах проектов, про которые можно сказать, что они вынашивают вредные цели. Тем не менее я хочу сказать, что нечестная игра, ложь, изощренное жульничество, как правило, работают во вред проекту. Краткосрочная выгода достигается ценой долговременной потери репутации и доверия со стороны команды.

(обратно)

106

Организационные изменения даются нелегко. Прежде чем самому браться за дело, определенно нужно изучить предмет. Я советую начать с книги Джона П. Коттера (John P. Kotter) «Start with Leading Change» (Harvard Business School Press, 1996).

(обратно)

Оглавление

Об авторе

Благодарности

  К новому изданию

  К предыдущему изданию

Введение

Предисловие

  Для кого предназначена эта книга

  Предположения о вас, читатель, придерживаясь которых я работал над этой книгой

  Как нужно читать эту книгу

Глава 1. Краткая история управления проектами (и почему ей стоит уделить внимание)

  Использование исторического опыта

  Нужно учиться на ошибках

  Веб-разработка, кухни и пункты первой помощи

  Роль управления проектами

  Управление программами и проектами в Microsoft

  Взвешенность при руководстве проектами

  Давление и распри

    Путаница в понятиях процесса и целей

  Нужная степень вовлеченности

    Преимущество собственного взгляда на происходящее

    Руководители проектов создают уникальные ценности

  Выводы

  Упражнения

Часть 1. Планирование

  Глава 2. Правда о календарных планах

    Три цели составления календарных планов

    Решающие факторы и методологии

    На что похож календарный план

      Разделяй и властвуй (большие планы равны множеству мелких)

    Почему рушатся планы

      Выстрел вслепую издалека

      Календарный план – это оценка вероятности

      Расчет – дело тонкое

      Качественное проектирование – залог хороших расчетов

      Элементарные просчеты

      Эффект снежного кома

    Что должно произойти, чтобы календарные планы заработали

    Выводы

    Упражнения

  Глава 3. Как определить, что делать

    Снятие покрова таинственности с вопросов планирования программных продуктов

      Типы проектов

      Как на планирование влияет его организация

      Документы, разрабатываемые при обычном планировании

    Подходы к планированию – три взгляда на проект

      Взгляд бизнесмена

      Взгляд разработчика

      Взгляд потребителя

    Магия единой точки зрения

      Баланс сил

    Постановка правильных вопросов

      Ответы на правильные вопросы

      Что делать при дефиците времени?

    Перечень типичных просчетов при определении конечной цели проекта

    Процесс планирования

      Повседневная работа

    Исследование потребительских запросов и допускаемые при этом просчеты

    Объединяем все вместе – выработка требований

      Проблемы превращаются в сценарии

      Объединение деловых и технологических требований

    Выводы

    Упражнения

  Глава 4. Разработка качественных концептуальных документов

    В чем ценность ведения записей

    Какой по объему концептуальный документ вам нужен?

      Общекомандные и индивидуальные цели

    Пять качеств хорошей концепции

      Простота

      Целенаправленность

      Консолидирующая способность

      Вдохновляющая способность

      Запоминаемость

    Ключевые моменты

    Умение четко излагать мысли

      Простота дается не легко

      У хорошей разработки только один главный автор

      Качество не определяется объемом

    Прикидки, пересмотры и переработки

    Перечень неудачных положений концепции (которых следует избегать)

    Примеры концептуальных положений и целей проекта

      Обоснование концептуальных положений и целей

    Концепции должны быть наглядными

      Наглядное представление неочевидных вещей

    Ежедневное поклонение концептуальным положениям

    Выводы

    Упражнения

  Глава 5. Откуда берутся идеи

    Разрыв между требованиями и решениями

      Качественные требования и ошибки

      Исследование проекта

      Страх перед просчетами и размышления о прогрессе

    Идеи бывают плохими…

      С чем сравнивать, хорошо это или плохо?

    Стандартное и нестандартное мышление

    Хорошие вопросы привлекают к себе хорошие идеи

      Вопросы, концентрирующие внимание

      Креативные вопросы

      Риторические вопросы

    Плохие идеи ведут к хорошим идеям

      Хорошие проекты рождаются из множества хороших идей

    Широта взглядов и импровизация

      Правила импровизации для генерации идей

      Другие подходы к генерации идей

    Проектирование начинается с восприятия пользователя

    Проектирование представляет собой серию переговоров

    Выводы

    Упражнения

  Глава 6. Как правильно распорядиться имеющимися идеями

    Идеи выходят из-под контроля

    Управление идеями требует твердой руки

      Изменения вызывают цепную реакцию

      Творчество – процесс инерционный

    Контрольные точки фаз проектирования

    Как объединить идеи

      Оптимизация и расстановка приоритетов

    Прототипы – ваши друзья

      С чего начинаются прототипы?

      Прототипы для проектов с пользовательским интерфейсом

      Прототипы для проектов без пользовательского интерфейса

      Прототипы – это опора программистов

      Альтернативные варианты повышают вероятность успеха

    Вопросы относительно последовательного приближения

    Список открытых проблем

    Выводы

    Упражнения

Часть 2. Как подготовить хорошие технические условия

  Глава 7. Практические навыки

    Что могут и чего не могут технические условия

    Что включать в технические условия

      Кто отвечает за подготовку технических условий

    Подготовка технических условий не относится к проектированию

      Описание окончательного замысла и его реализации

      Упрощение хороших технических условий

      Гарантия верного хода процесса

    Кто, когда и как

      Технические условия – это для одного или для многих?

    Когда считать законченной подготовку технических условий

      Какова мера достаточности

      Как справиться с открытыми проблемами

      Важность завершения подготовки технических условий

    Обсуждение документов и получение отзывов

      Как проводить обсуждение технических условий

      Кто должен присутствовать и как все должно происходить

      Список вопросов

    Выводы

    Упражнения

  Глава 8. Как принимать хорошие решения

    Оценка значимости решения (что поставлено на кон)

    Поиск и оценка вариантов

      Эмоции и ясность

      Простой способ сравнения

      Обсуждение и оценка

      Шерлок Холмс, бритва Оккама и размышления

    Информированность – это путь к решению

      Данные не принимают решений

      Данные легко истолковать неправильно

      Исследования в качестве аргументов

      Точность не значит достоверность

    Мужество решений

      Некоторые решения не дают выигрышных вариантов

      Хорошие решения могут давать плохие результаты

    Внимательность и умение оглянуться назад

    Выводы

    Упражнения

  Глава 9. Общение и взаимоотношения

    Управление посредством общения

      Взаимоотношения улучшают общение

    Базовая модель общения

    Наиболее распространенные проблемы общения

    Успех проекта зависит от взаимоотношений

      Распределение ролей

    Улучшение отношения к работе

      Как заставить людей работать лучше

      Мотивация

    Выводы

    Упражнения

  Глава 10. Как не раздражать людей на работе, в ходе электронной переписки, на совещаниях

    Почему люди раздражаются

    Положительное влияние хорошо организованного производственного процесса

      Формула хорошего процесса

      Как создавать и запускать процессы

      Управление процессом снизу

    Электронные сообщения, не вызывающие раздражения

      Толковые электронные сообщения

      Пример неудачного электронного сообщения

      Пример хорошего электронного сообщения

    Как не раздражать присутствующих на совещании

      Искусство содействия

      Несколько советов относительно содействия

      Три разновидности совещаний

      Вред регулярных совещаний

      Несколько советов относительно ведения совещаний

    Выводы

    Упражнения

  Глава 11. Что делать, если все идет не так

    Элементарные принципы руководства

    Стандартные ожидаемые ситуации

      Как понять, что вы попали в сложную ситуацию

      Перечень сложных ситуаций

      Практикуйтесь в преодолении трудностей

    Берите ответственность на себя

    Борьба за живучесть

    Разрешение конфликтов и ведение переговоров

    Роли и четко определенные полномочия

      Все должны знать, кто принимает решения

    Арсенал эмоций – работа под давлением, чувства от чувств и комплекс героя

      Работа под давлением обстоятельств

      Чувства от чувств

      Комплекс героя

    Выводы

    Упражнения

Часть 3. Управление

  Глава 12. Почему лидерство должно быть основано на доверии

    Обретение и утрата доверия

      Доверие строится на обязательности

      Непоследовательность ведет к утрате доверия

    Явное выражение доверия (зеленый свет)

    Разновидности власти

      Не уповайте лишь на предоставленную вам власть

      Работа по приобретению заслуженной власти

      Убеждение сильнее диктата

      При необходимости покажите свою власть

    Оказание доверия

      Передача полномочий

    Доверие – это гарантия от неприятностей

    Модели поведения, вопросы и конфликты

      Лидер сам определяет реакцию

    Доверие и ошибки

      Никогда не рубите с плеча

    Доверяйте себе (уверенность в собственных силах)

    Выводы

    Упражнения

  Глава 13. Как осуществить задуманное

    Правильно расставляйте приоритеты

      Типовые списки приоритетов

      Первоочередные и все остальные приоритеты

      Приоритеты – это сила

      Станьте генератором приоритетов

    Все получится, если сказать «нет»

      Учитесь говорить «нет» по-разному

    Реально оценивайте ситуацию

    Определите критический путь

    Будьте непреклонны

    Оставайтесь в рамках здравого смысла

      Партизанская тактика

    Выводы

    Упражнения

  Глава 14. Стратегия миттельшпиля

    Бежать впереди паровоза

      Мыслите здраво

      Тактические (ежедневные) вопросы, позволяющие бежать впереди паровоза

      Стратегические (еженедельные или ежемесячные) вопросы, позволяющие бежать впереди паровоза

    Действуйте осмотрительно

      Нарушение обязательств

    Производственный конвейер по созданию программного кода

      Агрессивный и консервативный варианты производственного конвейера

      Превращение конвейера по созданию кода в конвейер по исправлению ошибок

      Отслеживание хода процесса

    Работа в условиях смещения целей

      Тайные механизмы управления

      Исследование влияния изменений

      Потенциальная удаленность изменения

      Контроль изменений

    Выводы

    Упражнения

  Глава 15. Стратегия эндшпиля

    Долгие сроки – это просто сумма нескольких коротких

      Определение набора критериев выхода

      Почему соблюдение сроков напоминает посадку самолета

      Почему все становится хуже

      Примерное руководство по достижению нужного угла сближения

    Измерительные инструменты

      Ежедневная сборка

      Устранение ошибок и дефектов

      Диаграмма активности

      Оценка тенденций

      Полезные показатели при работе над ошибками

    Элементы управления

      Аналитические совещания

      Классификация

      Военный совет

    Окончание игры

      Кандидат на выпуск

      Процесс обкатки и связанные с ним действия

      Проектная постпрограмма

    Время устраивать вечеринку

    Выводы

    Упражнения

  Глава 16. Власть и политика

    День, когда я стал политиком

    Источники власти

    Злоупотребление властью

      Процессуальные причины злоупотребления властью

      Мотивационные причины злоупотребления властью

      Предотвращение злоупотреблений властью

    Способы решения политических проблем

      Выясните, что вам нужно

      Кто обладает полномочиями на то, чтобы удовлетворить все ваши потребности?

      Оценка обстановки

      Тактика влияния на власть предержащих

    Знание игрового поля

      Создайте собственное игровое поле

    Выводы

    Упражнения

Приложение. Руководство по работе дискуссионных групп

Представление дискуссионной группы по управлению проектами

Как организовать свою собственную дискуссионную группу

Поиск людей

Набор группы

Последующие действия

Обычные темы для обсуждения

Баланс личного времени и времени, уделяемого команде

Заказчики и их отношения с командой

Стоит ли следовать инновациям?

Мой босс – любитель покрасоваться

Соблюдение краткости совещаний

Смерть в результате несчастного случая

Наш поезд идет под откос

Борьба с излишней функциональностью

Стиль совещания, напоминающий чемпионат по борьбе

Самодельный или готовый продукт

Все и сразу

Fueled by Johannes Gensfleisch zur Laden zum Gutenberg

Наш сайт является помещением библиотеки. На основании Федерального закона Российской федерации "Об авторском и смежных правах" (в ред. Федеральных законов от 19.07.1995 N 110-ФЗ, от 20.07.2004 N 72-ФЗ) копирование, сохранение на жестком диске или иной способ сохранения произведений размещенных на данной библиотеке категорически запрешен. Все материалы представлены исключительно в ознакомительных целях.

Copyright © читать книги бесплатно