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

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

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

 

Использование исторического опыта

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

 

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

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

К примеру, я знаю одного веб-разработчика, который искренне верит в то, что его работа не похожа ни на какую другую за всю мировую историю. Он считает, что его проект и управление задачами непохожи ни на что из ранее существовавшего, поскольку в процессе веб-разработки он должен принимать сложные инженерные решения, связанные с проектированием и согласованием, а также проверкой изменений буквально в течение нескольких часов или даже минут, а потом публиковать результаты своей работы во Всемирной сети. Он с гордостью перечисляет технологии, которыми овладел, – 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 получила название руководителя проектов. В его непосредственное подчинение попадали не все специалисты команды, но руководителю проектов давались существенные полномочия по руководству и управлению проектом. (В теории управления это примерно соответствует идее матричной организации управления, при которой существуют две линии структуры подчиненности специалистов: одна основана на функциях специалиста, а другая – на конкретном проекте. Таким образом, программист или тестировщик может иметь двойную подчиненность: основную, в соответствии со своей функциональной ролью, и второстепенную, но не менее серьезную, в соответствии с проектом, над котором он работает.)

Джейб сыграл эту роль в разработке продукта под названием 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» называет конфликтующие подходы парадоксами, или дилеммами. Вполне подходящее название, поскольку разные ситуации требуют разного поведения. Значит, руководитель проектов должен не только осознавать эту особенность своей работы, но и выработать инстинкт на поведение, соответствующее конкретно складывающейся обстановке. Это наводит на мысль, что руководство проектами является искусством, требующим проявления интуиции, рассудительности и опыта эффективного использования этих качеств. Следующий список дилемм составлен по материалам статьи Питерса.

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

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

Терпимость к неопределенности – Стремление к завершенности. Начальная стадия проекта характеризуется высокой открытостью и изменчивостью, где неизвестное в значительной степени перевешивает известное. В главах 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. Менеджеры среднего звена или те, кто руководит этими менеджерами, особенно склонны к излишнему участию во всех делах и в создании ненужных процессов, потому что они занимают среднее положение в структуре организации. Как рассудительный менеджер среднего звена мог бы избежать искушений к проявлению мелочной опеки и установлению слишком большого количества правил?