Майкл Лопп - Как управлять интеллектуалами. Я, нерды и гики

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

Эти люди действительно сильны в таких делах. Они добиваются в таких делах больших успехов. Инженерам трудно это понять. Тут та же проблема, что и с руководителями. Инженеры видят, как эти странные человеческие существа сосредоточенно носятся туда-сюда, и спрашивают: «Что, собственно говоря, эти люди разрабатывают?» Они правы. Менеджеры проекта не пишут код, они не тестируют сценарии использования софта и не разрабатывают дизайн интерфейса. Знаете, что делает хороший менеджер проекта? Он машина по разрушению хаоса; каждый новый человек, которого вы нанимаете в команду, каждая новая взаимозависимость, которую вы создаете, привносит в вашу команду еще больше трудноизмеримой энтропии. Хороший менеджер проекта эффективно оценивает, контролирует и разрушает энтропию.

Да, когда вас в команде было всего пятеро, вы делали всё просто и легко, но если вы собираетесь успешно дорасти до 105 человек, значит, то, что раньше протекало органично, теперь должно выполняться механически.

Проблемы руководителей проекта

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

Я переживаю из-за того, что менеджеры проекта будут оказывать слишком сильное влияние на развитие продукта. Тут есть два важных момента. Во-первых, помните, что вы больше не пребываете в мире, где все отвечают за всё. Да, вы скучаете по тому миру, потому что в нем вы могли так быстро реагировать, но сейчас вы стали просто-напросто слишком большими для него. Вам нужно распределить роли, а это значит, что вам нужно быть предельно ясным и понятным для всех: «Это отдаем Бобу, это отдаем Фрэнку, эту штуковину отдаем Перси». Рэндс, что значит «отдаем»? Я рад, что вы задали этот вопрос.

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

Второй момент. Какой руководитель (надутый индюк) не хочет, чтобы каждый отдельный сотрудник в командеимел свое собственное мнение о продукте? У хороших менеджеров проекта есть уникальная интуитивная способность чувствовать «состояние здоровья» проекта, потому что в этом и заключается их работа — видеть все компоненты механизма насквозь. Всем кажется, что у них есть компетентное мнение по поводу продукта.

Я переживаю из-за того, что могу утратить видение того, что происходит. У меня для вас плохая новость! Как я говорил ранее, это уже происходит; это происходит каждый раз, когда вы берете в команду нового человека с его собственным набором мнений, ценностей и опыта. Эффективный менеджер проекта инстинктивно создает артефакты интуитивного знания проекта. Их первый вопрос, когда они «выходят на сцену», звучит так: «Что, черт возьми, здесь происходит?» Ваш первый диалог с вашим новым менеджером проекта будет выглядеть примерно так. Вы говорите: «Я хочу измерить Х, Y и Z, причем я хочу измерять их на еженедельной основе». Менеджер проекта примет ваш запрос и будет из кожи вон лезть, чтобы раздобыть для вас эти данные (и людей, генерирующих эти данные), эффективно механизирует сбор этих данных и, в итоге, представит вам артефакт. Объем работы, необходимый для добычи этого артефакта, варьируется в широчайшем диапазоне в зависимости от уровня хаоса в вашей команде, но если вы не видите хотя бы проекта какого-нибудь ценного артефакта через два-три месяца, значит, что-то идет не так.

В моей команде нет ерундовой работы.Эта проблема возникла в голове человека, не понимающего роли менеджера проекта или однажды пострадавшего от слабого менеджера проекта. Вероятнее всего, это произошло примерно на таком совещании. Вы всей командой сидите на совещании; ваш менеджер проекта показывает на большом экране диаграмму Ганта и высказывает свое лишь наполовину компетентное мнение как факт: «Через три месяца мы выпустим продукт!» Все думают одно и то же, но никто не говорит вслух: «Бред!» Этот лишь наполовину компетентный человек бессвязно перескакивает с одной мысли на другую в течение дальнейших 30 минут, затем совещание заканчивается, и все шаркающей походкой расходятся по местам. Репутация менеджера проекта как «генератора бреда» лишний раз укрепилась. Это был пример слабого совещания, причины которого кроются в слабой работе менеджера проекта.

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

Один из самых легких способов обеспечить провал менеджера проекта заключается не в высказывании ваших ожиданий от его роли. Провал, который я не раз наблюдал, выглядел примерно так. Парень, облеченный высокой должностью, говорит менеджеру проекта: «Что ж, это выглядит плохо! Знаете, в Apple у нас были менеджеры проекта, которые сами были разработчиками. Нам тоже нужны такие! Иди и найми на работу таких людей!»

Это неверный подход! Вы не Apple, и вы никогда ими не станете. То, что вашей команде и вашей корпоративной культуре требуется от руководителя проекта, полностью зависит от вас самих, от команды, от ее корпоративной культуры, от ваших проектов и от конкретного момента времени. Навязывание инициатив сверху без глубинного понимания ситуации внутри команды — это страшный путь, ведущий к провалу новой роли. Появление менеджеров проекта (или как вы их будете называть) должно совпадать с явно присутствующей в данный момент угрозой для продукта или для команды. Они здесь, чтобы помочь нам с Х, потому что мы не можем решить проблему Х и мы в панике.