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

Чем больше становится организация, тем больше приходится опираться на предоставленную власть. Лидеры испытывают немалую озабоченность проблемами слаженной работы коллектива (или, возможно, проблемами предотвращения революционных взрывов), и здесь существует стойкое поверье, что на индивидуальные беседы и общение со всеми работниками организации, что подразумевает применение заслуженной власти, просто не хватит времени. Я знаю некоторых лидеров даже небольших команд, которые не верят, что у них хватит сил или времени на реализацию такого стиля руководства по отношению к своим ключевым разработчикам. Решить проблему можно с помощью другой разновидности доверия, называемой делегированием полномочий, когда людям доверяется самостоятельное принятие решений.

Полномочия и доверие часто аккумулируются вокруг различных задач или областей знаний. Джо может получить наибольшие полномочия, когда дело касается объектов C++, зато Салли лучше всех умеет работать с базами данных. В здоровой среде общения товарищей по команде уровень взаимного доверия вполне достаточен, чтобы признавать за кем-то более высокую степень мастерства или лучшее видение предмета и, не опасаясь столкновений с какими-нибудь препятствиями или чьими-то насмешками, просить у такого человека дельного совета. Хотя опасение и не лишено смысла, поскольку в инженерных дисциплинах в отношении запросов о помощи культивируется пассивно-агрессивное поведение (в ходу, например, аббревиатура rtfm [73]). Даже в колледжах на отделениях информатики самостоятельность считается основой компетентности, и если студенты просят помощи у своих сокурсников, это рассматривается как признак слабости.

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

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

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

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