Юрген Аппело - Agile-менеджмент. Лидерство и управление командами

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

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

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

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

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

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

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

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

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

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