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

Самоорганизация, самонаправление и самоотбор

Помимо самоорганизации при описании гибких команд используются (с той или иной степенью путаницы) еще несколько похожих терминов. Примеры показаны в таблице 6.1.

С самоорганизацией тесно связано понятие «самоотбор». Существуют команды, которые сами отбирают своих членов. Профессор Ричард Хэкман называет их командами, которые сами себя конструируют [Hackman 2002: 53]. Они эмерджентные, поскольку их свойства как целостных команд не будут результатом деятельности каких-либо менеджеров [Lewin, Regine 2001: 282–284]. Примеры таких команд – это стартапы, в состав которых входят только их основатели. Они сами управляют своим бизнесом практически без всяких ограничений (кроме тех, что налагаются законодательством).

Способность команды направлять саму себя – то же самое, что самоуправление [Hackman 2002: 53]. Это особая форма самоорганизации и самоотбора, на которую не воздействует внешний менеджмент [Lewin, Regine 2001: 282–284]. Группа друзей, которые играют в волейбол на пляже, представляет собой самонаправляемую команду. Они сами создают правила. Преступные организации также будут самонаправляемыми. Они намеренно нарушают законы, диктуемые средой.

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

И наконец, термин «самоуправляемый» достаточно двусмысленен. Большинство воспринимают его как синоним слова «самоорганизующийся», а некоторые – как синоним термина «самонаправляемый». Я предпочитаю вообще им не пользоваться.

Принцип темноты

Теперь, когда мы уточнили значение термина «самоорганизация», давайте рассмотрим некоторые выводы, которые на этой основе смогли сделать исследователи.

С точки зрения сложности есть убедительная причина, почему команды внутри организации должны принимать решения совместно. Это логически вытекает из принципа темноты, который утверждает, что каждый агент внутри системы не может знать обо всех деталях поведения системы. Если бы агент был в курсе всех подробностей поведения системы, вся ее сложность была бы заключена в данном агенте [Cilliers 1998: 4–5].

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

Некоторые менеджеры чувствуют себя некомфортно, когда команды имеют возможность принимать самостоятельные решения. Им кажется, что они утрачивают контроль над происходящим, если команды принимают решения без них. Такие менеджеры полагают, что решения должны привноситься извне, иначе наступит анархия. Но в результате анархии возникла целая Вселенная. Поэтому анархия не может быть так уж плоха. Переход к самоорганизующимся командам возникает именно потому, что он позволяет увеличить степень контроля над неопределенностью, с которой командам приходится сталкиваться [Thomas 2000: 35]. Менеджеры должны понять, что «они несут ответственность, но не контролируют процесс». Любые попытки «контролировать и сдерживать» обычно не работают, а иногда приводят к контрпродуктивным последствиям. Например, есть данные, что попытки полиции контролировать и сдерживать толпу на самом деле могут стать причиной проблем, которые полиция изначально пытается предотвратить [Bond 2009b: 41].

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

Теорема Конанта – Эшби

Делегирование управления – лучший способ обеспечить управляемость проектов. Мы можем прийти к данному выводу в несколько этапов, начав с теоремы Конанта – Эшби[33]33
  Взято из статьи «Википедии» Distributed and Complex Systems.


[Закрыть]:

Хороший регулятор системы должен располагать хорошей моделью этой системы.

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

• Пилот использует доступную ему при помощи приборов информацию, чтобы понять, как ведет себя самолет и как им управлять.

• Авиадиспетчеры используют информацию на экранах радаров, чтобы понять, что происходит в воздушном пространстве аэропорта, и управлять движением в нем.

• Чтобы понять динамику проекта, менеджер использует совещания и отчеты («Контроль и мониторинг» [Институт управления проектами 2008]).

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

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

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

Чем сложнее система, тем меньше мы способны ею управлять. (А проекты по разработке ПО могут быть действительно сложными.) К счастью, имеется простое решение:

• Авиадиспетчеры не управляют самолетами. Они предоставляют делать это пилотам.

• Пилоты тоже управляют самолетом в ограниченном объеме, в значительной степени полагаясь на автоматические системы управления.

• Мудрые менеджеры делегируют большинство функций самим командам.

