«Agile-менеджмент: Лидерство и управление командами»

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

30

Многие сторонники гибких методологий в качестве обязательного условия выдвигают

наличие поддерживающей «среды обитания» в виде открытого офисного пространства, а

также информационные радиаторы (к ним относятся, например, доска задач и диаграммы

сгорания задач). Предназначение инструментов в контексте Agile-методологий – усиливать

мотивацию, коммуникации и сотрудничество внутри команды.

Время

У Agile-методологий особые отношения со временем. В Agile-проектах даты поставки,

бюджеты и крайние сроки могут устанавливаться почти произвольно. Программное

обеспечение создается короткими отрезками, часто в рамках тайм-боксов или «спринтов», и

поставляется в виде инкрементных релизов; при этом каждый из релизов сам потенциально

является готовым к поставке продуктом. Это позволяет владельцам бизнеса управлять

графиком проекта, сдвигая дату сдачи готового продукта вперед или назад в зависимости от

того, в какие сроки они хотят сделать доступной ту или иную функциональность. Тем

временем команда стремится найти для себя оптимальную скорость разработки, которую она

сможет поддерживать практически бесконечно.

Ценность

Одной из важнейших причин создания Agile-манифеста было стремление подчеркнуть

важность своевременной реакции на изменения. Среда, в которой функционирует

программный продукт, никогда не бывает статичной. Функциональность, которая еще вчера

представляла собой значительную ценность, завтра может оказаться бесполезной, включая

функциональность, которая уже имеется в версиях продукта, переданных заказчику.

Разработчики, практикующие гибкие методологии, стараются справиться с этой проблемой,

предпочитая короткие циклы разработки и обратной связи. Смысл частых релизов

программного продукта не только в том, чтобы получить обратную связь от пользователей и

учесть ее в последующем процессе разработки, но и в том, чтобы предоставить

пользователям новую функциональность как можно скорее после выявления их потребности

в ней, тем самым повышая ценность ПО для клиента.

Процесс

Несмотря на то, что доминирующая парадигма Agile-методологий – люди, а не

процессы, это совсем не означает, что последние не важны. Наиболее важными процессами в

этом контексте будут минимальное планирование (или планирование методом набегающей

волны), ежедневное личное общение (часто это происходит в формате ежедневных

стендапов) и мониторинг хода проекта через оценку работающего продукта (по

функциональным возможностям, принятым клиентом). Приверженцы гибких методологий

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

разработки подвергаются регулярной переоценке и перенастройке посредством анализа и

ретроспектив (ретроспективных совещаний).

Конфликт

Все вышеизложенное отражает мое понимание сущности Agile-методологий.

Естественно, это не более чем моя точка зрения. Некоторые разработчики, практикующие

гибкие методологии, могут не согласиться с приведенным мной кратким описанием. Но это

вытекает из самого характера Agile-методологий. Я даже мог бы включить понятие

«конфликт» в качестве восьмого измерения, присущего этим методологиям. Как вы увидите

позже, наличие внутреннего конфликта – естественное свойство сложных систем и

31

необходимое условие для креативности и инноваций. Великая честь оказаться среди людей,

которым ничто не доставляет такого удовольствия, как возможность совершенствовать друг

друга.

Методологии, конкурирующие с Agile

Редко когда попадаются игры, не предусматривающие конкуренцию между игроками, и лишь

немногие системы обходятся без конфликта. Без расхождения во взглядах между разными

людьми жить было бы не так интересно. К счастью, в мире гибких технологий предостаточно

здоровой конкуренции, например между Scrum и Экстремальным программированием, Scrum и

канбаном и даже между Scrum и Scrum![5] Но гибкие методы разработки не будут здесь

единственными игроками. Существует несколько сильных и многообещающих конкурирующих

подходов, в основе которых лежат идеи, аналогичные идеям Agile-методологий, дополняющие

их, а часто и входящие с ними в прямое противоречие.

Одними из самых крупных конкурентов будут методологии бережливой разработки

программного обеспечения (Lean software development), переносящие идеи бережливого

производства в область разработки ПО. Семь принципов бережливого производства [Poppendieck

2009: 193] основываются на четырнадцати принципах Дао Toyota (философии управления

компании Toyota) и четырнадцати принципах менеджмента Э. Деминга. Между Agile- и

Lean-методологиями много общего, поэтому часто они играют на одной стороне, ими

занимаются одни и те же эксперты, у них одни и те же фанаты, а их развитие освещается в одних

