Скотт Беркун - Сделано

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

Как мы обсудим в главе 10, если книга или руководитель велят что-то делать или если тот же метод использовался в прошлом месяце либо в прошлом году, это еще не значит, что его следует применять сегодня. Каждая команда и проект разнятся. Зачастую можно найти немало веских причин, чтобы подвергнуть сомнению старые принципы и убеждения. Методы и процессы нужно выбирать крайне осторожно, имея в виду, что они разрастаются и затягивают команду в «смоляную яму сложных проектов», как говорится в книге Фреда Брукса «Мифический человеко-месяц». Когда одни процессы нужны для управления другими процессами, сложно понять, где выполняется реальная работа. Зачастую именно МП обладает возможностью избавить команду от бюрократии или же, напротив, толкнуть ее на бесконечный круг процедур и «комитетного» мышления.

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

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

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

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

У меня была привычка ходить по коридорам и заглядывать к программистам. Обычно я обменивался с ними парой слов, рассказывал анекдот и просил показать, над чем они работают. Иногда смотрел демо-версию. Я делал это раз в два-три дня, тратил всего несколько минут и прекрасно представлял себе реальный статус проекта (в главе 9 мы обсудим этот принцип управления – метод хождения).

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