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

вследствие значительной зависимости этой системы от начальных условий. Хаотически ведут

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

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

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

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

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

непостижимыми для простых людей вроде меня.

Чем эта модель отличается от других?

Известна модель Cynefin (читается как Кеневин) (рис. 3.3a), предложенная Дэвидом

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

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

сложные и хаотические (имеется также промежуточная категория — беспорядочные) и

применяется при принятии решений и выработке политик в разных областях [Snowden 2010b].

Похожая модель была создана и профессором менеджмента Ральфом Стейси. Его модель

называется матрицей согласованности и определенности (рис. 3.3b). Матрица разделена на

четыре области (область простых систем, запутанных, сложных и область анархии или хаоса),

размещенных вдоль двух осей: степени согласованности и степени неопределенности [Stacey

2000b].

Глава 16 в этой книге называется «Все модели неверны, но некоторые из них полезны», и это

утверждение соответствует действительности. Все три приведенные здесь модели неверны, но

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

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

идентифицированы шесть типов систем, а не четыре, при этом запутанные и сложные

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

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

43

Термин «запутанный» относится к устройству системы, которое может быть вполне

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

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

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

в этом смысле (представим себе два автомобиля в гараже). А сложная система необязательно

имеет неочевидное устройство — например, два человека в спальне. (Их

поведение может оказаться вполне непредсказуемым.)

Упрощение — действия, направленные на то, чтобы сделать структуру или устройство

системы более понятным (в моей модели этому соответствует движение сверху вниз).

Линеаризация — действия, направленные на то, чтобы сделать поведение системы более

предсказуемым (в модели — движение справа налево).

К сожалению, на дилетантском уровне часто путают линеаризацию и упрощение. И тут-то

возникают проблемы.

А как насчет сложности программного обеспечения?

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

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

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

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

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

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

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

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

содержанием. Поэтому в некотором смысле правота на стороне дилетантов, а не специалистов. И

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

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

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

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

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

Простое и хорошо структурированное ПО может демонстрировать очень сложное поведение,

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

44

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

Еще раз об упрощении

Предлагаемая мною модель основана на противопоставлении структуры и поведения. Как

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

ряд недоразумений.

Все следует упрощать до тех пор, пока это возможно, но не более того.

Альберт Эйнштейн

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

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

сверху вниз (упрощение). Тем не менее оговорка «но не более того», по всей видимости,

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

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

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

Простота — это миф, время которого прошло, если оно вообще когда-либо существовало

[Norman 2007].

В своей интереснейшей статье «Простота сильно переоценена» Дон Норман обсуждает

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

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

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

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

— горизонтальной и вертикальной. (Например, когда Google добавил в почтовый сервис Gmail

отдельный почтовый ящик для приоритетных сообщений, поведение Gmail усложнилось. Стал

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

К сожалению, Дон Норман использует термин «упрощение» как для обозначения

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

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

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

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

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

посредством визуализации, а не в том, чтобы упростить их[9].

В своем бестселлере «Визуальное мышление» Дэн Роэм предлагает использовать рисунки для

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

оси от запутанного к простому. Но даже в его предупреждении «не упрощать» присутствует

терминологическая путаница. На самом деле Дэн имеет в виду, что при представлении в виде

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

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

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

понимания. Но при этом следует избегать линеаризации («упрощения») поведения системы,

потому что это вводит в заблуждение.

Адаптивные и неадаптивные системы

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

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

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

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

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

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

могли адаптироваться к перепадам в моем настроении. Такие воронки — пример

сложных неадаптивных систем. Они сложные, но не в состоянии адаптироваться [Lewin 1999:

15].

Несколько более интересны сложные адаптивные системы (САС). Они способны

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

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

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

45

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

заказчика.

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

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

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

определенной траектории посредством «хаордических процессов», сочетающих в себе элементы

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

хаотическими [Highsmith 2002].

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

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

воронок. И это помогало мне понять, как можно их контролировать.

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

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

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

Не злоупотребляем ли мы научным подходом?

При обсуждении гибких методологий разработки ПО мы регулярно слышим такие научные

термины, как самоорганизация и эмерджентность.

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

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

результатов[10].

Например, колония муравьев, мозг, иммунная система, Scrum-команды и город Нью-Йорк

будут самоорганизующимися системами[11].

Scrum — это не методология, не четко расписанный процесс и не набор процедур. Это

открытый фреймворк при разработке программного обеспечения. Применяемые правила

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

самоорганизуется и приходит в состояние, адекватное решаемой задаче[12].

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

обеспечения? Согласны ли сами специалисты по сложным системам, что такие термины,

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

и иммунной системы, но также и к Agile-командам?

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

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

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

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

1998: 4].

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

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

сторонникам Agile-методологий, а людям в целом. Но сигнал мы услышали. Чтобы усвоить его

еще лучше, вот цитата, напрямую относящаяся к существу вопроса:

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

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

менеджмента — бывает, что она используется чуть ли не в метафорическом смысле. Один [такой

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

рекомендует вымарывать из них любые ссылки на теорию сложности[13].

Ох!

Впрочем, я вновь немного сжульничал. Эта критика была направлена против литературы по

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

о гибких методологиях. Но все же… лучше внять и этому предупреждению.

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

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

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

в большие проблемы, нет ничего легче, чем заявить, что это проявление «хаотического»

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

46

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

сложности…

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

терминологией?

А как насчет «эмерджентного дизайна»? Это тоже злоупотребление?

Лично я так не думаю. Но в любом случае будет разумно сохранять критичность и здоровую

долю скепсиса.

В этой книге я пишу об идеях и концепциях из теории сложности, которые мы могли

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

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

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

имеются достаточные основания.

Новая эра: мышление в категориях теории сложности

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

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

систему.

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

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

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

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

могут проявлять неожиданное нелинейное поведение [Stacey 2000a: 64]. Системная динамика

показала, что структура организации, с ее многочисленными циклическими

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

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

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

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

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

индивидуумов. Системная динамика не будет частью суммы наших знаний о системах. Это

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

математике.

В 1980-х годах возникла новая идеология, в чем-то схожая с системной динамикой,

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

Сенге «Пятая дисциплина»[14] [Senge 2006]. Системное мышление представляет собой набор

установок при решении «проблем», которые рассматриваются как часть более обширной

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

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

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

если компоненты рассматриваются изолированно. Системное мышление в чем-то похоже на

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

широко применяются симуляции и математические расчеты. Системное мышление считается

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

расплывчата [Forrester 1992]. Основная ценность системного мышления состоит в том, что оно

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

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

картину их организаций с интересных, но субъективных ракурсов.

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

направления, которое принято называть социологическая системная теория. К сожалению, ни

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

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

нереалистичными [Snowden 2005]. Использование упрощенных симуляций при описании

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

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

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

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

47

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

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

выдавать «правильные» результаты. Все эти подходы недалеко ушли от детерминистского

мышления XIX века [Stacey 2000a]. Но XXI век — век сложности. Это время, когда менеджеры

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

понять, как они формируются и растут, а не как их конструировать.

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

основными постулатами нелинейности, недетерминизма и неопределенности. Менеджмент 3.0

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

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

командам надо давать возможность формироваться и развиваться постепенно. Управление

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

Продуктивность — это постепенно проявляющееся свойство, возникающее благодаря

самоорганизации и эволюции команд. Мне нравится сравнивать этот тип мышления с

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

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

бесполезны.

В главе 4 мы направим этот поток света на команды разработчиков ПО и увидим, каким

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

самоорганизовываться и адаптироваться к изменениям в среде.

Резюме

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

достижения общей теории систем, кибернетики, теории динамических систем, теории игр и

эволюционной теории.

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

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

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

Одно из важных наблюдений состоит в том, что сложность системы (то, насколько она

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

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

изменениям в среде. Такие системы называют сложными адаптивными системами (САС).

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

качестве сложных адаптивных систем.

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

Давайте посмотрим, как применить некоторые идеи из данной главы в вашей компании:

Развивайте свою способность к мышлению в категориях сложных систем. Подпишитесь

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

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

Глава 4

Информационно-инновационная система

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

написано». Если он спрашивает «А какова моя мотивация?», я отвечаю: «Твоя зарплата».

Альфред Хичкок, режиссер (1899–1980)

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

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

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

рабочими?

По словам Митчелла Уолдропа, автора книги «Сложность: Новая наука на границе

упорядоченности и хаоса» (Complexity: The Emerging Science at the Edge of Order and Chaos),

основным предметом дискуссий в Институте Санта-Фе (лидер мировых исследований в области

сложных систем) стали состоящие из агентов системы. Этими агентами могут быть молекулы,

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

48

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

несводимым к поведению составляющих их элементов [Waldrop 1992: 88].

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

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

социальные группы, временные группы для решения какой-либо проблемы, комитеты и так

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

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

проекты по разработке ПО состоят из агентов (людей), которые взаимодействуют друг с другом

и образуют интегрированное целое. (Обратите внимание, что термин агенты в сложных системах

означает всего лишь взаимодействующие элементы или части и не имеет никакого отношения

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

Хотя проекты по разработке ПО могут состоять из большого количества элементов,

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

4.1). (На более высоком уровне агентами также можно считать сами команды.) Функциональные

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

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

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

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

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

императивом модели Менеджмента 3.0, и данная глава в основном о людях. Но прежде чем на

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

Инновации — ключ к выживанию

В любой конкурентной среде ключом к выживанию будут инновации. Это вопрос жизни и

смерти для компаний во всем мире [Davila 2006: 6]. Как правило, максимум ценности в сфере

бизнеса создается в результате инноваций [Highsmith 2009: 31]. Организации, конкурирующие на

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

очередь на инновациях, отмечает профессор Икудзиро Нонака в своей статье «Компания,

создающая знания» [Nonaka 2008]. И это относится не только к компаниям этого типа,

утверждает Роберт Остин — ученый, который специализируется на креативности и инновациях.

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

все в большем числе индустрий могут конкурировать в области инноваций [Austin, Devin 2003:

53].

Надо же, какое совпадение…

Понятие «инновации» находится в центре внимания наук, изучающих сложные системы.

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

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

49

системы находятся «на кромке хаоса» [Kauffman 1995]. В биосфере примерами инноваций могут

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

наличие у природы своеобразного чувства юмора). Исследователи утверждают, что в основе

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

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

Согласно таким публикациям, как «Сложность и инновации в организации» [Fonseca 2002] и

«Перспективы теории сложности в применении к инновациям и социальным изменениям» [Lane

2009], инновации — характерное явление типа «снизу вверх». Эти авторы подчеркивают, что

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

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

задача изобрести что-то новое). Такой подход представляет собой наивную попытку управлять