и тех же блогах, журналах и ТВ-шоу. С управленческой точки зрения Lean-методологии — с их

акцентом на сокращении непродуктивных затрат и оптимизации систем в целом — внесли

большой вклад в развитие гибких методологий. Хотя бережливые методологии разработки ПО

возникли на несколько лет позднее Agile, они сравнялись с ними по числу консультантов,

коучей, профессиональных консорциумов[6] и проводимых конференций.

Менее крупным, но весьма способным игроком будет также движение за мастерство

программирования, основополагающим документом которого стал манифест в защиту

мастерства программирования (рис. 2.3), о котором говорят, что он одновременно расширяет

Agile-манифест и бросает ему вызов. Сторонники этого движения считают, что разработчики ПО

вовсе не инженеры, а мастера. (Некоторые полагают вполне уместным сравнение с

распространенной в Средневековье моделью мастеров и подмастерьев.) В общем, это движение

— шустрый и бесстрашный новый игрок, возникший рядом с бережливыми и гибкими

методологиями и имеющий свои собственные конференции, книги и форумы (хотя и не в таком

количестве). Эти три «легкие» методологии вместе стали отличной командой, несмотря на

периодически возникающие между ними бурные споры.

32

Но и тяжеловесы все это время тоже не стояли на месте. Возможно, наиболее известным (и

наиболее спорным) из них будет методология CMMI (Capability Maturity Model Integration). Ее

разработка с 1987 года ведется Институтом программной инженерии, исследовательским

центром на базе Университета Карнеги–Меллон. Проект начался с создания протокола

оптимизации процессов разработки ПО, но постепенно трансформировался в более абстрактную

модель, которая в настоящее время применяется для оптимизации процессов и в других

отраслях. В модели описываются пять уровней зрелости процессов в двадцати двух процессных

областях, и она ставит себе целью порождение рекомендаций по их оптимизации. Но данная

модель лишь указывает, в каких именно процессных областях возможна оптимизация. Она не

дает рекомендаций относительно конкретных ее способов. По этой причине некоторые

сторонники Agile полагают, что, несмотря на свой объем (документация, описывающая

методологию CMMI, насчитывает многие сотни страниц), она все же совместима с гибкими

33

методологиями, поскольку последние дополняют ее, давая рекомендации, в том числе и по

конкретным способам оптимизации процессов. Но, как это всегда бывает среди сторонников

гибких технологий, и тут не обходится без споров. Многие считают, что, несмотря на благие

намерения, положенные в ее основу, CMMI в силу своей тяжеловесности уводит компании в

сторону бюрократии и создания не вполне дееспособных команд, которые весьма впечатляюще

выглядят со стороны, но не могут блеснуть реальными результатами.

С такой же смешанной реакцией столкнулась и методология, изложенная в «Руководстве к

своду знаний об управлении проектами» (Guide to Project Management Body of Knowledge,

PMBOK), издаваемом и поддерживаемом Институтом управления проектами. Интересно, что это

руководство первоначально возникло как описание лучших практик в области проектного

менеджмента в целом. С момента первого издания в 1987 году оно подверглось нескольким

переработкам и стало ближе к идеологии Agile в качестве реакции на успехи, достигнутые

проектными менеджерами, практикующими гибкие методологии. В отличие от CMMI,

методология, продвигаемая в рамках PMBOK, предлагает проектным менеджерам конкретные

рекомендации относительно управления проектами. И хотя рекомендуемые ею практики не

всегда хорошо сочетаются с принятыми в гибких методологиях, многие проектные менеджеры

предпринимают активные попытки преодолеть имеющиеся расхождения. То же самое можно

сказать о PRINCE2 — похожей методологии, издаваемой и поддерживаемой британским

министерством государственной торговли. Эта методология используется главным образом в

Европе.

Последним важным направлением в этом списке будет унифицированный процесс разработки

ПО, наиболее известный в версии унифицированный процесс Rational (Rational Unified Process,

RUP).Он был разработан в 1997 году компанией Rational Software (сейчас принадлежит IBM).

Для разработчиков ПО процесс RUP будет тем же, чем для проектных менеджеров стали

методологии, изложенные в руководстве PMBOK. В нем содержится описание

стандартизированных методов проектного управления, которые могут (и должны)

адаптироваться к конкретным проектам; однако документация составлена таким образом, что

весь подход зачастую воспринимается как бюрократический. Сторонники гибких методологий

считают, что процесс разработки формируется в ходе проекта, начинаясь с минимального числа

