Я чувствую, что не в состоянии завершить эту книгу должным образом. Такое впечатление, что любое описание гибкого менеджмента все равно неполно и каждый мой вывод можно поставить под сомнение.
Начать мыслить в категориях сложности – все равно что жениться на черной дыре. Чтобы сохранить рассудок, лучше с такими вещами вообще не связываться. И все же это очень привлекательный способ смотреть на окружающий мир. А кроме того, вас все равно затянет, и в результате все, во что вы верили, либо окажется опровергнутым, либо превратится в ничто. А я верю во множество вещей.
Шесть компонентов Менеджмента 3.0
Я считаю, что линейное мышление часто приводит нас к неверным выводам (см. главу 1) и что у гибких методологий разработки ПО и теории сложности имеется общий фундамент в виде нелинейного мышления (главы 2 и 3). Я полагаю, что люди – это самый важный элемент организаций и менеджерам необходимо прилагать максимум усилий, чтобы поддерживать в них активность, креативность и мотивацию (главы 4 и 5). Я уверен, что команды способны на самоорганизацию и для этого необходимо предоставлять им широкие права и полномочия, а также распространять на них доверие со стороны менеджмента (главы 6 и 7). В главах 8 и 9 показано, что самоорганизация может приводить к нежелательным последствиям и поэтому необходимо защищать людей и находящиеся в общедоступном пользовании ресурсы, а также ставить перед командами четкие цели. Я также считаю, что некомпетентные команды не смогут достичь поставленных целей и по этой причине в фокусе внимания менеджеров должно находиться развитие компетенций сотрудников (главы 10 и 11). Многие команды функционируют внутри сложных компаний, и поэтому я убежден, что важно уделять внимание созданию организационных структур, в которых коммуникация происходит без затруднений (главы 12 и 13). Я также думаю, что люди, команды и организации нуждаются в постоянном совершенствовании, чтобы в результате момент неудачи наступал как можно позже (главы 14 и 15). И наконец, мне иногда кажется, что поскольку мои выводы в этой книге достаточно просты для понимания, то это может быть симптомом, что они неверны.
На рис. 16.1 еще раз показана модель Менеджмента 3.0. В нее входит шесть компонентов, или точек зрения:
• Добавьте людям энергии.
• Расширяйте полномочия команд.
• Настройте ограничения.
• Развивайте компетенции.
• Выращивайте структуру.
• Улучшайте всё.
Я осознанно использую термин «точки зрения», а не «принципы» или «основы», чтобы подчеркнуть, что речь идет об одной и той же системе, рассматриваемой под разными углами зрения. Например, понятие «сообщество практикующих» (глава 13) хорошо вписывается по крайней мере в три компонента модели (компетенции, структура и улучшение). Рекомендация командам создавать свои ценности (глава 5) хорошо встраивается в такие компоненты модели, как добавление энергии, расширение полномочий команд и настройка ограничений. Мы действительно рассматриваем один и тот же объект с шести разных углов зрения.
Но как бы точно ни резюмировать содержание книги и как бы хороши ни были иллюстрации, теория сложности подсказывает мне, что любое простое описание менеджмента в гибких организациях будет незавершенным. Любое утверждение может быть опровергнуто мышлением в категориях сложности или вообще превратиться в ничто.
Это очень расстроило бы меня, если бы не тот факт, что вы дочитали книгу до этого места, – он все же несколько смягчает мои переживания по данному поводу.
Да, моя модель «неверна»
Причина моих переживаний – тот самый принцип несжимаемости:
Не существует точного (вернее, идеального) способа представить систему, кроме как предъявить саму эту систему. Создавая модели открытых систем, мы вынуждены исключать из рассмотрения какие-то их характеристики, а поскольку возникающие в результате такого исключения эффекты имеют нелинейный характер, мы не можем заранее сказать, насколько они впоследствии окажутся важными [101] .
Разрешите мне немного перефразировать это утверждение…
В главе 3 я упоминал, что в основе теории сложности лежит теория хаоса. Эффект бабочки (глава 14) позволяет продемонстрировать, какие далекоидущие последствия могут иметь даже самые небольшие отклонения в первоначальных параметрах сложной системы. Когда мы пытаемся моделировать и описывать сложные системы, то вынуждены опускать какие-либо элементы; в противном случае мы будем погребены под огромным количеством деталей. Проблема в том, что в сложных системах любые детали имеют значение, поэтому если их опустить, то результат может оказаться весьма неожиданным!
Принцип несжимаемости утверждает, что единственным точным представлением сложной системы будет она сама. Любые упрощенные модели неполны, потому что в них могут быть упущены существенные детали. В соответствии с той же логикой моя модель Менеджмента 3.0 также неполна. Сожалею, если вы разочарованы – но если вы искали простые решения, то явно выбрали не ту книгу. К счастью для нас, на помощь приходит Джеральд Вайнберг, один из отцов системного мышления, со своим законом дополнительности:
Любые две точки зрения дополняют друг друга [102] .
Несколько неполных моделей сложных систем могут оказаться достаточно точными и полезными, поскольку часто представляют собой дополняющие друг друга (а возможно, и противоречащие друг другу) способы смотреть на вещи [Richardson 2004a].
Не существует единой теории эволюции. Есть множество дополняющих друг друга, конкурирующих друг с другом и иногда противоречащих друг другу моделей. И тем не менее эта коллекция моделей обладает огромными описательными и прогнозирующими возможностями [McKelvey 1999: 19]. Нечто подобное наблюдается и в физике: принимаются обе модели – волновая и корпускулярная, – поскольку они обе дают точные описания происходящих процессов и позволяют надежно предсказывать их результаты. Судя по всему, физики не считают это доказательством того, что физика как наука потерпела фиаско.
Я думаю, что то же самое можно сказать и о различных моделях процесса разработки ПО. Scrum, канбан и Экстремальное программирование дополняют друг друга, конкурируют друг с другом и в чем-то даже противоречат друг другу. Но это не значит, что мы имеем дело с неудачными методологиями. Просто при пользовании ими и порождаемой ими информацией следует проявлять критичность и некоторую осторожность.
Что касается сложных систем, то наши знания всегда ограничены историей и контекстом. Никто не утверждает, что сама идея моделирования сложных систем порочна… Однако мы должны проявлять осторожность и не полагаться чрезмерно на «знание», которое обретаем в результате использования моделей. ‹…› Полученное таким образом «знание» нуждается в интерпретации, а интерпретации всегда приводят к упрощению. Значит, наш основной аргумент состоит не в том, что сложным системам присуща некая метафизическая непознаваемость, а в том, что это мы не в состоянии «познать» систему во всей ее сложности [103] .
Более или менее совместимые или конфликтующие модели менеджмента вместе со своими сильными и слабыми сторонами будут существовать всегда, поскольку организации (и команды разработчиков) представляют собой сложные системы. Это напрямую следует из принципа несжимаемости. Никогда не будет создана единая теория управления организациями или разработкой ПО (от этой идеи мы отказались еще в главе 1). Нам неизбежно придется иметь дело с лоскутным одеялом из различных теорий, методов и стандартизированных подходов [Richardson 2008: 17]. Вполне очевидно, что доступный нам массив знаний о разработке ПО столь же уродлив, как и массив знаний о сложных системах (см. главу 3). Хотя юбочка, возможно, и другого цвета (см. рис. 16.2).
Другие модели точно так же «неверны»
Если случается, что я проваливаю какой-либо тест, то обычно утешаю себя тем, что я далеко не единственный, с кем это случилось. Также у меня вызывает чувство удовлетворения тот факт, что существуют другие модели управления организациями и что они в такой же степени «неверны», как и моя. Иногда этот общий для авторов моделей дискомфорт даже доставляет мне удовольствие. Вайнберг же говорит нам, что сумма нескольких моделей будет менее неполной, чем отдельно взятая модель. В общем, не исключено, что в этом случае два минуса в итоге дают плюс…
Дао Toyota
Дао Toyota было опубликовано в 2001 году. Оно описывает модели поведения, лежащие в основе управленческой и производственной системы компании Toyota. Дао состоит из двух главных принципов: уважение к людям и непрерывное улучшение, точно совпадающих с двумя компонентами моей модели (добавление энергии и улучшение всего).
Профессор Джеффри Лайкер проанализировал управленческую философию компании Toyota, детально описав четырнадцать управленческих принципов [Liker 2004]. Некоторые из них, например долгосрочные цели, воспитание лидеров, обучение сотрудников и постоянная рефлексия, вполне адекватно отражены в модели Менеджмента 3.0. Другие принципы, такие как представление производственного процесса в виде потока, система вытягивания и медленное принятие решения / быстрое внедрение, безусловно, полезны для многих организаций, но я предпочитаю рассматривать их просто в качестве полезных приемов, поскольку вряд ли они могут стать основополагающими принципами, которых во всех случаях следует придерживаться менеджерам.
Между моей моделью и Дао Toyota есть одно интересное отличие, а именно: в Дао отсутствует компонент, связанный с выращиванием структуры. Я не утверждаю, что это делает Дао Toyota непригодным, но остаюсь при своем мнении, что структура сложных систем является слишком важным элементом, чтобы его можно было проигнорировать – именно структура будет одним из основных факторов, обуславливающих эффективность гибких методологий.
Четырнадцать принципов Деминга
В книге «Выход из кризиса» профессор менеджмента Уильям Эдвардс Деминг предложил четырнадцать принципов управления и трансформирования организаций [Deming 1986]. Принципы Деминга бессчетное число раз цитировались в литературе по менеджменту и вдохновили многих, кто развивает гибкие и бережливые методологии по всему миру.
Шесть компонентов моей модели вместе с соответствующими примерами и практическими приемами пересекаются практически со всеми из четырнадцати принципов Деминга. В тех или иных главах этой книги говорится о постоянстве цели, стремлении к изменениям, отказе от инспекций как инструмента обеспечения качества, постоянном улучшении всех производственных процессов, организации обучения без отрыва от производства, менеджерах как лидерах, а не надзирателях, искоренении страха, устранении барьеров между подразделениями, отказе от пустых лозунгов и призывов, создании возможностей для сотрудников испытывать гордость за свою работу, внедрении программ развития компетенций и ответственности всех работников за улучшение производственных процессов. Единственный из принципов Деминга, о котором в моей книге ничего не сказано, – это отказ от практики закупок по самой низкой цене; здесь я могу только выразить надежду, что, когда вы покупали мою книгу, она не показалась вам неоправданно дорогой.
Я также испытываю определенное беспокойство по поводу упоминаемого Демингом принципа, заключающегося в отказе от управления по целям, который, по-видимому, противоречит некоторым идеям, изложенным в главах, посвященных настройке ограничений и развитию компетенций. Однако поскольку у Деминга под этим принципом в основном подразумевается отказ от использования внешних стимулов и констатация, что у менеджеров зачастую отсутствует системный взгляд на вещи, то можно утверждать, что мы и так уделили достаточно времени и тому и другому.
Шестиуровневая модель Минцберга
Профессор Генри Минцберг – один из лучших мировых мыслителей и авторов, пишущих на темы менеджмента в бизнесе. В своей книге «Менеджмент» он представил новую модель, разработкой которой занимался много лет [Mintzberg 2009: 48]. В рамках этой модели менеджмент осуществляется на трех «уровнях», при этом на каждом выполняются функции двух типов: уровень действий (делание и распределение ресурсов), уровень людей (функции лидера и связного) и уровень информации (коммуникация и контроль).
При сравнении модели Менеджмента 3.0 с моделью Минцберга создается впечатление, что они наполовину перекрывают друг друга. Мне представляется, что в этой книге мы достаточно детально обсудили темы лидерства, коммуникации и производственных процессов и не имеет смысла дополнительно говорить об этом. В моей модели практически не упоминается о второй половине действий из модели Минцберга (функции связного, контроля и распределения ресурсов), которые, с моей точки зрения, необязательно будут обязанностями менеджера и могут легко делегироваться командам. В то же время в модели Минцберга не упоминается добрая половина из того, о чем идет речь в модели Менеджмента 3.0: вопросы управления ростом организационных структур, развитием компетенций и улучшений, хотя я убежден, что для гибких организаций эти аспекты очень важны.
Данные расхождения объясняются тем, что модель Минцберга создавалась на основе эмпирических данных о том, чем менеджеры вынуждены заниматься на практике. В свою очередь, моя модель создана на основе научной теории. Она показывает, чем менеджерам следует заниматься на самом деле.
Пять принципов Хэмела
Гэри Хэмел, также один из известнейших бизнес-мыслителей и авторов, в своей книге «Будущее менеджмента» описал пять принципов «управления компаниями в XXI веке» [Hamel 2007]. Эти принципы таковы: жизнь (порождение разнообразия), рынки (гибкость при распределении ресурсов), демократия (поощрение активности), вера (понимание смысла) и существование крупных городов (создание предпосылок для возникновения случайных удачных открытий).
Хотя предложенные Хэмелом названия принципов менеджмента достаточно расплывчаты, мне представляется, я смог разглядеть основные идеи, лежащие в их основе, (экспериментирование, мутации, естественный отбор, сети вместо иерархий, распределенное лидерство, вдохновляющие цели, неравнодушные люди, разнообразие, креативность, инновации и так далее) – и все они обсуждаются в моей книге. По-видимому, единственное измерение, отсутствующее в модели Хэмела, это развитие компетенций. Как и в первоначальной версии Agile-манифеста, в модели Хэмела подразумевается, что компетентные сотрудники падают с неба на парашютах и ничего не стóят. К сожалению, мой опыт говорит об обратном.
Есть и еще множество других моделей…
Существуют еще десятки, если не сотни, моделей менеджмента. Я решил включить в свой обзор и сравнить лишь несколько, которые были предложены наиболее уважаемыми и знающими авторами. (Я не хочу причинять вам страдания, заставляя читать от корки до корки источники с названиями вроде «Сто сорок два закона лидерства, применяемых жрецами, священниками и военными».) Моя цель – подчеркнуть, что ни одна из моделей не может быть идеальной и каждая может оказаться весьма полезной.
Типичные заблуждения практиков гибких методологий
Но не только менеджерам приходится иметь дело с обилием конкурирующих моделей, аналогичная ситуация существует и в области разработки ПО. Эксперты по Agile без конца повторяют, что для того, чтобы правильно использовать Scrum или XP, «разработчики должны перепроектировать код». Кто-то утверждает, что «всем нужны юнит-тесты» или что «Scrum все ухудшает из-за того, что игнорирует инженерные практики» и что «ты не гибкий, если не используешь непрерывную интеграцию каждый день». Для этих экспертов Agile не про адаптацию и выполнение всего возможного для того, чтобы проект был долгое время успешным. Если верить этим Agile-экспертам, гибкость – это следование практикам X, Y и Z. Но это очередное заблуждение.
Гибкость – это способность оставаться успешным в постоянно меняющейся внешней среде.
Я
Вот и все, к этому нечего добавить.
С моей точки зрения, существует лишь одна универсальная практика, которая в равной степени подходит всем организациям, – гнать с порога любых «экспертов», которые осмеливаются утверждать, что практика X оптимальна для любой организации. Скорее всего, имеется в виду та практика, в которой данный эксперт особенно силен и которую он за хороший гонорар готов помочь вам внедрить. (Если вам интересно, мне никто не приплачивает за усилия, которые я прилагаю, выгоняя таких экспертов из нашего офиса.)
Некоторые практики гибких методологий предлагают вообще отказаться от бренда «гибкие» или «Agile-методологии». В конце концов, поскольку данный термин так и не получил ясного определения, гибкими иногда называют даже дисфункциональные проекты. Это возможно только потому, что гибкие методологии не предписывают выбор конкретных методов и инструментов. Но это естественно, поскольку универсальных практик просто не существует! Если бы они имелись, мы могли бы прописывать любой сложной системе одну и ту же стратегию выживания, а это напрямую противоречит природе сложности (и более конкретно – теории игр). В задачу гибких методологий никогда не входило рекомендовать определенный набор практик. В Agile-манифесте нигде не сказано, что вы должны непременно применять автоматизированное тестирование, парное программирование или рефакторинг. (Я был бы не в состоянии написать книгу по гибким методологиям, если бы какие-либо из практик были обязательными.) Как только люди начинают считать ту или иную практику обязательной, само словосочетание «гибкая практика» становится логически противоречивым.
Казалось бы, естественно ожидать, что эксперты по гибким методологиям должны понимать основы теории сложности. В конце концов, гибкие методологии выросли именно из нее. Но если бы они по-настоящему разбирались в теории сложности, то не давали бы глупых рекомендаций вроде «Если вы не пользуетесь практикой X, то вашу методологию нельзя признать гибкой» или «У вас не настоящий Scrum, поскольку вы не делаете Y». К сожалению, это до сих пор случается очень часто. Последователи спорят о преимуществах гибких методологий над бережливыми, превосходстве Экстремального программирования над Scrum, плюсах канбана по сравнению со Scrum и так далее и тому подобное. (На момент написания этой книги Scrum все еще считается нормой, поэтому если вы усматриваете в нем недостатки, то вполне сможете произвести впечатление на непосвященных.) Но ведь любая модель неполна, и найти в каждой недостатки достаточно легко – только пользы от этого немного.
В мире полно специалистов по гибким методологиям, выучивших слова эмерджентность и самоорганизация, которые в настоящий момент не использует только ленивый. Но они не до конца понимают, что означают эти термины в контексте гибких методологий и в практике разработки ПО. Не пора ли и мне выступить с программным документом?
Инструкция по управлению сложностью
Мне кажется, нам всем пора признать, что, предпочитая простые решения, мы игнорируем сложность окружающего нас мира. Поэтому я предлагаю следующий набор рекомендаций…
У каждой проблемы есть много решений
Кубик Рубика можно собрать несколькими способами. Не существует единственного верного способа управлять бизнесом. Не существует единой оптимальной стратегии, позволяющей всегда выигрывать в настольной игре «Риск». И нет единого оптимального метода управления проектами. По-человечески понятно, что нам бы хотелось, чтобы только предлагаемые нами решения оказывались эффективными. Но следует все же допускать, что и решения, предложенные другими, могут также быть эффективными.
Выбор решения зависит от контекста
Форма биологического вида зависит от окружающей его среды. При выборе оптимальной стратегии необходимо учитывать характеристики данной команды и ее противников. Выбор маркетинговых решений зависит от того, с какими клиентами вы имеете дело. А выбор наиболее эффективных практик зависит от внешней среды, в которой реализуется конкретный проект. При разработке ПО многие факторы важны, но главным из них будет именно контекст.
Изменяющиеся контексты диктуют изменяющиеся решения
Когда изменяется среда обитания, изменяются и населяющие ее биологические виды. Лучшие стратегии продвижения аккаунта в социальных сетях в этом году отличаются от прошлогодних. (Подпишитесь на меня в Twitter, и мы вместе понаблюдаем, какие стратегии будут применяться в следующем году.) Стоит измениться контексту, как приходится изменять и способы управления соответствующими проектами.
Любое странное решение где-то будет лучшим
Антарктический криль – самый успешный вид на планете. Стратегия «око за око» – одна из доминирующих стратегий выживания в теории игр. Но даже рыбе-капле с ее специфической внешностью удалось найти свою нишу в этом мире. Ни одна стратегия в теории игр не будет универсальной. Как бы ни были популярны некоторые методологии разработки ПО, они не заменят другие методы, подходящие именно в нестандартных ситуациях – а такие ситуации будут всегда.
Выбранное решение в свою очередь влияет на контекст
Некоторые новые фильмы оказывают трансформирующее воздействие на всю киноиндустрию, и всем выходящим впоследствии фильмам волей-неволей приходится учитывать новые веяния. Оказавшиеся у нас в головах мемы изменяют наш образ мыслей и облегчают усвоение связанных с ними новых мемов. Аналогичным образом выбранные нами практики разработки ПО изменяют среду, в которой мы функционируем, и влияют на нашу способность применять другие практики.
Простота требует понимания сложности
Биологи, компании и правительства успели причинить много вреда, в свое время не разобравшись в сложности окружающего мира. Тем, кто не понимает, как устроен мир, трудно спрогнозировать, какие именно простые решения могут оказаться эффективными при решении сложных проблем.
Невозможно заранее предсказать, какое решение окажется лучшим
Прогнозирование, безусловно, это ценный инструмент, но тем не менее невозможно точно знать заранее, какие из предлагающихся решений сработают, а какие нет. Только располагая эмпирическими данными о реальной ситуации, мы можем делать заявления об ожидаемом успехе того или иного решения. Но надо научиться признавать, что часто мы просто не в состоянии вынести об этом какое-либо суждение и сначала предстоит испробовать различные методы, прежде чем выяснится, какой из них оказался эффективным в конкретной ситуации.
Предлагаемая ниже инструкция по управлению сложными проектами (рис. 16.3) не призвана опровергнуть никакие из существующих ценностей, принципов, ориентиров и практик (она также не противоречит никаким манифестам). Напротив, в ней подчеркивается, что все методологии полезны, если рассматривать их в соответствующем им контексте. При разработке ПО мы должны обсуждать не то, кто из нас прав, а кто нет. Единственное, что нас должно интересовать, – какой из методов эффективен в конкретной ситуации. Мы не должны слишком увлекаться противопоставлением пользовательских историй вариантам использования, гибких технологий – методам CMMI, Scrum – канбану или гибких технологий – бережливым. Вопрос лишь в том, когда и какой метод уместно использовать. Просто спор о том, кто прав, а кто нет, только служит росту популярности, а не пониманию.
Из-за простоты своих высказываний люди необразованные в глазах толпы кажутся более убедительными, чем образованные.Аристотель
Я надеюсь, что разработчики ПО и менеджеры по всему миру поймут, что не стоит подвергать друг друга уничтожающей критике при обсуждении методологий, стандартизированных подходов, принципов и практик. В сложном мире найдется время и место для любой идеи. Нет смысла обсуждать, какая из имеющихся идей неверна, потому что они все неверны. Настоящий вызов в том, чтобы выяснить, какая из них может оказаться полезной в конкретном контексте.
Все модели неверны, но некоторые из них полезны [Box, Draper 1969].
Я осознаю, что в моей книге «неверно» все, но очень надеюсь, что она тем не менее будет вам полезна.
Резюме
В модели Менеджмента 3.0 шесть компонентов: настройка ограничений, развитие компетенций, расширение полномочий команд, выращивание структуры, добавление энергии и улучшение всего. Каждая из практик, применяемых менеджерами в рамках гибких методологий, должна вносить положительный вклад по крайней мере в один из этих шести компонентов.
В конечном итоге все модели терпят неудачу, включая и предлагаемую в этой книге. Ни одна модель не в состоянии дать полное описание сложных систем, примером которых являются, в частности, проекты по разработке программных продуктов. Поэтому все модели неверны; впрочем, некоторые из них могут оказаться полезными. Вот почему есть смысл для разных случаев иметь наготове разные дополняющие и противоречащие друг другу модели.
То же самое относится к методологиям разработки ПО. Любая из них может быть полезной, но только в определенном контексте. В сложном мире сложно все. И в конечном итоге истина всего одна: все и всегда зависит от ситуации.
Подумать и сделать
Давайте посмотрим, как применить некоторые идеи из данной главы в вашей компании:
• Пользуетесь ли вы при управлении своими задачами и проектами всеми шестью компонентами Менеджмента 3.0? Возможно, вы также делаете что-то, что отсутствует в данной модели?
• Сформулируйте свое отношение к этой книге. Понравилась ли она вам? Если да, посоветуйте ее тем, для кого она также будет полезной.