Давным-давно, в далекой-далекой галактике мы с коллегами с гордостью провозгласили себя молодыми революционерами компьютерной индустрии, положившими начало новому поколению методов и технических приемов программирования, дизайна и анализа программных продуктов. Тогда нам казалось, что эти методы вполне гармонично сочетаются с директивными управленческими подходами сверху вниз, господствовавшими в то время. Нам не хватило мозгов, чтобы придумать для своих идей название вроде «Программное обеспечение 2.0», как это сделали впоследствии приверженцы «Web 2.0» и «Предприятия 2.0»… Но как бы то ни было, книга Юргена Аппело убедила меня в том, что идеи, выдвинутые моим поколением, оказались на свалке истории.
Проблема здесь не в методах разработки ПО, и книга Юргена на самом деле не о разработке программных продуктов – хотя гибкие методологии за последние десять лет становятся все более популярными и начисто отвергают идею о том, что функциональность и архитектура сложных систем могут быть разработаны строго линейными методами, базирующимися на иерархическом детерминистском подходе сверху вниз. В сложном мире, где конечные пользователи не совсем уверены, чего они хотят от программного продукта, а среда, в которой они работают, изменяется в процессе разработки ПО, нам необходим упорядоченный (смею ли я сказать «структурированный»?) подход к разработке программных продуктов – и все равно многие детали любого проекта остаются неизвестными и непредсказуемыми, если только эмерджентный подход не позволяет выявить их в нужное время.
Если это верно относительно технических функций, таких как анализ, проектирование и внедрение систем, – а я твердо верю, что это так, – то также это верно и относительно управленческого подхода в целом, который организует, мотивирует, отслеживает, ограничивает и (надеюсь) вознаграждает людей, делающих эти технические задачи.
Таким образом, иерархический стиль управления сверху вниз, который соответствовал нашему иерархическому «структурированному» подходу к анализу и проектированию ПО в 1970-е годы, в настоящее время называют «Менеджмент 1.0». Юрген также сообщает нам, что уже пройдена фаза, известная как «Менеджмент 2.0», которая в значительной степени была представлена новомодными изобретениями типа «Реинжиниринга бизнес-процессов», шести сигм и прочими дополнениями к предшествовавшему им Менеджменту 1.0.
Менеджмент 3.0, который стал предметом этой книги, основан на теории сложности. Это то, чем на протяжении последних нескольких десятилетий занимались математики и биологи. Теперь эта теория становится центральной частью экономики и социологии – а в более общем плане и частью науки об управлении людьми и их взаимоотношениями в организации. Вам действительно стоит прочитать содержащийся в этой книге обзор данной теории и связанных с ней концепций, включая причинно-следственные связи, детерминизм и редукционизм – темы, хорошо знакомые каждому инженеру, математику и специалисту в области компьютеров (все они знакомятся с этими идеями достаточно рано в процессе обучения).
Основываясь на этом фундаменте, вы будете готовы воспринять продвигаемую Юргеном модель современного менеджмента, которая у него представлена в виде шестиглазого монстра, чей взгляд направлен на людей, выравнивание, настройку ограничений, улучшение, развитие компетенций и вопросы структурирования организаций. Вам предстоит продраться через две вводные главы, в которых Юрген дает краткое изложение сути гибких, или Agile-методологий разработки программных продуктов, а также теории сложности; затем он посвящает по две главы каждому из шести компонентов модели Менеджмента 3.0.
Вы не найдете в книге ни одного «традиционного» аспекта управления проектами вроде управления рисками, оценки, планирования или мониторинга процесса разработки с помощью Microsoft Project – он в книге вообще не упоминается. Вы не найдете никаких ссылок на стандартные учебники по управлению рисками, планированию и бюджетированию проектов. Эти традиционные виды деятельности по-прежнему нужны, и, вероятно, имеет смысл пройти курс проектного менеджмента и убедиться, что вы его понимаете, но смысл аргументации Юргена состоит в том, что, даже если вы все будете делать правильно с точки зрения традиционного управления проектами, это совершенно не гарантирует вам успеха. (И даже наоборот, может лишь усугубить проблемы, связанные с поведением сложных систем, что приведет вас к катастрофе еще быстрее!)