Сделано - страница 11

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

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

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

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

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

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