Шрифт:
Интервал:
Закладка:
На рис. 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).
Если случается, что я проваливаю какой-либо тест, то обычно утешаю себя тем, что я далеко не единственный, с кем это случилось. Также у меня вызывает чувство удовлетворения тот факт, что существуют другие модели управления организациями и что они в такой же степени «неверны», как и моя. Иногда этот общий для авторов моделей дискомфорт даже доставляет мне удовольствие. Вайнберг же говорит нам, что сумма нескольких моделей будет менее неполной, чем отдельно взятая модель. В общем, не исключено, что в этом случае два минуса в итоге дают плюс…
