Сделано
Шрифт:
Но отсутствие МП порой чревато серьезными проблемами. Личные интересы одного члена команды могут легко сбить с толку остальных, если не появится кто-то, способный взять под контроль всю работу команды. Среди проектировщиков и бизнес-аналитиков формируются враждебные фракции, замедляя прогресс и препятствуя работе других членов команды.
В больнице один из врачей несет ответственность за лечение пациента. Это ускоряет процесс принятия решений и дает четкое представление об обязанностях каждого сотрудника отделения. Команда разработчиков без руководства может попасть в довольно затруднительное положение в случае проблем. Если никто не проводит триаж ошибок или не следит за графиком работы и не отмечает проблемные моменты, это серьезно повлияет на результат.
Многие программисты достаточно хорошо разбираются в проект-менеджменте, чтобы
Программный и проектный менеджмент в Microsoft
В конце 1980-х годов Microsoft столкнулась с проблемой координации технической работы с задачами маркетинга и бизнеса (некоторые скажут, что это до сих пор остается проблемой для Microsoft и многих других компаний). Мудрый человек по имени Джейб Блюменталь придумал должность, на которой человек одновременно будет выполнять лидерские и организационные функции. Ему предстояло работать над проектом с первого дня планирования и до последнего дня тестирования. Он должен был разбираться в технических вопросах настолько, чтобы завоевать уважение программистов, уметь широко смотреть на продукт, а кроме того с радостью заниматься написанием спецификаций, анализом маркетинговых планов, составлением графиков, управлением командами, стратегическим планированием, триажем ошибок, мотивированием команды и любой другой необходимой работой, которую не выполняет никто иной (по крайней мере, достаточно хорошо). Новая должность в Microsoft получила название программный менеджер. Он обладал значительными полномочиями, хотя не все члены команды находились в его прямом подчинении. (В теории менеджмента это пример матричной организационной структуры [17] , которая предполагает двойное подчинение: в зависимости от должности сотрудника и в зависимости от проекта. Так, программист или тестировщик подчиняются двум менеджерам.)
17
Резюме матричной организационной структуры и других типов см. Steven A. Silbiger The Ten-Day MBA (William Morrowand Company, 1993) (Силбигер С. МВА за 10 дней. Самое важное из программ ведущих бизнес-школ мира. М.: Альпина Паблишер, 2018), pp. 139–145. Хотя информацию можно найти почти в каждой книге по теории менеджмента.
Джейб стал программным менеджером в работе над продуктом под названием Multiplan (позже его переименовали в Microsoft Excel), и успех не заставил себя ждать. Улучшились процессы проектирования и разработки и координация работы команды, и все были счастливы. После многочисленных совещаний и рабочих встреч команды адаптировались к новой роли. Поручив конкретные обязанности линейному эксперту широкого профиля, Microsoft навсегда изменила динамику работы команд разработчиков. Практически все время работы в Microsoft я как раз выступал в роли программного менеджера. Я работал с продуктовыми командами Internet Explorer, MSN и Windows и даже руководил командами программных менеджеров.
И по сей день я не смогу назвать много компаний, которые бы решили переосмыслить и формализовать отдельную форму проектного менеджмента. В своих многочисленных взаимодействиях с другими фирмами, которые занимались разработками и софтом, я редко встречал человека, который исполнял бы схожие обязанности (либо это были разработчики, либо специалисты по маркетингу, либо, в редких случаях, проектировщики). Многие компании используют командную структуру для организации работы, однако редко кто выделяет роли, которые совмещают функции проектирования и бизнеса. Сегодня в Microsoft трудятся более 5000 программных менеджеров (из 80 000 сотрудников), и хотя изначальный смысл этой концепции уже давно исказили, многие команды еще придерживаются основных принципов.
Однако независимо от того, что было написано на моей визитке или каким легендам Microsoft вы верите, мои ежедневные обязанности в качестве программного менеджера совпадали с функциями менеджера проекта. В двух словах, это означало, что я ответственен за успех проекта – и всех, кто в нем участвует. Все главы этой книги отражают основные задачи, связанные с этой функцией, от предварительного планирования ( глава 3 и глава 4 ) до
Помимо перечисленных навыков, пригодятся определенные личные характеристики и отношение к работе – иначе каждый, кто руководит или управляет проектом, окажется в невыгодном положении.
Сбалансированность проектного менеджмента
Сложно найти хороших менеджеров проекта, потому что им нужно гармонично сочетать в себе разные мировоззрения. В своем эссе Pursuing the Perfect Project Manager [18] Том Питерс называет их парадоксами или дилеммами. Это подходящее название, потому что разные ситуации требуют разного поведения. Менеджер проекта должен не только осознавать все необходимые черты характера, но и выработать в себе чутье, чтобы чувствовать, какие из них приемлемы в тех или иных случаях. Такой взгляд наталкивает на мысль о том, что проект-менеджмент – все-таки искусство: оно требует интуиции, суждения и опыта, чтобы эффективно применять все эти умения. Вкратце перечислим характеристики из эссе Питерса.
18
http://www.tompeters.com/col_entries.php?note=005297&year=1991.
• Эгоизм / альтруизм. Из-за колоссального объема ответственности менеджеры проекта зачастую черпают огромное личное удовлетворение в работе. Как вы понимаете, они вкладывают немало эмоций в свое дело, и зачастую именно это позволяет им выдержать его интенсивность. Однако в то же время менеджеры проекта не должны ставить личные интересы превыше проекта. Они должны быть готовы делегировать важные или интересные задачи и делить славу со всей командой. Хотя эго может быть полезным топливом, грамотный менеджер проекта должен чувствовать, когда он перегибает палку.
• Авторитарность / делегирование полномочий. В некоторых ситуациях самое важное – четкое руководство и быстрый отклик. Менеджер проекта должен быть достаточно уверенным и жестким, чтобы контролировать работу и навязать определенные решения команде. Однако общая цель – избегать подобных крайностей. Проект должен создавать условия, где полномочия можно делегировать и эффективно сотрудничать.
• Терпимость к неопределенности / стремление к завершенности. Ранние этапы любого проекта – абсолютно открытый и изменчивый опыт, где неизвестное перевешивает известное. Как мы обсудим в главе 5 и главе 6 , контролируемая неопределенность необходима для поиска хороших идей, и менеджер проекта должен чтить эту особенность, даже если не удается управлять ею. Однако есть моменты, особенно на более поздних этапах проекта, когда дисциплина и точность имеют первостепенное значение. Нужна мудрость, чтобы понять, когда стремление к завершенности оправдано, а когда вполне достаточно решения на скорую руку (раздел «Поиск и оценка вариантов» в главе 8 ).
• Устное / письменное общение. Хотя большинство софтверных организаций делает основной акцент на электронную почту, устные навыки общения критически важны. Всегда будут собрания, переговоры, обсуждения в кулуарах и мозговой штурм. МП должен уметь воспринимать и выдавать идеи в личном общении. Чем масштабнее организация или проект, тем важнее становятся навыки письменного общения. Несмотря на личные предпочтения, менеджер должен понимать, в каких случаях эффективнее письменная форма общения, а в каких случаях – устная.
• Признавать сложность / отстаивать простоту. Многие становятся жертвой сложности. Столкнувшись с организационными или инженерными трудностями, они тонут в частностях и забывают об общей картине. Некоторые предпочитают отрицать сложность и принимать неудачные решения, потому что плохо воспринимают все тонкости ситуации. Баланс состоит в том, чтобы понимать, какой подход к проекту принесет больше пользы для текущей проблемы, и умело переключаться между разными подходами или держать их в голове одновременно (только чтобы голова не взорвалась при этом). Менеджеры проекта должны убедить команду стремиться к простоте в работе, не приуменьшая при этом всю сложность, связанную с созданием правильного, надежного кода.