Делегирование управления командам – метод, при помощи которого менеджеры управляют сложными системами. Вы спускаете решения и обязанности на тот уровень, где в распоряжении людей меньший объем информации и она более точная. Умные менеджеры понимают, что они должны принимать как можно меньше решений. Чтобы улучшить управление сложной системой, большинство решений должно приниматься на уровне подсистем.

Распределенный контроль

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

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

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

Кевин Келли, автор и эксперт в области цифровой культуры, в своей книге «Вне контроля» (Out of Control) перечисляет девять «божественных законов» [Kelly 1994: 469]. Вот первые два:

• Распределенность. Сложная система – нечто большее, чем сумма ее составляющих. Этот «дополнительный компонент» распределен по всей системе. Его нельзя приписать одному из компонентов, даже наиболее важному.

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

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

Мы можем добиться сходного результата и в организациях. Расширение прав и полномочий сотрудников – доступный способ создавать в компаниях распределенный контроль.

Тут нет ничего нового, ведь речь просто о делегировании?

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

Я лишь пытаюсь описать и обобщить эти идеи в контексте социальной сложности.

Делегирование прав и полномочий как концепция

Делегирование прав и полномочий – тема, постоянно возникающая в литературе по менеджменту. Некоторые авторы даже предлагают вообще отказаться от использования соответствующей терминологии [Thomas 2000]. По их мнению, с ней связаны отрицательные коннотации, поскольку она подразумевает, что пока «делегирование» не состоялось, сотрудники по умолчанию лишены прав и полномочий, и поэтому они должны специальным образом получить их из рук менеджера [Lewin, Regine 2001]. По этой причине данные авторы предпочитают называть сотрудников «коллегами» или «партнерами» [Stallard 2007: 76].

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

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

Я даю ключи от своего дома женщине, которая приходит убирать. Я плачу ей каждую неделю, но обычно не даю конкретных инструкций. (Признаюсь, что я не смог бы их дать, даже если бы захотел.) И у меня нет ощущения, что я ее руководитель. Мы просто находимся в экономических отношениях, в рамках которых я передал ей часть работы за вознаграждение. Однажды, когда я вернулся с работы раньше обычного, я обнаружил, что в уборке ей помогает дочь-подросток. И хотя это означало, что теперь по моему дому расхаживают, касаются моих вещей и раскладывают их не в те ящики шкафов, в которые нужно, уже два человека, я все же решил положиться на ее суждение. Это и есть передача прав и полномочий.

Передача прав и полномочий как необходимость

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

Две тысячи шестьсот лет назад китайский философ Лао-цзы в своем философском трактате «Дао Дэ Цзин» написал:

Мудрое правление выглядит как отсутствие правления и свобода. И по этой причине это действительно мудрое правление. Немудрое правление выглядит как внешнее господство. И по этой причине оно немудрое. Мудрое правление влияет незаметно. Немудрое правление пытается влиять через проявление силы.

К сожалению, в той ситуации я не располагал полезной информацией об этих трех проектах. Пришлось найти людей, которые предоставили нужную информацию, и в итоге мне удалось во всем разобраться. В целом это типичная для сложных систем проблема. Информация распространяется во всех направлениях, но к топ-менеджменту так и не попадает. Или скорее информационные потоки обходят топ-менеджмент, и по этой причине управление должно осуществляться на локальном уровне [Kelly 1994].

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

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

Мудрость управления состоит в том, чтобы влиять незаметно. При этом правила должны возникать из взаимодействий между людьми, а не исходить от начальства. В общем… Если бы я делал свою работу хорошо, я должен был бы просто сказать своим сотрудникам: «Вот мои цели. Теперь сами решайте, как их достичь». Но нет, вместо этого я сделал глупость и погрузился в изучение имеющейся информации о технологиях, взаимозависимостях, доступных ресурсах и знаниях, которые предполагалось задействовать в этих проектах. Мне удалось придумать оптимальное решение (которое оказалось весьма простым), и я представил его заинтересованным лицам в виде рекомендации и спросил, согласны ли они с ним. Конечно же, они все с ним радостно согласились. Это была жуткая трата моего времени, к тому же трата впустую. За то же самое время можно было сыграть шесть партий в «Сапера» (я играю на уровне эксперта).

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

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

Менеджеров можно сравнить с садовниками