практик. В рамках RUP продвигается противоположный подход, в котором изначально

предписывается большое количество практик с сопровождающей их рекомендацией, что в ходе

проекта от ненужных практик можно отказаться. (Я часто сравниваю этот подход с покупкой

Boeing 747, который владелец затем разбирает на части, чтобы собрать велосипед для поездок за

покупками.) Неудивительно, что на фоне многочисленных успехов Agile-методологий этот

подход подвергся нескольким ревизиям с целью сделать его более гибким, в результате чего

возникли такие его модификации, как гибкий унифицированный процесс (Agile Unified Process,

AUP), открытый унифицированный процесс (OpenUP) и минимально необходимый гибкий

процесс (Essential Agile Process, EssUp). Но ни один из них не нашел широкого применения,

сравнимого с распространением Agile-методологий.

Препятствие на пути Agile-методологий

Эмпирические данные вновь и вновь подтверждают, что Agile-методологии, если правильно

ими пользоваться, обеспечивают огромный возврат инвестиций [Rico 2009]. Но если эти

методологии дают столь блестящие результаты, то почему далеко не все ими пользуются? И

почему столько проектов по разработке ПО во всем мире все еще заканчиваются неудачами?

В опросе, посвященном оценке текущего состояния Agile-методологий, проведенном в 2009

году компанией VersionOne, респонденты в качестве причин, препятствующих принятию

компаниями гибких методологий, указали следующие: «менеджмент настроен против

изменений», «опасение утратить управленческий контроль», «недостаточная техническая

дисциплина», «команды настроены против изменений» и «недостаточный уровень

компетентности разработчиков». Параллельно упоминается потребность организаций в

планировании, предсказуемости и документировании своих действий [VersionOne 2009].

Подождите… Давайте еще раз вглядимся в эти причины: тут говорится об управленческом

контроле, управлении организационными изменениями, выращивании талантов…

34

Простите, возможно, я не прав, но… разве все это не прямые функции менеджмента? Не

значит ли это, что именно менеджеры по всему миру будут основным препятствием на пути

внедрения Agile-методологий?

Как менеджера меня расстраивает этот вывод.

А как автора — радует.

Я думаю, что гибкие методологии упустили из поля зрения важность линейного

менеджмента. Если менеджеры не знают, чем им заниматься и чего ожидать от внедрения гибких

методологий в своих организациях, то почему они должны поддерживать переход к этим

методологиям? В чем состоит послание Agile-методологий этим менеджерам? В том, что

«менеджеры нам не нужны»? Тогда неудивительно, что внедрение этих методологий

наталкивается на препятствия во всем мире.

Чтобы организации могли воспользоваться всеми преимуществами гибких методологий, они

должны ответить на важный вопрос: какое будущее ожидает менеджеров в мире Agile?

Линейный и проектный менеджмент

Мое имя в Голландии не самое распространенное. Поэтому на разных этапах моей карьеры

мне приходилось мириться с тем, что его часто коверкали. Временами из-за этого возникали

недоразумения. Когда имена людей или названия предметов похожи, многие склонны почти не

замечать остальных различий между ними. Если бы имя Эллы Фицджералд было не Элла, а

Юрген, то, уверен, коллеги попросили бы меня спеть.

Мне кажется, что с термином «менеджер» есть точно такая же проблема.

В 2005 году группа людей, специализирующихся в области управления (проектные

менеджеры, линейные менеджеры и др.) собрались вместе и опубликовали Декларацию

взаимозависимости (рис. 2.4).

В первом воплощении декларация в первую очередь предназначалась проектным

менеджерам. Позднее стало ясно, что ее принципы могут быть интерпретированы более широко

и применены к «менеджменту в целом». И все же в первую очередь декларация ориентирована

на управление проектами по разработке ПО, а не на управление группами людей. Это

необходимо подчеркнуть, поскольку именно авторы декларации впоследствии основали

организацию Agile Project Leadership Network.

К сожалению, проектный менеджмент и функциональный (линейный) менеджмент часто

путают. В ряде отличных книг, написанных ведущими экспертами, включая «Гибкий

менеджмент» (Agile Management) [Anderson 2004], «Управление Agile-проектами» (Managing

Agile Projects) [Augustine 2005] и «Гибкое управление проектами» (Agile Project Management)

[Highsmith 2009], вопросы проектного и функционального менеджмента обсуждаются

параллельно. Та же ситуация наблюдается и на многих форумах, в блогах и журналах. Мне бы

хотелось, чтобы это было не так, поскольку проектный и линейный менеджмент — не одно и то

же. Это все равно что путать разработчиков ПО с системными администраторами. Возможно,

они разделяют одни и те же идеи, смеются над одними и теми же шутками и (фигурально

выражаясь) стригутся и одеваются одинаково, но все же это разные люди. (Я серьезно.

Попробуйте попросить разработчика софта починить вам компьютер. Но лучше даже не

пробуйте.)

35

Не делая четкого разграничения между линейными менеджерами и менеджерами проектов,

мы затрудняем понимание и теми и другими своей роли в компаниях, практикующих гибкие

методологии разработки. К счастью, я далеко не единственный, кто это понимает. В нескольких

книгах, вышедших задолго до моей, включая «За закрытыми дверями» (Behind Closed Doors)

[Rothman, Derby 2005] и «Управление разработкой ПО на основе Lean-методологий» (Leading

Lean Software Development) [Poppendieck 2009], функции линейных менеджеров в компаниях,

специализирующихся на разработке ПО, изложены более четко.

В своей книге я последовательно провожу различие между линейным и проектным

менеджментом. Моя основная цель — помочь линейным менеджерам (включая тех, кто

руководит командами разработчиков, и лидеров команд) понять, в чем состоит их роль в

компании. Но я уверен, что и проектные менеджеры, системные менеджеры, сервис-менеджеры,

36

офис-менеджеры и кофе-менеджеры тоже найдут для себя в этой книге некоторые интересные

моменты.

А что касается тех, кто думал, открывая эту книгу, что я DJ Юрген, то им не повезло.

Резюме

Гибкие или Agile-методологии — это подход к разработке программного обеспечения,

появившийся в 1990-е годы в качестве реакции на засилье бюрократии, а также частных методов,

создаваемых каждый раз заново «под конкретную задачу» (все они не обеспечивали успешной

разработки ПО).

Гибкие методологии, принципы и ценности которых изложены в Agile-манифесте,

фокусируются на людях и командах, частых и высококачественных релизах программных

продуктов, тесном сотрудничестве с заказчиками и быстрой реакции на возникающие изменения

при минимуме предварительного планирования.

Ценности и принципы гибких подходов реализуются при помощи различных методов, таких

как Scrum и Экстремальное программирование. Однако ни один из этих методов не

рассматривает роль линейного менеджмента (не путать с проектным менеджментом) в

компаниях, перешедших на гибкие методологии разработки. В результате линейный менеджмент

часто становится препятствием на пути принятия гибких методологий.

Подумать и сделать

Давайте посмотрим, сможете ли вы применить в своей компании некоторые идеи,

изложенные в данной главе:

Взгляните на свою организацию с точки зрения семи проектных измерений (люди,

функциональность, качество, инструменты, время, ценность, процесс). Учитываете ли вы

все эти измерения в своих проектах по разработке ПО? Гибки ли ваши команды во всех

семи измерениях? Если нет, то что вы планируете по этому поводу предпринять?

Подумайте о менеджерах, работающих в вашей компании. Кто из них может стать

потенциальным препятствием на пути внедрения гибких методологий? Можете ли вы

что-то в связи с этим предпринять? Удостоверьтесь, что вы четко понимаете, что вам

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

Всем ли ясно, кто является линейным менеджером (и по отношению к кому), а кто нет?

Существует ли неясность или разногласия относительно распределения функций между

линейными и проектными менеджерами? Если да, то что вы предпримете, чтобы решить

эту проблему?

Развивайте свои навыки в области Agile-методологий, подписавшись на блоги или

группы, в которых обсуждается данная тематика. Актуальный список этих блогов и групп

