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

выстраивая изложение в книге. Эта история берет свое начало в причинно-следственных

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

познакомимся с моделью Менеджмента 3.0.

Причинно-следственные связи

Представлением о том, что обычно все происходит в соответствии с нашими планами

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

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

предыдущих в соответствии с законами природы». Детерминизм говорит нам, что причиной

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

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

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

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

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

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

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

либо сестру и при этом не получить по шее.

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

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

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

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

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

что философ Иммануил Кант провозгласил всеобщий детерминизм в качестве необходимого

условия любого научного знания [Prigogine, Stengers 1997: 4].

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

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

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

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

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

16

операционных систем, аварийных отключений электричества, неквалифицированных

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

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

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

клиентов.

Но, как это ни было бы странно, одного детерминизма недостаточно. Хотя мы умеем

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

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

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

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

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

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

Так в чем же проблема?

Сложность

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

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

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

смотреть телевизор. В то же самое время сложность зачастую превращает взаимодействия

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

сюрпризов.

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

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

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

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

непросто). Эта молекула состоит всего из двух атомов водорода и одного атома кислорода.

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

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

плотностью воды, и других физических и химических явлениях [Solé 2000: 13], которые не

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

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

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

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

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

17

научного знания, наука не стояла на месте. Теория динамических систем, теория хаоса,

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

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

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

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

собирательно именуют теорией сложности (см. главу 3 «Теория сложности»).

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

сложность как предмет исследования возникла в XX веке; соответствующие исследования

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

выделилась в отдельную научную дисциплину. Физик-теоретик Стивен Хокинг утверждал,

что XXI век будет веком сложности [Chui 2000].

Развитие теории сложности – хорошая новость для руководителей, лидеров команд и

менеджеров проектов (а также всех прочих «лидеров» и «менеджеров»), работающих в

компаниях, создающих ПО. Это означает, что возник научный подход к исследованию

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

организациями в целом. И хотя для меня момент истины опоздал ровно на 10 миллионов

евро, я согласен со Стивеном Хокингом, что представление о сложности – ключевая

парадигма XXI века.

Наше линейное мышление

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

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

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

«Рожденные верить: Как наш мозг создает богов» [Brooks 2009] автор показывает, что

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

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

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

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

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

если для этого нет никаких оснований.

«Вы слышите шорох в кустах и делаете вывод, что там кто-то притаился».

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

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

недостаточно обнаруживать их в девяти случаях из десяти. Лучше

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

иллюзорной. В конце концов, цена такой перестраховки невелика1.

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

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

(гипотезой, что в реальности все обстоит гораздо сложнее). Мы привыкли считать, что

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

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

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

он», чем утверждение «некоторые вещи просто случаются». Если в наличии проблема B, то

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

банкиры; в сокращении числа рабочих мест виноваты иммигранты; в плохой атмосфере в

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

1 Michael Brooks, “Born believers: How your brain creates God,” New Scientist, February 4, 2009 [Brooks 2009:

32].

18

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

Линейное мышление воспринимает мир как пространство, наполненное легкообъяснимыми

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

Вайнберг называет это ошибкой причинности [Weinberg 1992: 90].

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

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

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

результатом событие B, а ситуация – событие C, при этом C лучше, чем B, то

всего-навсего надо заставить A превратиться в , и все будет хорошо. Так по крайней мере

часто кажется.

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

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

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

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

сих пор существуют во многих организациях [Stacey 2000a: 7]. Сейчас уже всем известно,

что системы контроля эффективны, только если речь идет о повторяющихся операциях, не

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

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

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

время затянули.

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

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

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

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

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

достигнуты.

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

проектировании и планировании сверху вниз. Мой бизнес-план (который, кстати, был даже

отмечен профессиональными премиями) состоял из 30 страниц тщательно выверенной

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

бизнес-план. В конце концов, поскольку его разработал я, как он мог быть неправильным?

Редукционизм

Подход, в рамках которого систему разбирают на части, а затем изучают

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

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

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

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

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

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

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

Редукционистский подход хорош только до определенного предела (рис. 1.2). После

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

на созданные за последние сто с лишним лет многочисленные теории, экономисты так и не

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

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

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

процесс разработки программного обеспечения, тем не менее во всем мире множество

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

человека, экономика, изменение климата и проекты по разработке ПО – все эти системы

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

19

изучения компонентов по отдельности.

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

ограниченна

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

отличительная черта людей – тенденция неточно интерпретировать информацию,

поступающую из окружающей действительности. Мы склонны игнорировать

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

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

или менее точно предвидеть будущие события.

Идея целостности

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

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

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

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

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

[Corning 2002: 69].

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

все явления могут быть сведены к поведению их составных частей. Философ Дэниел Деннет

предложил термин «Жадный редукционизм» [Dennet 1995] для обозначения форм

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

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

это не более чем электроны и на самом деле они не существуют» будет примером такого

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

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

смехотворные аргументы. Но я отвлекся.

В качестве компромисса биолог-эволюционист Ричард Докинз предложил понятие

иерархического редукционизма [Dawkins 1996], смысл которого в том, что сложная

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

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

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

объяснить провал своего проекта тем, что вам помешали кварки и лептоны.

20

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

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

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

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

[Miller, Page 2007: 41]. Знание компонентов, находящихся на нижних уровнях системы, вовсе

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

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

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

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

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

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

недостаточности (конструкционизм).

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

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

она обращена исключительно в прошлое. С ее помощью можно решить проблемы,

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

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

не так.

Иерархический менеджмент

Взгляд на систему как на единое целое (холизм) и иерархический редукционизм

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

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

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

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

идентифицировать внутри деконструированной утки рычажки, подшипники и шестеренки,

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

объект в парке, вы сразу понимаете, что это утка.

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

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

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

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

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

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

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

как функционируют живые организмы на уровне клеток-эукариотов, генов и РНК, не

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

знать о хромосомах и геноме. Точно так же генеральный директор должен иметь обширные

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

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

лично сталкивались с такими ситуациями).

Управление организацией требует совершенно иных знаний и опыта, чем управление

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

уровнях, может оказаться полезным. Инженер-программист Джоэл Сполски предложил

закон дырявых абстракций [Spolsky 2002] в качестве объяснения, почему в системах

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

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

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

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

21

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

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

ошибках, которые получают пользователи (рис. 1.3).

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

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

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

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

который я называю своим мышлением. И тем не менее мне вовсе не нужно анализировать

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

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

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

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

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

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

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

что коммуникация делегирована надежной команде других управленцев (в этом его отличие

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

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

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

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

Гибкий менеджмент

Когда иерархический менеджмент встречается со сложными системами и нелинейным

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

Это логическое дополнение к Agile-методологиям разработки программного

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

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

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

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

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

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

Гибкие методы разработки ПО некоторыми своими корнями уходят в теорию

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

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

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

сложным системам [Schwaber, Beedle 2002], и люди, практикующие в настоящее время

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

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

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

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

22

или воспитания детей.

Несмотря на блестящие успехи с точки зрения окупаемости инвестиций Agile-проектов

[Rico 2009], многие менеджеры по всему миру в своих компаниях препятствуют гибкому

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

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

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

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

давление [VersionOne 2009]. За многое из этого отвечают именно менеджеры. Если верить

имеющимся отчетам на эту тему (а у меня нет оснований в них сомневаться), то сами

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

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

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

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

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

назад высказывал Уильям Эдвардс Деминг. Именно поэтому нам нужна теория гибкого

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

ПО.

Моя теория всего

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

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

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

Regine 2001: 5]. Настоящая научная теория должна быть в состоянии не только указывать на

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

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

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

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

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

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

проблеме или ситуации. В этом смысле хорошим примером будет теория ограничений. Это

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

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

ограничениях.

Значит ли это, что я в состоянии предложить свою собственную «теорию» гибкого

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

Друкер? Боюсь, что нет.

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

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

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

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

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

дырявой абстракции.

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

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

командах (здесь можно порекомендовать книгу «Малые группы как сложные системы»

(Small Groops as Complex Sistems) [Arrow 2000], а также журнал «Эмерджентность. Теория

сложности в применении к организациям» 2 ). Эта область известна как социальная

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

2 Журнал E: CO. Emergence: Complexity & Organization выходит в издательстве Emergency Publications.

23

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

затронута в главе 16 «Все модели неверны, но некоторые из них полезны». Я испытал

облегчение, когда понял это: «Сделать это невозможно. Прекрасно! Значит, я могу начать

работать над чем-то другим!» Это отличный пример того, когда понимаешь свои

заблуждения еще на раннем этапе. (Из теорем Гёделя о неполноте следует, что такая

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

своих поисках не сдаются так легко, как я.)

Модель, предлагаемая в этой книге

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

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

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

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

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

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

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

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

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

делать это хорошо.

Применяемая в книге модель показана на рис. 1.4. Я называю ее моделью Менеджмента

3.0. Она рассматривает организацию с шести углов зрения. Каждый из этих компонентов

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

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

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

сложности, а также уделить немного времени истории каждого из этих комплексов. Глава 2

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

главе 3 рассматриваются основы теории сложности. Суть модели, то есть способы

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

открывается главой 4 «Информационно-инновационная система» и заканчивается главой 15

«Улучшение всего». И наконец, глава 16 содержит краткое заключение.

24

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

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

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

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

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

суметь вовремя это увидеть.

Резюме

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

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

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

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

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

Несмотря на то, что редукционизм (понимание природы системы через осмысление ее

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

следуя по этому пути, можно зайти слишком далеко.

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

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

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

Менеджмент 3.0 – это модель для Agile-менеджмента, которая позволяет применять

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

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

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

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

• Возьмите в качестве примера какую-нибудь реальную нерешенную проблему из своей

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

Уверены ли вы, что эта причина – единственная? Почему вы так считаете? Обсуждали ли вы

эту проблему со всеми заинтересованными сторонами? Все ли из них согласны, что

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

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

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

неправильно.

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

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

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

отношения причины и следствия. У многих явлений, происходящих в сложных системах,

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

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

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

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

помощью дискуссии на эти темы с компетентными коллегами. Организуйте такое

обсуждение.

Глава 2

Гибкие методологии разработки ПО

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

мир и прекрасно провести время. Иногда это затрудняет

25

составление плана на день.

Э.Б. Уайт, американский писатель (1899–1985)

Для некоторых из вас эта глава необязательна. Если вы знакомы с Agile-методологиями

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

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

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

говорить о роли менеджеров в гибких организациях (глава 4

«Информационно-инновационная система»).

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

гибких методологий. А пока сделайте вид, будто считаете, что XP – это старая операционная

система, и продолжайте читать.

Прелюдия к гибким методологиям

Я люблю считать деньги почти так же, как и тратить их. В начале 1990-х годов, когда я

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

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

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

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

сосчитать. Увы, этого не случилось.

Я был единственным автором этого программного продукта (около 30 000 строк кода).

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

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

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

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

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

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

1990-е годы). Хотя прошло уже двадцать лет, я до сих пор пользуюсь этой программой для

управления своими финансами.

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

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

Не имею ни малейшего представления.

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

«Agile-методологии» и производные от них.

26

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

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

• Я работал над своим продуктом с энтузиазмом. У меня был кое-какой опыт

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

с целью лишить пользователей всех жизненных и душевных сил. Мое видение состояло в

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

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

• Я сам был своим критично настроенным заказчиком. Я создавал эту программу

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

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

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

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

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

операции, как ввод транзакций. Затем перешел к менее критичным функциям вроде

составления баланса и внесения корректировок. В конце добавил такие необязательные

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

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

• Процесс создания программы менялся по мере написания кода. Я начал

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

длиннее. Я никогда до этого не слышал о покомпонентном тестировании, но моя система

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

Вот, собственно, и все. У меня была мотивация, а также критично настроенный

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

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

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

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

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

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

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

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

Евангелие от Agile

Вначале инженеры сотворили компьютеры и программное обеспечение. Программное

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

И инженеры сказали: «Да будет структура». И возникла структура.

И даже в избытке.

За последние пять-шесть десятков лет многие инженеры-компьютерщики озаботились

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

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

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

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

служило представление, что создание ПО – чисто инженерная задача. В результате

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

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

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

оказывались неэффективными. Гораздо чаще их результатом становилось возникновение

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

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

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

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

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

27

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

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

В начале 1990-х была предложена новая методология под названием быстрая

разработка приложений (Rapid Application Development, RAD). В рамках этой

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

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

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

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

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

[McConnell 1996]. В результате такого скрещивания формализованных и

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

эволюционное управление разработкой (Evo) (1988), Scrum (1995), методы разработки

динамических систем (DSDM) (1995), методы Crystal (1997), Экстремальное

программирование (XP) (1999), разработка, управляемая функциональностью (FDD)

(1999), прагматическое программирование (1999) и адаптивная разработка ПО (2000).

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

статей, книг и семинаров по «легким» методологиям (некоторые даже сравнивали его с

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

дел. В 2001 году они встретились на лыжном курорте в штате Юта. Там и был выбран

термин «гибкие методологии» (Agile), заменивший применявшуюся ранее терминологию, а

также был создан Agile-манифест разработки ПО (рис. 2.2).

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

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

были слишком «упорядоченными». Но лишь немногие поняли, что авторы манифеста также

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

процессов и низкого качества, которое в то время доминировало на рынке ПО. Лидеры

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

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

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

программисты-первопроходцы, но анархии при этом не было.

28

Впоследствии группа наиболее авторитетных представителей Agile-движения создала

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

гибких методологий во всем мире. Возникла целая новая экосистема, состоящая из

конференций, консультантов, книг и журналов. В результате процессы разработки

программного обеспечения стали Agile c большой буквы А, превратившись в нечто более

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

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

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

превратились в образ жизни.

Фундаментальные принципы Agile-методологий

В наши дни численность людей, которые разделяют ценности и принципы

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

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

крайней мере некоторых из «основных Agile-практик» [VersionOne 2009].

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

4 У этой организации есть свой сайт

29

многих авторов это получается гораздо лучше, чем у меня. И все же я чувствую

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

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

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

разработке ПО, – и еще раз вернусь к этой теме в главе 11 «Развитие компетенций».

Люди

Прежде всего Agile-методологии признают за людьми их уникальность и не относятся

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

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

компетенции. Данный подход также предполагает работу в небольших

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

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

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

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

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

как эту работу выполнить, и осознают свою ответственность за результат.

Функциональность

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

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

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

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

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

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

дизайну каждой из функциональных возможностей. Полезность данной функциональности

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

Качество

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

Agile-методологий находится техническое совершенство. Высокий технический уровень

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

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

ревью кода (часто в сочетании с парным программированием), Definition of Done (чек-лист

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

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

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

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

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

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

Инструменты

Сторонники Agile-методологий считают, что инструменты – наименее важный из

факторов, влияющих на успешность проекта. И тем не менее инструменты часто

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

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

непрерывную интеграцию и автоматическое тестирование. Команды нуждаются в