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

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

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

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

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