Есть огромная разница между управлением искусственно сконструированными системами и по-настоящему сложными системами. Сконструированные системы (самолеты, мосты, кофемашины) – лишенные жизни предметы, построенные с нуля, элемент за элементом, и готовые к использованию. Сложные системы (сад, домашнее хозяйство, цыплята) находятся в процессе роста день за днем, пока не созреют и (некоторое время спустя) не умрут.

Люди очень беспечно пользуются языком и часто путаются в терминологии. Они могут говорить о построении систем, которые на самом деле живые и «построить» которые просто невозможно. Мы не строим города, мы их, по сути, выращиваем. Если мы что-то и строим, так это отдельные дома, дороги и урны для мусора. Мы растим семьи, свой бизнес, деревья и большие популяции уродливых голубей. Сумма всего этого и образует город. Это не просто результат конструирования. Мы действительно растим их. Точно так же мы не выстраиваем взаимоотношения, а выращиваем их.

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

К сожалению, я не могу претендовать на авторство этих блестящих идей. Все они были предложены Фредериком Бруксом тридцать пять лет назад:

Метафора строительства устарела. Пора вновь вносить изменения. Если, как я считаю, создаваемые сегодня концептуальные структуры слишком сложны, чтобы их можно было точно определить заранее и создавать их без ошибок, то нужен радикально иной подход. ‹…› Давайте изучать живые организмы со всей присущей им сложностью, а не только безжизненные творения, созданные человеком. В природе мы обнаружим конструкции, сложность которых вселяет в человека священный трепет. Наш мозг уже настолько сложен, что невозможно составить его схему. Его мощь потрясает воображение, он чрезвычайно разнообразен, способен к самосохранению и самообновлению. Секрет в том, что мозг возник в результате эволюции, а не был построен по чертежам. Так же должны создаваться наши программные системы[34]34
  Frederick Brooks, The Mythical Man-Month. Reading: Addison-Wesley Pub. Co, 1975/1995 [Brooks 1995: 201].


[Закрыть].

Когда речь заходит об управлении командами, то и здесь часто используется не самая удачная терминология. Лучше говорить о выращивании команд, чем об их построении.

Мы перестали говорить о построении команд и заговорили о том, что их надо выращивать. Этот процесс уместно сравнить с сельским хозяйством. В нем никогда нельзя до конца контролировать результаты. Вы вносите удобрения, высаживаете семена, организовываете полив в соответствии с последними веяниями, а затем ждете, затаив дыхание. Урожай может вырасти, а может и не вырасти. При виде буйных всходов вам гарантировано прекрасное настроение, но на следующий год все усилия придется повторить заново. Примерно так же создаются команды[35]35
  Tom DeMarco and Timothy Lister, Peopleware: Second Edition. New York: Dorset House Pub, 1999 [DeMarco, Lister 1999].


[Закрыть].

И здесь мои идеи далеко не оригинальны. Демарко и Листер все прекрасно поняли еще двадцать три года назад. С тех пор сельскохозяйственная метафора не раз использовалась при объяснении процесса управления людьми. Например, процесс найма и увольнения сотрудников сравнивали с отбором растений для посадки в саду и прополкой сорняков, понапрасну истощающих ресурсы почвы [Bobinski 2009]. И аналогии на этом не заканчиваются. Я попытаюсь привести еще три примера:

• Живые системы поначалу быстро растут, а затем достигают уровня зрелости. Зрелые системы не требуют столько же ухода, сколько молодые. Зрелые команды также не нуждаются в слишком тщательном присмотре. Они достаточно опытны, чтобы самостоятельно решать свои проблемы. Чтобы все работало гладко, достаточно только время от времени проверять, как идут дела.

• Если за садом не следить, он будет просто продолжать расти, но скорее всего не так, как вам бы этого хотелось. То же самое происходит с командами разработчиков и системами программного обеспечения. Если ими не управлять, они начнут развиваться в непредусмотренном направлении. И результат будет совсем не так хорош, как вы рассчитывали.

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

У разработчиков и менеджеров много общего, мы все – садовники. Мы пользуемся одинаковыми инструментами (рис. 6.4). Мы сажаем семена, вносим удобрения и подкармливаем наши системы. Мы знаем, что молодые системы требуют больше заботы, чем зрелые. Мы выпалываем все, что высасывает энергию из наших растущих систем, а когда подходит время, заменяем старое новым.

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