Недавно снова вспомнил свою статью про качества хорошего ScrumMaster, без которых пользы от него команде мало. И в обсуждениях сторонники “классических” подходов начали утверждать, что для успешной работы с командой нужна власть. Это очень забавное мнение на мой взгляд, поэтому я решил посвятить ему отдельную небольшую статью.

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

Вла́сть — это возможность навязать свою волю, управлять или воздействовать на других людей, даже вопреки их сопротивлению. Суть власти не зависит от того, на чём основана такая возможность. Власть может базироваться на различных методах: демократических и авторитарных, честных и нечестных, насилии и мести, обмане, провокациях, вымогательстве, стимулировании, обещаниях и т.д.

Навязать свою волю и свое мнение команде… А зачем? А что если видение менеджера на способ достижения цели неверное или неоптимальное? Для чего мы проводим детальные собеседования и отбираем опытных кандидатов, которые могут думать и принимать решения самостоятельно? Чтобы потом навязывать им свою волю и мнение? Разве лучше решение проблемы не рождается в коллективном обсуждении специалистов своего дела?

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

Очень часто менеджеры пытаются подменить лидерские навыки наличием власти. Вместо плотной работы с человеком они “эскалируют” проблемы на его ресурс-менеджера, навязывают команде “улучшения” на ретроспективе вместо того чтобы услышать голос самой команды, строят “Agile” процесс разработки в их понимании этого термина вместо того, чтобы выработать его совместно с командой с учетом всех особенностей проекта. При этом никто в команде не видит в таком менеджере пользы и слушает его только потому что “он есть власть”. Сильным разработчикам такое не нравится и они просто уходят в другой проект или другую компанию. Остаются те, кому комфортно плыть по течению…

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

Вот где действительно нужна “власть” менеджера, так это за пределами команды, чтобы создавать команде комфортные условия для работы и убирать препятствия с ее пути. Менеджер должен:

– уметь работать со сложным клиентом (stakeholder management), чтобы команда не сталкивалась с его “придурью” и не демотивировалась;
– знать как организовать работу с требованиями и кого привлечь для этого на стороне клиента, чтобы команде они поступали в готовом к разработке виде согласно definition of ready (requirements management);
– уметь анализировать, собирать из разных источников, включая команду, и классифицировать проектные риски (risk management), которые потом становятся темой регулярных обсуждений с клиентом и командой;
– решать финансовые и инфраструктурные вопросы внутри компании и за ее пределами (budgeting and infrastructure management), используя свою позицию и возможности для обеспечения нужд проекта;
– находить подходящих людей в рамках компании и за ее пределами для усиления команды согласно ее запросам и нуждам (resouce management);
– и т.д.

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