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

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

Убеждение сильнее диктата

В процессе руководящей деятельности я понял, что убеждая людей перед тем, как заставлять их что-нибудь делать, можно извлечь намного больше пользы. Воспользоваться властью тирана и поставить всех на место может любой идиот – для этого не надо никакого мастерства. Но убедить умного человека (или группу людей) в том, что изначально нежелательная для него (или для них) работа является нужной, хорошей и даже, возможно, полезной для него (для них), намного сложнее. Когда люди потратят на работу не один час и начнут сомневаться в ее целесообразности, они не смогут предъявить вам никаких претензий. Чтобы понять, на что именно они тратят свое время, занимаясь текущей работой, они смогут воспользоваться собственными рассуждениями, подкрепленными вашей аргументацией.

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

При необходимости покажите свою власть

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

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

Оказание доверия

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

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

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

Передача полномочий

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

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

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

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