Даже некоторые из наиболее рьяных редукционистов отказались от представления, что все явления могут быть сведены к поведению их составных частей. Философ Дэниел Деннет предложил термин «Жадный редукционизм» [Dennet 1995] для обозначения форм редукционизма, которые стремятся полностью вывести поведение системы из взаимодействия между ее составными частями. Например, утверждение, что «гиперссылки – это не более чем электроны и на самом деле они не существуют» будет примером такого жадного редукционизма. В качестве контраргумента я сказал бы, что если жадные редукционисты правы, то значит, они тоже не существуют, и это полностью снимает все их смехотворные аргументы. Но я отвлекся.

В качестве компромисса биолог-эволюционист Ричард Докинз предложил понятие иерархического редукционизма [Dawkins 1996], смысл которого в том, что сложная система может быть представлена в виде иерархии, в которой события на каждом уровне могут быть объяснены поведением компонентов, находящихся в данной иерархии одним уровнем ниже, но только одним уровнем. Если следовать этой логике, вы не сможете объяснить провал своего проекта тем, что вам помешали кварки и лептоны.

Многие ошибочно полагают, будто бы из редукционизма следует, что мы в состоянии реконструировать любую систему, если понимаем, как функционируют ее составные части. В этом и состоит заблуждение: даже если мы отлично понимаем, как ведут себя все компоненты системы, это не значит, что система сводится к сумме своих составных частей [Miller, Page 2007: 41]. Знание компонентов, находящихся на нижних уровнях системы, вовсе не означает, что мы сможем воссоздать всю систему как единое целое. Интересно, что, если исходить из редукционистского подхода и отследить изначальную причину проблемы (например, воспользовавшись методикой анализа основной причины), мы все равно не сможем создать систему, в которой данная проблема отсутствовала бы. Например, мы можем установить причину конкретного случая сердечной недостаточности (редукционизм), но нам никогда не удастся создать сердце, которое принципиально не будет подвержено сердечной недостаточности (конструкционизм).

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

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

Управление организацией требует совершенно иных знаний и опыта, чем управление людьми, хотя некоторое представление о том, как система функционирует на более низких уровнях, может оказаться полезным. Инженер-программист Джоэл Сполски предложил закон дырявых абстракций [Spolsky 2002] в качестве объяснения, почему в системах компоненты, находящиеся на более высоких уровнях, могут проявлять себя неожиданным образом в результате воздействия на них событий, происходящих на более низких уровнях, хотя более высокие уровни, по идее, должны быть изолированы от такого воздействия. Более высокие программные уровни, которые подвергаются воздействию событий, происходящих на более низких программных уровнях, считаются дырявыми. Типичным свидетельством такого рода дырявых абстракций в программировании будут непонятные сообщения об ошибках, которые получают пользователи (рис. 1.3).

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

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

Гибкие методы разработки ПО некоторыми своими корнями уходят в теорию сложности, признающую недостаточность причинного детерминизма для реализации успешных проектов. Такие хорошо известные и используемые в гибких методологиях понятия, как «самоорганизация» и «эмерджентность», напрямую взяты из литературы по сложным системам [Schwaber, Beedle 2002], и люди, практикующие в настоящее время Agile-методологии, понимают, что при конструктивистском подходе гарантированы неудачи. Только непрерывная идентификация возникающих в ходе проекта проблем и устранение их причин позволяют последовательно развивать проект по разработке ПО и в конечном итоге получить на выходе успешный программный продукт. Это похоже на процесс взросления или воспитания детей.