можно найти на сайте, посвященном Менеджменту 3.0 (3

Теория сложности

Способность задавать вопросы отличает нас от всех остальных форм жизни. Никакой другой

биологический вид не задает вопросов о смысле своего существования, сложности Вселенной

или сложности самого себя.

Герберт Бойер,

профессор биохимии

Многие эксперты в области гибких методологий согласны, что команда разработчиков

представляет собой сложную адаптивную систему, поскольку состоит из множества частей,

взаимодействующих друг с другом и отделенных внешней границей, и способна изменяться и

учиться на собственном опыте [Highsmith 1999: 8], [Schwaber 2002: 90], [Larman 2004: 34],

[Anderson 2004: 1], [Augustine 2005: 24]. Кто я такой, чтобы утверждать обратное?

Журнал «Эмерджентность: Теория сложности в применении к организациям» однажды

провел обширное исследование книг по менеджменту, в которых упоминается теория сложных

систем. Среди рецензентов были специалисты в самых различных областях, включая физику и

37

математику. Все они сошлись во мнении о полезности теории сложности при управлении

организациями и для менеджмента в целом:

Было зафиксировано общее согласие [рецензентов], что использование идей теории

сложности имеет значительные перспективы для менеджмента как дисциплины и при

практическом управлении организациями[7].

Как вы увидите позже, дебаты среди экспертов касаются в основном того, какая

именно научная терминология должна применяться и в каком именно контексте.

Как и предыдущая, данная глава содержит не более чем вводный обзор по данной теме.

Только на этот раз нашим предметом будет теория сложности. Или скорее теории — во

множественном числе, — поскольку, как у вас будет возможность убедиться, система знаний о

таких системах за последние сто лет разрослась и сейчас представлена значительным числом

различных теорий.

Всегда полезно представлять себе контекст и историю вопроса. Когда вы в следующий раз

окажетесь на вечеринке, то сможете блеснуть, объяснив, например, разницу между общей

теорией систем и теорией динамических систем, а также дав понять, что рецепт восхитительного

лимонного торта, которым угощает хозяйка, не сложный (complex), а лишь запутанный

(complicated).

Необходимое предупреждение: данный обзор по необходимости неполон, излишне упрощен

и временами субъективен. Но я уверен, что именно по этим причинам он будет абсолютно

понятен.

Важность междисциплинарного подхода

В главе 13 «Как управлять ростом организационных структур» обсуждаются

организационные колодцы, то есть разделение сотрудников, выполняющих разную работу, и то,

почему это часто оказывает негативное воздействие на результаты деятельности всей компании.

Интересно, что подобная ситуация много лет существовала и в науке.

Большинство университетов и исследовательских институтов организованы именно в виде

таких колодцев. Физики работают бок о бок с другими физиками, биологи — с биологами, а

математики — с математиками. Это привело к фрагментации науки и распространению

туннельного зрения среди ученых и исследователей. Различные научные дисциплины настолько

изолированы друг от друга, что ученые обычно не знают, над чем работают их коллеги [Waldrop

1992: 61].

Организационные колодцы в науке — это проблема, поскольку многие явления из разных

научных областей часто похожи друг на друга. Например, некоторое время назад экономисты не

могли понять природу такого явления, как «локальное равновесие», в то время как физикам уже

была известна природа его физического аналога [Waldrop 1992: 139]. Фазовые переходы в

физике подозрительно напоминают случаи периодически нарушаемого равновесия в

эволюционной биологии. Биологи заметили, что математики могут помочь им в анализе

экологии видов [Gleick 1987: 59]. А некоторые «открытия» математиков, как выясняется, были за

годы до того сделаны метеорологами [Gleick 1987: 31].

В течение многих десятилетий ученые из различных областей пытались понять сложные

явления, которые не могли объяснить. Но когда наметились более тесные междисциплинарные

связи междуразличными областями и возникло общее представление о том, что изучаемые

разными науками системы — сложные, внезапно многое стало гораздо понятнее. Я где-то читал,

что самые значительные прорывы в науке совершались именно тогда, когда ученым приходилось

работать в областях, с которыми они прежде не были знакомы. А все потому, что они

привносили туда знания и опыт (включая опыт трудностей и неудач) из тех областей, в которых

были специалистами!

Как и гибкие методики разработки ПО, теория сложности подразумевает

междисциплинарный подход к решению проблем. Мышление в категориях сложных систем —

это противоядие от излишней специализации в науке. Оно предполагает существование общих

закономерностей в поведении систем, исследуемых различными научными дисциплинами, и

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

Однако теория сложности далеко не первая попытка синтеза различных предметных областей.

Давайте бросим беглый взгляд на историю вопроса.

38

Общая теория систем

В конце 1940-х годов усилиями группы ученых и исследователей, возглавляемых Людвигом

фон Берталанфи, была создана область науки, получившая название общая теория

систем (иногда ее называют просто теория систем). В своих исследованиях эти ученые исходили

из представления, что большинство явлений во Вселенной можно рассматривать как сеть

взаимодействий между элементами определенной системы. При этом независимо от того, будут

ли данные системы биологическими, химическими или социальными по своей природе, их

поведению присущи общие закономерности, исследование которых может пролить свет на

поведение систем в целом. Основной целью теории систем, таким образом, было создать общий

междисциплинарный понятийный аппарат и язык, при помощи которых можно было бы

описывать сходные явления во всех областях науки.

Одним из достижений теории систем, развитие которой продолжалось вплоть до 1970-х

годов, был перенос фокуса с элементов системы как таковых на организацию этих

элементов. Тем самым было признано, что взаимоотношения между элементами системы —

динамические, а не статические. Ученые идентифицировали и изучили такие явления,

как аутопоэзис (самопостроение или способы, которыми системы конструируют сами

себя), идентичность (каким образом системы можно опознать), гомеостаз (способность систем

поддерживать свою стабильность) и проницаемость (то, как системы взаимодействуют с

окружающей их средой) [Mitchell 2009: 297].

Именно общей теории систем мы обязаны пониманием, что группы разработчиков

представляют собой системы, которым свойственна способность к самопостроению, а также к

созданию и поддержанию собственной идентичности. Таким группам необходимо

взаимодействовать с внешней средой, а взаимодействия между членами группы столь же важны,

сколь и характеристики отдельных членов группы (или даже важнее).

К сожалению, объединение этих первоначально разрозненных концепций не было доведено

до конца (что не должно удивлять тех разработчиков ПО, которые пытались соединить

различные практики или технологии). И тем не менее наследие общей теории систем весьма

значительно. Почти все законы этой теории применимы и к сложным системам [Richardson

2004a: 75], и в целом эта теория продвинулась дальше, чем попытки унифицирования в области

разработки программных продуктов.

Кибернетика

Примерно в то же время, когда концепции общей теории систем разрабатывались группами

биологов, психологов, экономистов и других исследователей, столь же разношерстная группа

нейрофизиологов, психиатров, антропологов и инженеров создала новую область исследований,

которая получила название кибернетика. Наиболее известной фигурой, представлявшей данное

направление, был математик Норберт Винер.

Кибернетика изучает сложные управляемые системы, имеющие цели и взаимодействующие с

окружающей средой через механизмы обратной связи. Задача кибернетики — изучение

процессов, происходящих в управляемых системах. Эти процессы состоят из

многократных итераций какого-либо действия (которое вызывает изменения во внешней

среде), получения информации о состоянии среды(данные о реакции внешней среды на

совершенное действие), оценки (сравнение текущего состояния с целевым) и возврата на этой

основе к совершению нового действия. Для кибернетики этот циклический процесс

фундаментален.

Из кибернетики мы позаимствовали представление, что команда разработчиков представляет,

по сути, ориентированную на определенную цель систему, саморегулирующуюся посредством

различных циклов обратной связи. Мы поняли, что в саморегулирующейся системе, которой

является команда разработчиков, наиболее важными факторами будут информация,

коммуникация и целеполагание (в отличие, скажем, от силы и энергии). Кибернетика также

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

[Mitchell 2009: 296].

Многие путают общую теорию систем и кибернетику. Это неудивительно, поскольку они

очень сильно повлияли друг на друга. Обе они имеют не вполне прозрачные названия, обе

ставили себе целью создание единой научной теории, описывающей поведение систем. И ни той,

39

ни другой не удалось реализовать первоначальные цели. И тем не менее кибернетика и общая

теория систем продвинули данную область знания вперед, заложив фундамент, на котором были

созданы позднейшие теории.

Теория динамических систем

Если рассматривать общую теорию систем и кибернетику как ноги некоего человека,

символизирующего собой всю массу знаний о поведении систем, то одной из его рук, бесспорно,

будет теория динамических систем.

Возникнув из прикладной математики в 1960-х годах, теория динамических систем говорит о

том, что системам свойственно много состояний и одни из них устойчивы, а другие нестабильны.

Если отдельные компоненты системы не меняются со временем или же, подвергнувшись тем или

иным возмущениям, всегда возвращаются к исходным значениям, мы говорим, что такие

устойчивые состояния выступают в роли аттракторов.

Актуальность теории динамических систем для разработки программных продуктов состоит в

том, что она помогает объяснить, почему некоторые проекты устойчивы, а другие нет. И почему

иногда невозможно изменить организацию, имеющую устойчивую тенденцию возвращаться к

своему исходному состоянию.

Теория динамических систем сыграла ключевую роль в возникновении последующих теорий,

предложив математические инструменты для работы с трудноизмеряемыми понятиями общей

теории систем и кибернетики. (Приятно осознавать, что хотя бы некоторые компоненты теории

сложности не результат гениальных озарений, а базируются на надежном математическом

фундаменте.)

Теория игр

Мы уже упоминали, что теорию динамических систем можно представить себе в виде руки

некоего человека, символизирующего все наши знания о системах. В этом случае теория игр, вне

всякого сомнения, представляет собой вторую руку. Многие системы часто конкурируют друг с

другом за одни и те же ресурсы — или пытаются съесть друг друга на обед. Как вытекает из

теории игр, в таких случаях системы могут создавать конкурирующие стратегии.

Будучи одним из направлений прикладной математики, теория игр ставит себе задачей

описание поведения систем в ситуациях, требующих стратегического подхода. В этих ситуациях

успех одной системы отчасти зависит от тех моделей поведения, которые выбрали другие

системы. Теория игр получила свое развитие в 1930-х годах, а в начале 1970-х нашла применение

в биологии и эволюционной теории. Тогда стало понятно, что она вполне годится для анализа

стратегий, к которым живые организмы прибегают во время охоты, спасаясь от хищников, при

защите своей территории и во время брачных игр.

Теория игр оказалась полезным инструментом во многих областях, включая экономику,

философию, антропологию и политологию. И конечно, в сфере разработки программного

обеспечения, где она не только позволяет программистам создавать компьютерные игры,

электронные аукционы и одноранговые сети, но также объясняет поведение людей в командах и

поведение команд в организациях.

Эволюционная теория

Сейчас трудно представить себе человека, который не был бы знаком с эволюционной

теорией. Она получила известность с момента выхода в свет в 1859 году «Происхождения видов»

Дарвина, одной из самых знаменитых книг в истории. Практически все биологи согласны с

базовыми утверждениями теории эволюции: постепенное генетическое изменение видов и

выживание наиболее приспособленных организмов в результате естественного отбора.

Конечно, согласие относительно базовых постулатов не мешает бесконечным спорам

биологов по поводу деталей процесса. Важность случайного генетического дрейфа (изменение

вида без определенных причин), периодически нарушаемого равновесия (внезапные изменения

вместо постепенных), эгоистичных генов (отбор на уровне генов, а не на уровне особей или

популяций) и горизонтального переноса генов (передача генов другому организму) — все эти

гипотезы многократно и страстно биологами обсуждались, принимались или опровергались

[Mitchell 2009: 81–87]. (Но стоит только в качестве альтернативы предъявить биологам теорию

разумного замысла, как они моментально объединяются в своем отрицании этой ненаучной

ерунды.)

40

Эволюционная теория внесла значительный вклад в изучение всех видов систем, будь то

биологические, цифровые, экономические или социальные. Утверждается, что команды, проекты

и продукты эволюционируют в процессе приспособления к изменяющейся среде. И хотя

«эволюционное управление разработкой» систем программного обеспечения — это далеко не та

эволюция, о которой писал Дарвин, эволюционное мышление помогло разобраться с ростом,

выживанием и адаптацией систем во времени. Поэтому я считаю, что эволюционная теория

представляет собой интеллектуальную основу нашего знания о системах.

Теория хаоса

Хотя несколько открытий в рамках теории хаоса были сделаны ранее, настоящий прорыв был

совершен в 1970–1980-х годах, а основной вклад был внесен такими людьми, как Эдвард Лоренц

и Бенуа Мандельброт.

Теория хаоса учит, что даже самые небольшие изменения в начальных параметрах

динамической системы могут впоследствии вызвать серьезные последствия. Это означает, что

поведение многих систем в конечном итоге непредсказуемо, а небольшие затруднения могут

трансформироваться в огромные проблемы, с чем легко согласится любая группа разработчиков

программного обеспечения. Такая непредсказуемость означает далекоидущие последствия с

точки зрения предварительной оценки, планирования и контроля системы — это отлично знают

ученые-климатологи и специалисты по организации дорожного движения и значительно хуже

понимают менеджеры проектов и линейные менеджеры.

Еще одним из открытий теории хаоса стали фракталы и масштабная инвариантность, то есть

свойство графиков, отражающих поведение систем, выглядеть одинаково независимо от

применяемого масштаба.

Некоторые считают теорию хаоса непосредственной предшественницей теории сложности,

поскольку обе они признают неопределенность и изменчивость в качестве основных свойств

исследуемых систем. По моему мнению, теория хаоса — это основа наших знаний о сложных

системах.

Общая картина наших знаний о поведении систем

Как нет единого определения сложности, так нет и единой теории, которая объясняла бы

поведение всех сложных систем разом [Lewin 1999: x]. Ученые давно пытаются обнаружить

фундаментальные законы, которые были бы применимы к любым системам при любых

обстоятельствах, но пока что эти попытки не увенчались успехом.

Представляется разумным задать вопрос: что же такое эта «теория сложности»? И хотя есть

множество ее определений, существует точка зрения, что единого описания данная теория не

имеет[8].

Каждая система имеет свои специфические особенности, поэтому выводы, сделанные из

прошлых результатов, не дают гарантии будущих успехов. Так что, судя по всему, все, что у нас

сейчас есть, — это набор различных теорий, которые иногда дополняют друг друга, иногда

перекрывают, а иногда и противоречат друг другу.

Более того, существует достаточное количество более локальных исследований, каждое из

которых внесло свой вклад в развитие знаний о сложных системах. Их можно сравнить с

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

момент знаний о поведении сложных систем. Например, исследования диссипативных

систем дали нам представление о спонтанном формировании структур и о том, каким образом

может протекать самоорганизация систем внутри границ. Изучение клеточных

автоматов продемонстрировало, что сложное поведение системы может быть

результатом простых правил. Исследования в области искусственной жизни показали, как

осуществляется обработка информации в агент-ориентированных системах. Благодаря

изучению самообучающихся систем мы поняли, каким образом генетические

алгоритмы обеспечивают способность живых систем к адаптивному обучению. А в

результате анализа социально-сетевых структур мы теперь понимаем, как распространяется

информация среди людей.

Несмотря на то, что некоторые части тела нашего человека выглядят непропорционально и

что сам он уродливее, чем зомби в балетной пачке, он тем не менее весьма живой — как и сумма

знаний, которую олицетворяет (рис. 3.1). И когда эти знания применяются к сложным системам,

41

мы называем их теорией сложности. Но что конкретно мы имеем в виду, когда говорим, что

система, с которой мы имеем дело, сложная?

Простота: новая модель

В дискуссиях по поводу простоты и сложности отметились многие эксперты. Но их участие

не привело к прояснению вопроса, поскольку зачастую присутствовала значительная

терминологическая путаница. Ниже приводится моя попытка внести ясность в этот вопрос. Так

что же такое простота?

Простота обычно определяется количеством усилий, которое необходимо, чтобы понять или

объяснить какое-либо явление. Явление, которое легко понять или объяснить, будет простым, в

отличие от тех явлений, что запутанны.

Если мы хотим обсудить, что такое простота, полезно уточнить содержательную разницу

между сложными и запутанными понятиями или явлениями. Непонимание этой разницы может

привести к тому, что вы выберете неправильный подход к решению той или иной проблемы.

Я считаю, что разница между этими двумя терминами должна объясняться в двух

измерениях, показанных на рис. 3.2. Первое измерение относится к структуре проблемы и тому,

насколько хорошо мы ее понимаем:

Простая = легко поддающаяся пониманию.

Запутанная = очень трудная для понимания.

Второе измерение касается поведения системы и того, насколько легко мы можем его

предсказывать:

Упорядоченное = полностью предсказуемое.

Сложное = предсказуемое в определенной степени.

Хаотическое = чрезвычайно непредсказуемое.

Мои трусы устроены очень просто. Нетрудно понять, как они работают. Напротив,

устройство моих часов весьма непросто: если бы я разобрал их, то мне понадобилось бы много

времени, чтобы разобраться в их конструкции и том, как взаимодействуют отдельные части. И

42

все же ни мои часы, ни мои трусы не обещают никаких сюрпризов (по крайней мере для меня).

Это упорядоченные, предсказуемые системы.

Команда разработчиков из трех человек также будет простой системой. Чтобы достаточно

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

походов в кафе во время обеденного перерыва и пара кружек пива. Возьмем в качестве другого

объекта город. Очевидно, что город устроен не просто, а запутанно. Таксистам требуются годы,

чтобы изучить все его улицы, проезды, отели и рестораны. При этом как команды, так и города

будут сложными системами. Как бы хорошо вы их ни знали, сюрпризы неизбежны. Они

предсказуемы лишь в ограниченной степени, и невозможно знать наверняка, что случится завтра.

Двойной маятник (два маятника, соединенные вместе) также представляет собой простую

систему. Легко понять, как он устроен, и изготовить его тоже несложно. И тем не менее при

определенных условиях такой маятник совершает непредсказуемые хаотические движения