Скотт Беркун - Искусство управления IT-проектами

• Название: Искусство управления IT-проектами
• Автор: Скотт Беркун
• Жанр: Прочая околокомпьтерная литература
• Год: 2014
• ISBN: 978-5-388-00543-4

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

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

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

---

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

Давление и распри

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

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

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

Путаница в понятиях процесса и целей

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

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

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

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

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

В главе 10 мы узнаем, что книжные предписания или указания руководителя на создание какого-то продукта или сам факт, что предписываемая методика использовалась в прошлом месяце или году, не являются основанием для того, что все это применялось и сегодня. Все команды и проекты отличаются друг от друга, поэтому существуют весьма веские основания, чтобы подвергнуть сомнениям все прежние положения. Причина консерватизма в применяемых методах и процессах кроется в том, что излишества в данном вопросе могут превратиться в снежную лавину, увлекающую за собой команду в вязкую западню сложных проектов, как об этом говорится в книге Фрэда Брукса (Fred Brooks) «The Mythical Man-Month». Когда от процессов требуется управление процессами, трудно понять, где осуществляется реальная работа. Именно руководителю команды или проекта чаще всего предоставляется великолепная возможность управлять командой без бюрократических излишеств или наоборот послать ее на полной скорости в нескончаемый водоворот различных процедур и заседаний.

Нужная степень вовлеченности

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