Несмотря на блестящие успехи с точки зрения окупаемости инвестиций Agile-проектов [Rico 2009], многие менеджеры по всему миру в своих компаниях препятствуют гибкому проектному менеджменту и гибким методологиям. Исследования и опросы свидетельствуют, что основными препятствиями на пути принятия гибких методов разработки ПО становятся традиционные методы управления изменениями, организационная культура, недостаток поддержки со стороны руководства, низкая подготовленность персонала, а также внешнее давление [VersionOne 2009]. За многое из этого отвечают именно менеджеры. Если верить имеющимся отчетам на эту тему (а у меня нет оснований в них сомневаться), то сами менеджеры во всем мире будут скорее проблемой, чем частью решения. Печально, что это характерно не только в случаях внедрения гибких методологий разработки ПО. То же самое происходит при любых других серьезных организационных изменениях.

Моя позиция в этой книге состоит в том, что, когда необходимы подобные изменения, традиционный менеджмент будет проблемой, а не решением. Эту же точку зрения много лет назад высказывал Уильям Эдвардс Деминг. Именно поэтому нам нужна теория гибкого менеджмента: теория, которая хорошо сочеталась бы с гибкими методологиями разработки ПО.

Существует ли теория, которая может помочь менеджерам работать в гибкой среде? За последние несколько десятилетий было предложено много управленческих теорий – впрочем, большинство из них вовсе не будут теориями в строгом научном смысле [Lewin, Regine 2001: 5]. Настоящая научная теория должна быть в состоянии не только указывать на существование каких-либо природных явлений, но и делать проверяемые утверждения о наблюдаемом реальном мире, предсказывая, каких событий следует ожидать, прежде чем их можно будет наблюдать. Именно в этом смысле различные управленческие «теории» не соответствуют ожиданиям. Они зачастую представляют собой не столько теории, сколько наборы технических приемов. Вместо того чтобы давать описание того, как функционирует реальный мир, они предлагают советы (часто полезные), как подойти к той или иной проблеме или ситуации. В этом смысле хорошим примером будет теория ограничений. Это не научная теория, а управленческая философия, которая предлагает способы оптимизации процессов и позволяет добиваться целей, постоянно фокусируясь на имеющихся ограничениях.

Значит ли это, что я в состоянии предложить свою собственную «теорию» гибкого менеджмента, втайне надеясь войти в пантеон таких мыслителей, как Портер, Деминг и Друкер? Боюсь, что нет.

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

К счастью, я вскоре понял, что эта цель недостижима по двум причинам. Во-первых, уже существует множество теорий, претендующих на объяснение того, как люди работают в командах (здесь можно порекомендовать книгу «Малые группы как сложные системы» (Small Groops as Complex Sistems) [Arrow 2000], а также журнал «Эмерджентность. Теория сложности в применении к организациям»[2]). Эта область известна как социальная сложность. Во-вторых, сама теория сложности говорит нам, что любые попытки создать единую модель, описывающую сложные системы, неизбежно обречены на неудачу. Эта тема затронута в главе 16 «Все модели неверны, но некоторые из них полезны». Я испытал облегчение, когда понял это: «Сделать это невозможно. Прекрасно! Значит, я могу начать работать над чем-то другим!» Это отличный пример того, когда понимаешь свои заблуждения еще на раннем этапе. (Из теорем Гёделя о неполноте следует, что такая невозможность распространяется и на любые единые теории. Все-таки хорошо, что ученые в своих поисках не сдаются так легко, как я.)

Эта книга поможет вам стать более хорошим менеджером. В частности, в ней показано, в чем должны заключаться ваши обязанности в качестве Agile-руководителя в компании, занимающейся разработкой программных продуктов на основе гибких методологий. Книга дает богатый инструментарий, что позволяет применять теорию в ежедневной практике. Она объясняет, как нужно управлять командами, исходя из представления, что системы в большинстве случаев оказываются сложными, а не линейными, а также как фокусироваться на адаптивности, а не на предсказуемости. Не имеет особого значения, кто вы – менеджер проекта по разработке ПО, лидер команды, технический директор или программист. В конечном итоге все мы пытаемся управлять окружающей нас средой. Давайте научимся делать это хорошо.

Применяемая в книге модель показана на рис. 1.4. Я называю ее моделью Менеджмента 3.0. Она рассматривает организацию с шести углов зрения. Каждый из этих компонентов описан в книге отдельно, и каждому посвящено по две главы – теоретической и практической. Но прежде чем мы начнем обсуждать модель в деталях, я считаю важным еще раз вернуться к двум базовым комплексам идей, лежащим в ее основе, а именно к гибкости и сложности, а также уделить немного времени истории каждого из этих комплексов. Глава 2 содержит краткий обзор гибких методологий разработки программного обеспечения, а в главе 3 рассматриваются основы теории сложности. Суть модели, то есть способы управления командами разработчиков, вы найдете в центральной части книги, которая открывается главой 4 «Информационно-инновационная система» и заканчивается главой 15 «Улучшение всего». И наконец, глава 16 содержит краткое заключение.

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

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

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

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

Менеджмент 3.0 – это модель для Agile-менеджмента, которая позволяет применять подходы теории сложности к управлению командами, занимающимися разработкой программных продуктов с использованием гибких методологий.

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

• Возьмите в качестве примера какую-нибудь реальную нерешенную проблему из своей профессиональной сферы. Попробуйте представить, в чем может состоять ее причина. Уверены ли вы, что эта причина – единственная? Почему вы так считаете? Обсуждали ли вы эту проблему со всеми заинтересованными сторонами? Все ли из них согласны, что проблема вызвана единственной причиной? Проведите такой же анализ для каждой из наиболее важных проблем, с которыми имеете дело. Убедитесь, что вы не упрощаете сложность данных проблем и не пытаетесь устранить причину, которая определена неправильно.