Текст книги "Искусство управления IT-проектами"

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

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

К примеру, как-то утром, работая над проектом IE 5.0, я заглянул в офис Фрэда. Он спорил со Стивом, другим программистом, о том, как они собираются заставить заработать элемент управления для просмотра списка, после того как утром внезапно обнаружились проблемы его совместимости с другими компонентами. Никто из них не хотел с этим связываться. И, исходя из всего мною услышанного, на исправление элемента должно было уйти не менее половины рабочего дня. Я подключился к разговору и подтвердил все то, о чем они говорили. Они кивнули головами, словно спрашивая: «Зачем вам это нужно?» Я сказал, что им нужно пройти вниз и поговорить с Биллом. Они опять спросили, зачем, думая, что дело касается весьма тонких вопросов архитектуры проекта, в которых я не слишком-то разбираюсь. Я улыбнулся и сказал: «Дело в том, что я только что от него, и у него на машине есть уже новый великолепно работающий элемент управления. Минувшей ночью ему удалось решить проблему и все исправить попутно с выполнением других дел».

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

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

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

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

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

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

Выводы

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

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

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

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

• Руководство программами – это вариант руководства проектами, применяемый исключительно в корпорации Microsoft. Оно берет начало в идее матричной организации управления.

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

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

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

Упражнения

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

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

3. Придумайте повод и устройте вечеринку. (Вы выдержали чтение первой главы, чем не повод?) После преодоления похмельного синдрома и вызволения друзей из «кутузки», рассмотрите следующие вопросы: чем вечеринка отличается от проекта? Сравните трудности и награды за роль организатора вечеринки по сравнению с ролью руководителя реального проекта. В чем различия и сходства?

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

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

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

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

Часть 1. Планирование

Глава 2. Правда о календарных планах

Людям свойственно опаздывать. Они часто выбиваются из повседневного графика, пусть всего на несколько минут или пару раз в неделю. (Поскольку возражать люди научились ничуть не хуже, я пойму, если вы откажетесь принимать это утверждение на свой счет.) Студенты опаздывают на занятия, сотрудники – на рабочие совещания, а друзья приходят в бар на десять минут позже назначенного времени. Мы считаем, что понятие «вовремя» относится не к конкретному моменту, а к какому-то интервалу времени, который может быть для кого-то шире, чем для всех остальных. Характерный пример – старшие официанты. Они вас уверяют, что столик вот-вот будет готов, но при этом зачастую заставляют ждать значительно дольше объявленного.[7]7
  Как-то в Питтсбурге мы с приятелями зашли пообедать в пиццерию и получили заверение, что столик будет готов через десять минут. Ровно через десять минут мой друг Чад МакДаниел поинтересовался готовностью столика и получил ответ распорядителя, что все будет готово через десять минут. Тогда он спросил: «Это те же десять минут или другие десять минут?» – но его шутку должным образом так и не оценили.


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

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

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

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

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

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

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

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

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

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

Существует множество различных систем планирования и управления, ориентированных на разработку программного обеспечения. Эти системы часто называют методологиями, то есть наборами методов, направленных на достижение конечного результата в конкретной области. Среди основных методологий разработки программных продуктов можно отметить водопадную и спиральную модели, ускоренную разработку приложений, экстремальное программирование и функционально-ориентированную разработку.[8]8
  В оригинале «Feature-driven development». – Примеч. ред.


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

Однако целью главы, да и всей книги, не является сравнение различных методологий. Я полагаю, что есть концепции, положенные в их основу, и именно ими нужно овладеть, дабы добиться успеха при использовании любой методологии. Во всех случаях методологии нуждаются в корректировке и адаптации под особенности команды и проекта, а такая адаптация возможна только при наличии базовых знаний, более глубоких, чем знание самих методологий. Итак, если вы сможете воспринять и применить основополагающие идеи, рассматриваемые в данной главе и во всей остальной книге, то независимо от применяемой методологии ваши шансы на успех возрастут. Я намерен объяснить аспекты некоторых методов, по мере необходимости прояснения некоторых вопросов, но если вы коллекционируете информацию о методологиях, лучше обратиться к другим источникам.[9]9
  Сравнительное обсуждение традиционных и гибких методов разработки программных средств вы сможете найти в книге Барри Боэма (Barry Boehm) и Ричарда Тернера (Richard Turner) «Balancing Agility and Discipline: A Guide for the Perplexed» (Addison Wesley, 2003).


[Закрыть]

При всей своей важности для разработки программных средств методы не являются решающими факторами. Нет ничего хуже, чем слепо следовать наборам абсолютно несостоятельных правил только потому, что они изложены в популярных книгах или проповедуются многоуважаемыми гуру. Очень часто я убеждаюсь, что одержимость процессом – весьма тревожный знак, свидетельствующий о затруднениях в руководстве: это может быть попыткой переложить обычные проблемы и ответственность, с которыми сталкиваются руководители, на систему процедур и бюрократических приемов, подменяющих необходимость осмысленных руководящих действий. Возможно, намного более пагубным для команды разработчиков может стать пристрастие к методологии, которой в организации отводится чуть ли не первостепенная роль. Том Демарко (Tom DeMarco) в своей книге «PeopleWare» (Dorset House, 1999) («Человеческий фактор в программировании») отмечал:

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

Сосредоточенность на приемах и методах, подменяющая организацию процесса, направленного на поддержку человеческого фактора, приводит к тому, что планирование проектов начинается с наложения ограничений на вклад каждого из участников в его реализацию. При этом может быть установлена уйма правил и инструкций, вместо того чтобы подумать о корректировке или совершенствовании этих правил. Поэтому будьте очень осторожны в применении любой методологии: она не должна подавлять инициативу команды.[10]10
  Информацию об определениях и понятиях изменений процесса разработки программного обеспечения, а также об управлении этими изменениями можно найти в книге Уоттса С. Хамфри (Watts S. Humphrey) «Managing the Software Process» (Addison Wesley Professional, January 1989).


[Закрыть] Наоборот, она должна стать средством поддержки, стимуляции и помощи команде в продуктивной работе (советы по организации процессов см. в главе 10).

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