Помоги проекту - поделись книгой:
Управление программами и проектами в 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»[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 дней». При такой «степени детализации» всем, включая и самого бригадира, будет довольно трудно понять, что нужно делать. Но если строитель сможет предоставить объемы работ по неделям, каждый сможет понять, когда и какие задания будут выполняться, в чем заключаются приоритеты, и задать более целенаправленные вопросы и уяснить принимаемые им обязательства. С точки зрения руководителя проекта качественно составленный календарный план дает более понятное видение проекта, на ранней стадии рассеивает претензии, сглаживает оплошности и повышает шансы на благоприятный исход.
С ростом масштабности и сложности проекта возрастает и роль календарных планов. В больших проектах усиливается взаимозависимость исполнителей, а при выборе решений и сроков повышается вероятность влияния на других людей. Если у вас всего несколько сотрудников, работающих в небольшой команде, то шансы выявить проблемы в работе друг друга намного выше. Ошибки в планировании работ плохо воспринимаются даже в небольшой команде, но в этом случае потерянные полдня компенсируются ударным трудом трех человек в течение того же времени, позволяя наверстать упущенное. Кто-то может задержаться на работе или, если надо, вся команда может сплотиться и помочь отставшим войти в график. При работе над более объемным проектом с привлечением десятков и сотен сотрудников утраченные сутки могут привести к «эффекту домино» и возникновению различных проблем в самых непредвиденных ситуациях, справиться с которыми силами одной команды порой невозможно. Но при любой команде, большой или маленькой, календарные планы дают возможность руководителям и финансистам проекта ставить вопросы, вносить поправки и оказывать помощь команде разработчиков, выявляя возникающие проблемы и оперативно реагируя на них.
Осознавая эти три цели, нетрудно заметить, что даже самые совершенные календарные планы не решают всех проблем проекта. Планы не могут исправить неудачный проект или его техническое воплощение, не могут защитить проект от слабого руководителя, нечетко сформулированных целей и плохо организованного взаимодействия. Поэтому, сколько бы времени не было затрачено на создание календарных планов, они все равно останутся лишь набором слов и цифр. А вот будут ли они использованы в качестве инструмента управления проектом для его успешного продвижения – зависит от конкретных людей. Осознавая это, пора вытащить толстое руководство и на примере создания программных продуктов исследовать тяжеловесные методологии управления проектами.
Решающие факторы и методологии
Существует множество различных систем планирования и управления, ориентированных на разработку программного обеспечения. Эти системы часто называют
Однако целью главы, да и всей книги, не является сравнение различных методологий. Я полагаю, что есть концепции, положенные в их основу, и именно ими нужно овладеть, дабы добиться успеха при использовании любой методологии. Во всех случаях методологии нуждаются в корректировке и адаптации под особенности команды и проекта, а такая адаптация возможна только при наличии базовых знаний, более глубоких, чем знание самих методологий. Итак, если вы сможете воспринять и применить основополагающие идеи, рассматриваемые в данной главе и во всей остальной книге, то независимо от применяемой методологии ваши шансы на успех возрастут. Я намерен объяснить аспекты некоторых методов, по мере необходимости прояснения некоторых вопросов, но если вы коллекционируете информацию о методологиях, лучше обратиться к другим источникам.[9]
При всей своей важности для разработки программных средств методы не являются решающими факторами. Нет ничего хуже, чем слепо следовать наборам абсолютно несостоятельных правил только потому, что они изложены в популярных книгах или проповедуются многоуважаемыми гуру. Очень часто я убеждаюсь, что одержимость процессом – весьма тревожный знак, свидетельствующий о затруднениях в руководстве: это может быть попыткой переложить обычные проблемы и ответственность, с которыми сталкиваются руководители, на систему процедур и бюрократических приемов, подменяющих необходимость осмысленных руководящих действий. Возможно, намного более пагубным для команды разработчиков может стать пристрастие к методологии, которой в организации отводится чуть ли не первостепенная роль. Том Демарко (Tom DeMarco) в своей книге «PeopleWare» (Dorset House, 1999) («Человеческий фактор в программировании») отмечал:
Навязчивая идея применения методологий на рабочем месте – еще один пример высокотехнологичной иллюзии. Она берет начало из веры в то, что технология – это единственное, что на самом деле имеет значение… Какими бы ни были технологические преимущества, они могут быть получены только за счет существенного ухудшения социального климата в команде разработчиков.
Сосредоточенность на приемах и методах, подменяющая организацию процесса, направленного на поддержку человеческого фактора, приводит к тому, что планирование проектов начинается с наложения ограничений на вклад каждого из участников в его реализацию. При этом может быть установлена уйма правил и инструкций, вместо того чтобы подумать о корректировке или совершенствовании этих правил. Поэтому будьте очень осторожны в применении любой методологии: она не должна подавлять инициативу команды.[10] Наоборот, она должна стать средством поддержки, стимуляции и помощи команде в продуктивной работе (советы по организации процессов см. в главе 10).
Использование конкретной методологии не может быть единственной причиной своевременного или несвоевременного завершения проекта. Существуют факторы, воздействующие на все проекты, и руководители проектов должны в них разобраться до того, как приступать к любой работе по составлению календарных планов. Но перед тем как говорить об этом, нужно поговорить о составляющих календарного плана.
На что похож календарный план
Существует одно основное правило составления всех календарных планов – так называемое «правило трех частей». При всей его приблизительности и упрощенности оно предлагает самый простой подход к пониманию сути календарных планов. Если у вас уже есть опыт составления календарных планов, то немного потерпите, поскольку я представлю весь процесс в слишком упрощенном виде. Это делается, чтобы заложить элементарную основу для объяснения, что может не получиться, почему это может произойти и как с этим справиться.
Правило трех частей работает следующим образом: все отпущенное время разбивается на три части: проектирование, разработку и тестирование. В зависимости от используемой вами методологии эти части могут называться по-другому, но во всех методологиях предусматривается выделение времени на реализацию этих трех этапов. В любой конкретный день или час вы либо определяете то, что должно быть сделано (проектируете), либо фактически создаете продукт (пишите программный код), либо проверяете, анализируете и совершенствуете сделанное (проводите тестирование).
В соответствии с правилом, на каждый день, отводимый на разработку программного кода, выделяется день на планирование и проектирование и день на проверку и доводку сделанного (рис. 2.1). Вряд ли что-нибудь еще может быть проще – перед вами простой механизм проверки любых существующих календарных планов или создания календарного плана «с нуля». Если все отведенное на реализацию проекта время не разделено приблизительно на три равных этапа работы, должны быть вполне объяснимые причины, почему проекту требуется неравномерное распределение усилий. Если позволяют сроки, правило трех частей допускает некоторый дисбаланс, при котором считается нормальным отводить на тестирование на двадцать и более процентов времени больше, чем на разработку.
Рис. 2.1. Простейшая схема календарного плана, созданного по правилу трех частей
Рассмотрим гипотетический проект разработки веб-сайта: если вам на его запуск отвели шесть недель, то первым шагом должно стать деление этого времени приблизительно на три части и на основе полученного результата вычисление времени завершения работы. Если оказывается, что времени на работу с ожидаемым высоким уровнем качества не хватает, значит, что-то в корне неправильно. Надо либо менять календарный план, либо сокращать предполагаемый объем работ (или снижать ожидаемое качество). Выкраивание времени за счет тестирования всего лишь увеличит шансы на то, что время, потраченное на написание кода, уйдет впустую, или будет получен код, малоприспособленный для управления и поддержки. Правило трех частей полезно тем, что заставляет выявить ситуацию, при которой выигрывая в одном, проигрываешь в другом. Добавление новых возможностей выливается не только в дополнительную работу программиста по их реализации, но и влечет за собой неизбежные издержки на проектирование и тестирование, на которые кто-то должен идти. Когда календарный план срывается, причина заключается в неучтенных скрытых или проигнорированных издержках.
Стоит рассмотреть и самый простой вариант: отсутствие проекта как такового. Вся работа делается по мере поступления заказов, которые сравниваются по объему с другой работой и включаются в следующее свободное место календарного плана. Некоторые команды разработчиков, создатели веб-сайтов или отделы программирования информационных систем часто именно таким образом и действуют. Эти организации редко вкладывают деньги в крупные проекты или вообще за них не берутся. Гибкие методы (которые будут вскоре рассмотрены) в силу присущей им возможности перенаправления усилий, простоте и ожидаемости изменений часто рекомендуются таким командам в качестве наиболее естественной системы организации работы. Если вы работаете сразу над несколькими мелкими заданиями (не проектами), вам придется экстраполировать приводимые в данной книге примеры, ориентированные исключительно на проекты.
И все же правило трех частей применимо и к этим ситуациям. Даже если каждый программист работает в одиночку над выполнением мелких заданий, он, вероятнее всего, затрачивает примерно одну треть общего времени на разработку алгоритма, одну треть – на его реализацию и одну треть – на проверку и отладку. Он может перескакивать по этим этапам взад и вперед каждые несколько минут, но для упрощенного понимания работы какой бы то ни было разновидности правило трех частей применимо для любого масштаба.
Разделяй и властвуй (большие планы равны множеству мелких)
Изучая большинство методологий разработки программного продукта, вы можете обнаружить, что в их основу заложено правило трех частей. Преследуемые при проектировании или разработке конкретные цели и используемые подходы могут существенно различаться, но желаемые результаты на самом высоком уровне схожи.
Там, где проекты усложняются из-за своей объемности или продолжительности, календарные планы делятся на части, каждая из которых имеет собственные периоды проектирования, разработки и тестирования. В экстремальном программировании (Extreme Programming, XP) такие части называются итерациями, в спиральной модели – фазами, а в некоторых организациях их называют этапами. Хотя в XP считается, что эти отрезки времени занимают всего несколько недель, а в спиральной модели счет идет на месяцы, в них заложена одна и та же фундаментальная идея: создание подробных календарных планов для ограниченных периодов времени.
Чем больше ожидаемых изменений и проектных отклонений, тем короче должен быть каждый этап. Таким образом снижается степень суммарного риска, связанного с выполнением календарного плана, поскольку общий план оказывается поделенным на управляемые фрагменты. Такое деление календарного плана на этапы предоставляет естественную возможность вносить коррективы и повышает шансы на более четкую организацию работ на следующем этапе. (О том, как это делается, рассказывается в главе 14.)
Экстремальное программирование и другие гибкие методы предполагают, что будущее всегда изменчиво, поэтому они делают ставку на процессы, включающие естественные изменения направления. Дорогостоящие проекты (скажем, строительство небоскреба, создание игровой видеоприставки или встроенной операционной системы) реализуются по-другому и предполагают большие затраты на планирование и проектирование. При реализации проекта каждый должен следовать решениям, принятым в процессе проектирования, а непомерно высокая стоимость внесения изменений приводит к единственно возможному пути реализации.
Большинство проектов по разработке программных продуктов представляют собой нечто среднее. В них присутствует некое первичное планирование, но для того чтобы справиться с будущими изменениями требований и желаний заказчиков, работа делится на фазы, в которых время распределяется на проектирование, разработку и проверку качества. Если возникают новые проблемы, их можно решить в течение текущей фазы или поместить в очередь работ для более тщательной проработки и осмысления в следующей фазе.
Поделиться книгой: