Мы наблюдаем аналогичные проблемы в других сложных системах. Мое сознание нередко становится жертвой временных помутнений, дежавю, забывчивости, произвольно всплывающих воспоминаний и иных странных вещей, которые могут быть объяснены только как сбои в нейронных цепочках низшего уровня, проникающие на более высокий уровень, который я называю своим мышлением. И тем не менее мне вовсе не нужно анализировать нейронные цепочки, чтобы обеспечить удовлетворительную работу своего сознания, хотя порой приятно осознавать, что, по мнению неврологов, такого рода явления достаточно распространены. Точно так же вам не нужно хорошо разбираться в программировании на языке ассемблера, чтобы создавать хорошие программы более высокого уровня, хотя опять же некоторое представление о том, как это все работает уровнем ниже, может иногда облегчить вашу жизнь. В менеджменте все то же самое. Чтобы управлять компанией, генеральному директору необязательно уметь эффективно общаться с людьми, при условии что коммуникация делегирована надежной команде других управленцев (в этом его отличие от менеджеров по разработке новых продуктов, проектных менеджеров и лидеров команд, которым необходимо ежедневно общаться с коллегами). Но на случай, если проблемы нижнего уровня все же прорываются на более высокий (иными словами, когда имеет место дырявая абстракция), владение некоторыми навыками коммуникации может пригодиться.
Гибкий менеджмент
Когда иерархический менеджмент встречается со сложными системами и нелинейным мышлением, мы попадаем в область, которую я называю гибким (Agile) менеджментом. Это логическое дополнение к Agile-методологиям разработки программного обеспечения, которые были созданы в 1990-х годах несколькими группами и отдельными специалистами. Необходимость нового подхода была продиктована неудачами при разработке программного обеспечения, к которым приводил детерминистский подход, основанный на тщательном контроле, предварительном детальном проектировании и планировании сверху вниз. Несмотря на весь этот интенсивный менеджмент, результатом во многих случаях было программное обеспечение, работавшее из рук вон плохо.
Гибкие методы разработки ПО некоторыми своими корнями уходят в теорию сложности, признающую недостаточность причинного детерминизма для реализации успешных проектов. Такие хорошо известные и используемые в гибких методологиях понятия, как «самоорганизация» и «эмерджентность», напрямую взяты из литературы по сложным системам [Schwaber, Beedle 2002], и люди, практикующие в настоящее время Agile-методологии, понимают, что при конструктивистском подходе гарантированы неудачи. Только непрерывная идентификация возникающих в ходе проекта проблем и устранение их причин позволяют последовательно развивать проект по разработке ПО и в конечном итоге получить на выходе успешный программный продукт. Это похоже на процесс взросления или воспитания детей.
Несмотря на блестящие успехи с точки зрения окупаемости инвестиций Agile-проектов [Rico 2009], многие менеджеры по всему миру в своих компаниях препятствуют гибкому проектному менеджменту и гибким методологиям. Исследования и опросы свидетельствуют, что основными препятствиями на пути принятия гибких методов разработки ПО становятся традиционные методы управления изменениями, организационная культура, недостаток поддержки со стороны руководства, низкая подготовленность персонала, а также внешнее давление [VersionOne 2009]. За многое из этого отвечают именно менеджеры. Если верить имеющимся отчетам на эту тему (а у меня нет оснований в них сомневаться), то сами менеджеры во всем мире будут скорее проблемой, чем частью решения. Печально, что это характерно не только в случаях внедрения гибких методологий разработки ПО. То же самое происходит при любых других серьезных организационных изменениях.
Моя позиция в этой книге состоит в том, что, когда необходимы подобные изменения, традиционный менеджмент будет проблемой, а не решением. Эту же точку зрения много лет назад высказывал Уильям Эдвардс Деминг. Именно поэтому нам нужна теория гибкого менеджмента: теория, которая хорошо сочеталась бы с гибкими методологиями разработки ПО.
Моя теория всего
Существует ли теория, которая может помочь менеджерам работать в гибкой среде? За последние несколько десятилетий было предложено много управленческих теорий – впрочем, большинство из них вовсе не будут теориями в строгом научном смысле [Lewin, Regine 2001: 5]. Настоящая научная теория должна быть в состоянии не только указывать на существование каких-либо природных явлений, но и делать проверяемые утверждения о наблюдаемом реальном мире, предсказывая, каких событий следует ожидать, прежде чем их можно будет наблюдать. Именно в этом смысле различные управленческие «теории» не соответствуют ожиданиям. Они зачастую представляют собой не столько теории, сколько наборы технических приемов. Вместо того чтобы давать описание того, как функционирует реальный мир, они предлагают советы (часто полезные), как подойти к той или иной проблеме или ситуации. В этом смысле хорошим примером будет теория ограничений. Это не научная теория, а управленческая философия, которая предлагает способы оптимизации процессов и позволяет добиваться целей, постоянно фокусируясь на имеющихся ограничениях.
Значит ли это, что я в состоянии предложить свою собственную «теорию» гибкого менеджмента, втайне надеясь войти в пантеон таких мыслителей, как Портер, Деминг и Друкер? Боюсь, что нет.
Было время, когда я надеялся изобрести теорию всего, что касалось бы управления разработкой программного обеспечения. Эта теория описывала бы универсальные принципы функционирования любых команд, работающих над созданием программных продуктов, и предоставила бы в помощь менеджерам единую и законченную модель управления такими командами. Оглядываясь назад, я думаю, что в то время мое мышление было жертвой дырявой абстракции.
К счастью, я вскоре понял, что эта цель недостижима по двум причинам. Во-первых, уже существует множество теорий, претендующих на объяснение того, как люди работают в командах (здесь можно порекомендовать книгу «Малые группы как сложные системы» (Small Groops as Complex Sistems) [Arrow 2000], а также журнал «Эмерджентность. Теория сложности в применении к организациям»[2]). Эта область известна как социальная сложность. Во-вторых, сама теория сложности говорит нам, что любые попытки создать единую модель, описывающую сложные системы, неизбежно обречены на неудачу. Эта тема затронута в главе 16 «Все модели неверны, но некоторые из них полезны». Я испытал облегчение, когда понял это: «Сделать это невозможно. Прекрасно! Значит, я могу начать работать над чем-то другим!» Это отличный пример того, когда понимаешь свои заблуждения еще на раннем этапе. (Из теорем Гёделя о неполноте следует, что такая невозможность распространяется и на любые единые теории. Все-таки хорошо, что ученые в своих поисках не сдаются так легко, как я.)
Модель, предлагаемая в этой книге
Эта книга поможет вам стать более хорошим менеджером. В частности, в ней показано, в чем должны заключаться ваши обязанности в качестве Agile-руководителя в компании, занимающейся разработкой программных продуктов на основе гибких методологий. Книга дает богатый инструментарий, что позволяет применять теорию в ежедневной практике. Она объясняет, как нужно управлять командами, исходя из представления, что системы в большинстве случаев оказываются сложными, а не линейными, а также как фокусироваться на адаптивности, а не на предсказуемости. Не имеет особого значения, кто вы – менеджер проекта по разработке ПО, лидер команды, технический директор или программист. В конечном итоге все мы пытаемся управлять окружающей нас средой. Давайте научимся делать это хорошо.