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

Сейчас будет трудный для понимания некоторых момент. Напрягитесь…

Акционеры не будут владельцами всего, что имеется в организации. Они владеют лишь активами. Они не будут владельцами людей, их мыслей или взаимоотношений между ними. Известное клише «люди – наш самый ценный актив» представляет собой пример жуткого злоупотребления терминологией. Людей не отражают в бухгалтерском балансе – и на это есть веские причины.

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

Милтон Фридман был прав, когда утверждал, что цель бизнесменов – зарабатывание денег. Но во время, когда Фридман писал свою знаменитую статью, теория сложности только зарождалась. В его время компании воспринимались большей частью в качестве машин, а акционеры – в качестве владельцев этих машин. Фридман был бы прав насчет ценности для акционеров, если бы организации были машинами. Но это не так. Они представляют собой живые системы. По словам Джека Уэлча, чьи взгляды на ценность для акционеров через тридцать лет обогатились нюансами, «ценность для акционеров является результатом, а не стратегией» [Business Week 2009].

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

Конечно же, это был вопрос с подвохом. Внутренняя цель проектной команды – создание программного продукта. Это единственная органичная «тенденция» или «побуждение», стоящее за любым проектом по созданию ПО, которое мне приходит в голову. Когда команда прекращает создавать программное обеспечение (или промежуточные продукты), она прекращает быть командой разработчиков. Но еще более интересной будет идея, что команда, являющаяся живой системой, способна самостоятельно поставить перед собой автономную цель.

Проектная команда – это социальная система, состоящая из различных заинтересованных сторон. Цели, которые в ходе опроса мне присылали в Twitter, будут примерами индивидуальных целей таких заинтересованных сторон. Ни клиенты, ни отдельные члены команды, ни менеджеры не могут утверждать, что их цели – это цели команды как единого целого. Также команда не может существовать исключительно для того, чтобы удовлетворять потребности владельца продукта. Как не может она существовать и только для того, чтобы удовлетворять вашим потребностям как менеджера. Если вы попробуете организовать дела подобным образом, вы совершите ту же ошибку, что и Милтон Фридман, считавший, что проекты – это машины, а не живые системы. Впрочем, Фридман получил Нобелевскую премию. Так что оказаться с ним в одной компании далеко не худший вариант.

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

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

Командующий ставит перед войсками внешнюю задачу и позволяет включиться самоорганизации, потому что его подчиненные достаточно профессиональны, чтобы самим определить, каким способом эту задачу решить. В противном случае они все погибнут. (В главе 7 мы обсуждали, почему людям необходимо самим выработать способ решения задачи, а в главе 11 «Развитие компетенций» вы увидите, как именно они должны это делать.)

В сравнении с целями, которые ставятся перед войсками, внутренние цели команды разработчиков ПО выглядят довольно скучными. Ее задача состоит в том, чтобы существовать и разрабатывать программный продукт. С такой целью войну не выиграешь.

Но именно в этом и заключается причина, почему вы обязаны поставить перед командой внешнюю цель. (И внутреннюю это не отменяет.) Но поставив внешнюю, вы тем самым обозначаете границы, настраиваете ограничения и позволяете самоорганизации развиваться в нужном направлении. Ваша команда достаточно компетентна, чтобы самостоятельно понять, как этой цели достичь. В противном случае судьба ее фатальна (или почти фатальна).

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

Естественно, у этой главы также есть цель. Она заключается в том, чтобы описать третий компонент модели Менеджмента 3.0 и объяснить, что функции менеджера состоят в том, чтобы развивать, защищать и направлять команду, накладывая на самоорганизацию некоторые ограничения; что как лидерство, так и правление – это составные части менеджмента и что у команд бывают цели трех типов. Но мы еще не вполне закончили со всеми этими темами. В этой главе речь пока шла только о теоретических аспектах настройки ограничений. Ее практической стороной мы будем заниматься в главе 9.