Юрген Аппело - Agile-менеджмент. Лидерство и управление командами

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

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

Гэри Хэмел, также один из известнейших бизнес-мыслителей и авторов, в своей книге «Будущее менеджмента» [106]описал пять принципов «управления компаниями в XXI веке» [Hamel 2007]. Эти принципы таковы: жизнь (порождение разнообразия), рынки (гибкость при распределении ресурсов), демократия (поощрение активности), вера (понимание смысла) и существование крупных городов (создание предпосылок для возникновения случайных удачных открытий) .

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

Существуют еще десятки, если не сотни, моделей менеджмента. Я решил включить в свой обзор и сравнить лишь несколько, которые были предложены наиболее уважаемыми и знающими авторами. (Я не хочу причинять вам страдания, заставляя читать от корки до корки источники с названиями вроде «Сто сорок два закона лидерства, применяемых жрецами, священниками и военными».) Моя цель – подчеркнуть, что ни одна из моделей не может быть идеальной и каждая может оказаться весьма полезной.

Но не только менеджерам приходится иметь дело с обилием конкурирующих моделей, аналогичная ситуация существует и в области разработки ПО. Эксперты по Agile без конца повторяют, что для того, чтобы правильно использовать Scrum или XP, «разработчики должны перепроектировать код». Кто-то утверждает, что «всем нужны юнит-тесты» или что «Scrum все ухудшает из-за того, что игнорирует инженерные практики» и что «ты не гибкий, если не используешь непрерывную интеграцию каждый день». Для этих экспертов Agile не про адаптацию и выполнение всего возможного для того, чтобы проект был долгое время успешным. Если верить этим Agile-экспертам, гибкость – это следование практикам X, Y и Z. Но это очередное заблуждение.

Гибкость – это способность оставаться успешным в постоянно меняющейся внешней среде.

Я

Вот и все, к этому нечего добавить.

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

Некоторые практики гибких методологий предлагают вообще отказаться от бренда «гибкие» или «Agile-методологии». В конце концов, поскольку данный термин так и не получил ясного определения, гибкими иногда называют даже дисфункциональные проекты. Это возможно только потому, что гибкие методологии не предписывают выбор конкретных методов и инструментов. Но это естественно, поскольку универсальных практик просто не существует! Если бы они имелись, мы могли бы прописывать любой сложной системе одну и ту же стратегию выживания, а это напрямую противоречит природе сложности (и более конкретно – теории игр). В задачу гибких методологий никогда не входило рекомендовать определенный набор практик. В Agile-манифесте нигде не сказано, что вы должны непременно применять автоматизированное тестирование, парное программирование или рефакторинг. (Я был бы не в состоянии написать книгу по гибким методологиям, если бы какие-либо из практик были обязательными.) Как только люди начинают считать ту или иную практику обязательной, само словосочетание «гибкая практика» становится логически противоречивым.