50

будущим и базируется на причинно-следственном детерминизме. Подобные программы просто

не работают.

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

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

которой оно может возникнуть. Я идентифицировал пять драйверов инноваций (рис. 4.5),

которые мы сейчас и обсудим.

Знания

Как отмечают Дон Тапскотт и Энтони Уильямс в книге «Викиномика» [Tapscott, Williams

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

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

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

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

многих профессий лежит работа с информацией, гуру менеджмента Питер Друкер предложил

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

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

[Nonaka 2008]).

Именно так все и происходит в проектах по разработке ПО. Знания позволяют нам создавать

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

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

инновации.

Знания образуются через постоянное поступление информации из внешней среды через

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

результатом непрерывное накопление опыта. Команда разработчиков ПО будет системой,

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

инноваций.

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

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

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

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

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

Хранение знаний в мозгу организовано подобно существованию информации в интернете — в

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

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

централизованное управление информацией. Некоторые называют это «голографической

памятью» по аналогии с голограммами, которые многократно сохраняют информацию о

целостном трехмерном изображении в каждом участке пластинки [Hunt 2008: 48].

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

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

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

числа соединений. Точно к такому же выводу в своих исследования пришли Роб Кросс и Эндрю

Паркер, опубликовавшие свои результаты в книге «Невидимая сила социальных связей»[16].

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

51

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

данный индивидуум обладает в организации [Cross 2004: 11].

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

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

передавать их друг другу посредством «осмотической коммуникации» в процессе совместной

работы [Cockburn 2007: 202]. Следовательно, критически важно, чтобы люди, входящие в

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

вернемся к проблемам коммуникации в главе 12 и 13. В данный момент нас интересуют лишь

аспекты, связанные с людьми.)

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

фактом № 22 из книги Роберта Гласса «Факты и заблуждения профессионального

программирования»:

80% усилий по созданию ПО приходятся на интеллектуальную деятельность. Значительная

часть этой деятельности креативна. И лишь небольшая часть — чисто техническая[17].

Профессия разработчиков ПО заключается в решении проблем. Гласс выполнял свои

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

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

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

бизнес-консультантов).

То же самое исследование, проведенное Глассом, показало, что 16% интеллектуальных задач,

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

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

инновации.

Креативность

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

знаний [Kao 2007]. Креативность заключается в способности отходить от шаблонных подходов

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

там, где до этого никто их не видел. (Иногда это выглядит как кража старых идей и заметание

следов, чтобы никто об этом не узнал.)

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

признается исследователями [Runco, Pritzker 1999]. Имеются подтверждения, что креативность в

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

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

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

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

Не существует единого определения креативности или общепринятого понимания ее

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

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

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

одновременно оригинальны и полезны.

Оригинальность

Намерение (или надежда) многих разработчиков таково: решать проблемы, разрабатывая

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

из них хочет, чтобы это удалось именно ему, а не кому-нибудь другому!). Чтобы сделать каждую

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

программирование, компонентное программирование, сервисно-ориентированная архитектура и

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

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

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

или парикмахеров. В арсенале представителей других креативных профессий нет такого

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

конструкции или косвенная адресация.)

Полезность

52

Аналогичным образом второе намерение большинства разработчиков таково:

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

деятельности в сфере бизнеса не внес такой вклад в повышение глобальной производительности.

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

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

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

парикмахеров. (Единственное исключение я готов сделать для рок-звезд.) При этом разработчики

даже не считают себя «креативными» со всеми расплывчатыми коннотациями, которые связаны

с этим словом. У большинства из них далеко не артистический темперамент. Они просто хотят