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