Делегировать или нет - вот в чем вопрос?

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

“Объяснив подчиненным, какая задача перед ними стоит, заставьте их ее решить…Способность к делегированию - это одно из качеств, которое вы, лидер, должны постоянно совершенствовать” - Дж. Ханк Рейвотер - “Как пасти котов”, Питер, 2006

“Some swing a lot toward the technical and risk losing touch with their team and thereby building the wrong thing or missing their dates. Some swing toward the management, losing touch with the technology and losing the respect of their developers. Of the two, swinging too much toward the technology is the biggest danger, but only by a little.” Chris Sells, Microsoft Program manager.

“При большом объеме задач, явно не соответствующих вашей компетенции и стоимости вашего времени, подумайте о покупке внешней услуги - секретаря, технического помощника и.т.п” Глеб Архангельский. “Тайм-Драйв”

“Я убежден, что если делегирование руководства осуществляется правильно, то обе стороны только выиграют от этого и гораздо больший объем работы будет выполнен за гораздо меньшее время” Стивен Кови. Семь “Навыков высокоэффективных людей.”

И есть ещё тысяча и один довод за делегирование. Причем, хочу обратить ваше внимание, обычно предлагается делегировать работу рутинную, “не соответствующую вашей компетенции” , монотонную, не творческую и тому подобное. Вообще-то я с ними со всеми согласен - это здорово сбросить на менее оплачиваемых помощников рутину, а самому заниматься решением действительно творческих и интересных задач, справиться с которыми способен только твой гений :-).

Кроме того, делегирование - это способ масштабирования работ. Если все задачи проходят через одного человека, то в какой то момент этот человек становится “узким местом”, “бутылочным горлом” , на котором застревают все дела и вопросы. И делегирование, правда уже не рутинных задач, а руководства какими-то направлениями (вполне себе по Стивену Кови) - это вероятно единственный способ избегать бутылочного горла.

Хорошо, раз я с ними со всем согласен (да и кто я собственно такой чтобы не соглашаться с мэтрами), то зачем этот пост? Я хочу привлечь внимание к обратной, темной стороне делегирования - потере квалификации и понимания происходящего.

Делегирование - это не только разгрузка от рутинной работы и возможность “масштабирования” руководства. Это ещё и способ хорошенько забыть все, что ты когда-то умел делать. Эти самые рутинные задачи порождают в нас мысли о том , как их выполнение автоматизировать. Это постоянные мучения с системой контроля версий позволяют нам понимать почему её нужно поменять на другую ( уж извините - примеры будут из программирования, так как это область с которой я лучше знаком). Это жутко медленно выползающее окошко Output заставляет нас говорить о том , что компьютеры нужно поменять на новые. Мы можем видеть прогресс проекта, только если мы занимаемся рутиной.

Большая часть работы, которой мы занимаемся, программирования - это именно рутина. Продумать алгоритм, разработать сложную и элегантную архитектуру - это здорово и интересно, но львиную долю времени занимает не это. “Технические вопросы”, как многие “менеджеры” их называют , могут занимают существенно больше времени. Как правильно устроить структуру проекта в системе контроля версий? Как правильно хранить ресурсы, так чтобы их было удобно локализовать? А как можно осуществить мониторинг запуска процессов в Windows? А почему ошибка не правильно передается в ATL attributed проекте? Все эти и подобные им вопросы возникают очень часто и в большинстве случаев являются хорошими кандидатами на делегирование.

Вот только в результате - теряется “чувство” проекта. Долго, долго тебе кажется что ты все это знаешь и понимаешь, а когда в какой-то момент кто-то заболевает и тебе приходится слезть со своего менеджерского пьедестала и спуститься в окопы, то оказывается что ты все забыл! То есть теория-то вроде есть, а вот практика … с ней хуже. Все верно, многое вспоминается довольно быстро, но тем не менее.

Рутина - это тренировка! Тренировка для мозгов и для рук. У культуристов есть такая поговорка “Чтобы много жать - нужно много жать”. Мне кажется, она справедлива не только в спорте. Технический менеджер конечно же должен делегировать задачи, особенно в большом коллективе, иначе он станет узким местом. Но он ни в коем случае не должен совсем сбрасывать с себя “рутину”. Иначе он перестанет быть частью команды - он станет эдаким живым Excel-ем, который просто каждое утро опрашивает всех о состоянии дел и считает что он знает в каком состоянии находится проект.

Не делегируйте все! Знайте меру! Это тяжело, но необходимо.