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

Agile-менеджмент. Лидерство и управление командами (fb2) - Agile-менеджмент. Лидерство и управление командами (пер. А. Олейник) 10733K скачать: (fb2) - (epub) - (mobi) - Юрген Аппело

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

Переводчик А. Олейник

Научный редактор Анна Обухова

Редактор А. Черникова

Главный редактор С. Турко

Руководитель проекта А. Василенко

Корректоры Е. Аксёнова, О. Улантикова

Компьютерная верстка А. Абрамов

Дизайн обложки Ю. Буга

© 2011 by Pearson Education, Inc.

© Издание на русском языке, перевод, оформление. ООО «Альпина Паблишер», 2018

Аппело Ю.

Agile-менеджмент: Лидерство и управление командами / Юрген Аппело; Пер. с англ. – М.: Альпина Паблишер, 2018.

ISBN 978-5-9614-0937-6

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

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

* * *

Посвящается Раулю.

C благодарностью за десять лет в одной команде

Предисловие

Роберта Мартина

Я ненавижу книги по менеджменту. Просто ненавижу. Люди все время дают их мне со словами: «Вы должны прочесть эту книгу, она изменила мою жизнь!» В таких книгах обычно порядка 150 страниц, они набраны крупным шрифтом с двойным межстрочным интервалом, и в них много иллюстраций. Они имеют названия вроде: «Как управлять не управляя», «Менеджмент с открытыми дверями», «Сначала нарушьте все правила», «Откройте свои сильные стороны», «Сила позитивных наказаний» или даже «Tnemeganam!». Эти книги только занимают место на моих полках. Иногда я читаю их в туалете.

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

Такие книги, как правило, страдают повторами, наивны, бессодержательны и написаны на уровне третьего класса для старательных двоечников, которые считают, что одной простой идеи достаточно, чтобы решить все их проблемы.

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

Как сказано выше, я ненавижу книги по менеджменту. Так что же заставило меня написать предисловие именно к этой книге? Я делаю это потому, что тут встречается слово «эукариоты»! Что оно означает? Не так важно. Главное, что в этой книге используются научные термины! В ней говорится о гонке Черной Королевы и есть изображения тессерактов. Тут можно прочитать про путь пьяницы. Короче говоря, это интеллектуальная книга!

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

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

Эда Юрдона

Давным-давно, в далекой-далекой галактике мы с коллегами с гордостью провозгласили себя молодыми революционерами компьютерной индустрии, положившими начало новому поколению методов и технических приемов программирования, дизайна и анализа программных продуктов. Тогда нам казалось, что эти методы вполне гармонично сочетаются с директивными управленческими подходами сверху вниз, господствовавшими в то время. Нам не хватило мозгов, чтобы придумать для своих идей название вроде «Программное обеспечение 2.0», как это сделали впоследствии приверженцы «Web 2.0» и «Предприятия 2.0»… Но как бы то ни было, книга Юргена Аппело убедила меня в том, что идеи, выдвинутые моим поколением, оказались на свалке истории.

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

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

Таким образом, иерархический стиль управления сверху вниз, который соответствовал нашему иерархическому «структурированному» подходу к анализу и проектированию ПО в 1970-е годы, в настоящее время называют «Менеджмент 1.0». Юрген также сообщает нам, что уже пройдена фаза, известная как «Менеджмент 2.0», которая в значительной степени была представлена новомодными изобретениями типа «Реинжиниринга бизнес-процессов», шести сигм и прочими дополнениями к предшествовавшему им Менеджменту 1.0.

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

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

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

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

Меня позабавило следующее утверждение Юргена почти в самом начале: «Хотелось бы мне, чтобы подобная книга попала мне в руки десять лет назад, когда я занимался своим стартапом. Но в этом случае вполне могло случиться, что я все же заработал бы свои миллионы и, по всей вероятности, вряд ли стал бы заморачиваться написанием этой книги». Меня посетила такая же мысль: было бы крайне полезно, если бы такая книга была доступна (или известна) сорок пять лет назад, когда я впервые начал заниматься разработкой ПО, ну или по крайней мере двумя годами позже, когда меня необдуманно повысили и я стал проектным менеджером. Но в этом случае я тоже мог стать миллионером и вряд ли написал бы это предисловие.

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

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

Что еще более важно, вы будете возвращаться к этой книге еще не раз. Я абсолютно уверен, что «Agile-менеджмент» минимум на десятилетие станет библией среди других книг по гибкому менеджменту.

Благодарности

Спасибо. Это, пожалуй, единственное слово, которое никогда не бывает лишним, неуместным или бесполезным. О нем часто забывают. Но только не на этот раз.

Спасибо Майку Кону за то, что он читал мой блог и предложил стать шестым автором в издаваемой им серии книг, а также за оперативные ответы на мои вопросы (иногда в течение часа).

Спасибо авторам других книг, изданных в той же серии, – Лиссе Эдкинс, Лизе Криспин, Джанет Грегори, Клинтону Киту, Роману Пиклеру и Кенни Рубину – за возможность почувствовать себя частью команды и за то, что вы поделились со мной своим опытом – это позволило мне не сделать слишком много ошибок.

Спасибо первым рецензентам моей книги, среди которых Эндрю Вудворд, Анджело Анолин, Кори Фой, Дэвид Харви, Дэвид Моран, Диана Ларсен, Эстер Дерби, Флориан Хоорнаар, Джеффри Лоуни, Израэл Гат, Дж.-Б. Райнсбергер, Якопо Ромеи, Джаред Ричардсон, Йенс Шаудер, Джим Хайсмит, Джоанна Ротман, Джон Бауэр, Келли Уотерс, Лиза Криспин, Луис Дитворст, Марчин Флориан, Маркус Андрезак, Мендельт Сибенга, Майк Кон, Майк Коттмайер, Нико ван Хемерт, Олав Маассен, Пол Клипп, Пол Шталенхоф, Павел Бродзински, Филипп Гадир, Раду Давидеску, Рамкумар КБ, Роберт ван Куутен, Рассел Хили, Рууд Кокс, Скотт Дункан, Стивен Хилл, Васко Дуарте, Ив Ануй и Закари Спенсер. Ваши ценные (а иногда и болезненные для меня) комментарии помогли сделать эту книгу и ее сайт-компаньон намного лучше. Иногда я даже был согласен с вами.

Спасибо, Крис Гузиковски, Райна Чробак, Шери Кейн, Энди Бистер и все остальные талантливые сотрудники издательства Addison-Wesley, за ваше терпение в работе с начинающим автором и ваши объяснения, как устроен издательский процесс (хотя вам, наверное, приходилось это объяснять в тысячный раз).

Спасибо Стефану Мейджеру, Леннерту Уверкерку, Раджу Менону и другим друзьям, коллегам и знакомым за помощь в ходе написания этой книги. Много маленьких услуг внесли в итоге огромный вклад.

Миссис Стапперс, спасибо за то, что вы научили меня английскому языку. К счастью, существуют онлайн-словари, которые часто выручали меня, когда я не успевал выучить заданные на дом слова.

Спасибо, друзья мои: Амнон, Флорис, Эрик, Фемке, Надира, Девика, Руди, Нильс, Ханнеке, Труди, Йерун и Арно. Редко можно найти людей, готовых искренне поддержать энтузиазм другого человека.

Спасибо моим бывшим коллегам по ISM eCompany. В течение семи лет у меня была возможность учиться, как (не) надо управлять командами разработчиков ПО. Приношу извинения, если написанный мною код был из рук вон плох, а также за злоупотребление электронной почтой.

Спасибо, Алистер Коберн, Артем Марченко, Брайан Марик, Кристофер Авери, Кори Хейнс, Деннис Стивенс Эд Юрдон, Элизабет Хендриксон, Джордж Динуидди, Джозеф Пелрайн, Карл Скотленд, Майк Виздос, Филипп Круктен, Рон Джеффрис и многие-многие другие блогеры и авторы, с которыми я имел удовольствие встречаться лично. Все вы вдохновляли меня, и общение с вами было чрезвычайно полезно для этого странного нового «парня на районе».

Спасибо Эду Юрдону и Бобу Мартину за поддержку автора-новичка и написанные вами предисловия. Когда-нибудь я отплачу услугой за услугу. (Дайте знать, если вам вдруг понадобится нарисовать на кого-нибудь карикатуру.)

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

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

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

Об авторе

Юрген Аппело – автор, спикер, тренер, разработчик, предприниматель, менеджер, читатель, блогер, лидер, мечтатель и свободный философ. К тому же он голландец, что объясняет его многочисленные странности.

После изучения программирования в Делфтском техническом университете и получения в 1994 году степени магистра Юрген занимался созданием стартапов и руководил несколькими голландскими компаниями в роли лидера команд, менеджера и топ-менеджера.

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

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

И последнее (не по важности) его достижение: Юрген проводит обучающие семинары на основе модели Менеджмента 3.0, где рассматриваются темы развития инициативы, расширения полномочий и возможностей команд, оптимизации ограничений, развития компетенций, развития организационных структур и улучшения всего.

Тем не менее иногда он откладывает в сторону написание статей, выступления и проведение тренингов и сам занимается программированием; дома он проводит время, сортируя свою коллекцию книг по научной фантастике и фэнтези: он складывает их в шкаф высотой четыре метра, который сам и сконструировал.

Вместе со своим партнером Раулем Юрген живет в Роттердаме (Нидерланды) – и иногда в Брюсселе (Бельгия). У него двое детей, а также есть воображаемый хомяк, которого зовут Джордж.

Предисловие автора

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

Исследования показывают, что при переходе к гибким методам основным препятствием оказывается традиционный менеджмент [VersionOne 2009]. Командам разработчиков ПО тяжело внедрять такие процессы, как Scrum, XP или канбан, если их «лидеров» заклинило на устаревших управленческих подходах. Менеджерам необходимо понять, в чем заключается их новая роль в XXI веке и как добиваться от команд разработчиков максимальных результатов. Данная книга предназначена для менеджеров, которые хотят перейти на гибкие методы управления в своих компаниях, и на разработчиков, которые уже используют эти методы при создании ПО, но хотят больше узнать о менеджменте в целом.

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

Одной из моих важнейших целей при написании этой книги было придерживаться описательного подхода, а ни в коем случае не нормативного. Цель – дать вам понять, как работают организация и Agile-команды для того, чтобы вы могли решить собственные проблемы. Мир слишком сложен, чтобы можно было отделаться списком практик, которым необходимо следовать. Что действительно необходимо менеджерам в XXI веке, так это понимание общих подходов, используя которые, они смогут создать свои собственные рецепты, соответствующие их конкретным потребностям [Mintzberg 2004: 252].

История этой книги

Мне потребовалось десять лет, чтобы написать эту книгу. В свое время я заинтересовался гибкими методологиями разработки ПО и теорией сложности (не помню, в какой последовательности), и в течение первых пяти лет авторы, пишущие об этих двух предметах, едва поспевали за моим интересом. При чтении разных книг у меня постепенно начала складываться общая картина. Я понял, что гибкие методы создания ПО – это практическое приложение теории сложности и команды разработчиков ПО и соответствующие проекты выступают в качестве примера таких систем. Также стало ясно, что практически никто не видит эту связь между теорией и практикой (заметными исключениями стали Джим Хайсмит и Кен Швабер). В результате примерно в 2005 году я попытался написать собственную книгу на эту тему. Но в тот момент ничего не получилось. У меня был в руках текст, но отсутствовали читатели. Были новые идеи, но не было обратной связи. Обилие теорий и минимум опыта. Я был преисполнен энтузиазма, но мне не хватило терпения.

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

В январе 2008 года я запустил свой блог на с целью получить обратную связь от читателей относительно моих идей в области разработки ПО, менеджмента и сложных систем, а также понять, интересна ли эта тематика вообще кому-нибудь. Через полтора года у меня было 4000 подписчиков. Я участвовал в интереснейших дискуссиях с экспертами со всего мира и удачно выступил на нескольких конференциях в Европе и США. Было похоже, что я нашел свою нишу.

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

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

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

Структура книги

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

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

Глава 1 – введение. В ней описано, как линейное мышление порой приводит нас к неправильным выводам. Здесь же впервые представлена центральная модель книги: Менеджмент 3.0 – шесть углов зрения, с которых в ней рассматриваются команды и организации.

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

В главах 4 и 5 описывается первый компонент модели Менеджмента 3.0, а именно как заряжать энергией людей. В первой из этих глав излагаются теоретические аспекты проблемы, а во второй – практические. Здесь говорится, что люди – это важнейшая часть организации и что менеджеры должны делать все, что в их силах, чтобы сотрудники проявляли активность, были креативными и мотивированными.

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

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

В главах 10 и 11 обсуждается проблема компетенций, недостаток которых может не позволить командам достичь поставленных целей. Поэтому в зоне ответственности менеджеров должна находиться задача развития необходимых компетенций и дисциплины. Развитие компетенций – это четвертый компонент модели Менеджмента 3.0.

Главы 12 и 13 посвящены пятому компоненту Менеджмента 3.0 – функционированию команд в контексте организации. Подчеркивается важность выбора правильной социально-сетевой структуры, обеспечивающей беспрепятственный обмен информацией.

Главы 14 и 15 рассматривают процесс «Улучшай все», который будет шестым и последним компонентом модели. Подчеркивается необходимость непрерывного улучшения функционирования людей, команд и организации в целом как способа максимально отодвинуть провал. Как и прежде, материал первой из этих двух глав носит более теоретический, а второй – более прикладной характер.

И наконец, в главе 16 мы подводим итоги и проводим общий обзор Менеджмента 3.0, а также его сравнение с некоторыми другими моделями менеджмента.

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

Содержание отдельных глав не слишком сильно зависит друг от друга. Так что в теории вы можете читать о шести компонентах модели в любом порядке. Однако на практике, вероятно, легче всего начинать с первой главы. Я лично не проверял, какое именно из 720 возможных сочетаний этих компонентов будет наиболее удобным с точки зрения восприятия.

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

Содержание книги

Текст книги написан в бета-версии Microsoft Word 2010. Все иллюстрации нарисованы и отсканированы мной, а затем раскрашены в приложении Paint.NET. Иногда в книге попадаются серые вставки с вопросами или замечаниями и ответами на них. Большинство этих вопросов задавались читателями моего блога и рецензентами первых версий книги. Я также использую много ссылок на сайт «Википедии». Некоторые считают, что ссылаться на «Википедию» – порочная практика, но я с этим не согласен. Я предпочитаю ссылки на живой ресурс, над которым постоянно ведется работа по улучшению, чем на ветки потенциально мертвого дерева.

Предвидя обвинения в излишнем теоретизировании, я сделал так, что в сумме объем практических глав превышает объем тех, что отданы теории. Более того, в конце каждой главы есть раздел «Подумать и сделать», что делает книгу еще более полезной с практической точки зрения.

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

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

О названии модели

«Менеджмент 3.0» – довольно странное название. Но, как мне кажется, указание на версию 3.0 дает верное представление о направлении развития менеджмента в XXI веке.

Менеджмент 1.0 = иерархии

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

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

Можно сделать уверенный вывод, что менеджмент 1.0, пусть он до сих пор и наиболее распространенная версия во всем мире, имеет целый ряд серьезных недостатков. Он устарел и нуждается в обновлении.

Менеджмент 2.0 = дань преходящим увлечениям

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

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

Менеджмент 2.0 – это все тот же знакомый нам менеджмент 1.0, к которому добавили некоторое количество надстроек, чтобы несколько снять остроту проблем, порожденных старомодной системой. Но в основе архитектуры менеджмента 2.0 лежат те же устаревшие иерархии.

Менеджмент 3.0 = сложные системы

В последние несколько десятилетий мы стали свидетелями зарождения и развития теории сложности, вначале в применении к математике и биологии, а затем к экономике и социологии. Это было крупным прорывом. Стивен Хокинг считал это направление в науке настолько важным, что называл XXI век веком сложности.

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

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

Иногда стоит менять названия. От них многое зависит. Название «Менеджмент 3.0» подчеркивает, что менеджмент нуждается в изменениях. Компании Microsoft обычно требуется сделать три релиза продукта, чтобы он нормально заработал. Я считаю, что в своем третьем воплощении менеджмент наконец нашел надежную научную основу. Предлагавшиеся ранее надстройки и апгрейды все еще полезны. Но мы обязаны поменять свою исходную гипотезу с иерархий на сетевые структуры, потому что XXI век – это эпоха сложности.

О подзаголовке книги

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

Принцы

Некоторые утверждают, что «лидерство – это не то же самое, что менеджмент» в том смысле, что лидерство предполагает вдохновение, в то время как менеджмент относится скорее к исполнению. Они утверждают, что лидерство находится на «более высоком уровне», чем менеджмент. Меня всякий раз коробит, когда компания называет своих топ-менеджеров «лидерами».

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

К сожалению, в данный момент среди топ-менеджеров распространена мода называть себя лидерами независимо от того, есть у них последователи или нет. Топ-менеджеры используют «лидерство» как социальный миф для укрепления своих позиций в организационной иерархии [Hazy 2007: 110]. Я называю таких топ-менеджеров принцами (и принцессами), поскольку они думают, что занимаемая должность дает им больше прав на роль лидера, чем всем остальным, а еще потому, что они предпочитают блестящие предметы здравому смыслу.

Жрецы

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

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

Увы, некоторые считают, что иерархия – это всегда «плохо», а самоорганизация – всегда «хорошо». Я называю их жрецами (и жрицами), потому что они проповедуют свою веру в то, что считают «хорошим», хотя (как показано в этой книге) никаких научных оснований для этой веры нет.

Прагматики

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

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

Я написал эту книгу для прагматиков.

Глава 1 Почему все не так просто

Всякая сложная проблема имеет решение – простое, удобное и ошибочное.

Г.Л. Менкен, журналист и писатель (1880–1956)

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

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

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

При написании этой книги меня поддерживала надежда, что и вы многому научитесь на моих ошибках и ошибках тех, кто совершал их до меня. За последние десять лет я понял, что при разработке программного обеспечения оптимальные результаты дают именно Agile-методологии (см. главу 2 «Гибкие методологии разработки ПО»). Я также убедился, что серьезнейшее препятствие на пути принятия Agile-методологий во всем мире – это традиционный менеджмент. Я исхожу из представления, что вы либо руководитель, либо просто интересуетесь менеджментом. Возможно, вы разработчик, технический директор, глава проектной группы или тестировщик. На данный момент это не имеет особого значения. Важно то, что вы хотите больше узнать о менеджменте – о так называемых Agile-методологиях менеджмента и разработки. Обещаю, что вы действительно узнаете много нового. Задача этой книги – научить вас хорошо разбираться в гибких методологиях и помочь в создании гибкой организации. Мы скоро перейдем к конкретному обсуждению гибких методологий, но сначала необходимо уделить внимание основам, которые заключаются в знании того, как ведут себя люди и системы. Вы спросите: «Зачем это нужно?» По той же причине, по которой врачи сначала изучают, как устроен человеческий организм, пилоты постигают функционирование самолета, а программисты знакомятся с устройством компьютера. Ну а менеджеры должны знать, как функционируют социальные системы.

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

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

Причинно-следственные связи

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

В мире науки детерминизм оказался чрезвычайно успешным, позволив ученым предсказывать огромное количество разнообразных событий и явлений. Например, используя механику Ньютона, ученые уверенно предсказывают возвращение кометы Галлея в Солнечную систему в 2061 году. Научный метод предсказания будущих событий на основе событий, им предшествовавших, а также законов природы оказался настолько успешным, что философ Иммануил Кант провозгласил всеобщий детерминизм в качестве необходимого условия любого научного знания [Prigogine, Stengers 1997: 4].

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

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

Так в чем же проблема?

Сложность

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

Многие иногда путают создаваемые сложностью проблемы с проблемой больших чисел (когда одновременно происходит огромное количество событий), но сложные явления не всегда предполагают наличие большого количества элементов. Возьмем, например, молекулу воды (фигурально выражаясь, естественно, на практике это сделать очень непросто). Эта молекула состоит всего из двух атомов водорода и одного атома кислорода. Ничего сложного, не так ли? И тем не менее даже такая простая структура из трех атомов проявляется неожиданным образом в сложных явлениях текучести, эффектах, связанных с плотностью воды, и других физических и химических явлениях [Solé 2000: 13], которые не поддаются легкому объяснению с точки зрения поведения отдельных атомов. Таким образом, сложность необязательно будет проявлением больших чисел. Достаточно трех молекул воды, чтобы состоящая из них система характеризовалась сложным поведением – примером будет знаменитая задача трех тел.

К счастью, с того момента, когда Кант с энтузиазмом объявил причинность основой научного знания, наука не стояла на месте. Теория динамических систем, теория хаоса, теория сетей, теория игр и ряд других научных дисциплин добились значительного прогресса, объяснив, почему некоторые явления невозможно предсказывать и почему некоторые события невозможно планировать или рассчитать заранее – их можно только испытывать или наблюдать. Часто весь комплекс исследований в области сложных систем собирательно именуют теорией сложности (см. главу 3 «Теория сложности»).

Если развитие науки начиная с XVII века проходило под знаком детерминизма, то сложность как предмет исследования возникла в XX веке; соответствующие исследования значительно ускорились с того момента, когда в конце XX века теория сложности выделилась в отдельную научную дисциплину. Физик-теоретик Стивен Хокинг утверждал, что XXI век будет веком сложности [Chui 2000].

Развитие теории сложности – хорошая новость для руководителей, лидеров команд и менеджеров проектов (а также всех прочих «лидеров» и «менеджеров»), работающих в компаниях, создающих ПО. Это означает, что возник научный подход к исследованию сложных систем, включая проблемы разработки программного обеспечения и управления организациями в целом. И хотя для меня момент истины опоздал ровно на 10 миллионов евро, я согласен со Стивеном Хокингом, что представление о сложности – ключевая парадигма XXI века.

Наше линейное мышление

К сожалению, применяя теорию сложности к решению конкретных проблем, мы постоянно сталкиваемся с определенным неудобством: наш мозг предпочитает видеть простые причинно-следственные связи и игнорировать сложность. В своей статье «Рожденные верить: Как наш мозг создает богов» [Brooks 2009] автор показывает, что человеческий мозг чрезмерно ориентирован на установление причинно-следственных связей, что заставляет нас видеть их даже там, где их нет. Как отмечается в статье, дети думают, что острые скалы созданы для того, чтобы о них могли чесаться животные, а реки – чтобы по ним можно было плавать на лодках. По всей видимости, устройство человеческого мозга заставляет нас повсюду усматривать целеполагание и причинно-следственные связи, даже если для этого нет никаких оснований.

«Вы слышите шорох в кустах и делаете вывод, что там кто-то притаился». ‹…› Вероятно, чрезмерная склонность повсюду усматривать причины и следствия дает преимущество с точки зрения выживания. Если вокруг полно хищников, недостаточно обнаруживать их в девяти случаях из десяти. Лучше перестраховаться и убежать, даже если в некоторых случаях опасность окажется иллюзорной. В конце концов, цена такой перестраховки невелика[1].

Наш мозг жестко запрограммирован отдавать предпочтение «линейному мышлению» (представлению о предсказуемости следствий, если известны причины) перед «нелинейным» (гипотезой, что в реальности все обстоит гораздо сложнее). Мы привыкли считать, что события от начала и до конца разворачиваются линейно. В школе нас учат решать линейные уравнения, а более часто встречающиеся на практике нелинейные игнорируются просто потому, что справиться с ними гораздо труднее. Нам легче принять утверждение «это сделал он», чем утверждение «некоторые вещи просто случаются». Если в наличии проблема B, то мы предполагаем, что ее причиной стало событие A. Причиной финансового кризиса стали банкиры; в сокращении числа рабочих мест виноваты иммигранты; в плохой атмосфере в компании виноват менеджер; таяние полярных льдов вызвано выбросами CO2; проектной группе не удалось уложиться в отведенные сроки из-за того, что кто-то плохо работал. Линейное мышление воспринимает мир как пространство, наполненное легкообъяснимыми событиями, вызванными простыми причинами и имеющими простые следствия. Джеральд Вайнберг называет это ошибкой причинности [Weinberg 1992: 90].

Наша мыслительная зависимость от детерминизма заставляет людей искать способы контроля, которые позволили бы обеспечить наступление желательных событий и ненаступление нежелательных. В конце концов, если известно, что ситуация A имеет своим результатом событие B, а ситуация Á – событие C, при этом C лучше, чем B, то всего-навсего надо заставить A превратиться в Á, и все будет хорошо. Так по крайней мере часто кажется.

Инженеры и другие люди с техническим складом ума особенно восприимчивы к идеям, базирующимся на идее управляемости. Именно инженеры создали научный менеджмент, основанный на отдаче распоряжений и контроле их исполнения, который всецело господствовал с начала XX века. И именно они придумали системы контроля, которые до сих пор существуют во многих организациях [Stacey 2000a: 7]. Сейчас уже всем известно, что системы контроля эффективны, только если речь идет о повторяющихся операциях, не требующих особых размышлений. Но они не работают в ситуациях, когда необходим творческий подход при разработке новых продуктов! Поэтому было бы только справедливо, если бы инженеры и вытащили нас из того управленческого болота, в которое они нас в свое время затянули.

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

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

Редукционизм

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

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

Способность людей интерпретировать окружающую действительность весьма ограниченна

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

Идея целостности

Холизм как теория предполагает, что поведение системы несводимо к сумме поведений ее отдельных частей, а напротив, решающим образом определяется ее свойствами как единого целого. Этот подход часто воспринимают как противоположность редукционизму, хотя ученые, исследующие такие системы, полагают, что сложность будет связующим звеном между обоими подходами и каждый из них необходим, но недостаточен [Corning 2002: 69].

Даже некоторые из наиболее рьяных редукционистов отказались от представления, что все явления могут быть сведены к поведению их составных частей. Философ Дэниел Деннет предложил термин «Жадный редукционизм» [Dennet 1995] для обозначения форм редукционизма, которые стремятся полностью вывести поведение системы из взаимодействия между ее составными частями. Например, утверждение, что «гиперссылки – это не более чем электроны и на самом деле они не существуют» будет примером такого жадного редукционизма. В качестве контраргумента я сказал бы, что если жадные редукционисты правы, то значит, они тоже не существуют, и это полностью снимает все их смехотворные аргументы. Но я отвлекся.

В качестве компромисса биолог-эволюционист Ричард Докинз предложил понятие иерархического редукционизма [Dawkins 1996], смысл которого в том, что сложная система может быть представлена в виде иерархии, в которой события на каждом уровне могут быть объяснены поведением компонентов, находящихся в данной иерархии одним уровнем ниже, но только одним уровнем. Если следовать этой логике, вы не сможете объяснить провал своего проекта тем, что вам помешали кварки и лептоны.

Многие ошибочно полагают, будто бы из редукционизма следует, что мы в состоянии реконструировать любую систему, если понимаем, как функционируют ее составные части. В этом и состоит заблуждение: даже если мы отлично понимаем, как ведут себя все компоненты системы, это не значит, что система сводится к сумме своих составных частей [Miller, Page 2007: 41]. Знание компонентов, находящихся на нижних уровнях системы, вовсе не означает, что мы сможем воссоздать всю систему как единое целое. Интересно, что, если исходить из редукционистского подхода и отследить изначальную причину проблемы (например, воспользовавшись методикой анализа основной причины), мы все равно не сможем создать систему, в которой данная проблема отсутствовала бы. Например, мы можем установить причину конкретного случая сердечной недостаточности (редукционизм), но нам никогда не удастся создать сердце, которое принципиально не будет подвержено сердечной недостаточности (конструкционизм).

Значит ли все это, что методика анализа основной причины бесполезна?

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

Иерархический менеджмент

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

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

Управление организацией требует совершенно иных знаний и опыта, чем управление людьми, хотя некоторое представление о том, как система функционирует на более низких уровнях, может оказаться полезным. Инженер-программист Джоэл Сполски предложил закон дырявых абстракций [Spolsky 2002] в качестве объяснения, почему в системах компоненты, находящиеся на более высоких уровнях, могут проявлять себя неожиданным образом в результате воздействия на них событий, происходящих на более низких уровнях, хотя более высокие уровни, по идее, должны быть изолированы от такого воздействия. Более высокие программные уровни, которые подвергаются воздействию событий, происходящих на более низких программных уровнях, считаются дырявыми. Типичным свидетельством такого рода дырявых абстракций в программировании будут непонятные сообщения об ошибках, которые получают пользователи (рис. 1.3).

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

Гибкий менеджмент

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

Гибкие методы разработки ПО некоторыми своими корнями уходят в теорию сложности, признающую недостаточность причинного детерминизма для реализации успешных проектов. Такие хорошо известные и используемые в гибких методологиях понятия, как «самоорганизация» и «эмерджентность», напрямую взяты из литературы по сложным системам [Schwaber, Beedle 2002], и люди, практикующие в настоящее время Agile-методологии, понимают, что при конструктивистском подходе гарантированы неудачи. Только непрерывная идентификация возникающих в ходе проекта проблем и устранение их причин позволяют последовательно развивать проект по разработке ПО и в конечном итоге получить на выходе успешный программный продукт. Это похоже на процесс взросления или воспитания детей.

Несмотря на блестящие успехи с точки зрения окупаемости инвестиций Agile-проектов [Rico 2009], многие менеджеры по всему миру в своих компаниях препятствуют гибкому проектному менеджменту и гибким методологиям. Исследования и опросы свидетельствуют, что основными препятствиями на пути принятия гибких методов разработки ПО становятся традиционные методы управления изменениями, организационная культура, недостаток поддержки со стороны руководства, низкая подготовленность персонала, а также внешнее давление [VersionOne 2009]. За многое из этого отвечают именно менеджеры. Если верить имеющимся отчетам на эту тему (а у меня нет оснований в них сомневаться), то сами менеджеры во всем мире будут скорее проблемой, чем частью решения. Печально, что это характерно не только в случаях внедрения гибких методологий разработки ПО. То же самое происходит при любых других серьезных организационных изменениях.

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

Моя теория всего

Существует ли теория, которая может помочь менеджерам работать в гибкой среде? За последние несколько десятилетий было предложено много управленческих теорий – впрочем, большинство из них вовсе не будут теориями в строгом научном смысле [Lewin, Regine 2001: 5]. Настоящая научная теория должна быть в состоянии не только указывать на существование каких-либо природных явлений, но и делать проверяемые утверждения о наблюдаемом реальном мире, предсказывая, каких событий следует ожидать, прежде чем их можно будет наблюдать. Именно в этом смысле различные управленческие «теории» не соответствуют ожиданиям. Они зачастую представляют собой не столько теории, сколько наборы технических приемов. Вместо того чтобы давать описание того, как функционирует реальный мир, они предлагают советы (часто полезные), как подойти к той или иной проблеме или ситуации. В этом смысле хорошим примером будет теория ограничений. Это не научная теория, а управленческая философия, которая предлагает способы оптимизации процессов и позволяет добиваться целей, постоянно фокусируясь на имеющихся ограничениях.

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

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

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

Модель, предлагаемая в этой книге

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

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

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

Резюме

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

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

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

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

Подумать и сделать

Давайте посмотрим, как применить некоторые идеи данной главы в вашей компании:

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

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

Глава 2 Гибкие методологии разработки ПО

Каждое утро я встаю, преисполненный решимости изменить мир и прекрасно провести время. Иногда это затрудняет составление плана на день.

Э.Б. Уайт, американский писатель (1899–1985)

Для некоторых из вас эта глава необязательна. Если вы знакомы с Agile-методологиями разработки программного обеспечения[3], вы уже и так много знаете (если не все) о том, о чем тут пойдет речь. Эта глава скорее предназначена для тех читателей, которые хотели бы узнать немного больше об истории и основах гибких методологий прежде, чем мы начнем говорить о роли менеджеров в гибких организациях (глава 4 «Информационно-инновационная система»).

В этой книге я исхожу из представления, что вы знаете лишь кое-что об основах гибких методологий. А пока сделайте вид, будто считаете, что XP – это старая операционная система, и продолжайте читать.

Прелюдия к гибким методологиям

Я люблю считать деньги почти так же, как и тратить их. В начале 1990-х годов, когда я учился в Делфтском техническом университете, в свободное время я написал бухгалтерскую программу. Мне было интересно этим заниматься, несмотря на небольшое неудобство: денег, которые нужно было считать, у меня не было. Не исключено, что где-то в глубине души я надеялся, что миллионы появятся автоматически, как только я буду готов их сосчитать. Увы, этого не случилось.

Я был единственным автором этого программного продукта (около 30 000 строк кода). Я не владел формальной методологией, у меня было мало опыта создания ПО, а также не было менеджера, коуча или ментора. Но у меня имелось время, компьютер, видение и страстное желание создать великолепный продукт (рис. 2.1).

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

Как это вообще возможно? Как неопытному программисту удалось создать продукт столь высокого качества, что он работает почти безупречно вот уже почти двадцать лет?

Не имею ни малейшего представления.

Но… У меня есть список из нескольких пунктов, которые должны быть знакомы последователям гибких методологий разработки.

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

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

• У меня не было плана, только список функциональных возможностей, которыми должен был обладать новый продукт. Я начал с такой наиболее часто применяемой операции, как ввод транзакций. Затем перешел к менее критичным функциям вроде составления баланса и внесения корректировок. В конце добавил такие необязательные приятные вещи, как подсказки и возможность экспорта данных. Я занимался этим до тех пор, пока мне все не надоело, и я просто не объявил продукт готовым.

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

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

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

Евангелие от Agile

Вначале инженеры сотворили компьютеры и программное обеспечение. Программное обеспечение же было бесформенно и нефункционально, и тьма царила над пользователями. И инженеры сказали: «Да будет структура». И возникла структура.

И даже в избытке.

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

В начале 1990-х была предложена новая методология под названием быстрая разработка приложений (Rapid Application Development, RAD). В рамках этой методологии наиболее успешным командам разработчиков удавалось сочетать некоторые формализованные методы, позаимствованные у «тяжеловесного» инженерного подхода (контроль за внесением изменений в техдокументацию, инспекции и применение контрольных показателей), с такими продиктованными практикой методами, как создание прототипов, выпуск инкрементных версий ПО и тесное сотрудничество с заказчиком [McConnell 1996]. В результате такого скрещивания формализованных и неформализованных методик возникли первые «легкие» методологии, включая эволюционное управление разработкой (Evo) (1988), Scrum (1995), методы разработки динамических систем (DSDM) (1995), методы Crystal (1997), Экстремальное программирование (XP) (1999), разработка, управляемая функциональностью (FDD) (1999), прагматическое программирование (1999) и адаптивная разработка ПО (2000).

Как следствие внезапного и почти одновременного появления множества методик, статей, книг и семинаров по «легким» методологиям (некоторые даже сравнивали его с Кембрийским взрывом), у лидеров движения возникла идея собраться и обсудить положение дел. В 2001 году они встретились на лыжном курорте в штате Юта. Там и был выбран термин «гибкие методологии» (Agile), заменивший применявшуюся ранее терминологию, а также был создан Agile-манифест разработки ПО (рис. 2.2).

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

Впоследствии группа наиболее авторитетных представителей Agile-движения создала Agile Alliance[4] – некоммерческую организацию, которая ставит себе целью продвижение гибких методологий во всем мире. Возникла целая новая экосистема, состоящая из конференций, консультантов, книг и журналов. В результате процессы разработки программного обеспечения стали Agile c большой буквы А, превратившись в нечто более глубокое, чем просто набор практик, которые можно использовать при разработке софта. Признавая, что проекты по разработке программного обеспечения существуют в области, которая располагается между упорядоченностью и хаосом, Agile-подходы, по сути, превратились в образ жизни.

Фундаментальные принципы Agile-методологий

В наши дни численность людей, которые разделяют ценности и принципы Agile-методологий, составляет несколько миллионов человек. Опросы подтверждают, что большинство разработчиков программного обеспечения во всем мире придерживаются по крайней мере некоторых из «основных Agile-практик» [VersionOne 2009].

Фундаментальные принципы Agile-методологий были неоднократно описаны, и у многих авторов это получается гораздо лучше, чем у меня. И все же я чувствую необходимость привести в своей книге их краткий обзор. Будучи практиком гибких методологий, я предпочитаю делать все так, как удобно лично мне; поэтому кратко опишу их основные положения, перечислив «семь измерений», в которых «живут» проекты по разработке ПО, – и еще раз вернусь к этой теме в главе 11 «Развитие компетенций».

Люди

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

Функциональность

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

Качество

Качество играет определяющую роль в успехе продукта, поэтому в центре внимания Agile-методологий находится техническое совершенство. Высокий технический уровень обеспечивается посредством разработки через тестирование (написание протокола тестирования готового продукта предшествует созданию собственно программного кода), ревью кода (часто в сочетании с парным программированием), Definition of Done (чек-лист готовности элементов), итеративной разработки (адаптация кода в результате появившихся изменений или других обстоятельств) и рефакторинга (непрерывная оптимизация кода даже при отсутствии изменений в функциональности). Сторонники гибких методологий признают необходимость последовательного улучшения дизайна; под этим понимается, что в начале проекта архитектура продукта не разрабатывается в деталях (а только в самом базовом виде) и выявляется при дальнейшем развитии проекта.

Инструменты

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

Время

У Agile-методологий особые отношения со временем. В Agile-проектах даты поставки, бюджеты и крайние сроки могут устанавливаться почти произвольно. Программное обеспечение создается короткими отрезками, часто в рамках тайм-боксов или «спринтов», и поставляется в виде инкрементных релизов; при этом каждый из релизов сам потенциально является готовым к поставке продуктом. Это позволяет владельцам бизнеса управлять графиком проекта, сдвигая дату сдачи готового продукта вперед или назад в зависимости от того, в какие сроки они хотят сделать доступной ту или иную функциональность. Тем временем команда стремится найти для себя оптимальную скорость разработки, которую она сможет поддерживать практически бесконечно.

Ценность

Одной из важнейших причин создания Agile-манифеста было стремление подчеркнуть важность своевременной реакции на изменения. Среда, в которой функционирует программный продукт, никогда не бывает статичной. Функциональность, которая еще вчера представляла собой значительную ценность, завтра может оказаться бесполезной, включая функциональность, которая уже имеется в версиях продукта, переданных заказчику. Разработчики, практикующие гибкие методологии, стараются справиться с этой проблемой, предпочитая короткие циклы разработки и обратной связи. Смысл частых релизов программного продукта не только в том, чтобы получить обратную связь от пользователей и учесть ее в последующем процессе разработки, но и в том, чтобы предоставить пользователям новую функциональность как можно скорее после выявления их потребности в ней, тем самым повышая ценность ПО для клиента.

Процесс

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

Конфликт

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

Методологии, конкурирующие с Agile

Редко когда попадаются игры, не предусматривающие конкуренцию между игроками, и лишь немногие системы обходятся без конфликта. Без расхождения во взглядах между разными людьми жить было бы не так интересно. К счастью, в мире гибких технологий предостаточно здоровой конкуренции, например между Scrum и Экстремальным программированием, Scrum и канбаном и даже между Scrum и Scrum![5] Но гибкие методы разработки не будут здесь единственными игроками. Существует несколько сильных и многообещающих конкурирующих подходов, в основе которых лежат идеи, аналогичные идеям Agile-методологий, дополняющие их, а часто и входящие с ними в прямое противоречие.

Одними из самых крупных конкурентов будут методологии бережливой разработки программного обеспечения (Lean software development), переносящие идеи бережливого производства в область разработки ПО. Семь принципов бережливого производства [Poppendieck 2009: 193] основываются на четырнадцати принципах Дао Toyota (философии управления компании Toyota) и четырнадцати принципах менеджмента Э. Деминга. Между Agile– и Lean-методологиями много общего, поэтому часто они играют на одной стороне, ими занимаются одни и те же эксперты, у них одни и те же фанаты, а их развитие освещается в одних и тех же блогах, журналах и ТВ-шоу. С управленческой точки зрения Lean-методологии – с их акцентом на сокращении непродуктивных затрат и оптимизации систем в целом – внесли большой вклад в развитие гибких методологий. Хотя бережливые методологии разработки ПО возникли на несколько лет позднее Agile, они сравнялись с ними по числу консультантов, коучей, профессиональных консорциумов[6] и проводимых конференций.

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

Но и тяжеловесы все это время тоже не стояли на месте. Возможно, наиболее известным (и наиболее спорным) из них будет методология CMMI (Capability Maturity Model Integration). Ее разработка с 1987 года ведется Институтом программной инженерии, исследовательским центром на базе Университета Карнеги – Меллон. Проект начался с создания протокола оптимизации процессов разработки ПО, но постепенно трансформировался в более абстрактную модель, которая в настоящее время применяется для оптимизации процессов и в других отраслях. В модели описываются пять уровней зрелости процессов в двадцати двух процессных областях, и она ставит себе целью порождение рекомендаций по их оптимизации. Но данная модель лишь указывает, в каких именно процессных областях возможна оптимизация. Она не дает рекомендаций относительно конкретных ее способов. По этой причине некоторые сторонники Agile полагают, что, несмотря на свой объем (документация, описывающая методологию CMMI, насчитывает многие сотни страниц), она все же совместима с гибкими методологиями, поскольку последние дополняют ее, давая рекомендации, в том числе и по конкретным способам оптимизации процессов. Но, как это всегда бывает среди сторонников гибких технологий, и тут не обходится без споров. Многие считают, что, несмотря на благие намерения, положенные в ее основу, CMMI в силу своей тяжеловесности уводит компании в сторону бюрократии и создания не вполне дееспособных команд, которые весьма впечатляюще выглядят со стороны, но не могут блеснуть реальными результатами.

С такой же смешанной реакцией столкнулась и методология, изложенная в «Руководстве к своду знаний об управлении проектами» (Guide to Project Management Body of Knowledge, PMBOK), издаваемом и поддерживаемом Институтом управления проектами. Интересно, что это руководство первоначально возникло как описание лучших практик в области проектного менеджмента в целом. С момента первого издания в 1987 году оно подверглось нескольким переработкам и стало ближе к идеологии Agile в качестве реакции на успехи, достигнутые проектными менеджерами, практикующими гибкие методологии. В отличие от CMMI, методология, продвигаемая в рамках PMBOK, предлагает проектным менеджерам конкретные рекомендации относительно управления проектами. И хотя рекомендуемые ею практики не всегда хорошо сочетаются с принятыми в гибких методологиях, многие проектные менеджеры предпринимают активные попытки преодолеть имеющиеся расхождения. То же самое можно сказать о PRINCE2 – похожей методологии, издаваемой и поддерживаемой британским министерством государственной торговли. Эта методология используется главным образом в Европе.

Последним важным направлением в этом списке будет унифицированный процесс разработки ПО, наиболее известный в версии унифицированный процесс Rational (Rational Unified Process, RUP). Он был разработан в 1997 году компанией Rational Software (сейчас принадлежит IBM). Для разработчиков ПО процесс RUP будет тем же, чем для проектных менеджеров стали методологии, изложенные в руководстве PMBOK. В нем содержится описание стандартизированных методов проектного управления, которые могут (и должны) адаптироваться к конкретным проектам; однако документация составлена таким образом, что весь подход зачастую воспринимается как бюрократический. Сторонники гибких методологий считают, что процесс разработки формируется в ходе проекта, начинаясь с минимального числа практик. В рамках RUP продвигается противоположный подход, в котором изначально предписывается большое количество практик с сопровождающей их рекомендацией, что в ходе проекта от ненужных практик можно отказаться. (Я часто сравниваю этот подход с покупкой Boeing 747, который владелец затем разбирает на части, чтобы собрать велосипед для поездок за покупками.) Неудивительно, что на фоне многочисленных успехов Agile-методологий этот подход подвергся нескольким ревизиям с целью сделать его более гибким, в результате чего возникли такие его модификации, как гибкий унифицированный процесс (Agile Unified Process, AUP), открытый унифицированный процесс (OpenUP) и минимально необходимый гибкий процесс (Essential Agile Process, EssUp). Но ни один из них не нашел широкого применения, сравнимого с распространением Agile-методологий.

Препятствие на пути Agile-методологий

Эмпирические данные вновь и вновь подтверждают, что Agile-методологии, если правильно ими пользоваться, обеспечивают огромный возврат инвестиций [Rico 2009]. Но если эти методологии дают столь блестящие результаты, то почему далеко не все ими пользуются? И почему столько проектов по разработке ПО во всем мире все еще заканчиваются неудачами?

В опросе, посвященном оценке текущего состояния Agile-методологий, проведенном в 2009 году компанией VersionOne, респонденты в качестве причин, препятствующих принятию компаниями гибких методологий, указали следующие: «менеджмент настроен против изменений», «опасение утратить управленческий контроль», «недостаточная техническая дисциплина», «команды настроены против изменений» и «недостаточный уровень компетентности разработчиков». Параллельно упоминается потребность организаций в планировании, предсказуемости и документировании своих действий [VersionOne 2009].

Подождите… Давайте еще раз вглядимся в эти причины: тут говорится об управленческом контроле, управлении организационными изменениями, выращивании талантов…

Простите, возможно, я не прав, но… разве все это не прямые функции менеджмента? Не значит ли это, что именно менеджеры по всему миру будут основным препятствием на пути внедрения Agile-методологий?

Как менеджера меня расстраивает этот вывод.

А как автора – радует.

Я думаю, что гибкие методологии упустили из поля зрения важность линейного менеджмента. Если менеджеры не знают, чем им заниматься и чего ожидать от внедрения гибких методологий в своих организациях, то почему они должны поддерживать переход к этим методологиям? В чем состоит послание Agile-методологий этим менеджерам? В том, что «менеджеры нам не нужны»? Тогда неудивительно, что внедрение этих методологий наталкивается на препятствия во всем мире.

Чтобы организации могли воспользоваться всеми преимуществами гибких методологий, они должны ответить на важный вопрос: какое будущее ожидает менеджеров в мире Agile?

Линейный и проектный менеджмент

Мое имя в Голландии не самое распространенное. Поэтому на разных этапах моей карьеры мне приходилось мириться с тем, что его часто коверкали. Временами из-за этого возникали недоразумения. Когда имена людей или названия предметов похожи, многие склонны почти не замечать остальных различий между ними. Если бы имя Эллы Фицджералд было не Элла, а Юрген, то, уверен, коллеги попросили бы меня спеть.

Мне кажется, что с термином «менеджер» есть точно такая же проблема.

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

В первом воплощении декларация в первую очередь предназначалась проектным менеджерам. Позднее стало ясно, что ее принципы могут быть интерпретированы более широко и применены к «менеджменту в целом». И все же в первую очередь декларация ориентирована на управление проектами по разработке ПО, а не на управление группами людей. Это необходимо подчеркнуть, поскольку именно авторы декларации впоследствии основали организацию Agile Project Leadership Network.

К сожалению, проектный менеджмент и функциональный (линейный) менеджмент часто путают. В ряде отличных книг, написанных ведущими экспертами, включая «Гибкий менеджмент» (Agile Management) [Anderson 2004], «Управление Agile-проектами» (Managing Agile Projects) [Augustine 2005] и «Гибкое управление проектами» (Agile Project Management) [Highsmith 2009], вопросы проектного и функционального менеджмента обсуждаются параллельно. Та же ситуация наблюдается и на многих форумах, в блогах и журналах. Мне бы хотелось, чтобы это было не так, поскольку проектный и линейный менеджмент – не одно и то же. Это все равно что путать разработчиков ПО с системными администраторами. Возможно, они разделяют одни и те же идеи, смеются над одними и теми же шутками и (фигурально выражаясь) стригутся и одеваются одинаково, но все же это разные люди. (Я серьезно. Попробуйте попросить разработчика софта починить вам компьютер. Но лучше даже не пробуйте.)

Не делая четкого разграничения между линейными менеджерами и менеджерами проектов, мы затрудняем понимание и теми и другими своей роли в компаниях, практикующих гибкие методологии разработки. К счастью, я далеко не единственный, кто это понимает. В нескольких книгах, вышедших задолго до моей, включая «За закрытыми дверями» (Behind Closed Doors) [Rothman, Derby 2005] и «Управление разработкой ПО на основе Lean-методологий» (Leading Lean Software Development) [Poppendieck 2009], функции линейных менеджеров в компаниях, специализирующихся на разработке ПО, изложены более четко.

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

А что касается тех, кто думал, открывая эту книгу, что я DJ Юрген, то им не повезло.

Резюме

Гибкие или Agile-методологии – это подход к разработке программного обеспечения, появившийся в 1990-е годы в качестве реакции на засилье бюрократии, а также частных методов, создаваемых каждый раз заново «под конкретную задачу» (все они не обеспечивали успешной разработки ПО).

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

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

Подумать и сделать

Давайте посмотрим, сможете ли вы применить в своей компании некоторые идеи, изложенные в данной главе:

• Взгляните на свою организацию с точки зрения семи проектных измерений (люди, функциональность, качество, инструменты, время, ценность, процесс). Учитываете ли вы все эти измерения в своих проектах по разработке ПО? Гибки ли ваши команды во всех семи измерениях? Если нет, то что вы планируете по этому поводу предпринять?

• Подумайте о менеджерах, работающих в вашей компании. Кто из них может стать потенциальным препятствием на пути внедрения гибких методологий? Можете ли вы что-то в связи с этим предпринять? Удостоверьтесь, что вы четко понимаете, что вам нужно от них, чтобы ваш подход к внедрению Agile-методологий оказался успешным.

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

• Развивайте свои навыки в области Agile-методологий, подписавшись на блоги или группы, в которых обсуждается данная тематика. Актуальный список этих блогов и групп можно найти на сайте, посвященном Менеджменту 3.0 ().

Глава 3 Теория сложности

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

Герберт Бойер,профессор биохимии

Многие эксперты в области гибких методологий согласны, что команда разработчиков представляет собой сложную адаптивную систему, поскольку состоит из множества частей, взаимодействующих друг с другом и отделенных внешней границей, и способна изменяться и учиться на собственном опыте [Highsmith 1999: 8], [Schwaber 2002: 90], [Larman 2004: 34], [Anderson 2004: 1], [Augustine 2005: 24]. Кто я такой, чтобы утверждать обратное?

Журнал «Эмерджентность: Теория сложности в применении к организациям» однажды провел обширное исследование книг по менеджменту, в которых упоминается теория сложных систем. Среди рецензентов были специалисты в самых различных областях, включая физику и математику. Все они сошлись во мнении о полезности теории сложности при управлении организациями и для менеджмента в целом:

Было зафиксировано общее согласие [рецензентов], что использование идей теории сложности имеет значительные перспективы для менеджмента как дисциплины и при практическом управлении организациями[7].

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

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

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

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

Важность междисциплинарного подхода

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

Большинство университетов и исследовательских институтов организованы именно в виде таких колодцев. Физики работают бок о бок с другими физиками, биологи – с биологами, а математики – с математиками. Это привело к фрагментации науки и распространению туннельного зрения среди ученых и исследователей. Различные научные дисциплины настолько изолированы друг от друга, что ученые обычно не знают, над чем работают их коллеги [Waldrop 1992: 61].

Организационные колодцы в науке – это проблема, поскольку многие явления из разных научных областей часто похожи друг на друга. Например, некоторое время назад экономисты не могли понять природу такого явления, как «локальное равновесие», в то время как физикам уже была известна природа его физического аналога [Waldrop 1992: 139]. Фазовые переходы в физике подозрительно напоминают случаи периодически нарушаемого равновесия в эволюционной биологии. Биологи заметили, что математики могут помочь им в анализе экологии видов [Gleick 1987: 59]. А некоторые «открытия» математиков, как выясняется, были за годы до того сделаны метеорологами [Gleick 1987: 31].

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

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

Общая теория систем

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

Одним из достижений теории систем, развитие которой продолжалось вплоть до 1970-х годов, был перенос фокуса с элементов системы как таковых на организацию этих элементов. Тем самым было признано, что взаимоотношения между элементами системы – динамические, а не статические. Ученые идентифицировали и изучили такие явления, как аутопоэзис (самопостроение или способы, которыми системы конструируют сами себя), идентичность (каким образом системы можно опознать), гомеостаз (способность систем поддерживать свою стабильность) и проницаемость (то, как системы взаимодействуют с окружающей их средой) [Mitchell 2009: 297].

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

К сожалению, объединение этих первоначально разрозненных концепций не было доведено до конца (что не должно удивлять тех разработчиков ПО, которые пытались соединить различные практики или технологии). И тем не менее наследие общей теории систем весьма значительно. Почти все законы этой теории применимы и к сложным системам [Richardson 2004a: 75], и в целом эта теория продвинулась дальше, чем попытки унифицирования в области разработки программных продуктов.

Кибернетика

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

Кибернетика изучает сложные управляемые системы, имеющие цели и взаимодействующие с окружающей средой через механизмы обратной связи. Задача кибернетики – изучение процессов, происходящих в управляемых системах. Эти процессы состоят из многократных итераций какого-либо действия (которое вызывает изменения во внешней среде), получения информации о состоянии среды (данные о реакции внешней среды на совершенное действие), оценки (сравнение текущего состояния с целевым) и возврата на этой основе к совершению нового действия. Для кибернетики этот циклический процесс фундаментален.

Из кибернетики мы позаимствовали представление, что команда разработчиков представляет, по сути, ориентированную на определенную цель систему, саморегулирующуюся посредством различных циклов обратной связи. Мы поняли, что в саморегулирующейся системе, которой является команда разработчиков, наиболее важными факторами будут информация, коммуникация и целеполагание (в отличие, скажем, от силы и энергии). Кибернетика также помогла осознать решающую роль обратной связи в эволюции поведения сложных систем [Mitchell 2009: 296].

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

Теория динамических систем

Если рассматривать общую теорию систем и кибернетику как ноги некоего человека, символизирующего собой всю массу знаний о поведении систем, то одной из его рук, бесспорно, будет теория динамических систем.

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

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

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

Теория игр

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

Будучи одним из направлений прикладной математики, теория игр ставит себе задачей описание поведения систем в ситуациях, требующих стратегического подхода. В этих ситуациях успех одной системы отчасти зависит от тех моделей поведения, которые выбрали другие системы. Теория игр получила свое развитие в 1930-х годах, а в начале 1970-х нашла применение в биологии и эволюционной теории. Тогда стало понятно, что она вполне годится для анализа стратегий, к которым живые организмы прибегают во время охоты, спасаясь от хищников, при защите своей территории и во время брачных игр.

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

Эволюционная теория

Сейчас трудно представить себе человека, который не был бы знаком с эволюционной теорией. Она получила известность с момента выхода в свет в 1859 году «Происхождения видов» Дарвина, одной из самых знаменитых книг в истории. Практически все биологи согласны с базовыми утверждениями теории эволюции: постепенное генетическое изменение видов и выживание наиболее приспособленных организмов в результате естественного отбора.

Конечно, согласие относительно базовых постулатов не мешает бесконечным спорам биологов по поводу деталей процесса. Важность случайного генетического дрейфа (изменение вида без определенных причин), периодически нарушаемого равновесия (внезапные изменения вместо постепенных), эгоистичных генов (отбор на уровне генов, а не на уровне особей или популяций) и горизонтального переноса генов (передача генов другому организму) – все эти гипотезы многократно и страстно биологами обсуждались, принимались или опровергались [Mitchell 2009: 81–87]. (Но стоит только в качестве альтернативы предъявить биологам теорию разумного замысла, как они моментально объединяются в своем отрицании этой ненаучной ерунды.)

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

Теория хаоса

Хотя несколько открытий в рамках теории хаоса были сделаны ранее, настоящий прорыв был совершен в 1970–1980-х годах, а основной вклад был внесен такими людьми, как Эдвард Лоренц и Бенуа Мандельброт.

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

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

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

Общая картина наших знаний о поведении систем

Как нет единого определения сложности, так нет и единой теории, которая объясняла бы поведение всех сложных систем разом [Lewin 1999: x]. Ученые давно пытаются обнаружить фундаментальные законы, которые были бы применимы к любым системам при любых обстоятельствах, но пока что эти попытки не увенчались успехом.

Представляется разумным задать вопрос: что же такое эта «теория сложности»? И хотя есть множество ее определений, существует точка зрения, что единого описания данная теория не имеет[8].

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

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

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

Простота: новая модель

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

Простота обычно определяется количеством усилий, которое необходимо, чтобы понять или объяснить какое-либо явление. Явление, которое легко понять или объяснить, будет простым, в отличие от тех явлений, что запутанны.

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

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

• Простая = легко поддающаяся пониманию.

• Запутанная = очень трудная для понимания.

Второе измерение касается поведения системы и того, насколько легко мы можем его предсказывать:

• Упорядоченное = полностью предсказуемое.

• Сложное = предсказуемое в определенной степени.

• Хаотическое = чрезвычайно непредсказуемое.

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

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

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

Чем эта модель отличается от других?

Известна модель Cynefin (читается как Кеневин) (рис. 3.3a), предложенная Дэвидом Сноуденом – специалистом в области управления знаниями. Эта модель предлагает типологизировать ситуации как относящиеся к одной из четырех областей: простые, запутанные, сложные и хаотические (имеется также промежуточная категория – беспорядочные) и применяется при принятии решений и выработке политик в разных областях [Snowden 2010b].

Похожая модель была создана и профессором менеджмента Ральфом Стейси. Его модель называется матрицей согласованности и определенности (рис. 3.3b). Матрица разделена на четыре области (область простых систем, запутанных, сложных и область анархии или хаоса), размещенных вдоль двух осей: степени согласованности и степени неопределенности [Stacey 2000b].

Глава 16 в этой книге называется «Все модели неверны, но некоторые из них полезны», и это утверждение соответствует действительности. Все три приведенные здесь модели неверны, но каждая из них может быть полезна. Разница между моей моделью и двумя другими состоит в том, что в моей между запутанными и сложными системами нет четкой границы. В ней также идентифицированы шесть типов систем, а не четыре, при этом запутанные и сложные пересекаются. Если эта модель покажется вам полезной, используйте ее при оценке систем различных типов. Если нет, возьмите любую из двух оставшихся. Они тоже неплохие.

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

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

• Линеаризация – действия, направленные на то, чтобы сделать поведение системы более предсказуемым (в модели – движение справа налево).

К сожалению, на дилетантском уровне часто путают линеаризацию и упрощение. И тут-то возникают проблемы.

А как насчет сложности программного обеспечения?

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

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

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

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

Еще раз об упрощении

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

Все следует упрощать до тех пор, пока это возможно, но не более того.

Альберт Эйнштейн

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

Простота – это миф, время которого прошло, если оно вообще когда-либо существовало [Norman 2007].

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

К сожалению, Дон Норман использует термин «упрощение» как для обозначения линеаризации поведения (движение вдоль горизонтальной оси в моей модели), так и для обозначения упрощения структуры (движение по вертикальной оси). Тем самым он сделал свой тезис достаточно запутанным, и именно поэтому многие в нем не разобрались. Может быть, для иллюстрации своей мысли ему стоило бы воспользоваться рисунками:

Цель визуального мышления состоит в том, чтобы сделать сложные вещи понятными посредством визуализации, а не в том, чтобы упростить их[9].

В своем бестселлере «Визуальное мышление» Дэн Роэм предлагает использовать рисунки для представления идей в более понятном виде. Очевидно, что он говорит о сдвиге по вертикальной оси от запутанного к простому. Но даже в его предупреждении «не упрощать» присутствует терминологическая путаница. На самом деле Дэн имеет в виду, что при представлении в виде рисунков не должна утрачиваться сложность поведения системы, поскольку это помешает тем, кто пользуется данными рисунками, разобраться в существе вопроса.

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

Адаптивные и неадаптивные системы

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

Когда я был маленьким мальчиком, сидел в ванне и вокруг плавали игрушки, меня завораживали воронки – они появлялись, когда вынимали сливную пробку. Играя с этими воронками, я постепенно обнаружил, что могу их остановить, заставить появиться вновь и вращаться в обоих направлениях. Этим воронкам приходилось терпеть мое присутствие, и они не могли адаптироваться к перепадам в моем настроении. Такие воронки – пример сложных неадаптивных систем. Они сложные, но не в состоянии адаптироваться [Lewin 1999: 15].

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

Системы, о которых чаще всего идет речь в этой книге, включая команды разработчиков, будут сложными адаптивными. Они сами сдвигают себя в комфортную область между упорядоченностью и хаосом. Они способны обучаться и адаптироваться, а также двигаться по определенной траектории посредством «хаордических процессов», сочетающих в себе элементы хаоса и порядка, но никогда не являющихся ни полностью упорядоченными, ни действительно хаотическими [Highsmith 2002].

В той ванне десятки лет назад воронки были глупыми неадаптивными системами. Настоящей сложной адаптивной системой был я. Я адаптировал свои действия в зависимости от поведения воронок. И это помогало мне понять, как можно их контролировать.

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

Не злоупотребляем ли мы научным подходом?

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

Основная причина, почему теория сложных адаптивных систем актуальна при разработке программного обеспечения, это продвигаемая ею концепция эмерджентности и эмерджентных результатов[10].

Например, колония муравьев, мозг, иммунная система, Scrum-команды и город Нью-Йорк будут самоорганизующимися системами[11].

Scrum – это не методология, не четко расписанный процесс и не набор процедур. Это открытый фреймворк при разработке программного обеспечения. Применяемые правила ограничивают поведение сложной адаптивной системы, в результате чего система самоорганизуется и приходит в состояние, адекватное решаемой задаче[12].

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

Некоторые ученые уже обрушились с критикой на людей вроде нас за то, что мы заимствуем их научную терминологию. Они утверждают, что мы берем термины, не вникая в их значение, и используем научные понятия, не имея на то достаточных концептуальных оснований. И еще они говорят, что нас опьяняют сами слова вне связи с тем, что они на самом деле означают [Sokal 1998: 4].

По правде говоря, я здесь немного сжульничал. Разнос, который Сокал устроил тем, кто использует теорию сложности (или скорее злоупотребляет ею), адресован в первую очередь не сторонникам Agile-методологий, а людям в целом. Но сигнал мы услышали. Чтобы усвоить его еще лучше, вот цитата, напрямую относящаяся к существу вопроса:

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

Ох!

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

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

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

А как насчет «эмерджентного дизайна»? Это тоже злоупотребление?

Лично я так не думаю. Но в любом случае будет разумно сохранять критичность и здоровую долю скепсиса.

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

Новая эра: мышление в категориях теории сложности

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

В этом нет ничего нового. Системная динамика, первоначально возникшая в 1950-х годах (не путать с теорией динамических систем), разрабатывалась как инструмент, призванный помочь менеджерам лучше понимать и совершенствовать производственные процессы. Она была одним из первых методов, продемонстрировавших, что даже те организации, что кажутся простыми, могут проявлять неожиданное нелинейное поведение [Stacey 2000a: 64]. Системная динамика показала, что структура организации, с ее многочисленными циклическими взаимноблокирующими взаимодействиями и частыми задержками реакции, может сильнее воздействовать на поведение организации, чем параметры ее отдельных компонентов. Системная динамика помогла менеджерам улучшить понимание бизнес-процессов и в то же время привлекла внимание к тому, что свойства организации часто становятся результатом ее поведения как целостной системы и не могут быть сведены к свойствам образующих ее индивидуумов. Системная динамика не будет частью суммы наших знаний о системах. Это просто инструмент (вроде старого калькулятора), интересный для менеджеров со склонностью к математике.

В 1980-х годах возникла новая идеология, в чем-то схожая с системной динамикой, получившая название системное мышление и обязанная своей популяризацией книге Питера Сенге «Пятая дисциплина»[14] [Senge 2006]. Системное мышление представляет собой набор установок при решении «проблем», которые рассматриваются как часть более обширной системы. Системное мышление фокусируется на циклических взаимоотношениях между компонентами системы и нелинейных причинно-следственных связях внутри нее. Часто это позволяет избежать непредвиденных последствий, риск возникновения которых повышается, если компоненты рассматриваются изолированно. Системное мышление в чем-то похоже на системную динамику, однако в последней при анализе последствий альтернативных решений широко применяются симуляции и математические расчеты. Системное мышление считается более субъективным в своей оценке сложных структур, поскольку его концепция более расплывчата [Forrester 1992]. Основная ценность системного мышления состоит в том, что оно позволяет людям сосредоточиться на проблемах систем, а не людей. Я бы сказал, что системное мышление похоже на старую фотокамеру, которая может дать менеджерам более полную картину их организаций с интересных, но субъективных ракурсов.

Исследование сложности в социальных системах ведется в рамках социологического направления, которое принято называть социологическая системная теория. К сожалению, ни системная динамика, ни системное мышление в явном виде не признают, что любые попытки проанализировать и применить социальную сложность на основе подхода сверху вниз будут нереалистичными [Snowden 2005]. Использование упрощенных симуляций при описании поведения организаций или кружков, соединенных стрелками, для описания взаимодействия между командами или людьми создает ложное впечатление, что менеджеры в состоянии проанализировать свои организации, внести в них изменения и направить в нужное русло. Конечно же, системная динамика и системное мышление не отрицают существование нелинейных процессов, но все равно они исходят из базовой идеи, что топ-менеджмент в состоянии каким-то образом сконструировать «правильную» организацию, которая будет выдавать «правильные» результаты. Все эти подходы недалеко ушли от детерминистского мышления XIX века [Stacey 2000a]. Но XXI век – век сложности. Это время, когда менеджеры приходят к осознанию, что для управления сложными социальными системами необходимо понять, как они формируются и растут, а не как их конструировать.

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

В главе 4 мы направим этот поток света на команды разработчиков ПО и увидим, каким образом первый компонент Менеджмента 3.0 помогает таким командам расти, самоорганизовываться и адаптироваться к изменениям в среде.

Резюме

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

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

Одно из важных наблюдений состоит в том, что сложность системы (то, насколько она предсказуема) и запутанность ее структуры (то, насколько легко ее понять) – далеко не одно и то же. Еще одно важное наблюдение – многие сложные системы могут адаптироваться к изменениям в среде. Такие системы называют сложными адаптивными системами (САС).

Социологическая системная теория – дисциплина, рассматривающая социальные группы в качестве сложных адаптивных систем.

Подумать и сделать

Давайте посмотрим, как применить некоторые идеи из данной главы в вашей компании:

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

Глава 4 Информационно-инновационная система

Когда актер приходит ко мне, чтобы обсудить свою роль, я говорю ему: «В сценарии все написано». Если он спрашивает «А какова моя мотивация?», я отвечаю: «Твоя зарплата».

Альфред Хичкок, режиссер (1899–1980)

Проекты по разработке программного обеспечения являются сложными адаптивными системами. Эту точку зрения разделяют многие эксперты по разработке ПО и проповедники гибких и бережливых методологий. Но что делает адаптивные системы действительно рабочими?

По словам Митчелла Уолдропа, автора книги «Сложность: Новая наука на границе упорядоченности и хаоса» (Complexity: The Emerging Science at the Edge of Order and Chaos), основным предметом дискуссий в Институте Санта-Фе (лидер мировых исследований в области сложных систем) стали состоящие из агентов системы. Этими агентами могут быть молекулы, нейроны, веб-серверы и рыбы. А также люди, которые постоянно организуются и реорганизуются в более крупные объединения, образуя новые структуры с поведением, несводимым к поведению составляющих их элементов [Waldrop 1992: 88].

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

Хотя проекты по разработке ПО могут состоять из большого количества элементов, истинными агентами будут только люди, которые представляют собой активные элементы (рис. 4.1). (На более высоком уровне агентами также можно считать сами команды.) Функциональные требования, спецификации, артефакты, инструменты, технологии и процессы не будут агентами, поскольку они не могут самостоятельно организовываться, реорганизовываться или инициировать взаимодействие с другими элементами проекта. В рамках проектов только люди имеют необходимую способность к взаимодействию и организации, но также им нужна энергия для проявления этих способностей. Поэтому создание у людей энергии и становится первым императивом модели Менеджмента 3.0, и данная глава в основном о людях. Но прежде чем на них сосредоточиться, мы должны поговорить об организациях.

Инновации – ключ к выживанию

В любой конкурентной среде ключом к выживанию будут инновации. Это вопрос жизни и смерти для компаний во всем мире [Davila 2006: 6]. Как правило, максимум ценности в сфере бизнеса создается в результате инноваций [Highsmith 2009: 31]. Организации, конкурирующие на рынке знаний (включая компании, разрабатывающие ПО), должны фокусироваться в первую очередь на инновациях, отмечает профессор Икудзиро Нонака в своей статье «Компания, создающая знания» [Nonaka 2008]. И это относится не только к компаниям этого типа, утверждает Роберт Остин – ученый, который специализируется на креативности и инновациях. В условиях, когда современные технологии постоянно снижают стоимость итераций, компании все в большем числе индустрий могут конкурировать в области инноваций [Austin, Devin 2003: 53].

Надо же, какое совпадение…

Понятие «инновации» находится в центре внимания наук, изучающих сложные системы. Исследователи обнаружили, что сложные адаптивные системы активно ищут для себя позицию между упорядоченностью и хаосом, поскольку инновации и адаптация происходят, когда системы находятся «на кромке хаоса» [Kauffman 1995]. В биосфере примерами инноваций могут служить некоторые виды обезьян, кротов и осьминогов. И конечно, пудели (что подтверждает наличие у природы своеобразного чувства юмора). Исследователи утверждают, что в основе инноваций в физическом мире, биологии, психологии и других сферах лежит то самое интересное состояние между упорядоченностью и хаосом, которое мы называем сложностью.

Согласно таким публикациям, как «Сложность и инновации в организации» [Fonseca 2002] и «Перспективы теории сложности в применении к инновациям и социальным изменениям» [Lane 2009], инновации – характерное явление типа «снизу вверх». Эти авторы подчеркивают, что программы инноваций обречены на неудачу, если они спускаются вниз топ-менеджментом и сопровождаются назначением лиц за них ответственных (которым и поручается труднейшая задача изобрести что-то новое). Такой подход представляет собой наивную попытку управлять будущим и базируется на причинно-следственном детерминизме. Подобные программы просто не работают.

Теория сложности утверждает, что инновации могут быть лишь эмерджентным результатом, запланировать который невозможно. Чтобы возникло нечто новое, необходима основа, на которой оно может возникнуть. Я идентифицировал пять драйверов инноваций (рис. 4.5), которые мы сейчас и обсудим.

Знания

Как отмечают Дон Тапскотт и Энтони Уильямс в книге «Викиномика» [Tapscott, Williams 2008][15], инновации предполагают присутствие в компании категории сотрудников, чья деятельность связана с обработкой имеющейся и получением новой информации. К этой категории относятся разработчики, дизайнеры, архитекторы, аналитики, тестировщики и другие профессионалы в области создания ПО. Чтобы подчеркнуть, что в новых условиях в основе многих профессий лежит работа с информацией, гуру менеджмента Питер Друкер предложил термин «интеллектуальный работник». Идею, что знания становятся топливом для инноваций, впоследствии поддержали многие эксперты в области бизнеса (например, Икудзиро Нонака [Nonaka 2008]).

Именно так все и происходит в проектах по разработке ПО. Знания позволяют нам создавать новые программные продукты для заказчиков, представляющие собой бизнес-ценность, которой они ранее не располагали. Таким способом наши проектные команды превращают знания в инновации.

Знания образуются через постоянное поступление информации из внешней среды через образование и обучение, запросы и спецификации, измерения и обратную связь, имея своим результатом непрерывное накопление опыта. Команда разработчиков ПО будет системой, которая потребляет и трансформирует информацию, на выходе обеспечивая производство инноваций.

Некоторое время назад нейробиологи выяснили, что в человеческом мозгу невозможно локализовать конкретные участки, где хранится информация. В отличие от данных, записанных в двоичной системе счисления, которые помещаются в четко определенные ячейки в памяти компьютера, в человеческом мозгу знания хранятся в распределенном виде. Если небольшая часть мозга по какой-либо причине отключена, высока вероятность, что знания не пострадают. Хранение знаний в мозгу организовано подобно существованию информации в интернете – в виде параллельной распределенной системы, которой свойственна значительная избыточность, поскольку одни и те же данные хранятся во многих местах и при этом отсутствует централизованное управление информацией. Некоторые называют это «голографической памятью» по аналогии с голограммами, которые многократно сохраняют информацию о целостном трехмерном изображении в каждом участке пластинки [Hunt 2008: 48].

Это означает, что узлы информационных сетей (примерами которых будут человеческий мозг, интернет, социальные группы) сохраняют работоспособность даже в случае лишь частичного доступа ко всей сети, хотя производительность падает одновременно со снижением числа соединений. Точно к такому же выводу в своих исследования пришли Роб Кросс и Эндрю Паркер, опубликовавшие свои результаты в книге «Невидимая сила социальных связей»[16]. Они обнаружили, что вовсе не профессиональные знания людей будут самым надежным индикатором их результативности. Гораздо важнее количество и качество связей, которыми данный индивидуум обладает в организации [Cross 2004: 11].

Учитывая, что знания, используемые в проектах, в значительной степени неявные или подразумеваемые (не задокументированы и трудны для передачи), люди в организации должны передавать их друг другу посредством «осмотической коммуникации» в процессе совместной работы [Cockburn 2007: 202]. Следовательно, критически важно, чтобы люди, входящие в команду разработчиков, хотели сотрудничать друг с другом и делиться этими знаниями. (Мы вернемся к проблемам коммуникации в главе 12 и 13. В данный момент нас интересуют лишь аспекты, связанные с людьми.)

Разработчики ПО конвертируют информацию в инновации, и это полностью созвучно с фактом № 22 из книги Роберта Гласса «Факты и заблуждения профессионального программирования»:

80 % усилий по созданию ПО приходятся на интеллектуальную деятельность. Значительная часть этой деятельности креативна. И лишь небольшая часть – чисто техническая[17].

Профессия разработчиков ПО заключается в решении проблем. Гласс выполнял свои измерения на примере системных аналитиков, и мы уже знакомы с его выводом, что они проводят 80 % своего времени в размышлениях. Я думаю, что то же самое относится и ко всем остальным участникам проектных команд (может быть, за исключением некоторых бизнес-консультантов).

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

Креативность

Креативность – критически важная переменная в процессе создания ценности на основе знаний [Kao 2007]. Креативность заключается в способности отходить от шаблонных подходов при создании нового, предлагать новые ответы на основе старой информации и видеть решения там, где до этого никто их не видел. (Иногда это выглядит как кража старых идей и заметание следов, чтобы никто об этом не узнал.)

Важность знаний в качестве исходного сырья для креативности в настоящее время широко признается исследователями [Runco, Pritzker 1999]. Имеются подтверждения, что креативность в первую очередь базируется на знаниях людей и способности комбинировать несходные понятия, в результате чего возникают новые способы смотреть на вещи. С точки зрения наивных и неопытных наблюдателей, креативность часто похожа на магию. Но в реальности она возникает на плодородной почве знаний ценой многих часов тяжелого труда и размышлений.

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

Оригинальность

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

Полезность

Аналогичным образом второе намерение большинства разработчиков таково: создать полезное программное обеспечение. Вполне возможно, что ни один другой вид деятельности в сфере бизнеса не внес такой вклад в повышение глобальной производительности. Мне встречалось мнение, что ценность программных продуктов с точки зрения бизнеса на несколько порядков превышает ценность любых других креативных продуктов. И вряд ли с разработчиками ПО можно даже отдаленно сравнивать писателей, художников, архитекторов и парикмахеров. (Единственное исключение я готов сделать для рок-звезд.) При этом разработчики даже не считают себя «креативными» со всеми расплывчатыми коннотациями, которые связаны с этим словом. У большинства из них далеко не артистический темперамент. Они просто хотят создать нечто, чем будут пользоваться. (Не будем здесь говорить о том огромном количестве функционала, который создается ими в надежде, что он будет кому-нибудь нужен, но которым так никто и не пользуется.)

По всей видимости, в основе разработки программных продуктов лежит креативность, то есть создание продуктов одновременно оригинальных и полезных. Наиболее известная модель креативного процесса была предложена Грэмом Уоллесом и Ричардом Смитом в вышедшей в 1926 году книге «Искусство мыслить» (The Art of Thought). Описанный ими креативный процесс, включающий пять стадий, столь же применим к созданию ПО, как и к любому другому творческому процессу. Вообразим, например, что вам поручено улучшить работу сайта. В этом случае пять стадий креативного процесса могли бы выглядеть следующим образом:

1. Подготовка. Нахождение и определение измерения, в котором локализуется данная проблема; например, сколько времени уходит на выполнение (некоторых) запросов к серверу базы данных.

2. Обдумывание. Размышления о проблеме как в сознательном, так и в подсознательном режиме, например, когда вы принимаете душ, играете в покер и обсуждаете с друзьями последний фильм про Бэтмена (возможно, даже делая все это одновременно).

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

4. Озарение. Внезапное осознание, что решение может заключаться в «денормализации» некоторых таблиц базы данных, что ускорит обработку запросов.

5. Проверка. Испытание нового подхода, проверка его эффективности и работа по совершенствованию, пока не будут получены желаемые результаты.

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

А также при написании книг.

Мотивация

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

Люди – это также единственный элемент системы, способный создавать знания, проявлять креативность и предпринимать действия, необходимые для вывода своих идей на рынок. И только люди способны управлять проектами по разработке ПО, поскольку только им присущ уровень сложности, необходимый для управления сложными системами.

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

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

В книге «Одноминутный менеджер», одной из самых продаваемых книг по менеджменту XX века, Кеннет Бланшар сформулировал это так:

Люди, которые хорошо относятся к себе, добиваются хороших результатов[18].

В своей популярной книге «Сначала нарушьте все правила»[19], в основу которой легли результаты одного из наиболее обширных исследований, когда-либо проводившихся в области менеджмента, авторы Маркус Бакингем и Курт Коффман утверждают, что функции менеджера – подбирать людей, устанавливать ожидания, создавать мотивацию и способствовать профессиональному росту. Это, с их точки зрения, и есть четыре основных вида деятельности менеджера в качестве «катализатора» [Buckingham, Coffman 1999: 61].

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

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

Справедливости ради надо отметить, что, хотя в методологии CMMI отсутствуют процессные области, напрямую связанные с управлением людьми [Chrissis 2007], Институт программной инженерии разработал отдельную модель зрелости управления компетенциями (People Capability Maturity Model) [Curtis 2001], которая может помочь организациям успешно решить эту проблему.

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

Создание нового требует не только соответствующего образа мышления и набора личностных качеств, но также и желания (или как минимум готовности) отклоняться с проторенного пути, рисковать, не бояться оказаться неправым – иными словами, необходима соответствующая мотивация[20].

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

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

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

В следующей главе мы рассмотрим методы мотивации людей более подробно. Но сначала нам нужно завершить описание информационно-инновационной системы.

Разнообразие

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

По мере ее быстрого роста состав сотрудников претерпел серьезные изменения. Сначала появились женщины. Затем женатые мужчины. Люди, имеющие детей. Люди за сорок. Представители этнических, религиозных и сексуальных меньшинств. Инвалиды. Не успели мы оглянуться, как численность персонала достигла 200 человек, а белые холостые сотрудники в возрасте 20–30 лет с традиционной сексуальной ориентацией оказались в меньшинстве. Но компания по-прежнему была прекрасным работодателем, в том числе и для представителей меньшинств.

В биологических экосистемах генетическое разнообразие – один из важнейших принципов. Биологическое многообразие (множество биологических видов) – одно из наиболее очевидных проявлений этого принципа, но существует также и внутривидовое разнообразие. Знаете ли вы, что медоносные пчелы немного отличаются друг от друга? Так они регулируют температуру внутри улья. Когда в улье становится слишком холодно, пчелы плотно прижимаются друг к другу и быстро машут крыльями. А когда в улье слишком жарко, они держатся подальше друг от друга, и характер движения крыльев способствует охлаждению. Если бы все пчелы реагировали на одну и ту же температуру, они начинали бы пользоваться крыльями для обогрева или охлаждения одновременно. Это вело бы к резким скачкам температуры внутри улья. Поэтому пчелы реагируют на разные температуры, и это помогает стабилизировать температуру в улье. Когда температура поднимается, пчелы одна за другой начинают использовать свои крылья в качестве вентиляторов. Чем больше пчел присоединяется к этому действию, тем медленнее растет температура, пока не стабилизируется. Разнообразие пчел позволяет выровнять температуру внутри улья [Miller, Page 2007: 15].

Разнообразие, или гетерогенность, как его официально именуют, очень важно для сложных систем, поскольку порождаемые им преимущества перевешивают издержки. Ученые обнаружили, что гетерогенность может стабилизировать систему и сделать ее более устойчивой к внешним воздействиям. Разнообразие позволяет системам выживать в жесткой среде. Она повышает их гибкость и способствует инновациям [Stacey 2000a: 7].

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

Джим Коплин и Нил Харрисон в своей книге «Организационные закономерности разработки ПО с использованием гибких методологий» (Organizational Patterns of Agile Software Development) [Coplien, Harrison 2005: 135] включили разнообразие в список позитивных факторов. Они считают его хорошим способом стимулировать инновации и находить решения проблем. Том Демарко и Тимоти Листер в своей книге «Человеческий фактор»[21] указывают, что противоположностью разнообразия будет «пластиковый человек установленной формы». Под этим они понимают стремление менеджеров навязывать людям и командам однообразие. Более того, было показано, что результаты гетерогенных команд зачастую превышают результаты более однородных [Cockburn 2007: 70].

Как отмечает Джон Максвелл («Двадцать один неопровержимый закон лидерства»), у менеджеров есть тенденция нанимать людей, похожих на себя. Белые холостые мужчины традиционной ориентации 20–30 лет склонны нанимать белых холостых мужчин своего возраста и такой же ориентации, потому что так им легче достигать взаимопонимания. Все это естественно и легко объясняется предложенной Ричардом Докинзом теорией эгоистичного гена [Dawkins 1989]. Гены программируют нас отдавать предпочтение людям с копиями таких же генов, как и у нас, и относиться настороженно к тем, у кого набор ДНК явно отличается. Гены ведут эту войну друг с другом уже десятки тысяч лет и за это время привили нам склонность к дискриминации тех, кто отличается от нас. В социологии для обозначения тенденции индивидуумов объединяться с себе подобными существует термин гемофильность.

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

Креативные решения, которые люди способны предложить, зависят от личных историй этих людей. Отсюда следует, что разнообразие в составе команды способно значительно повысить ее творческий потенциал. Это не значит, конечно, что большее разнообразие всегда приводит к повышению креативности. Если вы соберете в одну команду полицейского, голландца, балерину и ребенка ясельного возраста, то рискуете на выходе не получить тот уровень креативности, на который рассчитываете. Необходим определенный баланс и достаточная общность взглядов, чтобы разные точки зрения все же позволяли сформировать общее видение. Левин и Реджайн называют такой подход инклюзивным разнообразием [Lewin, Regine 2001: 44].

Личность

Методологии Agile и Lean внесли замечательный вклад в индустрию разработки ПО. Но иногда меня коробит, когда приходится сталкиваться со списками «ценностей Agile-методологий» или «принципов Lean-разработки». Каждый раз эти списки отличаются друг от друга, и каждый раз они мне не до конца понятны.

В числе двенадцати принципов в Agile-манифесте упоминается доверие. А Мэри и Том Поппендик среди семи принципов Lean-методологии специальное место отводят уважению [Poppendieck 2007: 36]. Но среди семи принципов Lean доверие не упоминается вовсе, а уважение отсутствует среди принципов Agile. Откуда такая разница? Я абсолютно уверен, что слова «доверие» и «уважение» – не синонимы. Я доверяю в этом своему словарю. Но не могу сказать, что уважаю его!

К сожалению, путаница этим не исчерпывается… В коротком списке пяти ценностей Экстремального программирования, который составил Кент Бек, фигурируют коммуникация, простота, обратная связь, смелость и уважение [Beck 2005: 18–21], но отсутствует доверие! А в списке пяти ценностей Scrum, предложенном Кеном Швабером, три из пяти позиций упомянутого выше списка вообще заменены на приверженность достижению цели, сфокусированность и открытость [Schwaber, Beedle 2002]. Что гуру Agile-методологий пытаются этим сказать? Стоит ли нам погрузиться в обсуждение, чем одни ценности лучше других? Или следует просто объединить все списки, чтобы раз и навсегда покончить с этой темой?

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

Означает ли это, что в Agile-методологиях «доверие» ценится выше всего прочего? Что в Lean-методологиях «уважение» будет матерью остальных добродетелей? Что список ценностей Scrum лучше, чем список ценностей Экстремального программирования, поскольку коммуникация и обратная связь, упоминаемые в Экстремальном программировании, представляют собой действия, а не позитивные человеческие качества? Будут ли с точки зрения Agile– и Lean-методологий другие позитивные качества вроде стремления к совершенству, гибкости, честности, чувства юмора, ответственности, самодисциплины и компетентности относительно менее важными?

Я думаю, что ответы на все эти вопросы должны быть отрицательными. Скорее всего, наши гуру не углублялись в эту тему настолько сильно. Они могли с таким же успехом выбрать любые другие пять ценностей, например стремление к совершенству, честность, ответственность, самодисциплину и чувство юмора (я бы точно не стал включать в этот список целомудрие). Это никак бы не сказалось на принятии соответствующих методологий во всем мире. Или сказалось бы? В своем блоге и в выступлениях я неоднократно утверждал, что стремление к совершенству и самодисциплина напрасно воспринимаются как данность и почти никогда в явном виде не упоминаются в описаниях Agile– и Lean-методологий (см. главу 10). Но я отвлекся.

Исследования показывают, что креативность возникает на стыке знаний, мотивации и свойств личности [Runco, Pritzker 1999]. В любой проектной команде знания приведут к креативности только при наличии у людей мотивации и необходимых личных качеств. Именно они предопределяют поведение людей и оказывают огромное воздействие на мотивацию окружающих.

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

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

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

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

Почему только люди способны управлять сложными системами

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

Чтобы обеспечить устойчивость системы, количество возможных состояний ее управляющего механизма должно быть больше или равно количеству возможных состояний самой управляемой системы[22].

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

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

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

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

А что не так с инструментами?

Инструменты похожи на датчики. Они полезны при вводе и выводе данных, в результате чего нам становится легче контролировать ход проектов.

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

От создания идей к их реализации на практике

Инновации не только невозможны без людей, но и бесполезны, если целенаправленно не заниматься их внедрением. Не имеет значения, насколько креативны ваши сотрудники, если идеи, которые они генерируют, не используются при создании новых продуктов или услуг – в этом случае они будут не более чем интересными артефактами [Phillips 2008]. Бизнес-ценность создается при условии, что возникшая креативная идея встречается с практическим действием, становится частью работающей бизнес-модели и в конечном итоге выводится на рынок. По словам Теодора Левитта:

Бывает, что прекрасная новая идея годами витает в компании, но так и не находит себе применения – и не потому, что ее достоинства остались неоцененными; просто никто не берет на себя ответственность превратить ее из слов в дела[23].

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

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

Резюме

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

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

Для создания инновационных продуктов и услуг необходимо наличие всех перечисленных условий.

Подумать и сделать

Давайте посмотрим, сможете ли вы применить некоторые идеи этой главы в своей компании:

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

• Обсудите с коллегами осязаемые результаты реализованных инноваций. Можете ли вы привести примеры таких результатов? Если нет, то почему? Если все из необходимых условий имеются в наличии (знания, креативность, мотивация, разнообразие и личные качества членов команды), то почему инновации не находят себе применения? Какие необходимые для этого действия не предпринимаются?

Глава 5 Как добавить людям энергии

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

Карл Юнг, психиатр (1875–1961)

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

Фазы креативности

В ходе своих исследований я наткнулся на статью Артура Кропли «Определение креативности» [Cropley 1999: 511], в которой содержится интересный материал по этой теме. Кропли пишет, что креативность в своем развитии проходит три фазы:

• Преконвенциональная креативность – обычно проявляется детьми младше 7 лет. В основном формируется через визуальное восприятие и характеризуется спонтанностью и эмоциональной вовлеченностью; на практике иногда имеет своим результатом необходимость перекрасить разрисованные стены в детской.

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

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

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

Я полагаю, что модель трех фаз креативного мышления представляет собой полезный инструмент, но она на самом деле не имеет никакого отношения к тому, как функционирует детский мозг. Давайте я поясню это на примере. Давным-давно, в эпоху Windows 3.1, я показал своему приятелю несколько отпечатанных страниц текста, которые я создал при помощи очень интересного шрифта. И пожаловался, что каким-то образом потерял этот шрифт и никак не могу найти его в своем компьютере. Совершенно не разбирающийся (к счастью для него) в компьютерах приятель странно посмотрел на распечатанные страницы и сказал, что не понимает, в чем проблема. «Вот же он, на странице», – сказал он. «Да, – ответил я, – но его нет у меня на компьютере». На это последовал недоуменный ответ: «Но ты же вчера показывал мне свой новый сканер. Ты никак не можешь отсканировать этот шрифт и загнать его обратно в компьютер?»

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

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

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

Как создать рабочую среду, способствующую креативности

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

Ощущение безопасности

Люди проявляют креативность только в ситуациях, когда ощущают, что высказывать идеи безопасно. Когда речь идет о новых идеях, необходима свобода быть креативным, свобода идти на риск, а также понимание, что в неудачах нет ничего криминального. Если люди знают, что могут идти на риск и терпеть неудачи, они будут более расположены рождать что-то новое. Ощущение безопасности означает отсутствие страха выдвигать идеи и задавать вопросы (Уильям Эдвардс Деминг) [Austin, Devin 2003: 118].

Элемент игры

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

Разнообразие

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

Заметность

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

Выход из зоны комфорта

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

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

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

Дело не в том, чтобы вывести людей из зоны комфорта, просто завалив их работой. Но работа должна быть достаточно трудной и бросать серьезный вызов их интеллекту. Так вы поможете сотрудникам найти оптимальное положение на границе зоны комфорта, способствующее креативности.

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

Креативные методики

Существуют буквально сотни приемов, стимулирующих креативность. Чтобы перечислить их все, понадобится отдельная книга. (К счастью, такие книги уже существуют [Clegg, Birch 2006].) Интересно, что на метауровне приемы креативности можно легко объединить всего в несколько категорий.

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

• Формулировка проблемы: эти методики фокусируются на анализе и способах улучшения формулировки проблемы для прояснения задачи. Сюда относятся такие методы, как разбивка задачи на более мелкие подзадачи, метод шести вопросов («Кто? Почему? Что? Где? Когда? Как?») и определение рамок проблемы.

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

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

Внешняя мотивация

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

Профессор менеджмента Дуглас Макгрегор создал модель мотивации, состоящую из теории X и теории Y [McGregor, Cutcher-Gershenfeld 2006]. Теория X утверждает, что в общем случае люди предпочитают воздерживаться от работы. (О теории Y речь пойдет в следующем разделе.) В соответствии с теорией X лучший способ заставить людей выполнять свою работу – это деньги, контроль со стороны менеджмента и прочие стандартные кнуты и пряники. А чтобы люди делали свою работу хорошо, нужно просто побольше этих ингредиентов. Из этой теории следует, что для достижения людьми максимальной эффективности необходима внешняя мотивация.

Внешняя мотивация в денежной форме (в виде высоких окладов, стимулирующих выплат и бонусов) иногда срабатывает. Когда денег немного (например, при запуске стартапов), могут оказаться эффективными стимулы в виде опционов сотрудникам на приобретение акций [Yourdon 2004: 94]. Хорошо известен такой вид неденежной внешней мотивации, как дополнительные льготы и возможности. Как отмечает Стив Макконнелл, во время его работы в Microsoft он лично почувствовал эффективность подобных неденежных форм мотивации [McConnell 2004: 139].

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

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

К сожалению, нелинейность означает не только то, что желательные последствия могут так и не наступить. Из нее также следует, что могут наступить нежелательные. Как точно подмечено Томом Демарко и Тимоти Листером в книге «Человеческий фактор»:

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

Многие эксперты согласны, что повышение окладов за хорошую работу, стимулирующие выплаты и бонусы могут наделать много вреда:

Деминг считал, что любой бизнес – это система, а результативность сотрудников в значительной мере определяется тем, как эта система функционирует. С его точки зрения, причиной 80 % [а по другим источникам и более] возникающих в бизнесе проблем будет именно созданная в компании система, за состояние которой отвечают менеджеры. Он писал, что попытки путем увещеваний и материальных стимулов побудить сотрудников решать проблемы, не решенные менеджментом, неэффективны. Деминг выступал против составления любых рейтингов сотрудников, потому что они подрывают в людях ощущение гордости за свою работу, а также против повышения заработной платы за хорошую работу, потому что такие меры направлены на симптомы, а не к причины проблем[27].

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

Внешняя мотивация представляет собой проблему именно из-за нелинейного поведения сложных адаптивных систем. Когда менеджеры подталкивают, подстегивают или иным способом пытаются привести в движение людей, являющихся элементами такой системы, часто это имеет своим результатом неожиданные последствия и побочные эффекты, которые слишком сложны, чтобы их можно было предсказать, находясь вне этой системы. Например, правительство США проводило политику стимулирования (внешняя мотивация) покупки домовладений американцами с низким уровнем дохода. В сочетании с системой бонусов, сложившейся в банковском секторе (внешняя мотивация), это сначала привело к созданию искусственного пузыря на рынке недвижимости, а затем к экономическому коллапсу, в результате которого рецессия охватила весь мир [Norberg 2009]. Еще один пример, но в меньшем масштабе: известен случай, когда цена акций компании одномоментно упала на 22 % в результате всего лишь одного сообщения, разосланного генеральным директором всем сотрудникам, в котором он дал им понять, что ожидает ежедневно видеть служебную парковку полностью заполненной к 7:30 утра [Austin, Devin 2003: 119].

Разными авторами описано множество опасных побочных эффектов внешней мотивации. К ним относятся субоптимизация ключевых процессов, эрозия внутренней мотивации сотрудников, болезненная зависимость от внешних стимулов, снижение эффективности при решении проблем и непреднамеренная конкуренция между сотрудниками [Austin 1996], [Poppendieck 2004], [Pink 2009].

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

Внутренняя мотивация

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

Существует ли теория Z?

Вообще-то да. Она была разработана Уильямом Оучи и в целом считается производной от теории Y. Теория Z идет несколько дальше, чем теория Y, утверждая, что одно из основных предпочтений сотрудников – выстраивать хорошие отношения с коллегами, а также они хотят, чтобы их ценили на работе.

Лично я не вижу особой разницы между теорией Y и теорией Z, поскольку в основе обеих лежит все та же внутренняя мотивация.

В современной литературе широкое распространение получила точка зрения, что креативность имеет в своей основе внутреннюю мотивацию – желание заниматься какой-либо деятельностью ради самой этой деятельности, а не в надежде получить вознаграждение. Внешняя мотивация может тормозить креативность и даже быть для нее фатальной [Runco, Pritzker 1999: 521].

Внутренняя мотивация не порождает нелинейные побочные эффекты, которыми так часто сопровождается внешняя. Она не основана на логике «если нам нужен результат B, то мы должны простимулировать его причину A». В случае с внутренней мотивацией A равно B. Наши действия сами по себе награда!

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

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

Демотивация

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

Можно ли сделать человека счастливым? Или все, что можно, – это устранить причины, из-за которых он несчастен? Можно ли заставить человека смеяться? Или все, на что стоит рассчитывать, – это устранить причины, заставляющие его плакать?

Психологом Фредериком Герцбергом была предложена двуфакторная теория мотивации (теория мотивирующих и гигиенических факторов), которая утверждает, что состояния удовлетворенности и неудовлетворенности независимы друг от друга [Herzberg 2008]. Факторы, мотивирующие и демотивирующие людей на работе, совершенно различны. Плохая атмосфера, низкая зарплата и бюрократические правила – примеры демотивирующих факторов. Но даже если их устранить, это не приведет к возникновению мотивации. Приходилось ли вам когда-либо слышать «Боже мой, какое удобное офисное кресло! Оно мотивирует меня прилагать максимум усилий»? Конечно, нет. Людей мотивируют совершенно другие вещи, например возможность самостоятельно принимать решения и ощущение принадлежности к группе.

Герцберг различает мотивирующие и гигиенические факторы.

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

• Гигиенические факторы: гарантии занятости, зарплата, статус, условия работы, внутренние правила компании, дополнительные формы вознаграждения и так далее.

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

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

Десять базовых потребностей членов команды

Мы уже видели, что внутренняя мотивация предпочтительнее внешней. Сейчас мы сделаем еще один шаг и исследуем, что представляет собой внутренняя мотивация. Начнем мы с теории самодетерминации.

Теория самодетерминации представляет собой общую модель внутренней мотивации, различающую три основные внутренние потребности. Эти потребности – универсальные, врожденные и имманентно присущие психологии человека [Deci, Ryan 2004].

• Потребность в компетентности: необходимость ощущать свою способность справляться с окружающей средой.

• Потребность в автономности: стремление к активной роли при определении собственного поведения и автономности при выборе своих поступков.

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

Похожая теория была выдвинута профессором Стивеном Райссом. Он обнаружил, что шестнадцать базовых потребностей управляют практически всеми видами человеческого поведения[28].

Признание – Потребность в одобрении

Физическая активность – Потребность в физических упражнениях

Любознательность – Потребность узнавать новое, размышлять

Власть – Потребность оказывать влияние на других через проявление воли

Еда – Потребность в питании

Романтика – Потребность в любви и сексе

Семья – Потребность растить детей

Бережливость – Потребность собирать что-либо или накапливать

Честь – Лояльность группе

Социальные контакты – Потребность в друзьях

Идеализм – Потребность в предназначении

Статус – Потребность в социальном положении

Независимость – Потребность в сохранении индивидуальности

Спокойствие – Потребность в безопасности

Порядок – Потребность в стабильности

Месть – Потребность отвечать ударом на удар

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

1. Убедитесь, что члены команды ощущают себя компетентными в том, чем занимаются. Давайте им работу, которая требует от них напряжения усилий и при этом остается посильной.

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

3. Удостоверьтесь, что задействована их любознательность. Хотя некоторые виды деятельности скучны, в работе всегда должны присутствовать элементы, требующие исследования.

4. Дайте людям возможность удовлетворить свою потребность проявлять лояльность группе. Вы должны разрешать группам вводить свои собственные правила, чтобы они могли их с удовольствием (или через силу) выполнять.

5. Вносите в свою деятельность определенную степень идеализма (предназначение). Бизнесом занимаются не только для того, чтобы заработать деньги. Вы также стремитесь внести свой небольшой вклад в то, чтобы мир стал лучше. (Примечание: здесь нужно проявлять осторожность. Полно примеров, как топ-менеджмент злоупотребляет этим, пытаясь таким образом завуалировать свои истинные намерения, а именно – заработать побольше денег.)

6. Поощряйте независимость (автономность) сотрудников. Разрешите им отличаться от других. И не забывайте сделать комплимент, если заметили оригинальную прическу.

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

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

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

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

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

Но что делать, если сотрудники нуждаются во внешней мотивации?

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

Если без внешней мотивации не обойтись, вы можете попросить их проявить креативность и описать все возможные способы «обмануть систему», а затем спросить их, как (пере-)настроить систему внешней мотивации, чтобы она позволяла не допускать возникновения такого рода проблем.

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

Если вы не знаете, как опереться на внутренние потребности людей, всегда можно спросить об этом их самих. Скотт Беркун полагает, что есть один простой вопрос, который менеджер может задать каждому члену команды:

«Что я могу сделать, чтобы помочь вам добиваться максимальных результатов?»[29]

Просто задав этот несложный вопрос, вы достигаете следующих целей:

• Как минимум признаете, что человек способен на большее.

• Просите человека самостоятельно оценить свои результаты.

• Инициируете обсуждение, как можно добиться улучшений в будущем.

Совсем нетрудно регулярно задавать сотрудникам предложенный Скоттом вопрос. И его трудно забыть даже таким старперам, как я.

Что мотивирует людей: найдите баланс

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

• им удается создать продукт, который изменяет чью-то жизнь к лучшему;

• они ощущают, что полностью контролируют свой компьютер;

• они способны создать продукт, который облегчит кому-то жизнь;

• они имеют возможность развиваться в профессиональном и личностном плане;

• им разрешают заказывать книги, потому что они любят читать;

• они вдруг понимают, что прошло четыре часа, а по ощущению – только десять минут;

• к ним относятся по-человечески, а не как к очередному ресурсу;

• созданный ими продукт оказывается успешным, что повышает их уверенность в себе;

• они ощущают, что продукт, над которым они работают, это выражение их самих;

• они ощущают страстное желание найти решение трудных проблем;

• им нравится создавать ценность, находя простые программные решения;

• работа позволяет зарабатывать достойные деньги;

• им доверяют критически важные проекты;

• их увлеченность своей профессией адекватно вознаграждается;

• они могут использовать самые современные технологии;

• они получают высокую оценку от всех заинтересованных лиц;

• пользователь сказал им спасибо.

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

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

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

Поэтому если вы считаете, что какая-либо практика (вроде коллективного владения кодом) необходима, то как вы собираетесь мотивировать кого-то, кто столь же упрям, как я?

Представьте себе баланс (рис. 5.2), в котором перечислены факторы, мотивирующие или демотивирующие одного из участников вашей команды. «Лучшие практики» по-разному воспринимаются разными людьми. Меня коллективное владение кодом демотивирует. Следовательно, из моего баланса нужно вычесть один пункт. А мой приятель Нильс, самый оголтелый из социалистов, которых я когда-либо допускал в свою жизнь, был бы, скорее всего, в восторге от идеи передать свой код другим. Таким образом, для него коллективное владение кодом будет сильнейшим мотиватором, а в его мотивационном балансе появляется жирный плюс.

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

Применяя Scrum, мы можем до бесконечности обсуждать, какой метод оценки объема работ лучше – с помощью «единиц истории», «идеальных дней», «размеров футболок» или «попугаев»? Какова оптимальная продолжительность одной итерации – одна неделя или четыре? А также чем лучше пользоваться при планировании – специальным приложением или стикерами розового цвета? И так далее… Все равно главное в том, что, стимулируя членов своей команды проводить такие обсуждения, вы добавляете плюсы в мотивационный баланс каждого сотрудника. И вам это ничего не стоит!

Все дороги ведут в Рим. И хотя дорог, ведущих к успеху в проектах по разработке ПО, несколько меньше, все равно вы будете часто оказываться перед выбором. При возникновении очередной развилки мне часто приходится становиться свидетелем дискуссий о том, какие практики «лучше», – при этом многие забывают первую ценность Agile-манифеста: «Ценить людей выше, чем процессы». Мотивировать людей всегда важнее, чем заставлять их пользоваться теми практиками, которые нравятся лично вам. Если вам не повезло и ваша команда состоит из людей, похожих на меня, смиритесь с тем, что они никогда не полюбят коллективное владение кодом, независимо от того, сколько книг Кента Бека вы их заставите прочитать. Вам придется сбалансировать свою новую политику, привнеся в нее убеждающие и мотивирующие компоненты. В противном случае вам придется зализать раны и попробовать что-то еще.

А что если у кого-то из сотрудников отрицательный мотивационный баланс?

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

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

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

Сделайте ваши награды внутренними

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

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

Разнообразие? Вы имеете в виду связи!

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

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

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

Не понимаю почему.

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

Кроме того, если мы будем давать поблажки __________, то мы вынуждены будем также давать их всем остальным людям, которые могут быть @@@, ####, &&&, – и ===. И к чему все это приведет?

Конечно, если какие-то #*! люди проявляют дискриминацию против __________, мы должны с этим бороться. Только и всего. В конце концов, мы все должны научиться относиться друг к другу нейтрально. Мы не можем остановиться на полпути к этой цели.

В настоящий момент я доволен своей работой, потому что получил ее благодаря своей компетентности. Меня наняли не потому, что я __________.

В своих попытках обеспечить социальное разнообразие в командах некоторые менеджеры исходят из своих весьма упрощенных представлений о том, что это такое. В результате их действия с целью увеличения разнообразия внутри команд разработчиков часто сводятся к тому, чтобы нанимать больше женщин. Данный подход базируется на стереотипном восприятии гендерных отличий и с научной точки зрения полностью устарел [Eliot 2010: 26]. Разнообразие – это все же нечто большее, чем «форма гениталий» [Hamel 2007: 158].

Эксперты в области управления и специалисты по теории сложности отмечают, что эффективность сотрудников в значительной степени обусловлена системой, внутри которой они функционируют. В свою очередь из анализа социально-сетевых структур становится ясно, что эффективность отдельного сотрудника также зависит от количества связей, существующих между ним и другими людьми внутри данной сетевой структуры [Cross 2004: 11].

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

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

Оценка личности сотрудника

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

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

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

При составлении эннеаграммы личности выявляются девять типов людей, а результаты для конкретного человека представляются в виде круговой диаграммы с девятью точками. Считается, что эта модель полезна в качестве инструмента саморазвития, хотя ее часто критикуют за нефальсифицируемость (что означает ее ненаучный характер) и обвиняют в том, что она уходит своими корнями в мистические учения. Тем не менее может быть забавно пройти эту оценку вместе с командой. А если кто-то из сотрудников вообще противится научной оценке своей личности, то составление не вполне научных эннеаграмм может стать приемлемым компромиссом. Нет ничего страшного в том, что вы вместе с командой проявите здоровую долю скептицизма и вместе посмеетесь над полученными результатами: в любом случае это будет способствовать росту команды[30] и осознанию различий между входящими в ее состав игроками.

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

Четыре этапа при оценке личности членов команды

Оценка разнообразия и совместимости личностных характеристик членов команды может быть проведена в четыре этапа.

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

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

В-третьих, попросите сотрудников пройти тестирование в частном порядке. В интернете огромный выбор бесплатных тестов, но если вы готовы платить за это деньги, то получите более детальные и профессиональные отчеты, наняв консультантов со стороны. Требование, чтобы сотрудники научились лучше понимать самих себя, вполне разумно. Когда они станут лучше понимать свои сильные и слабые стороны, им будет легче вносить коррективы в свое поведение. А вы заработаете дополнительные очки как менеджер, продемонстрировав готовность инвестировать в развитие сотрудников.

В принципе, на этом можно и остановиться. Прекрасно, когда вы по-настоящему знаете себя, ваши сотрудники узнали вас и научились лучше понимать самих себя. Вы уже решили 75 % задач, связанных с оценкой личных черт своих сотрудников, и во многих ситуациях этого вполне достаточно. В то же время вы можете захотеть завершить работу в этом направлении на все 100 %…

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

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

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

Создание командных ценностей: набор инструментов

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

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

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

1. Распечатайте «Большой список 50 ценностей» (табл. 5.1) и раздайте его членам команды. (Примечание: некоторые «стандартные» ценности, принятые в гибких и бережливых методологиях, а также в Scrum и Экстремальном программировании, выделены жирным шрифтом.)

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

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

4. Затем соберите свою команду и сравните эти два списка (они должны составляться совершенно независимо друг от друга). Скорее всего, большинство позиций, попавших в эти списки, не совпадут, но некоторые совпадения или черты сходства все же могут наметиться. Скорее всего, у внешней среды и самой системы неодинаковые взгляды на то, что действительно важно. Обсуждайте взаимные ожидания до тех пор, пока не удастся добиться консенсуса относительно объединенного списка ценностей, состоящего максимум из трех – семи позиций («пять плюс-минус два»).

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

«Большой список 50 ценностей» вдохновлен сайтом Wisdom Commons, где можно найти дополнительные списки позитивных качеств, полезных для ежедневной работы и жизни в целом. При необходимости команды могут сами дополнять этот список, если в нем отсутствуют ценности, которые они считают совершенно необходимыми.

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

Что если вы управляете сразу несколькими командами?

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

Моей матери приходилось время от времени быть очень строгой с моим братом, и он постоянно жаловался, что ко мне она не так сурова. Но на то были веские причины: в отличие от него список моих детских прегрешений мог уместиться на половинке стикера.

Точно так же менеджеры вынуждены относиться по-разному к разным командам и разным людям. И они должны суметь при необходимости убедительно объяснить, почему так происходит.

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

Жизненно важно, чтобы выбранные командой ценности были поняты и приняты топ-менеджментом. Команда – это лишь часть организации, и, следовательно, важно, чтобы список ее ценностей был предметом консенсуса.

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

Определитесь со своими личными ценностями

Предметом ваших забот должны быть не только ценности команды, вам надо определиться и со своими личными ценностями.

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

Это нетрудно. Это всего лишь выше человеческих сил.

Невозможно быть добродетельным сразу в пятидесяти измерениях. Если одновременно пытаться заниматься многими делами, это все равно что не заниматься ничем. Лучше отобрать несколько и сфокусироваться на них. О других можно пока не беспокоиться. Придет время и для них.

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

Не хотите ли вы сказать, что я не могу быть самим собой?

Вовсе нет! Вы должны сохранять верность себе, потому что люди все равно увидят, если вы будете притворяться.

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

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

Политика отсутствия дверей

Раз уж мы уделили какое-то время саморефлексии, я бы хотел в завершение этой главы сказать несколько слов об отношениях между менеджером и командой.

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

Есть три причины, почему мне не нравится эта политика:

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

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

• Она также предполагает, что сотрудники могут в любой момент заглянуть в офис любого топ-менеджера и увидеть, что у него есть секретарша, стол из красного дерева, личная кофемашина Nespresso и титановые клюшки для гольфа.

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

Нам нужна другая политика, которая подчеркивала бы, что менеджеры не отделены от остальных сотрудников никакой стеной, что они – такие же люди, как и все остальные в компании.

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

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

Подводя итоги: в этой главе мы обсудили, каким образом в наших сложных системах нужно «добавлять энергию агентам». Но обсуждение роли, которую играют люди, на этом не заканчивается. Напротив, мы продолжим говорить об этом и дальше. В главах 6 и 7 мы обсудим, как происходит самоорганизация людей и почему в рамках второго компонента Менеджмента 3.0 именно ее мы считаем критически важной для гибкого управления.

Резюме

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

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

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

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

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

Подумать и сделать

Давайте посмотрим, как применить некоторые идеи из данной главы в вашей компании:

• Обсудите со своей командой понятие «интеллект новичка» (постконвенциональная креативность). Что вы предпринимаете, чтобы способствовать развитию и поддержанию в команде соответствующих установок?

• Проанализируйте, насколько обстановка в компании способствует креативности. Создаете ли вы такие необходимые для креативности условия, как ощущение безопасности и элемент игры? Стремитесь ли вы вносить разнообразие в выполняемую сотрудниками работу, демонстрировать им результаты креативного подхода, достигнутые другими, и создавать необходимость для сотрудников выходить из зоны комфорта?

• Обсудите со своей командой различные методики креативности. Какие из них уже используются? Нужно ли обучить людей дополнительным техникам или приемам?

• Определите, какие формы внешней мотивации применяются в вашей компании. Предложите план, как обойтись без них – в особенности без внешней финансовой мотивации.

• Посмотрите еще раз список из десяти внутренних потребностей людей. Соотносите ли вы свои усилия по созданию мотивации сотрудников с их внутренними потребностями?

• Если вы серьезно настроены развивать мотивацию сотрудников, регулярно задавайте им «простой вопрос», предложенный Скоттом Беркуном.

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

• На основе «Большого списка ценностей» составьте свой более конкретный перечень, которыми ваша команда сможет руководствоваться в своей работе при принятии повседневных решений.

• Подумайте о своих личных ценностях. Синхронизированы ли они с ценностями команды? Или же они существенно отличаются? Сможете ли вы вдохновить сотрудников своим примером?

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

Глава 6 Базовые принципы самоорганизации

Наука – это организованные знания.

Мудрость – это организованная жизнь.

Иммануил Кант, философ (1742–1804)

В течение столетий математики предпочитали работать с линейными (упорядоченными) системами, относя нелинейные (сложные) к отдельной группе. Но реальность полна парадоксов. Норма – это именно нелинейные системы. Они и преобладают во Вселенной, в то время как линейные встречаются редко и представляют собой скорее исключение. Кто-то однажды заметил, что разделить системы на линейные и нелинейные – это все равно, что разделить все биологические виды на две категории: плодовые мушки и все остальные. Люди, а также киты, тигры и дятлы в этом случае попадут во вторую категорию. Может быть, математики страдают наивностью? Или же это всего лишь говорит о том, что ничто человеческое им не чуждо?

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

Самоорганизация в контексте

В начале не было ничего. Затем появились мембраны или струны, из которых сформировались кварки и глюоны. Кварки и глюоны организовались в составные частицы, такие как протоны и нейтроны. При участии электронов эти частицы организовались в атомы. Самоорганизация атомов позволила подняться на следующий уровень – уровень молекул. Таким способом возникли миллионы разнообразных молекул, объединения которых превратились в звезды, планеты, кометы и другие причудливые объекты.

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

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

Начиная с момента возникновения Вселенной все, что в ней возникало, формировалось путем самоорганизации.

Самоорганизация – процесс возникновения в системе структур или форм, не являющийся результатом централизованного или внешнего воздействия или планирования.

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

Звучит немного глупо, когда Agile-методологии называют лучшими практиками при разработке ПО. Самоорганизация не может быть лучшей практикой. Это практика любой системы «по умолчанию», включая команды. Независимо от того, как вы управляете организацией, всегда будет иметь место и самоорганизация. Люди будут самостоятельно обсуждать и договариваться о проведении совещаний во время обеденного перерыва, структуре директорий для хранения данных, организации общего рабочего пространства и вечеринках по поводу дней рождения. Все, на что менеджмент не накладывает ограничений (и даже многое из того, на что он пытается наложить ограничения), имеет тенденцию самоорганизовываться. Они ведут себя подобным образом вот уже 200 000 лет.

Но всякая ли самоорганизация осуществляется в «правильном направлении»?

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

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

Самоорганизация с целью создания ценности

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

Человеческий род уникален в том смысле, что с возникновением сознания мы изобрели мораль, законы и институт государственной власти. Мы определили предпочтительные направления развития самоорганизующихся систем, поскольку считаем одни результаты ценными, а другие – вредными. Мы ценим человеческую жизнь, поэтому воспринимаем возбудителей малярии и СПИДа в качестве примеров нежелательной самоорганизации. С точки зрения эволюции наше стремление продлевать жизнь восьмидесятилетним старикам может показаться странным. Но, к счастью, мы идем на это. Мы также становимся сторонниками иррациональных и противоестественных стратегий вроде моногамности, стремления к поддержанию всеобщего мира и отказа от дискриминации.

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

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

Забавно, что многие полагают, будто директивно-подотчетная система управления была нормой во все времена, а концепция «самоорганизующихся команд» нова и оригинальна. Здесь мы вновь сталкиваемся с проявлением «наивности». Самоорганизация как принцип создания структур и форм без чьей-либо руководящей роли, спускающей директивы сверху вниз, пронизывает весь наш мир. В попытке защитить то, что, по их мнению, ценно, люди начали пользоваться директивными методами управления лишь через 13,7 миллиарда лет. Нормой же всегда была и остается самоорганизация. Директивно-подотчетное управление – не более чем частный случай.

В работе «Гибкие процессы и самоорганизация», опубликованной в 2001 году, Кен Швабер пишет следующее:

В рамках гибких процессов сложностью, возникающей в ходе разработки программных систем, управляют самоорганизующиеся команды. Такие команды формируются из индивидуальностей. Они самоорганизуются в качестве реакции на давление, которое на них оказывают дедлайны, напоминая мне об известной поговорке, что «ничто так не концентрирует внимание, как затягивающаяся на шее петля». Давление дедлайнов принуждает людей к сотрудничеству и креативности, которые в других ситуациях возникают очень редко. Возможно, это выглядит бесчеловечно, но по сравнению с другими негибкими способами решения проблем, вызванных сложностью, самоорганизация – это глоток свежего воздуха[31].

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

Самоорганизация в сравнении с анархией

Некоторые эксперты полагают, что самоорганизация отличается от анархии [Highsmith 2009: 60]. Джим Хайсмит говорит, что самоорганизация (в социальном контексте) подразумевает некие формы лидерства и что в противном случае она вырождается в анархию. Я вынужден почтительно не согласиться, хотя мое несогласие касается в основном семантики.

Своим происхождением термин «анархия» обязан греческим словам anarchia и anarchos, которые означают «безвластие». Различные словари дают два определения анархии:

• Отсутствие порядка (или присутствие беспорядка).

• Отсутствие или отрицание любой власти либо установленного порядка.

Это может означать одно из двух: хаос (отсутствие порядка) или сложность (порядок, возникший не в результате действий какой-либо власти). Это показано на рис. 6.1. Зона действия правления охватывает область между сложностью и порядком. Анархия, или отсутствие правления, распространяется на область между сложностью и хаосом. (Примечание: это упрощенная, метафорическая картинка. Но я нахожу ее достаточно удобной).

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

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

На самом деле людям не нравится в анархии то, что неуправляемые системы могут вести себя так, как не нравится заинтересованным сторонам. Когда мои дети играют в какую-нибудь игру и носятся вокруг меня с пронзительным визгом, я бы охотно согласился, что это проявление анархии. Но это просто означает, что такая их самоорганизация меня как заинтересованное лицо не устраивает. То же самое можно сказать о команде разработчиков, играющей в офисе в футбол, когда остальные работают. (Я говорю вполне серьезно, мне приходилось наблюдать подобное.) В этом случае я бы принял меры. Как однажды в ходе телеконференции заметил Дейв Сноуден, «в таких случаях надо начертить на полу линию и сказать детям, что если они ее пересекут, то они покойники»[32].

Самоорганизация и эмерджентность

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

Чтобы свойство было эмерджентным, оно должно удовлетворять трем условиям:

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

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

• Эмерджентное свойство должно обладать нисходящей причинностью, то есть в свою очередь влиять на поведение отдельных компонентов системы. Например, культура группы влияет на поведение составляющих ее индивидуумов.

Резюмируем: эмерджентное свойство должно быть глобальным (присущим только системе в целом), несводимым к свойствам ее компонентов и воздействующим в свою очередь на компоненты данной системы (рис. 6.2.).

Границы научных дисциплин зависят от уровней, на которых начинают проявляться эмерджентные свойства. Так, на определенном уровне физика становится химией, химия – биологией, биология – психологией, а психология превращается в экономику. Каждая последующая научная дисциплина занимается изучением свойств, генерируемых предыдущим уровнем [Miller, Page 2007: 45]. Это также означает, что на каждом новом уровне возникают свои собственные законы и зависимости. Психология – это нечто большее, чем прикладная биология; биологию невозможно свести к прикладной химии, а химия несводима к прикладной физике [Waldrop 1992: 82]. Именно поэтому не срабатывает жадный редукционизм. Нельзя объяснить неработающее программное обеспечение тем, что у одного из разработчиков было что-то не то в энцефалограмме; а если вы забыли о дне рождения супруги или супруга, невозможно списать это на неправильно функционирующие атомы или теорию струн. Поверьте моему опыту, это не работает – я пробовал.

В литературе присутствует некоторая путаница и разногласия по поводу соотношения между самоорганизацией и эмерджентностью [De Wolf, Holvoet 2005]. Некоторые ученые определяют одно через другое, в то время как другие утверждают, что это разные понятия [Corning 2002]. Я согласен с Питером Корнингом в том, что могут существовать самоорганизующиеся системы, не проявляющие эмерджентных свойств, а также что эмерджентные свойства могут возникать у систем, созданных целиком под управлением людей и не являющихся самоорганизующимися. Но все это не более чем вопрос определений. В этой книге я использую термин «эмерджентность» для обозначения «свойств целостных систем, складывающихся из результатов функционирования их отдельных частей, но несводимых к свойствам этих частей» [Corning 2003: 23]. И хотя данная книга не будет самоорганизующейся системой, впечатление, которое она произведет на вас, будет эмерджентным по своей сути: оно глобально, то есть определяется книгой в целом, не сводимо к содержанию отдельных страниц и даже может обладать нисходящей причинностью (например, по прочтении вы можете захотеть сжечь эту книгу).

Эмерджентность в командах

Пытаясь применить концепцию эмерджентности к командам, можно заметить массу интересных явлений. Первым будет возможность коллективного принятия решений при отсутствии централизованного планирования. Описанные в литературе нападения масс кочевых муравьев – крупнейшие совместные операции животных [Solé 2000: 166]. При этом нет ни одного муравья, который бы представлял себе план всей операции. Точно так же ни у одного члена команды не может быть исчерпывающего представления о проекте в целом. И тем не менее даже в ситуациях, когда отдельные члены команды руководствуются неполной информацией, в результате взаимодействия между ними возникают вполне осмысленные планы.

Исследования человеческого сознания показывают, что множественные конфликтующие точки зрения способны дать (более или менее) единый взгляд на всю систему. Дэниел Деннетт и Марвин Мински предложили гипотезу, что «единый поток сознания» – это иллюзия. По мнению Деннетта, сознание представляет собой множество возникающих параллельно и постоянно обновляемых фрагментов содержания [Dennett 1992]. Наш мозг сводит все эти конкурирующие интерпретации внешнего мира в единую сущность, которую мы и называем своей личностью или своим «я». Если сознание и иллюзия, надо признать, что она весьма убедительна. С аналогичных позиций выступает также Мински, продвигающий модель сознания как продукт взаимодействия не обладающих сознанием составляющих («сообщество элементов, вместе образующих разум») [Minsky 1986].

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

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

Мы также знаем, что система может быть чем-то большим, чем суммой ее частей. Например, нашему мозгу присущ достаточно стабильный альфа-ритм 8–12 Гц. Он представляет собой весьма точные часы, хотя в их основе лежит множество гораздо менее точных часов, представленных отдельными нейронами, частота импульсов которых колеблется в интервале от 8 до 12 раз в секунду. Таким образом, эмерджентный альфа-ритм более надежен, чем ритм любого из нейронов [Strogatz 2003: 42]. Аналогично этому нет ничего необычного в том, что команда как целое может быть эффективнее даже наиболее компетентных сотрудников в ее составе. Демарко и Листер называют этот феномен «команда, прошедшая кристаллизацию». Это группа людей, взаимодействующих настолько тесно, что целое представляет собой нечто большее, чем сумма составляющих его индивидуумов. Продуктивность такой группы превышает продуктивность, которая может быть достигнута путем простого суммирования вкладов каждого члена команды, если бы они работали по отдельности [DeMarco, Lister 1999: 123].

И наконец, природа эмерджентных свойств часто непредсказуема [Solé 2000: 20]. Вода, молекула которой состоит из двух атомов водорода и одного атома кислорода, может существовать в разных агрегатных состояниях, например она может замерзнуть или закипеть. В свойствах атомов водорода и кислорода нет ничего, что позволило бы предсказать эти свойства воды [Waldrop 1992: 82]. То же самое относится к командам. Невозможно предсказать поведение команды, даже если тщательно изучить личностные характеристики всех входящих в ее состав сотрудников. Эмерджентное поведение команды – результат взаимодействия ее членов. Команды отвечают за свою культуру, способ работы, образ в организации и иногда за собственное название. Вы не в силах предсказать эти эмерджентные свойства в тот момент, когда собираете команду. Единственное, что можно прогнозировать точно, – это стремление подорвать прибыльность проекта, поскольку члены команды гарантированно будут утверждать, что без дорогих инструментов и обучающих тренингов им не обойтись.

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

Помимо самоорганизации при описании гибких команд используются (с той или иной степенью путаницы) еще несколько похожих терминов. Примеры показаны в таблице 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]:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Метафора строительства устарела. Пора вновь вносить изменения. Если, как я считаю, создаваемые сегодня концептуальные структуры слишком сложны, чтобы их можно было точно определить заранее и создавать их без ошибок, то нужен радикально иной подход. ‹…› Давайте изучать живые организмы со всей присущей им сложностью, а не только безжизненные творения, созданные человеком. В природе мы обнаружим конструкции, сложность которых вселяет в человека священный трепет. Наш мозг уже настолько сложен, что невозможно составить его схему. Его мощь потрясает воображение, он чрезвычайно разнообразен, способен к самосохранению и самообновлению. Секрет в том, что мозг возник в результате эволюции, а не был построен по чертежам. Так же должны создаваться наши программные системы[34].

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

Мы перестали говорить о построении команд и заговорили о том, что их надо выращивать. Этот процесс уместно сравнить с сельским хозяйством. В нем никогда нельзя до конца контролировать результаты. Вы вносите удобрения, высаживаете семена, организовываете полив в соответствии с последними веяниями, а затем ждете, затаив дыхание. Урожай может вырасти, а может и не вырасти. При виде буйных всходов вам гарантировано прекрасное настроение, но на следующий год все усилия придется повторить заново. Примерно так же создаются команды[35].

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

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

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

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

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

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

Резюме

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

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

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

Подумать и сделать

Давайте посмотрим, как применить некоторые идеи данной главы в вашей компании:

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

• Представьте себе список решений, которые команда уполномочена принимать без вашего участия. А как выглядит список решений, которые принимаете лично вы? Какой из списков длиннее и почему?

Глава 7 Расширение прав и полномочий команд

В конечном итоге единственная власть, к которой человеку следует стремиться, это власть над собой.

Эли Визель, писатель, общественный деятель,лауреат Нобелевской премии мира (1928–2016)

Фрэнсис Бэкон однажды написал слова, ставшие знаменитыми: «Знание – сила». (Вообще-то он сказал, что «знание само по себе является силой», но история решила, что такая формулировка недостаточно броская.) Это хорошо согласуется с представлением о том, что реальными полномочиями обладают именно интеллектуальные работники. Они владельцы знаний, поэтому именно они и располагают в организации реальной властью. Часто они этого просто не осознают.

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

Не создавайте мотивационные долги

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

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

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

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

Бывает, что из-за хорошего менеджмента сложнее решить какие-то краткосрочные проблемы, в то время как он облегчает решение долгосрочных проблем. У хороших менеджеров вообще есть тенденция периодически затруднять работу другим. Я уверен, что отказ обоих кандидатов перейти в другую команду можно отчасти приписать лидерским умениям их руководителя. Трудно представить себе лучший комплимент, чем отказ сотрудников покинуть твою команду. Как заметил тот менеджер, «во всяком случае хоть что-то я делаю правильно!».

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

В общем, я показал вам, чего делать не надо. А теперь давайте посмотрим, что нужно делать, чтобы расширить полномочия команд. Данной теме посвящена вся эта глава.

Но разве вы тем самым не настраиваете людей друг против друга?

Нет, я просто стимулирую их урегулировать свои разногласия самостоятельно. Менеджеры не могут предотвратить возникновение споров и разногласий между сотрудниками. И руководителям далеко не всегда стоит бросаться исполнять роль арбитров.

Попробуйте стать волшебником

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

Однажды, когда мой проектный менеджер был в отпуске, мне пришлось спуститься из своей башни из слоновой кости и временно принять на себя его обязанности. В раздраженном состоянии и с тяжелым вздохом я собрал членов команды на короткое совещание. Мы быстро прошлись по всем позициям, которыми они занимались, я указал им на несколько рисков, связанных с текущими приоритетами, предложил ряд идей для возможного решения и сказал им расходиться. Через пару дней я решил проверить, как у них идут дела, и мы проделали ту же процедуру. Мне никогда не хотелось быть менеджером на полную ставку, поэтому я стал «одноминутным менеджером» (термин предложен Кеном Бланшаром [Blanchard, Johnson 1982]).

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

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

Выбирайте волшебников, а не политиков

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

Многие менеджеры, полагающие, что они обладают «даром управления людьми», часто вообще ничего не знают об этом предмете. Они никогда не читали «Сначала нарушьте все правила», «Человеческий фактор», «Двадцать один неопровержимый закон лидерства» или другие замечательные книги о лидерстве. Они предпочитают тратить свое время на всевозможные обсуждения, совещания, составление документов и неформальное общение с сотрудниками. Как правило, эти менеджеры свято верят, что они и так все знают. Но чтобы знать все, нужно с головой уйти в микроменеджмент.

Мне никогда не хотелось быть менеджером. Мне нравится создавать. И когда кто-нибудь подходит к моему рабочему столу, чтобы обсудить какую-либо проблему, я до сих пор иногда думаю: «Ну почему надо меня беспокоить по этому поводу именно сейчас?» Но я действительно прочитал необходимые книги по менеджменту. И продолжаю активно учиться быть руководителем (набивая себе шишки). Поэтому время от времени я снимаю наушники и мою шляпу волшебника, улыбаюсь сотрудникам, предлагаю несколько идей, чтобы сориентировать их в правильном направлении (при этом молюсь, чтобы это направление действительно оказалось правильным), и говорю им, что остальные проблемы они должны решить сами. После того, как мне удается таким образом временно от них отделаться, я вновь надеваю наушники и шляпу и напоминаю себе, что надо в конце того же дня вернуться к тем же вопросам и удостовериться, что все идет хорошо.

Расширение полномочий в сравнении с делегированием

Термин «наделение полномочиями» часто используется в сочетании с делегированием, но между ними есть существенная разница. Делегирование обычно представляет собой передачу каких-либо функций (при этом ответственность за результаты выполнения обычно сохраняется за делегирующим менеджером). Расширение полномочий – нечто большее, чем просто делегирование. Оно подразумевает, что делегирующий менеджер готов поддержать инициативы данного сотрудника, сопряженные с риском, а также содействовать его личностному и культурному росту [Quinn, Spreitzer 1997]. Некоторые говорят, что, передавая сотруднику полномочия, мы тем самым признаем, что он уже пользуется в организации серьезным влиянием [Fox 1998].

Лучший лидер – такой, о существовании которого люди едва догадываются. ‹…› Когда его работа оказывается сделанной, а цели – достигнутыми, люди говорят: «Мы сделали это сами».

Лао-цзы

Результаты исследований показывают, что существует много причин расширять права и полномочия сотрудников. Это обычно повышает их удовлетворенность и качество жизни на работе. В большинстве организаций повышается продуктивность и уровень сервиса. В результате осуществленных инициатив по наделению сотрудников более широкими правами в половине исследованных компаний повысилась прибыльность и конкурентоспособность [Bowen, Lawler 1995: 75]. И наконец, в качестве непосредственного результата расширения полномочий сотрудников называют рост удовлетворенности клиентов и снижение текучести кадров. И тем не менее я отнесусь с пониманием, если вы похожи на меня: столь же упрямы, неразумны и намеренно не обращаете внимания на эмпирические данные.

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

Без распределенного контроля снизу-вверх сложные системы, к которым относятся и Agile-организации, просто не работают. В Советском Союзе система потерпела крах не из-за недовольства потребителей или неудовлетворенности работников. Она развалилась, потому что ее стало невозможно поддерживать в рабочем состоянии. Поэтому, если вам и в XXI веке хочется быть корпоративным диктатором вроде Генри Форда, вы все равно будете вынуждены расширять права и полномочия сотрудников хотя бы для того, чтобы ваш бизнес оставался на плаву.

Как всегда в таких случаях, это легче сказать, чем сделать. Хотя в некоторых компаниях наделение сотрудников полномочиями вошло в привычку, во многих других организациях (и других культурах) эта практика потребует серьезных культурных изменений. Крупные трансформации лучше осуществлять через серию небольших последовательных изменений. Однако программы по расширению полномочий сотрудников зачастую не дают мгновенных результатов, что порой приводит к преждевременной приостановке таких программ [Caudron 1995: 28]. В следующих разделах этой главы мы увидим, что с этим можно сделать.

Уменьшайте свой страх, повышайте свой статус

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

Вот важное сообщение для таких менеджеров:

Передача полномочий сотрудникам не ведет к понижению вашего статуса. Наоборот: скорее всего, ваш статус повысится.

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

Гуру менеджмента Джон Максвелл однажды написал: чтобы стать незаменимым, нужно научиться быть заменимым [Maxwell 1998: 126]. Конечно же, это гипербола, и многое зависит от того, как смотрит на вещи ваш собственный руководитель. Но по своему опыту я видел, что восприятие руководством моей ценности как менеджера сильно коррелировало с моей способностью добиваться результатов, позволяя людям делать то, что мне от них нужно, не выполняя при этом работу лично.

Сложная система – это не игра с нулевой суммой. Усилия по повышению благосостояния бедных стран не снижают благосостояния богатых стран. Европейские поселенцы в Америке не отбирали рабочие места у индейцев (хотя боюсь, что они отобрали у них много чего другого). И мой «социальный капитал» в Twitter или LinkedIn не снижается от того, что я хвалю или рекомендую своих друзей и подписчиков. Наоборот, мой рейтинг в сетях зависит от того, насколько охотно я поддерживаю других.

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

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

Выбирайте правильный уровень зрелости

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

Низкий уровень

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

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

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

Средний уровень

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

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

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

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

Высокий уровень

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

Изменить культуру организации таким образом, чтобы она соответствовала данной категории, настолько трудно, что для большинства компаний это вообще невозможно. Те немногие, кому это удается, обычно с самого начала создавались с таким прицелом. Легче построить скоростной корабль с нуля, чем на ходу переделывать крейсер «Queen Mary 2» в яхту на полпути между Гренадой и Барбадосом. Точно так же проще агрессивно отобрать в стартап обладающих соответствующим менталитетом и профессионализмом сотрудников, чем пытаться изменить ментальные установки сотрудников крупной компании. Если вам повезло и вы запускаете новую компанию или новый бизнес с нуля, возможно, вам стоит с самого начала стремиться к самой широкой передаче прав и полномочий. Просто убедитесь, что вы отбираете людей, чей профиль соответствует столь высокому уровню предоставляемых полномочий.

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

Выбирайте правильный уровень полномочий

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

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

Для каждого вида деятельности можно выделить семь уровней полномочий:

• Первый уровень: руководство через конкретные указания. Вы принимаете решения и доводите их до сведения подчиненных. (На самом деле это пока никакая не передача полномочий.)

• Второй уровень: продажа идей. Вы принимаете решение, но даете его обоснование, «продавая» эту идею сотрудникам.

• Третий уровень: консультирование с сотрудниками. Прежде чем принять решение, вы просите людей высказать свое мнение. При этом вы ясно даете понять, что окончательное решение остается за вами.

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

• Пятый уровень: вы в роли советника. Вы влияете на сотрудников, сообщая им свое мнение по данному вопросу. Но окончательное решение принимают они.

• Шестой уровень: информирование. Вы разрешаете команде самостоятельно принять решение. При этом вы заранее сообщаете им, что после было бы желательно (но необязательно), чтобы они проинформировали вас, почему они пришли именно к такому решению.

• Седьмой уровень: делегирование. Вы предоставляете команде самой разбираться с проблемой, а сами тем временем идете развлекаться (или используете это время для управления системой).

Уровни 1, 2, 4 и 5 соответствуют четырем лидерским стилям, о которых идет речь в теории ситуационного лидерства. Но версия с семью уровнями мне представляется более завершенной и более полезной, поскольку она не останавливается на пятом уровне.

В зависимости от вида деятельности или от темы вы можете варьировать эти уровни. Например, в ходе моего последнего проекта…

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

• Я продал свою бизнес-модель, включая какого типа клиенты нам понадобятся, тем людям, которых я отобрал для участия в своем проекте.

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

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

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

• Мне было все равно, кто что делает в моей команде, но время от времени я интересовался, какие решения они принимают, чтобы убедиться в их правильности.

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

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

Как выбирать уровень полномочий?

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

Настоящий ответ состоит в том, что вам некому перепоручить решение вопросов, связанных с передачей сотрудникам прав и полномочий. В отношении каждой обязанности и в отношении каждого сотрудника вы должны спросить себя: «Могу ли я поручить ему это дело?» Иногда подобрать правильный уровень передаваемых полномочий у вас не получится, а иногда все пойдет как по маслу. Но по крайней мере вы многому научитесь!

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

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

А что если уровни компетентности сотрудников сильно отличаются?

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

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

Тем не менее если вы считаете, что компетентность Сэма позволяет выполнить работу хорошо, а компетентность Макса пока нет, то будет только справедливо, если вы объясните почему. Возможно, Макс еще не принимал участия в таком большом количестве проектов или у Макса во время работы на предыдущем проекте было много проблем. Вы должны быть справедливы, но честны. Вы должны четко объяснить Максу, что он должен cделать, чтобы заслужить такие же права, как у Сэма.

Насколько возможно, вы должны предоставлять всем сотрудникам одинаковые права. Но я предпочитаю не давать сотрудникам (или командам) одинаковые полномочия, если их уровни компетентности существенно отличаются. В противном случае это будет моментально интерпретировано более компетентными сотрудниками как несправедливость. Политкорректность оказывает плохую услугу как новичкам, так и экспертам [Hunt 2008: 26]. Если мне приходится выбирать из двух зол, я выбираю лояльность по отношению к наиболее компетентным сотрудникам.

Кому передавать полномочия – командам или отдельным сотрудникам

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

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

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

В вышеописанном проекте были реализованы несколько вариантов распределения полномочий:

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

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

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

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

Иллюстрацией первого варианта может служить описанная мной ситуация, когда полномочия владельца продукта осуществлялись мной и еще одним сотрудником.

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

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

И наконец, примером реализации четвертого варианта было назначение одного сотрудника ответственным за развертывание релизов продукта у клиента. При этом мне было безразлично, кто конкретно будет этим заниматься.

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

Но, как и всегда, все зависит от конкретных обстоятельств.

Чек-лист для делегирования

В своей книге «За закрытыми дверями» (Behind Closed Doors) Джоанна Ротман и Эстер Дерби приводят удобный чек-лист, который можно использовать при делегировании задач[36]. Я добавил к этому перечню несколько дополнительных вопросов, чтобы учесть разные уровни зрелости и уровни полномочий, а также индивидуальные особенности команд и сотрудников.

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

2. Умеют ли сотрудники должным образом распоряжаться предоставляемыми им полномочиями и обладают ли они необходимой для этого дисциплиной?

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

4. Решили ли вы для себя вопрос, кому в данном случае следует предоставить полномочия – отдельным сотрудникам или команде в целом?

5. Вы делегируете большую часть работы?

6. Достаточно ли у сотрудников умений и навыков, чтобы справиться с этой работой?

7. Созданы ли все организационные условия, чтобы сотрудники могли выполнить данную работу

8. Располагают ли ваши сотрудники необходимыми инструментами, чтобы добиться успеха?

9. Понимают ли они, как должен выглядеть конечный результат?

10. Вы установили необходимые ограничения, касающиеся выполнения работы (включая бюджет, сроки, доступные ресурсы и требуемое качество)?

11. Известен ли сотрудникам крайний срок, когда работа должна быть завершена?

12. Понимают ли они, как должны выглядеть результаты выполнения отдельных этапов?

13. Знают ли они, как часто необходимо информировать вас о ходе работы (выполнении промежуточных этапов)?

14. Если им понадобится помощь, смогут ли они обратиться к вам (или другому сотруднику) за получением необходимого коучинга или менторства?

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

Если хотите, чтобы что-то было сделано, наберитесь терпения

В научно-фантастическом фильме «Пятый элемент» фигурирует персонаж по имени Зорг, коварный и безжалостный фабрикант оружия, которому постоянно приходится сталкиваться с некомпетентностью своих ассистентов. Ближе к концу фильма Зорг в состоянии фрустрации, вызванном их очередным провалом, сам берет в руки оружие и говорит: «Если хочешь, чтобы что-то было сделано, сделай это сам». Это одно из моих любимых мест в этом фильме. В течение своей карьеры я произносил те же слова десятки раз.

Профессор и исследователь Кеннет Томас сказал бы, что Зорг попал в «ловушку микроменеджмента»:

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

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

Вы должны рассматривать делегирование полномочий как инвестицию [Rothman, Derby 2005: 97]. Чтобы вернуть вложенные средства, требуется какое-то время, а до этого момента вы будете нести финансовые издержки, тратить время, энергию и, возможно, временами испытывать отчаяние. Ситуация, когда вы сами начинаете выполнять работу прежде, чем ваши сотрудники смогли выполнить ее самостоятельно без вашего контроля, похожа на то, как если бы вы забрали свои деньги из банка до того, как вам начислили проценты. Бесполезные усилия, связанные с передачей полномочий с последующим возвращением их самому себе, ни к чему, кроме чистых потерь, не приводят. Другими словами, решение заключается в том, что «если вы хотите, чтобы что-то было сделано, наберитесь терпения».

Если вы делегировали задачу сотруднику и что-то пошло не так, правильным вопросом будет: «Что я сделал неправильно?» Может быть, вы недостаточно ясно объяснили задачу. Или не настроили ограничения. Или не было никого, кто мог бы провести коучинг данного сотрудника. Возможно, вам следовало выбрать иной уровень передаваемых полномочий. Или же задача должна была быть делегирована команде, а не отдельному сотруднику. После того как делегирование задачи привело к нежелательным результатам, не снимайте с этого сотрудника ответственность за ее выполнение. Вместо этого возьмите на себя ответственность за то, как вы ее делегировали. Возможно, ваш бизнес требует, чтобы вы были таким же коварным и беспощадным, как Зорг. Но все равно ни в коем случае не берите оружие в руки сами.

Сопротивляйтесь своему менеджерскому сопротивлению

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

Топ-менеджер был одновременно и прав, и неправ. Оглядываясь назад на случавшиеся изредка в нашей компании крупные финансовые и технические катастрофы (например, когда мы вдруг начали раздавать на своем сайте бесплатные телевизоры или сделали почтовую рассылку клиентам, содержащую ссылку на сайт нашего конкурента), я в некоторых случаях могу указать тот пункт из чек-листа для делегирования, которому в свое время не было уделено достаточно внимания. Иногда задача была слишком рискованной, и ее следовало делегировать не одному сотруднику, а всей команде. В некоторых случаях следовало достичь с командой предварительного консенсуса относительно способа решения, а не просто делегировать задачу целиком. Были случаи, когда я заранее не убедился, что навыки сотрудника, которому поручается задача, позволят ему с ней справиться, либо я недостаточно четко объяснил, как должен выглядеть желаемый конечный результат. А иногда рядом просто не оказывалось коуча, который мог бы помочь сотруднику с данной работой. Но в любом случае топ-менеджер был неправ, утверждая, что я не должен был делегировать те проваленные задачи. Единственное, в чем он был действительно прав, – ответственность за результат лежала на мне, и мне было необходимо в будущем не допускать возникновения подобных проблем. Короче говоря, я был не глуп, а беспечен. (Или, может быть, наивен. Не могу решить, какой вариант хуже.)

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

Когда топ-менеджмент оказывает на вас давление, чтобы вы лично занялись какой-то проблемой, всегда старайтесь сопротивляться соблазну все сделать самому. Вам следует осознанно подходить к выбору метода делегирования. Распечатайте чек-лист и проверьте каждый пункт в применении к своей ситуации. Затем покажите результат своему руководству. Когда начальник требует от вас взять ситуацию под контроль, обычно он не имеет в виду, что вам следует все сделать лично. Все, что ему нужно, – убедиться, что вы в состоянии управлять группой людей и получить качественный результат. Вашему руководителю все равно, каким способом эти результаты будут достигнуты. Ему просто нужны результаты. Способы их достижения выбираете вы. (А можете и перепоручить их выбор!)

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

Не забывайте про десять внутренних потребностей людей

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

Лучший способ решить эти проблемы – увязать наделение полномочиями с десятью внутренними потребностями людей. Сначала необходимо выяснить, в чем состоит внутренняя мотивация ваших сотрудников (см. «Десять базовых потребностей членов команды» в главе 5). Например, если одна из базовых потребностей конкретного сотрудника – это порядок (потребность в стабильной обстановке), вы можете делегировать ему виды деятельности, соответствующие этой потребности, например поддерживать Wiki-страницы, где документируются применяемые вашей компанией процессы. А другой сотрудник может быть ориентирован на определенный набор идеалов (потребность в социальной справедливости). В этом случае вы можете предложить, что компания внесет небольшую сумму на счет любой благотворительной организации, которую он укажет, при условии, что его проект останется в рамках бюджета.

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

Мягко влияйте на рабочую среду

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

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

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

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

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

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

Доверие

В литературе по менеджменту и лидерству доверие – одна из наиболее часто упоминаемых тем. Доверие между двумя людьми работает в обоих направлениях. Я могу решить доверять вам, а вы – мне, но одно от другого не зависит. В ситуации с менеджером и несколькими сотрудниками можно определить четыре типа доверительных отношений (рис. 7.2): 1) доверие команде; 2) доверие со стороны команды; 3) доверие членов команды друг другу; 4) доверие самому себе. Все эти типы отношений описаны ниже.

Доверяйте своей команде

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

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

Если член команды приходит к вам и просит сделать нечто, что вы уже делегировали другому сотруднику, объясните ему, что теперь этими вопросами занимается другой человек. Поясните, что доверие должно быть транзитивным. Если сотрудник A доверяет менеджеру M, а менеджер M доверяет сотруднику B, то по общему принципу сотрудник A должен доверять сотруднику B. Никогда не подрывайте доверие к сотруднику B, принимая решения вместо него, а тем более за его спиной!

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

Заслужите доверие своих сотрудников

Вы заметили, что я не стал называть этот раздел «Сотрудники должны доверять своему менеджеру». Доверие необходимо заслужить. А заслужить его можно, всегда выполняя свои обещания [Anderson 2004: 41].

Когда я говорю, что мы обсудим проблему позже, я действительно возвращаюсь к обсуждению этой проблемы. Если я обещаю прислать документ по электронной почте, я присылаю этот документ. А если я кому-нибудь говорю, что он полностью отвечает за результат, то я воздерживаюсь от вмешательства и занимаюсь своими делами, если только этот сотрудник не попросит моей помощи прямым текстом.

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

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

Убедитесь, что ваше поведение как менеджера предсказуемо приятно, и я уверен, что у вас не будет никаких проблем с завоеванием доверия окружающих.

Помогайте людям доверять друг другу

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

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

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

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

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

Доверяйте себе

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

В результате у меня возникла мысль предложить следующую альтернативную формулировку:

Вы сможете доверять другим, только если сначала будете доверять самому себе.

В своей книге «Искусство управления IT-проектами»[38] Скотт Беркун объясняет, почему вера в себя так важна [Berkun 2008: 256]. Вы должны верить в себя и доверять своему разуму и здравому смыслу, даже если остальные с вами не согласны. Вы можете изменить свое мнение только в случае, если стали известны убедительные новые факты, а не под давлением других людей. Когда вы занимаетесь чем-то, во что не верите, вы подрываете свое доверие к самому себе. Человек, привыкший полагаться на себя, доверяет своему мнению, но позволяет новой информации изменить его.

Уважение

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

Уважайте людей, просите их давать обратную связь

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

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

По данным еще одной научной работы, обобщившей двадцать лет исследований в этой области и результаты 60 000 интервью при увольнении, 80 % текучки можно связать с неудовлетворительными отношениями с непосредственным руководителем[39].

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

Менеджеры должны делать все, что в их силах, чтобы пресекать неуважительное, грубое поведение в своих организациях [Stellard 2007: 65]. Хороший руководитель подает пример своим сотрудникам и никогда не запугивает, не унижает, не снисходит, не ведет себя высокомерно, не скупится на похвалы, не хлопает дверьми, не стучит кулаком по столу, не использует бранные слова, не грубит, не принижает людей в присутствии других. В его оценках не преобладает критика, он не кричит на людей, не врет и не говорит «полуправду», сам не нарушает правила, не любит ставить сотрудников в неудобное положение, не демонстрирует собственное превосходство, не делает сексистских замечаний, не дает волю своим предубеждениям, не придерживает значимую информацию, не прибегает к неуместному юмору, на устраивает истерик в ходе совещаний, не присваивает себе чужие заслуги, не мешает карьере других. У него нет любимчиков, он не злоупотребляет сарказмом, намеренно не игнорирует и не изолирует сотрудников, не ставит неосуществимые цели и не устанавливает невыполнимые сроки, не сваливает на подчиненных ответственность за свои просчеты, не подрывает чужой авторитет, не раскрывает чужие секреты, не распространяет сплетни или слухи, не дает понять, что кругом одни идиоты, не использует страх в качестве мотиватора, не мстит, не перебивает подчиненных, готов выслушать мнение других, не требует совершенства и не нарушает данных им обещаний. Естественно, это далеко не исчерпывающий список тех действий, которых вам лучше избегать [Kaye, Jordan-Evans 2008: 97–99].

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

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

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

• Что мне следует прекратить делать?

• Что мне следует начать делать?

• Что мне следует делать по-прежнему?

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

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

Добейтесь уважения сотрудников, давая им обратную связь

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

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

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

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

Резюме

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

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

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

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

Подумать и сделать

Посмотрим, сможете ли вы применить некоторые идеи из этой главы в своей компании:

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

• Сколько менеджеров находится в вашем подчинении? Они скорее политики или волшебники?

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

• Оцените всех сотрудников, входящих в вашу команду. Как бы вы охарактеризовали их уровень зрелости? Как низкий, умеренный или высокий? Что можно сделать, чтобы повысить этот уровень?

• Вспомните пример разногласий, которые были у вас с командой, или пример проблемы с принятием какого-либо совместного решения. Какой уровень полномочий был необходим для этого? Ваши сотрудники понимали, почему необходим именно такой уровень полномочий?

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

• Подумайте о топ-менеджменте, а также о других отделах компании. Все ли из них поддерживают ваш подход к расширению полномочий сотрудников? Если нет, то что вам следует в этой связи предпринять?

• Вспомните о четырех типах доверия. Все ли типы доверия между сотрудниками присутствуют? Есть ли люди, которые не полностью доверяют друг другу? Что можно сделать, чтобы исправить положение?

• Время от времени задавайте членам своей команды следующие вопросы: «Что мне следует прекратить делать?», «Что я должен начать делать?», «Что мне следует делать по-прежнему?».

Глава 8 Осмысленное лидерство и управление

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

Ричард Докинз, биолог-теоретик,популяризатор науки (род. 1941)

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

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

Игра «Жизнь»

Мы начнем наше исследование ограничений с простой игры без игроков, которую в 1970 году придумал английский математик Джон Конвей. Игра называется «Жизнь» и разворачивается на поле, размеченном на квадраты. У живущих в этом пространстве клеток может быть до восьми соседей, включая диагонали. Клетки рождаются, живут и умирают в соответствии с тремя правилами:

1. В клетке зарождается жизнь, когда живы три соседние клетки; иными словами, рождение происходит при наличии достаточных ресурсов.

2. Клетка остается живой при условии, что живы две или три ее соседки, что можно интерпретировать как наличие достаточных ресурсов для продолжения ее существования.

3. Клетка умирает или остается мертвой во всех остальных случаях, что соответствует перенаселенности (слишком много соседей) или нехватке ресурсов (слишком мало соседей).

Правила непрерывно применяются ко всем клеткам одновременно. В результате возникает последовательность поколений системы, а пассивному игроку остается только потрясенно наблюдать за возникновением замысловатых конфигураций. Мне нравится эта игра, поскольку только в ней мне все время удается выигрывать.

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

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

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

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

Классы клеточных автоматов

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

В одной из своих работ, оказавшей значительное влияние на других исследователей, Стивен Вольфрам, основатель первого научного журнала по сложным системам и проекта Wolfram Alpha («база знаний и набор вычислительных алгоритмов»), предложил классификацию клеточных автоматов, выделив четыре категории [Wolfram 1984], [Waldrop 1992: 225–226]:

• Класс I. Системы с набором правил, гарантирующих «Судный день». Они обрекают систему на вымирание через несколько поколений, независимо от первоначальной конфигурации.

• Класс II. Эти системы поживее, но не намного. Любая первоначальная конфигурация быстро вырождается в набор скучных статичных состояний.

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

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

Вас не удивит, что с точки зрения классификации динамических систем классы I и II будут упорядоченными, класс III – хаотическими, а класс IV (знаменитый пример которого – игра «Жизнь») – сложными системами. Если учесть, что сложные системы обычно интерпретируются как те, что находятся между упорядоченностью и хаосом, то системы класса IV должны располагаться между классами II и III (рис. 8.2). (Этот странный способ нумерации делает «базу знаний» Вольфрама еще более интересной.)

Ложная метафора

Ту же самую классификацию можно применить для различения видов самих сложных систем. Возьмем в качестве примера человеческий мозг. Мозг класса I – мертв. В нем ничего не происходит. Мозг класса II находится в коме или в состоянии кататонии: он молчит или проявляется в навязчивых повторяющихся движениях. Мозг класса III – это мозг сумасшедшего или эпилептика: продиктованное им поведение непредсказуемо и неуправляемо. И наконец, мозг класса IV – единственный, который жив и находится в здоровом состоянии. Во избежание обвинений, что мой мозг относится к классу III, хочу подчеркнуть, что использую данную классификацию исключительно в метафорическом смысле.

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

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

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

• Если дальше развивать эту метафору, то cложные организации располагаются где-то посередине. В сложных организациях сотрудники редко сами наделяют себя полномочиями. (Они самостоятельно не выбирают поставщиков, не нанимают на работу родственников и не платят себе зарплату). Их наделяют полномочиями менеджеры, перед которыми стоит задача найти правильный баланс между директивным стилем управления и делегированием, между «благосклонным» контролем и тем, чтобы полностью отпустить вожжи.

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

Вы не дизайнер игр

Как мы видели ранее, правила игры определяют, к какому типу систем будет относиться тот или иной клеточный автомат. Занимаясь конструированием своей игры, Джон Конвей обнаружил, что некоторые наборы правил делают систему слишком упорядоченной, в то время как другие правила делают ее слишком хаотической. Ему понадобилось некоторое время, чтобы подобрать хорошо сбалансированные правила и получить систему со сложным поведением, которая была бы не слишком упорядоченной и не слишком хаотической.

Клаус Тойбер, автор «Колонизаторов», самой популярной настольной игры всех времен, следовал примерно таким же путем. Тойбер постоянно играл в эту игру со своей семьей, вновь и вновь изменяя конфигурацию, правила, игровые карточки и фишки. Ему понадобилось четыре года, чтобы найти хорошо сбалансированный набор правил, в результате чего возникла интересная и сложная игра, в которую играют целыми семьями, полностью погружаясь в ожесточенные баталии [Curry 2009].

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

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

Но менеджеры никак не могут быть ответственными за самоорганизацию, поскольку тогда это по определению не самоорганизация. Не могут менеджеры выбирать и архитектуру системы, возникающую в итоге самоорганизации, поскольку это произойдет независимо от них [Stacey 2000a: 145].

Было бы соблазнительно думать о менеджерах как о дизайнерах игр вроде Джона Конвея и Клауса Тойбера. Например, когда менеджер ошибся с выбором набора правил, то на выходе получается система класса II (чрезмерно бюрократическая) или класса III (слишком хаотическая). Ну а если он вообще все сделал неправильно, то все заканчивается системой класса I, не подающей признаков жизни. В метафорическом смысле это интересный способ смотреть на вещи, но бессмысленный с научной точки зрения. В итоге утрачивается само понятие самоорганизующейся системы, которая развивается благодаря своей способности вырабатывать новые стратегии поведения [Stacey 2000a: 146].

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

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

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

Но… одной самоорганизации недостаточно

Однажды я смотрел фильм «Гоморра», снятый по бестселлеру Роберто Савиано [Saviano, Jewiss 2008]. В фильме жестко и без прикрас показана история людей, вынужденных жить внутри мафии и рядом с ней. Из фильма становится мучительно ясно, что происходит, если правительство неспособно обеспечить своим гражданам свободы и безопасность.

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

Самоорганизация – фундаментальное свойство любых сложных систем. Таким образом, самоорганизация сама по себе необязательно будет благом. Или, как выразился Ричард Докинз, «обстоятельства могут быть не жестокими или не добрыми, а просто безразличными – безразличными к любым страданиям».

Поскольку я сам – поклонник либертарианства, мне не очень-то приятно об этом говорить… но именно в этом заключается смысл правительств. Хорошее правительство должно обеспечивать свободы и безопасность всем гражданам. А не только тем, кто может себе позволить заплатить за это.

Но какое отношение это имеет к менеджменту? Самое прямое! Эксперт по проектному управлению Глен Эллеман так описывает необходимость менеджмента:

Есть разница между способностью к самоорганизации и способностью направлять свое развитие. Именно поэтому так важна роль менеджмента. Здесь не имеются в виду директивные методы. Речь идет о том, чтобы направить организацию по пути создания ценности. ‹…› Если самоорганизующиеся команды осуществляют обслуживание клиентов, то кто будет «управлять» одним из таких клиентов, если он по каким-то причинам не готов вести себя «цивилизованно»? Если над проектом работают несколько самоорганизующихся команд, кто будет координировать их взаимодействие? Если при распределении материальных, финансовых и иных ресурсов существует конкуренция, то кто будет осуществлять разрешение таких конфликтов?[40]

Некоторые хотят увидеть в самоорганизации нечто отличное от анархии. Но, как отмечалось выше, я не согласен с такой точкой зрения. Я считаю, что самоорганизация – это и есть анархия (которая может проявляться в сложном или хаотическом поведении системы). Команда, функционирующая по принципу анархии, вполне способна выдавать фантастические результаты. Но может оказаться, что с вашей точки зрения они не представляют никакой ценности. Следовательно, одной самоорганизации недостаточно. Необходимы по крайней мере минимальные менеджерские усилия, чтобы направить процесс самоорганизации по пути создания ценности для всех заинтересованных сторон. Санджив Огастин называет это «лидерство-лайт» [Augustine 2005]. Я называю это настройкой ограничений. (Речь действительно идет исключительно о настройке ограничений, а не о прямом воздействии на поведение людей, поскольку непосредственно возможно контролировать лишь создание системы ограничений. После чего нам остается надеяться, что в своей деятельности люди будут учитывать эти ограничения.)

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

Управляйте системой, а не людьми

Нобелевский лауреат Илья Пригожин показал, что сложные системы могут самоорганизовываться только при условии, что они отделены от внешнего мира границей. Эти границы и определяют ту «идентичность», которая будет развиваться путем самоорганизации [Eoyang, Conway 1999].

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

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

Сама Вселенная в этом смысле будет пределом. И наша планета тоже. Есть пределы у природных ресурсов. Группа людей в своем поведении придерживается ограничений, налагаемых данной культурой. Все это говорит нам о том, что имеется масса возможностей, чтобы в результате самоорганизации возникло нечто. Но вам как менеджеру необходимо добиться, чтобы вследствие выбранных вами базовых параметров системы и мер по ее защите результат оказался ценным для вас и других заинтересованных сторон. Ведь теория сложности вовсе не утверждает, что нужно просто ждать до тех пор, пока не возникнут нужные результаты. Создавая пределы и ограничения, менеджеры сильнейшим образом влияют на характер результатов, которые производит самоорганизующаяся команда [Lewin, Regine 2001]. Вы не управляете людьми. Вы управляете системой.

В биологии это называется управляемой эволюцией [Kelly 1994: 301–302]. Биотехнологические компании используют возможности эволюции при создании медикаментов. Они создают необходимое селекционное давление, а затем позволяют природе самоорганизоваться и сделать все остальное. Направляемая эволюция настраивает ограничения таким образом, чтобы природа сама произвела молекулы, которые представляют собой ценность. Направляемая самоорганизация в бизнесе – это вопрос манипулирования ограничениями таким образом, чтобы группа людей произвела результаты, являющиеся ценными для организации в целом.

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

Итак, мы определили три функции, которые менеджер должен выполнить при настройке ограничений для организации: 1) развитие системы; 2) защита системы и 3) придание системе направления (рис. 8.3).

Но как мне инициировать создание самоорганизующейся команды?

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

В главе 9 «Настройка ограничений» мы обсудим эти функции с практической стороны. Но перед этим во второй части данной главы нам необходимо разобраться с разницей между менеджментом и лидерством, а также определить, что такое предназначение.

Менеджеры или лидеры?

В книгах по менеджменту часто утверждается, что между менеджерами и лидерами огромная разница, при этом лидерство изображается как нечто более героическое, чем менеджмент. Считается, что лидеры «задают направление», в то время как менеджеры лишь «поддерживают движение в выбранном направлении» [Maxwell 1998]. Затем менеджерам дается рекомендация трансформироваться в лидеров и превратить сотрудников в искренних последователей, вместо того чтобы гнать их в нужном направлении как стадо овец. Примером таких книг может служить «От хорошего к великому»[41], в которой Джим Коллинз предлагает пятиступенчатую иерархию, где менеджеры помещены на более низкие уровни, чем лидеры [Collins 2001: 20]. Такая иерархия создает ложное впечатление, будто бы существует некая линейная прогрессия, а лидеры «более продвинуты», чем менеджеры.

Все это чепуха.

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

Правильнее сравнивать лидеров с правителями

Сет Годин утверждает, что еще никогда в истории не было момента, когда любой так легко мог стать лидером [Godin 2008]. С появлением интернета и социальных медиа любой из нас может легко обзавестись последователями. Далее Годин поясняет, что толпа становится племенем, как только у нее появляется лидер, а также что люди следуют за лидером по доброй воле. Это явление еще называется адаптивным [Marion, Uhl-Bien 2007: 151] или эмерджентным лидерством. Такое лидерство появляется по мере адаптации социальной системы. Интересно, как отмечает Годин, что люди могут следовать за разными лидерами в разных сферах жизни.

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

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

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

Очевидно, что менеджеры будут не только лидерами, но и правителями. Они единственные, кто наделен полномочиями нанимать и увольнять людей, включать их в состав команд или подразделений или исключать оттуда. Это называется правлением или административным лидерством [Marion, Uhl-Bien 2007: 153] и включает такие возможности, как приказывать людям, над каким проектом им работать, какую одежду носить в офис, а также определять, сколько сотрудники будут зарабатывать и сколько им придется платить за место на служебной парковке.

Стать лидером не является высшей целью менеджера. Его обязанность – определить для себя пропорцию между лидерством и правлением. Некоторые менеджеры склоняются в сторону лидерства, другие – в сторону правления, но всем приходится заниматься (по крайней мере отчасти) и тем и другим. Действуя как правитель, вы можете находиться на уровне 1 (руководство через указания), уровне 2 («продажа» идей) или 3 (консультирование). Действуя в качестве лидера, вы переходите на уровень 4 (достижение согласия), уровень 5 (вы в роли советника) или 6 (информирование) (расшифровка этих уровней приводится в главе 7 «Расширение прав и полномочий сотрудников»). Передача полномочий другим людям (изменение уровня их возможностей) может превратить вас из менеджера, который в основном правит, в менеджера, который по преимуществу будет лидером. Тем не менее каждому виду деятельности присущ свой уровень авторитарности. Попав на седьмой управленческий уровень (полное делегирование), вы вообще окажетесь выключенным из процесса в качестве лидера.

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

Во-вторых, менеджеру необязательно быть одновременно и правителем, и лидером. Быть хорошим правителем само по себе достаточно трудно. А если вы еще вдобавок хотите быть хорошим лидером, то вы просто создаете себе дополнительные проблемы. Судьи на поле обеспечивают условия для проведения матча. Они не пытаются быть лидерами. Они главные, но тем не менее находят в себе силы сдерживать свое эго. Это так называемое уполномочивающее лидерство [Marion, Uhl-Bien 2007: 152]. Оно подразумевает создание возможностей для других людей быть лидерами.

В своей презентации «Шаг назад от хаоса» Джонатан Уитти показывает, что часто менеджеры не будут центром социальных связей внутри данной группы. Преобладающая часть коммуникаций в такой сети проходит через эмерджентных лидеров. Задача менеджера может состоять в том, чтобы культивировать эмерджентное лидерство (посредством уполномочивающего лидерства) и следить за тем, чтобы эмерджентные лидеры соблюдали правила, установленные в рамках административного лидерства… или правления (табл. 8.1).

Смысл жизни

Теперь мы знаем, в чем состоят функции менеджеров при настройке ограничений для организации, а также чем лидерство отличается от правления. Этим можно было бы завершить данную теоретическую главу, однако прежде, чем мы перейдем к обсуждению практических аспектов, нам необходимо в деталях разобраться с темой постановки целей. В ее основе лежит понятие предназначения, и это будет последней темой, которую мы затронем в этой главе. Зачем мы здесь? Почему мы этим занимаемся? И почему мои стикеры с пометками плавают в кулере?

Вопросы типа «зачем» являются предметом бесконечных дебатов среди философов и обычно обозначаются термином телеология, обозначающим философскую дисциплину, занимающуюся вопросами целесообразности бытия и предназначения. Многие ученые избегают разговоров о предназначении. Они утверждают, что такому понятию, как «предназначение», нет места в точных науках вроде астрономии, физики и химии [Corning 2003: 172].

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

Рассмотрев внимательно, можно обнаружить, что направление и целеполагание в биологической эволюции могут возникать из множества разнонаправленных и не имеющих самостоятельных целей составных частей; при этом совершенно необязательно прибегать к виталистическим или сверхъестественным объяснениям. Эксперименты в области вычислительной эволюционной биологии находятся в соответствии с этим встроенным телеологизмом, с этой самозарождающейся «тенденцией». ‹…› Те, кого раздражает упоминание бок о бок терминов «цель» и «эволюция», могут рассматривать это свойство не столько как осознанную цель, результат планирования или проявление чьей-либо воли, сколько как «побуждение» или «тенденцию»[42].

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

В настоящее время для обозначения внутренней телеологии живых организмов биологи чаще всего используют термин «телеономия». ‹…› Он подчеркивает, что целенаправленность, которую мы обнаруживаем в природе, обязана своим происхождением эволюции и не является частью какого-либо большого замысла. ‹…› Телеономия в живых системах сегодня не вызывает особых споров…[43]

Второй причиной важности целеполагания будет наличие у сложных социальных систем дополнительного измерения – социального. В этом случае было бы неуместным игнорировать понятие цели, поскольку действия людей целенаправленны [Stacey 2000a: 14].

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

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

Судя по всему, нам удалось идентифицировать у живых систем три вида целей (организации также относятся к группе живых систем [DeGeus 1997]):

• У каждой живой системы (включая гены, организмы, людей и организации) есть внутренняя цель.

• Любая живая система может иметь внешнюю цель, которая привносится извне «владельцем» или «покровителем».

• Любая живая система может также сама выбирать для себя автономную цель.

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

Предназначение команды

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

Докинз пишет, что «цель» наших генов – репликация [Dawkins 1989]. Мы запрограммированы служить в качестве средства передачи генной информации. Но это не значит, что воспроизводство себе подобных – наша цель.

Мы можем быть благодарными своим генам, что они нас создали, но теперь, раз уж мы здесь оказались, вполне можем иметь и свои собственные планы.

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

• Целью мозга будет не сумма целей составляющих его нейронов, а результат взаимодействия между ними.

• Целью города будет не сумма целей горожан, а результат взаимодействия между ними.

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

Человеческому мозгу присуща «излишне развитая склонность повсюду видеть причинно-следственные связи, которая заставляет нас обнаруживать предназначение и замысел даже там, где их нет» [Brooks 2009]. Или, как выразился Ричард Докинз:

Нам, людям, свойственно навязчивое убеждение, что у всего есть своя цель. ‹…› Вопрос о предназначении чего-либо совершенно необязательно имеет ответ, и тем не менее это первый вопрос, который приходит нам в голову независимо от того, уместен он или нет[45].

Уместно ли на этом фоне задавать вопросы о предназначении той или иной организации?

В 1970 году Милтон Фридман, лауреат Нобелевской премии и один из самых знаменитых экономистов в мире, написал знаменитую статью под названием «Социальная ответственность бизнеса – увеличивать прибыль» [Friedman 1970]. Фридман отрицает, что у компаний есть нефинансовая или социальная ответственность. В 1980-х годах эта точка зрения воплотилась в концепцию ценности для акционеров, заключающуюся в том, что обогащение акционеров было провозглашено единственной целью бизнеса. Эта точка зрения моментально нашла свое отражение в миссиях множества компаний. Родоначальником соответствующего движения многие считают Джека Уэлча, бывшего президента General Electric. Однако недавний экономический кризис показал, что идея ценности для акционеров как единственной легитимной цели бизнеса имеет свои недостатки. (Многие компании полностью себя дискредитировали.)

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

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

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

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

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

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

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

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

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

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

Постановка внешних целей

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

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

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

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

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

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

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

Резюме

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

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

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

Подумать и сделать

Попробуйте применить некоторые идеи из этой главы в своей компании:

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

• Подумайте о своем менеджерском потенциале. Что у вас получается хорошо? Лидировать или править? На каком из этих двух стилей вы хотели бы сделать акцент? Как именно?

• Подумайте о себе как о личности. В чем состоит ваше профессиональное предназначение? Чем оно отличается от предназначения других людей?

Глава 9 Настройка ограничений

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

Чарльз Шульц, карикатурист (1922–2000)

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

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

У людей должна быть общая цель

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

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

Исследователи лидерства обнаружили, что одна из сильнейших потребностей команд – наличие видения у лидеров [Thomas 2000: 57]. Сформулировав предназначение команды, менеджер получает возможность объединить и мотивировать ее [Stallard 2007: 17], создавая тем самым разделяемую и достижимую мечту [Thomas 2000: 56–57]. И, может быть, самое главное – наличие цели позволяет группе людей «осознать контекст, в котором они функционируют» [Fox 1998]. (Будем временно считать, что «видение», «миссия», «цели» и «предназначение» обозначают одно и то же.)

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

Вывод очевиден: ответственность за постановку целей перед командами и организациями несут менеджеры. Раньше это называлось «управление по целям» (MBO, Management by Objectives). Но управление по целям имеет плохую репутацию среди экспертов по Agile-методологиям, потому что менеджеры, как правило, реализуют его из рук вон плохо. Зачастую это выглядит так: топ-менеджмент устанавливает на год «общую» цель и в декабре раздает премии, если цель была достигнута. Внесем ясность: никакого отношения к гибким методологиям это не имеет.

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

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

Я составил небольшой список возможных общих целей, который поможет вам сформулировать свой вариант:

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

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

• К концу следующего года общественное мнение признает, что наш продукт лучше, чем iPhone.

• В следующем году все члены команды пройдут профессиональную сертификацию.

• Мой сайт MyBigCalc.com станет самым посещаемым ресурсом для расчета налоговых вычетов.

• В следующем году наш продукт официально получит статус лучшего в индустрии.

• В нашем программном продукте «Ненадежный инструмент 3.5» будут решены все пользовательские проблемы, и это не отразится отрицательно на его функциональных возможностях и безопасности.

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

Чек-лист для Agile-целей

Следует ли ставить только одну цель или их может быть несколько? Скотт Беркун рекомендует записывать цели в виде упорядоченного списка [Berkun 2008: 262]. Кен Бланшар также считает, что целей может быть много, при этом каждая из них должна быть описана на отдельном листе бумаги, но не более чем в 250 словах [Blanchard, Johnson 1982: 34]. Мое же мнение состоит в том, что лучше ограничиваться одной целью, по крайней мере в теории. Поскольку практика часто вносит свои коррективы, в итоге у вас могут появиться еще одна-две дополнительные цели.

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

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

• Сформулирована ли цель достаточно просто и кратко, чтобы поместиться на небольшой карточке или стикере?

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

• Легко ли ее запомнить и воспроизвести по памяти, чтобы люди могли сообщить ее другим?

• Является ли цель достижимой и реалистичной, так что у людей есть шанс ее достичь?

• Достаточно ли цель амбициозна и стимулирующа, не слишком ли она легка в достижении?

• Предполагает ли цель осуществление конкретных действий и может ли она быть поручена конкретным сотрудникам или командам?

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

• Достаточно ли цель актуальна и полезна, чтобы люди не относились к ней безразлично?

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

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

• Способна ли данная цель мотивировать людей прилагать максимум усилий для ее достижения?

• Достаточно ли цель вдохновляющая и визионерская, помогает ли она людям увидеть общую картину?

• Базируется ли данная цель на ценностях и достаточно ли она фундаментальна, то есть привязана ли к ценностям компании, команды или личным ценностям сотрудников?

• Можно ли вернуться к данной цели в случае необходимости пересмотреть ее или внести в нее изменения?

Выбор целей в гибких методологиях сильно зависит от контекста, и в этом состоит решающее отличие от традиционной модели «управления по целям». Например: слишком банально предполагать, что все цели должны быть SMART-целями, то есть быть specific (конкретными), measurable (измеримыми), attainable (достижимыми), relevant (актуальными) и time-bound (ограниченными во времени). Если ваша цель – хорошо провести отпуск в Норвегии, то как вы собираетесь измерять ее достижение? Вы будете вести учет пережитых вами захватывающих приключений или подсчитывать, сколько раз за день вы рассмеялись? Имеет ли это значение для решений, которые вам необходимо принять в данный момент? А если ваша цель состоит в том, чтобы в следующем году победить конкурентов, то как вы собираетесь судить о том, достигнута ли она, – по размеру доходов, сумме прибыли, доле рынка, удовлетворенности сотрудников или клиентов? И какое это вообще имеет значение, если вам надо вдохновить людей сейчас?

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

Есть несколько моментов, которых при постановке целей следует избегать. Сьюзан Хитфилд описывает пять возможных опасностей [Heathfield 2010a]:

• Цели не должны создаваться для того, чтобы запугивать людей или создавать для них угрозу увольнения в случае, если не будут достигнуты.

• Не следует устанавливать цели с намерением произвести впечатление на акционеров или сторонних наблюдателей.

• Цели не должны отдавать предпочтение краткосрочным интересам в ущерб долгосрочным.

• Цели не должны требовать слишком много внимания на составление планов действий, тем самым отвлекая от непосредственной работы над их достижением.

• Целей не должно быть слишком много. Звучит как прекрасная цель сама по себе.

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

Резюмируем, чем постановка целей в Agile-менеджменте отличается от традиционной:

• Agile-цель – это цель более высокого уровня, она выше отдельных целей любых заинтересованных лиц. Это цель для всей живой системы, а не только для генерального директора или акционеров.

• От Agile-целей не требуется соответствия всем до единого критериям вроде конкретности, измеримости и так далее. Цель зависит от контекста. Иногда она должна быть вдохновляющей, а иногда – измеримой.

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

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

Рассказывайте о своей цели

Я однажды присутствовал при том, как на заседании совета директоров кто-то спросил: «Напомните, так в чем наша основная ценность на этот год?» И генеральный директор ответил, что такой ценностью в этом году были «смелые решения». Я даже и не знал, что на этот год предполагалось иметь какую-то корпоративную ценность. Дело было под Рождество. Может быть, годовые результаты были бы немного лучше, если бы чуть больше людей в компании были в курсе, что смелые решения ценятся и поощряются. Кто знает? И был ли кто-то вообще в курсе?

Позвольте мне поделиться секретной технологией, которая время от времени помогает мне достигать своих целей… Я просто всем о них рассказываю.

Я рассказываю о своих целях друзьям. Когда они знают, что это за цели, это обычно увеличивает мою решимость достичь их. Мне начинают регулярно задавать вопросы вроде «Когда выйдет твоя книга?», «Как твой новый бизнес? Клиенты уже появились?» или «Скоро станешь миллиардером?». Эти вопросы напоминают мне о целях, которые я себе поставил. Сообщая о своих целях друзьям и коллегам, я создаю ситуацию, когда окружающие мягко подталкивают меня к их достижению и следят за тем, насколько мне удалось к ним приблизиться. Это похоже на передачу управления собой внешней среде. Мне не хочется, чтобы кто-то сказал: «Я так и знал. Я с самого начала был уверен, что у тебя ничего не выйдет». Сохранение своих целей в секрете – легкий путь к неудачам. Когда эти неудачи происходят, в дело вступает когнитивный диссонанс, и вы начинаете убеждать себя, что, в принципе, и не собирались по-настоящему добиваться вами же и заявленной цели. Чтобы избежать неудачи, вы и сообщаете о своих целях окружающим. Это требует смелости.

Вообще-то этот подход не всегда применим

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

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

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

Как этого добиться?

Разговаривая с людьми о своей цели и оценивая их действия с этой точки зрения. А также задавая вопросы типа «Вы все еще не забыли, в чем состоит ваша цель?» и «Каким образом данное действие поможет нам достичь цели?». Цель работает, только если люди в организации используют ее для оценки своих действий. Это действительно их цель, если они способны назвать ее. И это никакая не цель, если к Рождеству о ней помните только вы.

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

Ну уж теперь-то я могу привязать премии к достижению цели, верно?

Не-е-е-е-е-е-е-е-е-е-е-е-е-е-е-ет! Вообще забудьте об этом!

Видение против миссии

В своей книге «Сделано, чтобы держаться» Чип Хиз и Дэн Хиз говорят о таком понятии, как «намерение командующего»:

Намерение командующего – это короткое простое заявление, предшествующее отдаче любого приказа, конкретизирующее запланированную цель и желаемое конечное состояние в результате проведения операции. ‹…› Намерение командующего позволяет обеспечить слаженные действия военнослужащих на всех уровнях, не прибегая к детальным пошаговым инструкциям со стороны офицеров[47].

Эквивалентами намерения командующего могут быть видение или миссия организации. Видение и миссия будут двумя разными, но тесно связанными способами постановки целей. Вот как они определяются в «Википедии»:

Видение описывает, какой организация хочет стать. Видение фокусируется на будущем. Является источником вдохновения. Предоставляет четкие критерии для принятия решений[48].

В миссии должно быть сформулировано фундаментальное предназначение организации. Она фокусируется на настоящем и определяет клиента и важнейшие процессы. Миссия информирует о желательном уровне эффективности организации[49].

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

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

Чтобы прояснить ситуацию (или еще больше ее запутать), я советую менеджерам не использовать термин «видение» при общении со своими командами. Видите ли, документ с названием «Видение», как правило, уже написан одним из заинтересованных лиц. Некоторые Scrum-эксперты полагают, что это ответственность владельца продукта [Sterling 2010].

А как же остальные заинтересованные стороны? Им тоже можно создавать свои собственные «видения»? С моей точки зрения, да. У каждой заинтересованной стороны есть своя цель, поэтому они могут развесить свои «видения» по всему офису (с разрешения офис-менеджера) – для меня это не будет иметь ровным счетом никакого значения. Но это не означает, что владелец продукта (или иное заинтересованное лицо) имеет право диктовать, в чем состоит цель всей команды. Команда – это нечто большее, чем сумма заинтересованных лиц. Аналогичной ошибкой было бы позволить акционерам навязать всей организации свое представление о «ценности для акционеров» в качестве ее цели.

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

Примеры организационных целей

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

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

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

Хм…

Достаточно ли кратко сформулированы эти цели? Вдохновляют ли? Они полезны? Измеримы? Мотивируют? Боюсь, что нет. А легко ли их запомнить? Если люди не могут выучить текст миссии, то как они собираются ею руководствоваться при принятии повседневных решений? Представьте себе сотрудника, которому необходимо срочно решить, выпустить ли на рынок бесполезный продукт вовремя или нормально функционирующий продукт слишком поздно. Что ему делать? Это продукт устареет прежде, чем он успеет найти и прочитать миссию компании, если она похожа на приведенные выше.

А вот интересный пример миссии:

Миссия Google – организовать всю имеющуюся в мире информацию, сделав ее доступной и удобной для использования[50].

Вот именно!

Представьте себе сотрудника Google, оказавшегося перед той же дилеммой. Что ему делать? Если программный продукт будет выпущен в бесполезном для людей виде, это явно не поможет организовывать имеющуюся в мире информацию. Миссия Google – понятная, краткая, легко запоминается, амбициозная, практичная, полезная, простая, осязаемая, волнующая и вдохновляющая. Она соответствует примерно половине критериев, и это хороший результат. Она позволяет быстро принимать решения. Да, она не отвечает на все возможные вопросы, но это и не требуется. Она четко ориентирует сотрудников в определенном направлении, и во многих случаях на ее основе они могут сами найти ответы на возникающие вопросы.

Разрешите своей команде иметь автономную цель

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

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

Большинство команд не формулирует для себя собственных целей. Но если у них все же есть цель, которая разделяется всеми, обычно она носит неформальный и неявный характер, например: «Мы САМАЯ продуктивная команда во всей организации», «Что бы ни случилось, мы хотим получать удовольствие от работы» или «Мы профессионалы. «Копировать – вставить» – не наш метод». Однако некоторые профессиональные команды способны собраться вместе и обсудить более сложные или более нюансированные автономные цели, под которыми все члены команды «подписываются» в явном виде.

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

А если у них нет автономной цели, то не вредно будет спросить их об этом. В результате у них могут появиться интересные идеи. Но никогда не отдавайте распоряжение придумать для команды автономную цель. Ведь это не будет являться самоорганизацией, не так ли?

Достигайте компромисса между вашей целью и целью вашей команды

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

Когда вы делегируете какие-то задачи, может возникнуть конфликт целей. Это происходит, если команда должна достичь целей, поставленных организацией (или в рамках определенного проекта), но команда успела самоорганизоваться и у нее появилась разделяемая всеми автономная цель. Аналогичная ситуация возникает, когда организационная или командная цель поручается индивидуальному сотруднику, у которого тоже может быть своя автономная цель.

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

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

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

Создайте список границ передаваемых полномочий

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

Когда менеджеры «наделяют сотрудников полномочиями», границы этих полномочий часто не обозначаются. В результате люди вынуждены выяснять это сами методом проб и ошибок, что приводит к эмоциональным потерям. Дональд Райнертсен называет это «поиском невидимых заборов, по которым пропущен электрический ток» [Reinertsen 1997: 107–108]. Все это напрасная трата времени и ресурсов. Хуже того, если люди постоянно натыкаются на эти невидимые заборы и их бьет током, то это лишает их мотивации. Они не имеют ни малейшего представления, где окажется очередной забор, и поэтому прекращают всякое движение.

Чтобы решить эту проблему, Райнертсен предложил список ключевых областей принятия решений [Reinertsen 1997: 107]. В сочетании с семью уровнями полномочий (глава 7) и выбором, кого наделять полномочиями – команду или отдельного сотрудника, вы получаете мощный инструмент, позволяющий налагать ограничения на предоставляемые полномочия (табл. 9.1).

Как уже упоминалось, действуя на уровнях полномочий 1, 2 и 3, вы окажетесь «правителем», поскольку именно вы будете принимать окончательные решения. В колонке «Кто (команда/отдельный сотрудник)» указывается команда или сотрудник, которых вы хотите вовлечь в принятие решений. На уровнях 4, 5 и 6 ваше намерение состоит в том, чтобы выполнять роль лидера, предлагая направления работы, но оставляя принятие решений другим. В этом случае в последней колонке вы указываете, каким командам или сотрудникам вы делегируете принятие окончательных решений.

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

Выберите правильный менеджерский угол зрения

Метафора упорядоченных и хаотических организаций (глава 8) полезна при выборе правильного подхода к менеджменту. Сталкиваются ли люди в организации с большим количеством правил? Или вообще не подозревают, что какие-то правила существуют? Жалуются ли на бюрократию? Или недовольны тем, что вокруг них постоянно возникают все новые и новые проекты? Боятся ли нарушать правила? Или умоляют, чтобы были введены дополнительные? Они неохотно берут на себя обязательства, потому что организация не разрешает им делать работу «по-своему»? Или и так все делают «по-своему», раздражая тем самым клиентов и постепенно уничтожая бизнес?

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

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

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

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

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

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

Защищайте людей

До сих пор я в основном обсуждал развитие самоорганизующихся команд и способы направить их к нужной цели. Но не стоит забывать о том, что людей и ресурсы необходимо защищать…

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

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

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

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

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

Но как выяснить, что с кем-то обращаются плохо?

Я совсем не психолог. Но по личному опыту знаю, что вряд ли поможет, если вы спросите кого-нибудь: «С вами тут хорошо обращаются?» Поскольку в этой ситуации любой, даже мальчик с синяком под глазом, тут же ответит: «Да, никаких проблем». В некоторых организациях есть психологи, к которым сотрудники могут обратиться со своими личными проблемами. Но и в моей школе был психолог. И, конечно же, я ни разу с ним не разговаривал. На что они рассчитывали? Что я сам зайду к нему в кабинет и скажу «Добрый день, просто зашел сказать, что расстроен, потому что одноклассники раздавили пакет шоколадного молока у меня в портфеле»?

Мне кажется, что есть два подхода, которые могут сработать. Первый состоит в том, чтобы спросить: «Есть ли у вас здесь друзья и кто они?» В школе я не смог бы ответить на этот вопрос (если бы кто-то из учителей побеспокоился задать его), потому что, по правде говоря, друзей у меня не было. Внимательно понаблюдайте, способен ли сотрудник сразу назвать пару фамилий, не потея при этом и не проявляя других признаков нервозности. Безусловно, отсутствие друзей на работе совсем необязательно означает, что происходит нечто ужасное. Но вы могли бы начать, продемонстрировав искренний интерес к человеку: «Наверное, все нормально, но почему бы нам вместе не пообедать и не поговорить о работе и связанных с нею делах?» Для кого-то это может оказаться очень важным. Про себя я точно знаю, что, если бы ко мне в свое время отнеслись по-человечески, я бы пошел на контакт.

Второй подход заключается в том, чтобы спросить других людей. Конечно, в свое время я мог бы продолжать вводить учителя в заблуждение и назвать в качестве друзей одноклассников, настроенных ко мне нейтрально. Но в этом случае учитель мог бы спросить: «А к другим ученикам в классе относятся хорошо?» или «Кому из детей в вашем классе приходится трудно?». Многие другие дети знали о моем униженном положении в классной иерархии. Но их никто никогда об этом не спрашивал. Поэтому мне и приходилось проводить время в раздевалке, стирая своей футболкой следы шоколадного молока со страниц учебников.

Но у вас-то есть выбор. Вы можете задавать вопросы.

Между прочим, сейчас обо мне не стоит беспокоиться. Я научился так огрызаться, что мало не покажется.

Защищайте ресурсы, находящиеся в общем пользовании

Когда я писал этот раздел, я работал в большом открытом офисе компании ISM eCommerce на заводе Неллефабрик в Роттердаме (фото 9.1). В этом офисе, одном из первых в Европе с открытой планировкой, работают около 100 человек. Даже сейчас, через 80 лет, любители архитектуры со всего мира приезжают посмотреть на этот офис, пофотографировать его и сделать зарисовки. Я и сам не раз махал им рукой.

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

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

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

Исследования показывают, что необходимо четыре компонента, чтобы совместное использование не приводило к исчерпанию общедоступных ресурсов [Van Vugt 2009: 42]:

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

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

• Идентичность, или потребность в социальной принадлежности, включающей всех участников, улучшает и расширяет ощущение принадлежности к сообществу и снижает конкуренцию.

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

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

Требования к качеству

Я не святой. В программных продуктах, за которые мне приходилось прямо или косвенно отвечать, бывали ужасные проблемы с качеством. Нет, я не был непосредственно виноват в том, что электронное сообщение было отправлено 1 000 000 адресатов вместо 10 000 зарегистрированных пользователей. И это не я повредил базу данных с адресами нескольких тысяч интернет-покупателей, в результате чего их приобретения не смогли быть доставлены. Я также не имел никакого отношения к ошибке программирования, которая позволяла 9 из 10 участников лотереи выигрывать основной приз. Я с удовольствием расскажу вам о совершенных лично мной ошибках (разумеется, при условии, что вы расскажете мне о своих).

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

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

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

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

Заключите общественный договор

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

Но что они получат взамен? Почему люди должны подписаться на ваше видение? Какой для них в этом смысл? Только зарплата?

Израэл Гат описывает, как он использует идею общественного договора, чтобы зафиксировать обязательства менеджера по отношению к сотрудникам:

Команда, моя основная цель на долгие годы – сохранить команду и ее профессиональные знания для нашей компании и ее клиентов. Мы достигнем этой цели, нарастив профессионализм как разработчики ПО до такого уровня, что возникшие в результате этого преимущества перевесят негативные последствия текущего финансового кризиса. ‹…› Независимо от того, собираетесь ли вы в будущем работать в нашей компании или нет, я признаю вашу потребность в профессиональном развитии и беру на себя обязательство инвестировать в ваше обучение/тренинги[51].

В этом общественном договоре Израэл Гат описывает не только свою миссию (отчасти), но и свои обязательства по отношению к членам команды.

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

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

Мы заканчиваем обсуждение темы настройки ограничений. В главе 10 «Искусство создавать правила» и главе 11 «Как вырастить компетентность» мы поговорим еще об одной базовой потребности людей – потребности ощущать себя компетентными в своей работе, а также о потребности менеджеров быть уверенными, что они работают с компетентными людьми.

Резюме

Самоорганизующаяся команда должна иметь общую цель; эта цель может исходить от менеджера. Характеристики такой цели (простота, измеримость, достижимость и так далее) зависят от контекста.

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

Целесообразно разрешить команде иметь свою автономную цель. Если она есть, важно добиться компромисса между этой автономной целью и общей целью команды, которую вы поставили в качестве менеджера.

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

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

Подумать и сделать

Сможете ли вы применить некоторые идеи этой главы в своей организации?

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

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

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

• Сравните поставленную вами перед командой внешнюю цель с автономной целью команды. Возможен ли конфликт между ними? Обсудите с командой, как вы будете разрешать такие конфликты.

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

• Поставьте перед собой цель понять, как реально себя чувствуют и что думают люди в вашей команде – о своем собственном положении и друг о друге.

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

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

• Подумайте о том, чтобы заключить со своей командой общественный договор. У вас есть ожидания по отношению к членам команды. На что они могут рассчитывать с вашей стороны? Вы готовы зафиксировать это в письменном виде?

Глава 10 Искусство создавать правила

Критиковать легче, чем самому стать мастером.

Зевксис, художник (V век до н. э.)

Люди часто пытаются предотвратить будущие проблемы, вводя в организации правила примерно в таком виде: «Когда возникает ситуация X, надо делать Y». Я с готовностью признаю, что и сам был виновен в подобных попытках. Сейчас же я уверен, что создание правил менеджерами – далеко не идеальный способ обеспечить устойчивость организации.

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

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

Самообучающиеся системы

В своей книге «Невидимый порядок: Как адаптация создает сложность» (Hidden Order: How Adaptation Builds Complexity) Джон Холланд, психолог и специалист в области информатики, таким образом описывает идею, лежащую в основе исследований самообучающихся классифицирующих систем: способность сложных адаптивных систем к самообучению имеет общие закономерности [Holland 1995: 42–80].

Интерпретатор

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

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

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

Присвоение коэффициентов доверия

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

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

Возникновение новых правил

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

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

Правила в сравнении с ограничениями

Эксперт по компьютерной графике Крейг Рейнолдс в свое время обнаружил, что поведение птиц в стаях может быть смоделировано на компьютере при помощи простого алгоритма [Reynolds 1987]. Этот тип поведения, широко распространенный в природе среди разных биологических видов, возникает в результате соблюдения трех простых ограничений (рис. 10.1):

• Все особи должны двигаться в одном направлении (согласованность).

• Нельзя сталкиваться друг с другом (разделение).

• Нужно держаться вместе с группой (сплоченность).

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

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

• Договориться об общем направлении движения команды (согласованность).

• Избегать столкновений с другими членами команды, предотвращать конфликты (разделение).

• Сотрудничать с другими членами команды, не быть одиночкой (сплоченность).

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

Мы видели, что в сложных системах в основе механизмов «стимул – реакция» лежит выполнение определенных правил. К агенту поступает сообщение, оно обрабатывается в соответствии с этими внутренними правилами, и затем агент определенным образом реагирует. Правила, которыми пользуется данный агент, могут быть сформулированы в виде оператора «если – то – иначе».

Я не очень много знаю о том, как моделировать на компьютере полет стаи птиц, но уверен, что трех перечисленных «правил» явно недостаточно. Нужно написать гораздо более длинный код, чтобы виртуальные птицы, летучие мыши, рыбы и пингвины начали вести себя ожидаемым образом. Реальные правила их поведения, записанные на каком-нибудь языке программирования, с точки зрения конкретной птицы могли бы выглядеть следующим образом:

1. Рассчитать среднее положение птиц, которых я вижу.

2. Рассчитать среднее направление движения птиц, которых я вижу.

3. Если расстояние от меня до среднего положения > константы A, то нужно скорректировать направление моего движения на X градусов по отношению к среднему направлению.

4. Если расстояние от меня до какой-либо другой птицы < константы В, то нужно отклониться от нее в сторону на Y градусов.

5. Если направление моего движения отклоняется от среднего направления движения стаи больше, чем на C градусов, то нужно скорректировать мое направление на Z градусов в сторону среднего направления.

6. И так далее…

7. Повторять до тех пор, пока кто-нибудь не крякнет, что пора садиться.

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

Ошибка, которую часто совершают наивные менеджеры, такова: они пытаются в буквальном смысле «запрограммировать» сотрудников на выполнение конкретных правил. «Если ты получаешь документ этого типа, ТОГДА ты должен выполнить вот это действие» или «Если клиент сообщит об ошибке в программном обеспечении, ТОГДА ты должен инициировать эту процедуру». Но сила сложных адаптивных систем в том и заключается, что их агенты могут самостоятельно управлять созданием правил. Менеджерам следует сосредоточиться на установлении ограничений и позволить, чтобы интерпретатор в головах сотрудников включился и проявил свои возможности при решении возникающих задач. Кроме всего прочего, устанавливаемые менеджментом правила все равно не приводят к оптимальному результату. В конце концов, самый эффективный способ поставить организацию на колени – заставить людей строго следовать всем без исключения правилам и не делать ничего, кроме этого [Stacey 2000a: 59].

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

Под креативностью понимается способность решать задачи способом, отличным от установленных, или даже бросать вызов общественным нормам… В определенном смысле креативные люди бросают вызов правилам – даже те из них, кто не привлекает к себе внимание своим антисоциальным поведением. Таким образом, креативность можно воспринимать как «неспособность» подчиняться общепринятым нормам[52].

Гибкие методологии – органичный способ управлять проектами и сотрудничать с креативными людьми. В этих методологиях устанавливаются ограничения вроде «сотрудничество с клиентом обязательно», «мы готовы вносить частые изменения в продукт», «передаем клиенту только работающее программное обеспечение». Но все остальные правила выбирает и устанавливает команда: «Если из-за снегопада невозможно добраться до работы, ТОГДА мы проведем нашу еженедельную демонстрацию софта по Skype», «Если клиент попросил внести в софт изменения, ТОГДА мы создадим новую ветку в системе контроля версий» или «Если кто-то при сборке допустит ошибку, ТОГДА мы все наденем смешные заячьи ушки».

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

И в результате ваши команды утратят гибкость.

Слепая зона гибких методологий

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

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

«Википедия» утверждает, что в моей родной Голландии самый низкий в мире уровень смертности в ДТП. И тем не менее у нас проживает целых 17 миллионов человек, и в стране 136 000 километров автомобильных дорог, которые уместились на территории размером с Западную Вирджинию. При этом я точно знаю, что окружающие меня водители ничуть не умнее водителей в остальном мире. (По правде говоря, уровень смертности в ДТП в Сан-Марино, на Маршалловых и некоторых других островах еще ниже, но мы не можем конкурировать с горой на территории Италии и несколькими скалами в Тихом океане.)

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

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

• Инструкторы. Получить водительские права в Голландии можно только при условии, что вы обучались с инструктором. Просто поставить на крышу знак «За рулем ученик» или попросить отца научить водить машину не получится. Надо посетить 20 или 30 занятий с инструктором, который целыми днями ездит с учениками по городу и получает за эту привилегию огромные деньги. (Я тоже попросил бы платить мне побольше, если бы мне приходилось по сорок раз в неделю ездить по одному и тому же маршруту.) Перевод: научите людей должным образом выполнять необходимые действия. Много раз подряд.

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

• Дорожные знаки. Я думаю, что ни в одной стране мира нет такого количества дорожных знаков. Не осталось ни одного километра дорог, который не имел бы каких-нибудь аккуратно расставленных знаков, разметки, светофоров, камер или чего-нибудь подобного. (А когда идет дождь, у нас даже коров выстраивают в одном направлении.) Перевод: снижайте количество возможных проблем, предоставив своим командам интеллектуальные проактивные инструменты; заставьте их пользоваться чек-листами; создайте систему уведомлений, предупреждений, напоминаний и так далее.

• Дорожная полиция. Да, мы все ее ненавидим. Я тоже. В прошлом году я заплатил штрафов на многие сотни евро. (Предпочитаю называть эти штрафы налогом на скорость). Перевод: пусть менеджер по управлению процессами время от времени прохаживается по офису и на выборочной основе проверяет качество сделанной работы. А если качество не на уровне… тут вам решать.

• Звуковые сигналы. Это моя любимая опция. Очень важно иметь возможность предупреждать людей, что они подвергают опасности вашу или чью-то еще жизнь, – это помогает свести количество жертв к минимуму. Перевод: пусть у ваших сотрудников будет возможность посигналить или показать друг другу средний палец. Фигурально выражаясь, конечно.

• Правительство. Когда все остальное не работает, вмешивается правительство. Оно расследует, что пошло не так, вводит новые правила и ограничения и решает, кто прав и кто виноват. Перевод: роль менеджмента – устранять беспорядок, сотворенный другими.

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

Важная тема: профессиональное мастерство

Вы, наверное, заметили, что я люблю поговорить о вождении. Это свойственно всем мужчинам и, скорее всего, запрограммировано где-то в Y-хромосоме. Я радуюсь каждой возможности сесть в автомобиль и куда-нибудь поехать. И, как каждому мужчине на планете, мне кажется, что я хороший водитель – в отличие от всех остальных идиотов за рулем.

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

Я сам выбрал для себя такое поведение на дороге. И хотя некоторые идеи и правила скопированы мною у других, выучить их и всегда им следовать было моим личным выбором.

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

В книге «Шесть лет спустя: О чем не было сказано в Agile-манифесте» (Six Years Later: What the Agile Manifesto Left Out) Брайан Мэрик, один из подписантов первоначальной версии этого документа, пишет, что, к сожалению, профессиональные умения и дисциплина так и не были в нем упомянуты в явном виде [Marick 2007]. (Стоит отметить, что на второй странице среди двенадцати принципов в нем все же упоминается «постоянное внимание качеству технических решений».)

Как следствие, не увидев в манифесте прямого упоминания профессиональных умений и дисциплины, многие неверно интерпретировали это либо как отсутствие в гибких методологиях дисциплины вообще (что неправда), либо как доказательство, что тема развития умений и дисциплины в этих методологиях просто забыта. Об этом писал Скотт Эмблер в статье «Дисциплина в гибких методологиях» (The Discipline of Agile) [Ambler 2007]. Истина же состоит в том, что дисциплина имеет решающее значение в проектах по разработке ПО (как и во множестве других профессий). Многие разработчики пришли к тем же выводам, так что теперь у нас появился Манифест в защиту мастерства программирования, в котором напрямую говорится о «хорошо сделанном ПО» и «сообществе профессионалов».

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

Сторонники гибких методологий воспринимают мастерство программирования как данность.

И лишь немногие работают над совершенствованием своего мастерства.

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

Мастерство программирования не возникает в гибких методологиях автоматически. Проекты не будут успешными, если забота о мастерстве программирования сведется только к размышлениям и разговорам о нем. Менеджеры, которые хотят улучшить результаты, должны признать, что им необходимо активно работать над отношением и поведением своих сотрудников. Они должны стимулировать развитие мастерства программирования и дисциплины. Иначе… несчастные случаи неизбежны.

Положительная обратная связь

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

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

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

Звук из громкоговорителя, проходя обратно через микрофон, моментально усиливается до невыносимого визга [Gleick 1988: 61]. Высокотехнологичные компании стремятся обосноваться в Кремниевой долине, потому что там уже находится много высокотехнологичных компаний [Waldrop 1992: 17]. Команда разработчиков пользуется хорошо известными ей средствами программирования только потому, что это позволяет ей поднять скорость разработки; в результате она приобретает еще больший опыт работы с этими средствами программирования [Weinberg 1992: 11]. Моральное состояние в команде снижается, когда из нее уходят лучшие сотрудники; в результате нагрузка на оставшихся возрастает, что еще больше ухудшает их моральное состояние [Yourdon 2004: 154]. Но самоусиливающиеся циклические процессы не будут по определению нежелательными. Например, высокое качество программного продукта может снизить затраты на его поддержание и повысить производительность, что, в свою очередь, создает условия для дальнейшего повышения его качества [DeMarco, Lister 1999: 22].

Следует помнить, что слово «положительный» в названии циклических процессов – это математическая условность. Полезная обратная связь может быть нежелательной. В целом самоусиливающиеся циклические процессы будут одним из основных механизмов самоорганизации [Waldrop 1992: 34].

Положительная обратная связь становится причиной как нестабильности, так и возникновения эффекта блокировки и эффекта снежного кома. Они лежат в основе механизма, который экономисты называют возрастающей отдачей (известного также как «деньги к деньгам» или «успех притягивает успех»). Кевин Келли называл самоусиливающиеся циклические процессы третьим божественным законом [Kelly 1993: 469]. Этому закону мы обязаны как своей жизнью, так и своими несчастьями.

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

Отрицательная обратная связь

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

Увеличение содержания CO2 в крови стимулирует движение легких и учащение дыхания, что приводит к снижению содержания CO2 [Solé 2000: 90]. Когда температура в улье понижается, пчелы прижимаются друг к другу и быстро машут крыльями, в результате чего температура повышается [Miller, Page 2007: 15]. Согласно закону убывающей отдачи, рост предложения товара на рынке приводит к снижению его цены и наступлению момента, когда дальнейшее наращивание производства становится нецелесообразным [Waldrop 1992: 34]. При росте организации накладные расходы растут опережающими темпами, в то время как производительность повышается линейно; это снижает относительную экономическую отдачу [Coplien, Harrison 2005: 104]. Когда сотрудник нарушает принятые в команде нормы, та может обсудить создавшееся положение и принять корректирующие меры [Arrow 2000: 202]. А если проект идет с существенным превышением бюджетов и сроков, то по результатам технологического аудита можно запустить в системе несколько отрицательных циклических процессов и с их помощью спасти положение [Weinberg 1992: 95].

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

Типичным примером будет термостат, который измеряет температуру в помещении и соответственно включает либо отключает обогреватели. Если использовать классическую формулировку ученого-системолога Уильяма Пауэра, полученное на входе значение сравнивается с внутренним «контрольным значением» и соотношение между ними определяет последующее поведение системы. Любое использование термина «обратная связь», которое отклоняется от этой ориентированной на достижение определенной цели и основанной на обработке информации модели, в лучшем случае будет метафорическим, а в худшем – введет в заблуждение[53].

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

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

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

А разве положительная обратная связь не лучше отрицательной?

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

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

Дисциплина × умения = компетентность

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

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

Очевидно, что дисциплина важна в любой профессии. Джеральд Вайнберг описывает эффект бумеранга, который возникает, когда люди не выполняют необходимые процедуры. Сначала они пропускают какой-либо элемент процесса контроля качества, что увеличивает количество дефектов в готовом продукте, и это приводит к росту жалоб со стороны клиентов, в результате чего возникает необходимость отрываться от других проектов, чтобы решить возникшие проблемы, что ведет к возрастанию давления на команду разработчиков, вследствие чего не выполняются еще какие-либо процедуры [Weinberg 1992: 278–282]. Мы все знаем из опыта, что нарушения производственной дисциплины не ускоряют, а замедляют процесс. Это поистине порочный круг.

Мэри и Том Поппендик говорят о том же, указывая, что высокая скорость разработки невозможна, если качеству не уделяется должного внимания [Poppendieck 2007: 190]. Когда мы не сверяемся с чек-листами и перескакиваем через необходимые этапы, поначалу действительно складывается впечатление, что процесс ускорился. Но вскоре нежелательные компромиссы с точки зрения качества продукта (известные также как технический долг) доконают вас окончательно.

Вайнберг описывает шесть уровней зрелости при исполнении процессов [Weinberg 1992: 23]:

• О процессах даже не вспоминают: «Мы и не знали, что выполняем какой-то процесс».

• Нестабильные процессы: «Мы делаем так, как нам в данный момент кажется необходимым».

• Рутина: «Мы просто следуем заведенному распорядку (если только не запаникуем)».

• Направляемый выбор: «При выборе правил мы руководствуемся своим представлением о том, какие результаты они позволят получить».

• Учет предыдущего опыта: «Мы устанавливаем правила работы в зависимости от того, насколько хорошо они работали в прошлом».

• Согласованность: «Все сотрудники вовлечены в процесс непрерывной оптимизации во всех областях»[54].

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

Похожая классификация была предложена Россом Петтитом. У него уровни зрелости называются так: регрессивный, нейтральный, ориентированный на сотрудничество, операционный, адаптивный и инновационный[55]. Содержание каждого немного отличается от описанных выше, но похоже, что, как и Вайнберг, Петтит также имеет в виду именно уровни зрелости выбора и применения процессов.

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

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

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

Если нарисовать две оси, соответствующие дисциплине и умениям, то мы получим матрицу (рис. 10.4). Она позволяет в удобном виде оценивать степень проектной зрелости. Умения можно утратить с возрастом, в результате травмы или отставания от технического прогресса, а дисциплину – в результате потери мотивации или из-за отвлекающих факторов. Компетентность подразумевает как профессиональные умения, так и дисциплину, а следовательно, менеджерам надо заниматься и тем и другим.

Разнообразие правил

В своей деятельности команды руководствуются определенными правилами: как документировать требования, как предварительно оценивать работу, как фиксировать исходный код, как писать тестовый код, как разворачивать готовые решения и так далее. Кроме того, у каждого члена команды есть свой личный набор правил. Один разработчик фиксирует тестовый код в виде ветви до того, как написан окончательный код, в то время как другой откладывает свой код, пока не убедится, что все работает безупречно. Одному дизайнеру нравится использовать Visio, а другой говорит, что лучше доски и маркеров пока еще ничего не придумано. Один тестировщик документирует результаты пользовательской приемки при помощи специально созданного для этой цели инструмента, а другой пользуется простой таблицей в Google Docs. Я предпочитаю, чтобы комментарии к исходному коду были предельно лаконичными, а другим нравятся огромные простыни с максимумом подробностей.

Хорошо ли, когда люди следуют собственным правилам?

Да. Скорее нет. Может быть. Все зависит от ситуации…

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

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

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

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

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

Принцип субсидиарности

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

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

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

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

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

Пожалуйста, объясните, почему установленные вами правила более эффективны, чем те, которые установил я сам?

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

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

Восприятие рисков и иллюзия безопасности

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

В своей статье «Дорожное движение безопаснее, когда нет правил» эксперт в этой области Ханс Мондерман отмечает, что в случаях, когда на перекрестках отключали светофоры и убирали все дорожные знаки, их пропускная способность возрастала, а аварийность снижалась [Sprangers 2007]. Причина состоит в том, что при отсутствии правил и указаний светофоров люди вынуждены брать на себя ответственность и самостоятельно решать, как им безопасно миновать перекресток.

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

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

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

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

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

К счастью, разработчики программных продуктов сейчас поумнели. Они все лучше осознают, что не существует универсальных методологий. Это признает Ивар Якобсон, один из основателей унифицированного процесса, в своей состоящей из трех частей статье «Хватит процессов: давайте сосредоточимся на практике» [Jacobson 2007]. В целом лучшие результаты достигаются, когда правила создаются на месте точно под текущую задачу. К такому же выводу пришли и три других исследователя, утверждающие, что лучший способ применять Agile-методологии – адаптировать их под свои задачи [Wailgum 2007].

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

Меметика

Я пишу эту главу сразу после Рождества – одного из самых удачных примеров массового помешательства. Я всегда с нетерпением жду этого праздника, и не только из-за многочисленных возможностей вкусно поесть. Должен признаться, что мне, как и многим другим, нравятся все эти милые глупости – наряжать рождественскую елку, зажигать свечи, покупать подарки, ходить в кино, петь рождественские гимны.

Идеи, концепции, представления, теории, идеологии, массовые увлечения и моду часто называют мемами [Dawkins 1989]. Люди копируют эти единицы информации друг у друга путем подражания, через взаимодействие и обучение [Stacey 2000a: 168]. Примерами мемов будут Санта-Клаус и рождественская елка, обычай класть подарки в чулок (в Голландии мы прячем их в ботинки) и олень Рудольф. Рождение Иисуса Христа, ангелы и эльфы – тоже мемы.

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

Мемплекс – это собрание взаимозависимых мемов (рис. 10.5). Типичным мемплексом будет Рождество. А также Agile-методологии разработки ПО. Теория универсального дарвинизма показала, что мемы объединяются в мемплексы, поскольку совместное копирование осуществляется более успешно (аналогичное поведение демонстрируют гены, объединяющиеся в генные комплексы). Рождество – успешный мемплекс, потому что входящие в его состав мемы, несмотря на разное происхождение, в настоящее время усиливают друг друга, становясь практически неуничтожимыми. Олень Рудольф вряд ли выжил бы в качестве отдельного мема. Но теперь этот мем в буквальном смысле прочно привязан к Санта-Клаусу и тем самым, по всей видимости, обрел надежду на бессмертие.

Аналогичным образом Agile-практики в разработке ПО также имеют тенденцию усиливать друг друга. Рефакторинг совместим с разработкой через тестирование, пользовательские истории хорошо вписываются в еженедельные итерации, а стендапы более эффективны, если при их проведении используется доска задач. Большинство Agile-практик существовало и до возникновения Agile-методологий. Этот аргумент часто приводят люди, скептически относящиеся к гибким методологиям. Но это не имеет отношения к делу. Важно то, что возникновение Agile-мемплекса стало катализатором для лихорадочного копирования Agile-практик в массовом масштабе, который, скорее всего, был бы невозможен в любом другом случае [Kruchten 2007].

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

Означает ли это, что серьезные революции делаются сверху?

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

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

Рассматривая Agile-практики в качестве мемов, можно сделать несколько интересных наблюдений:

• Порой проще заставить людей принять несколько идей, концепций или практик разом, чем одну-единственную. (Например, обучить сотрудников Экстремальному программированию в целом, а не только юнит-тестированию, а затем немедленно приступить к адаптации Экстремального программирования в контексте данной организации.)

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

• Удаление отдельных мемов может ослабить, а то и свести на нет силу всего мемплекса. (Пример: если исключить из мемплекса коллективное владение кодом, то внедрение Agile-практик может потерпеть полную неудачу.)

• Могут существовать конкурирующие мемплексы, которые тем не менее взаимно усиливаются и нуждаются друг в друге, поскольку конкуренция между ними отвлекает внимание от других подходов. (Пример: конкуренция между Экстремальным программированием, Scrum и канбаном в рамках мира Agile привлекает внимание к Agile-брендам в целом.)

• Мемы могут иметь разное происхождение и одновременно входить в состав нескольких мемплексов. (Пример: пользовательские истории возникли как мем в рамках Экстремального программирования, но в настоящее время прочно закрепились также и в мемплексе Scrum.)

Мне представляется продуктивным рассматривать Agile-методологии в качестве мемплексов. Единственная их цель – служить катализатором копирования Agile-практик. Любой, кто утверждает, что Agile-методологии не внесли в разработку ПО почти ничего, что не существовало бы ранее, полностью упускает эволюционные преимущества объединения разных практик под одним брендом.

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

Разбитые окна

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

Идея, что проблемы со временем становятся только хуже, обязана своей популярностью теории разбитых окон. Она утверждает, что, когда люди видят явные следы беспорядка или антиобщественного поведения, это провоцирует их на нарушение общественных норм или совершение правонарушений. А это приводит к распространению криминального поведения в целом. Считается, что если бороться с самыми мелкими проявлениями антиобщественного поведения и чаще наводить порядок, то могут быть предотвращены даже более серьезные преступления [Wilson, Kelling 1982: 2–3].Некоторые ученые относятся к теории разбитых окон критически. По их мнению, корреляция здесь могла быть ошибочно принята за причинно-следственную связь и привела к неверной интерпретации результатов некоторых исследований, в том числе к ошибке в знаменитом примере с уровнем преступности в Нью-Йорке, который описан в книге «Переломный момент»[56] [Gladwell 2002]. И тем не менее существует достаточно доказательств, что верен сам принцип, лежащий в основе теории разбитых окон [Keizer 2008]. Эта теория стала логическим развитием более общей идеи, выраженной в уравнении Левина:

П = f(Л,ВС).

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

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

Какие выводы мы можем сделать из всего этого? С моей точки зрения, их два:

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

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

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

Резюме

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

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

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

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

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

Подумать и сделать

Давайте посмотрим, как применить некоторые идеи из этой главы в вашей компании:

• Нарисуйте матрицу «дисциплина – умения» для своей команды. Вы знаете, куда в этой матрице поместить каждого из своих сотрудников? Если нет, то почему? Если да, то соответствует ли данная картина вашим ожиданиям? Если не соответствует, то что можно по этому поводу предпринять?

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

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

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

• Составьте список небольших проблем, которые вас беспокоят. Занимаетесь ли вы их решением? Или вы инвестируете время только в решение крупных проблем? Может быть, вы позволяете мелким проблемам превратиться в крупные?

Глава 11 Как вырастить компетентность

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

Дон Маркис, американский юморист,журналист и писатель (1878–1937)

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

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

Но разве эти модели не ориентированы на результат?

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

Хотя в основе таких моделей лежат благие намерения, многие из них механистичны и… неизменно игнорируют тот факт, что единственной убедительной причиной, почему компании вообще совершенствуют производственные процессы, будет стремление повысить свою способность создавать ценность для клиентов и акционеров. Соответственно, многие из таких «процессно-ориентированных моделей зрелости проектов» не принимают во внимание в явном виде следующие две фундаментальные реалии: 1) организации – это одновременно не только сложные бизнес-системы, но и сложные социальные системы; 2) образцовое управление бизнес-процессами требует от лидеров способности сотрудничать друг с другом, в том числе и с точки зрения кросс-функциональности[57].

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

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

Если реальное значение имеет только эффективность, то нам недостаточно рассматривать зрелость. Необходимо взглянуть, как организации развивают свои компетенции в области бизнес-процессов[58].

Если перефразировать Роберта Мартина, «рассуждают о своей зрелости подростки, а не взрослые».

Семь методов развития компетенций

Работая над составлением плана своих выступлений на различных конференциях, я однажды решил воспользоваться услугами профессионального агента. Я отправил ему по электронной почте описание своей квалификации, историю моих уже состоявшихся выступлений на конференциях в Европе и США, информацию о книге, которую писал, а также возможности взаимодействия. Я прождал три недели, но ответа так и не получил. Затем я отправил напоминание и моментально получил ответ с извинениями и с обещанием позвонить на следующий же день. Я продолжал ждать… Через три дня я отказался от своего намерения нанять этого человека в качестве своего агента.

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

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

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

• Тестирование. Результаты тестирования подтверждают (или должны подтверждать), что кто-то проверил наличие у данного сотрудника необходимых умений и желания выполнять определенные функции – например, что данный сотрудник в состоянии поднять телефонную трубку и правильно набрать номер.

• Инструменты. Извещения и напоминания – это способ ориентировать людей на выполнение необходимых действий, удостоверяясь, что они знают, что именно им надо сделать. За час до того, как я сел писать этот раздел, я позвонил клиенту и отметил в своем ежедневнике это дело как выполненное. Я настроил систему, чтобы она напоминала мне о подобных важных делах.

• Коллеги. Давление со стороны коллег может заставить сотрудника изменить свое поведение в соответствии с нормами, принятыми в данной группе. Первый раз, когда кто-то заставляет меня ждать, я стараюсь войти в его положение и мягко напоминаю этому человеку, что все еще жду ответа. Во второй раз в тоне моего напоминания сквозит раздражение. Ну а в третий раз я просто скажу все, что я о нем думаю.

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

• Менеджеры. Задачи менеджера – лидерство и управление. Менеджер должен подавать положительный пример, а также применять санкции в случае, если кто-то повел себя во вред интересам компании – например, полностью проигнорировал запрос от потенциального клиента, чем навредил репутации компании.

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

А что если у менеджера тоже ничего не получается?

Если проблемы с компетентностью не решаются даже после того, как испробованы все эти методы, пострадают либо клиенты, либо топ-менеджмент (либо и те и другие).

Какое непосредственное отношение это имеет к профессиональному мастерству разработчиков?

Agile-манифест сам по себе – пример осознания, что одних манифестов недостаточно, чтобы решить проблемы с компетенциями в организациях, которые специализируются на разработке программного обеспечения.

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

Оптимизируйте систему в целом – на разных уровнях

В главе 4 «Информационно-инновационная система» обсуждалась проблема измерения (и даже вознаграждения) контрпродуктивных элементов внутри системы, приводящих к отрицательным побочным эффектам. В главе 9 «Настройка ограничений» мы говорили о трагедии общих ресурсов, а также о том, что в процессе самоорганизации система способна оптимизироваться только в своих собственных интересах; отсюда вытекает необходимость накладывать внешние ограничения на саму систему и направление, в котором она движется. В теории систем эти идеи обобщены в принципе субоптимизации[59]:

Если каждая подсистема, рассматриваемая отдельно, функционирует максимально эффективно, то в результате система как целое не будет функционировать с максимальной эффективностью[60].

Решение этой проблемы (и один из постулатов Lean-методов разработки ПО) – оптимизация системы как единого целого [Poppendieck 2007: 38]. Питер Друкер однажды сказал: «Что можно измерить, тем и управляют». Альтернативная формулировка того же тезиса звучит так: «Что вы измеряете, то и получите на выходе». Отсюда логически вытекает, что, если мы хотим оптимизировать целое, надо измерять целое. Таким образом, необходимо измерять систему в целом с начала до конца сверху вниз (и накладывать ограничения тоже на систему в целом), в противном случае ее неизмеряемые и неограниченные части самоорганизуются и сделают результаты целого субоптимальными.

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

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

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

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

Мы даже могли бы добавить это к Agile-манифесту в виде пятой ценности:

Предпочтение глобальных метрик локальным.

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

Оптимизируйте систему в целом – в разных измерениях

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

Давайте попробуем трансформировать треугольник и квадрат в нечто более полезное. Мы уже сделали первый шаг, когда в главе 9 разделили охват проекта на функциональные возможности и качество. Хотя они и будут двумя сторонами одной медали, тем не менее рассматривать их и управлять ими нужно по-разному.

Но анализ проектов можно продолжить и далее. То, что некоторые называют «ресурсы», представляет собой комбинацию людей и инструментов, а люди и инструменты требуют разных менеджерских подходов. Более того, Алистер Коберн утверждает, что процесс – это дополнительное измерение и в первоначальной версии треугольника оно отсутствовало [Cockburn 2003]. А Джим Хайсмит модифицировал этот треугольник, добавив в качестве дополнительного измерения (бизнес-)ценность (и поменяв остальные ограничения местами) [Highsmith 2009: 21].

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

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

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

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

Роберт Каплан и Дэвид Нортон более десяти лет назад создали знаменитую методику управления параметрами системы, известную как сбалансированная система показателей [Kaplan, Norton 1996]. Я бы просто предложил менеджерам команд разработчиков заменить предложенный Капланом и Нортоном стандартный набор из пяти параметров (финансы, клиенты, бизнес-процессы, инновации и обучение) нашими семью, которые, с моей точки зрения, полезнее в проектах по разработке ПО.

Советы при выборе операционных показателей

Правильный выбор операционных показателей очень важен. Обучаясь в школе, занимаясь спортом или искусством, люди хотят знать, каковы их успехи. Они получают оценки за свои знания в математике, языках и географии; успехи в футболе, баскетболе и теннисе находят отражение в рейтингах; точно так же существуют рейтинги книг, пьес и телевизионных шоу. Если вы не знаете, чего вам уже удалось достичь, то невозможно проверить, улучшаются ли ваши результаты. Именно поэтому, сдав квалификационные экзамены Microsoft, люди хотят узнать, чем все закончилось. Именно поэтому они ставят сенсоры на кроссовки Nike и с помощью iPod отслеживают свои результаты в беге. По этой же причине я с нетерпением жду появления ваших оценок моей книги на Amazon.com.

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

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

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

• Выставляйте одновременно рейтинги по нескольким видам деятельности. У каждого из нас есть дела, с которыми ему удается справляться лучше, чем с другими. Гораздо легче пережить унижение, получив низкий рейтинг по одному виду деятельности, если одновременно получен высокий рейтинг по другому. Точно так же сотрудники легче воспринимают критику, если ее компенсировать похвалой за какие-либо достижения в другой области. Одновременные рейтинги по нескольким видам деятельности дают возможность быть более справедливым к людям. Должны быть рейтинги, отражающие качество релиза и его своевременность, степень удовлетворенности клиента и экономию затрат при реализации проекта, соблюдение принятых в компании стандартов и проявленную командой гибкость.

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

• По возможности всегда используйте относительные рейтинги. Сравнивайте актуальные результаты команды с предыдущими («в этот раз на 15 % лучше, чем было»); с результатами других команд в вашей организации («на 20 % хуже, чем у коллег, которые занимаются проектом X») либо с другими компаниями («наши дела обстоят на 32 % лучше, чем в компании B»). Относительные показатели стимулируют команды от раза к разу повышать свою производительность, вместо того чтобы однократно достичь цели и застыть в этой точке [Highsmith 2009: 353].

• Цикл обратной связи должен быть предельно быстрым. Не должно быть большого разрыва во времени между действием и получением обратной связи в виде рейтинга или другого показателя. Это одна из причин, почему я стал вести блог до того, как начал писать эту книгу. Мне нужна была моментальная обратная связь от читателей, чтобы научиться писать лучше. Только через полтора года я почувствовал достаточную уверенность, чтобы начать писать книгу – как известно, у книг цикл обратной связи занимает гораздо больше времени.

• Используйте как опережающие, так и запаздывающие параметры. Изменения в опережающих параметрах позволяют понять, какова вероятность, что вы достигнете поставленной цели. (Пример: увеличение покрытия кода тестами может свидетельствовать о более высоком качестве продукта.) Запаздывающие параметры показывают (уже после завершения проекта), удалось ли вам достичь своих целей. (Пример: низкое количество жалоб от клиентов на ошибки уже после релиза подтверждает качество продукта.) В целом рекомендуется пользоваться обоими типами параметров [Cohn 2009: 440].

• Никогда не составляйте рейтинги сами. Ценность вашего мнения как менеджера для членов команды очень и очень низка. Пусть все и любые рейтинги – не важно, количественные или качественные – составляются не вами. Вы можете приносить благую весть, но не быть ее автором. Будьте судьей, а не прокурором.

Говоря о судьях… Признаю себя виновным (в который раз). Как и многие другие наивные менеджеры в этом мире, я виновен в том, что раз в год лично составлял индивидуальные и командные рейтинги по пятибалльной шкале. Сейчас я об этом жалею. Я считаю, что рейтинги должны составляться многократно, по разным видам деятельности и как можно оперативнее. И не мной. Пусть мир знает, что я раскаиваюсь. Больше этого не повторится.

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

Четыре ингредиента саморазвития

Мне нужно писать книгу. Но иногда совершенно нет настроения. Я бы с бóльшим удовольствием почитал свои любимые романы. Но все равно я сажусь и пишу.

Почему?

Это называется самодисциплиной.

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

Исследования говорят о том, что у студентов самодисциплина в два раза сильнее влияет на результаты выпускных экзаменов, чем IQ. Есть основания полагать, что количество прилагаемых усилий при овладении компетенциями важнее, чем талант [Jensen 2006].

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

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

2. Требуются базовые навыки тайм-менеджмента. Если вам не удается найти в своем графике время для важных дел, то вы их не сделаете. (Мне трудно находить время на занятия спортом. Всегда кажется, что чтение и работа над книгой важнее.)

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

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

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

1. Помогайте людям осознать важность решаемых задач. Объясните им, что рефакторинг очень важен. Что важен правильно поставленный контроль версий кода. Что важно личное общение. Если вы хорошо справитесь с этим, то решите первые 20 % проблем с дисциплиной.

2. Обучите сотрудников базовым навыкам тайм-менеджмента. Объясните им, чем важность отличается от срочности. Покажите им, как резервировать время для повторяющихся действий и как составлять расписание. Если они в состоянии каждый день чистить зубы, чтобы избавляться от микробов, то почему не могут каждый день проводить проверку написанного ими кода на предмет ошибок? Научив их тайм-менеджменту, вы решите вторые 20 % проблем с дисциплиной.

3. Обучите сотрудников приемам, которые позволяют не забывать важные дела. Покажите им, как создавать напоминания и превратить составление плана на каждый день в привычку. Также могут помочь методы повышения личной эффективности, описанные в книгах «Как привести дела в порядок» Дэвида Аллена[61] [Allen 2003] и «Личный канбан» Джима Бенсона. Так вы решите еще 20 % проблем с дисциплиной.

4. Покажите людям, как сделать их работу более интересной. Крис Спануоло отмечает, что удовольствие от работы – критически важный компонент мотивации [Spagnuolo 2008]. Это также одна из основных тем бестселлера «Ловись, рыбка!» [Lundin 2000]. Люди лучше мотивированы, если они в состоянии получать удовольствие даже при выполнении рутинных задач. Этим способом можно решить очередные 20 % проблем с дисциплиной.

Все это в сумме дает 80 %. А что с остальными 20 %?

Даже если люди понимают важность своих задач, у них есть время, они ничего не забывают и при этом мотивированы, все равно есть вероятность, что они не будут выполнять необходимое действие, если обнаружат, что остальные его не выполняют.

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

Вот так мне и удалось завершить эту главу, хотя очень хотелось почитать книгу Стивена Эриксона. Но для меня было важно качественно написать очередную главу. Поэтому организовал свои дела так, чтобы у меня было на это время. Я меня есть чек-лист, который гарантирует, что я не забуду сделать автоматическую проверку правописания, перепроверить примечания и ссылки, вставить уведомления об авторских правах и создать версию в PDF. Размещая посты в Twitter о своих усилиях в качестве автора, рисуя иллюстрации и форматируя главы, чтобы текст выглядел привлекательно, я мотивирую себя, поскольку все это позволяет получать от работы удовольствие.

Я также надеюсь, что мне удалось кого-нибудь вдохновить своим примером.

Менеджмент, коучинг, менторинг

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

Похоже, что руководители должны стать еще и персональными коучами:

Часть обязанностей менеджера – коучинг своих подчиненных. Это повышает их квалификацию и эффективность. Коучинг может фокусироваться на развитии либо навыков межличностного общения, либо чисто технических умений, необходимых в работе. ‹…› Вы можете провести коучинг сотрудника, у которого есть определенные проблемы с эффективностью, или же поработать над развитием у него новых умений и навыков[62].

Но есть и другие варианты…

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

В качестве линейного менеджера вы действительно обязаны обеспечить коучинг тем, кто в этом нуждается. Но совсем необязательно заниматься этим лично! Вы можете делегировать эту обязанность наиболее опытным сотрудникам, поручив им коучинг более молодых коллег с целью развить их профессиональные умения. В предыдущие столетия мастера в каком-нибудь ремесле поручали учеников своим подмастерьям. Зачастую подмастерья справлялись с коучингом лучше самих мастеров [Snowden 2010a]. На этом основании иногда возникают рекомендации использовать коучинг в основном при работе на начальных уровнях компетенций, например со стажерами [Hunt 2008: 31].

У каждого сотрудника в компании только один руководитель, но у него может быть ноль, один или даже несколько коучей для личного развития в разных областях. Вам даже не нужно быть коучем для самых опытных сотрудников. Можно делегировать и это, наняв консультанта со стороны. Вы все еще будете руководителем для всех своих подчиненных, сэкономите кучу времени, да еще и расширите полномочия некоторых сотрудников, назначив их коучами (если у них есть для этого данные) – и все это одновременно! А если в компании нет хороших коучей, вам следует их либо нанять, либо обучить [Adkins 2010].

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

Что делают лидеры компетенций? Их первостепенная задача – совершенствование технологий, применяемых организацией. Они начинают с того, что устанавливают критерии качественной разработки ПО с точки зрения архитектуры, внедрения защищенных от ошибок ревью кода, поэтапной эволюции и технической компетентности. ‹…› Они устанавливают стандарты, настаивают на ясности кода, требуют, чтобы кроме задачи выявления ошибок обзоры кода ставили перед собой цели обучения ‹…› Вероятно, самая важная роль лидера компетенций – роль учителя, который целенаправленно развивает практики, приводящие к высокому уровню технической компетентности. ‹…› Лидеры компетенций часто бывают линейными менеджерами, но линейные менеджеры не всегда становятся лидерами компетенций[63].

Здесь уместно дать один совет тем, кто ищет для себя ментора. Ментор – это нечто совершенно иное, чем коуч, хотя эти слова часто используют как синонимы. Ментор помогает человеку управлять своей жизнью или строить карьеру, при этом у него нет личной повестки дня, кроме интересов своего подопечного. Напротив, коуч имеет дело с задачами и обязанностями конкретного сотрудника, у него своя программа или методы обучения, и он сосредоточен на повышении эффективности своего подопечного [Starcevich 2009]. Будучи менеджером, вы можете назначить коуча кому-либо из сотрудников, но никакого отношения к выбору ментора вы иметь не можете. Менторы похожи на любовников и любовниц. Всегда очень интересно узнать, есть ли они у ваших сотрудников, но в целом вас это совершенно не касается.

Подумайте о сертификации сотрудников

Как и многие другие евангелисты Agile-методологий, я скептически отношусь к людям, которые гордятся своими сертификатами. По моему опыту, наличие сертификата почти ничего не говорит о способностях человека, за исключением того, что в какой-то момент в прошлом кто-то измерил, насколько данный человек в курсе определенной информации. Не более того. Даже сертификаты, подтверждающие «освоение специальных навыков» (в отличие от сертификатов, подтверждающих усвоение определенных знаний), ничего не подтверждают, кроме способности человека выполнять определенные функции в тепличных условиях. И никак не соотносятся с его способностью успешно осуществить реальный проект.

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

Точно такая же проблема у нас и с разработкой ПО, и с управлением проектами.

Сертификация Project Management Professional (PMP), проводимая Институтом управления проектами, вроде бы предъявляет очень серьезные требования – от претендентов требуется изучить обширный материал, иметь определенный практический опыт и тому подобное. Однако вынужден констатировать, что, хотя мне и приходилось встречать хороших сертифицированных проектных менеджеров, диплом PMP также имели и худшие сотрудники, которых мне когда-либо приходилось видеть. Им вообще нельзя было поручать никаких проектов. Именно они больше всех кичились своей сертификацией, при этом меньше других осознавали ограниченность своих возможностей. Аббревиатура PMP точно не означает «минимально приемлемый уровень компетентности»[64].

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

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

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

Используйте силу социального давления

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

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

Но независимо от того, воспринимается ли социальное давление в качестве «желательного» или «нежелательного», оно представляет собой пример положительной обратной связи. Чем больше членов группы демонстрируют определенную модель поведения, тем большее давление осуществляется на остальных ее членов с целью заставить их принять те же модели поведения. И не успеваете вы оглянуться, как все они начинают делать одно и то же. Независимо от того, идет ли речь о разработке через тестирование или употреблении ЛСД.

При разработке ПО давление группы может играть конструктивную роль. Но, чтобы заставить его работать в ваших интересах, нужно учитывать следующие моменты:

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

2. Придайте социальному давлению направление, сделав группу в целом ответственной за достижение разделенной цели. Спортивные команды выигрывают или проигрывают – и тут важен каждый человек. То же самое относится к командам разработчиков. Ответственность команды – ответственность, разделяемая всеми ее членами.

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

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

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

А что если люди все равно ничему не учатся?

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

Поговорите с ним.

Поговорите с ним в последний раз.

Избавьтесь от него.

Используйте адаптируемые инструменты

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

Я имею в виду инструменты.

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

Инструменты могут играть важную роль в повышении дисциплины в компании. Приверженцы Lean-методологий настаивают, что инструменты должны быть сконфигурированы таким образом, чтобы это позволяло максимально защитить процессы от ошибок (метод также известен как «защита от дурака») и тем самым затруднить выпуск программного обеспечения, содержащего дефекты [Poppendieck 2007: 196]. Меры по превентивному исключению ошибок можно считать техническим эквивалентом коучинга, который также помогает повысить дисциплину разработки.

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

Люди и процессы – сердце вашей компании, к этой же категории относятся и инструменты. Это значит, что, подобно людям и процессам, инструменты должны быть тщательно подобраны и адаптированы под потребности вашего бизнеса. Никогда не меняйте свой бизнес под свои инструменты. Как однажды написал Джоэл Спольски:

Если речь идет о критически важной для вашего бизнеса функции – выполните ее сами, чего бы это ни стоило[65].

Я думаю, этот тезис с небольшими оговорками может быть распространен и на используемые инструменты:

Если инструмент очень важен для вашего бизнеса – разработайте его сами, чего бы это ни стоило.

Не поймите меня превратно. Я никого не призываю создавать свой личный Visual Studio или Eclipse. Но вы должны выбирать для себя столь же адаптируемые программные продукты, какими являются Visual Studio и Eclipse. Не выбирайте настраиваемые инструменты. Чаще всего под настраиваемостью понимается возможность изменить набор пунктов меню, поменять их местами и выбрать ваш любимый цвет. Это не то, что я имею в виду под адаптируемостью. Точно так же не думайте, что вы в порядке, если пользуетесь инструментами, в названии которых есть слово Agile. Его обычно применяют с маркетинговыми целями, и его присутствие в названии продукта совсем не означает, что он имеет соответствующую архитектуру. Мне приходилось видеть так называемые гибкие инструменты, в которых было столько же гибкости, сколько в Ким Чен Ире, помещенном в ледник.

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

Подумайте о супервайзере

Я где-то читал, что «управлять людьми труднее, чем программировать, поскольку добиться нужного от людей труднее, чем от компьютера». (Не обрушивайтесь на меня с критикой, если вы не согласны. Это просто цитата из неизвестного источника.)

Эта фраза никак не выходила у меня из головы, когда я недавно столкнулся с рядом проблем… назовем их проблемами с дисциплиной…

• Сотрудник отсутствует на совещании без предупреждения, при этом ранее он прислал подтверждение своего участия.

• Доска задач не поддерживается в актуальном состоянии и не отражает последнее состояние задач и пользовательских историй.

• Никто по собственной инициативе не проверяет, не перерасходован ли бюджет.

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

• Документация по проекту не попадает в общедоступный репозитарий.

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

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

То есть мы поняли, что такое быть людьми. Но как быть с проблемами?

Одно из часто предлагаемых решений – назначение супервайзера, в зону ответственности которого входило бы проведение инспекций. Такая мера выглядит как первый шаг к бюрократии, против которой так страстно выступают поклонники методологий Agile и Lean.

Например, Мэри и Том Поппендик считают, что инспекции, чья цель – обнаружение дефектов, это пустая трата времени. Они призывают вообще отказаться от инспекций. И утверждают, что ресурсы необходимо направлять на профилактику дефектов, а не на их исправление, потому что профилактика дешевле [Poppendieck 2007: 7].

В то же время Том и Кэй Гилб, прославившиеся именно своими работами по организации инспекций [Gilb 2003], проводят формальное обучение методам проверки проектной документации, направленным на выявление и измерение дефектов. Они даже вручают сертификаты с названиями вроде Inspection Leader и Inspection Process Owner!

Что вообще происходит? Как примирить эти точки зрения? Могу ли я получить сертификат за полный отказ от инспекций? Или мы стали свидетелями серьезной разборки между двумя самыми известными семейными парами, специализирующимися в области разработки ПО?

Я бы сказал, что их точки зрения – не более чем две стороны одной медали. Да, профилактика проблем дешевле, чем их исправление, но только в 98 % случаев. К тому же, как отмечалось многими, добиться полного отсутствия дефектов невозможно, поскольку превентивные меры с целью исключить последние 2 % дефектов стоят слишком дорого.

Призывы к «нулевому уровню дефектов» контрпродуктивны, статистически невозможны и абсолютно запрещены с точки зрения цены вопроса. Статистически нулевой уровень ошибок означает, что сигма уровня дефектов приобретает бесконечное значение, а это не представляется возможным. Говоря о нулевом уровне дефектов, люди в большинстве случаев имеют в виду проактивное отношение к совершенствованию производственных процессов, но буквально понимаемые призывы только вредят. Движение за «нулевой уровень дефектов» по умолчанию исходит из представления, что все дефекты одинаковы. Но это неверно. На практике в большинстве компаний и для большинства продуктов достаточно обнаружить и уделить первостепенное внимание обнаруженным дефектам и заниматься ими, начиная с самых важных и лишь затем переходя к наименее важным. Может даже иметь смысл вовсе не браться за дефекты, попавшие в конец списка приоритетов, а просто двигаться дальше[66].

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

Одна из типичных форм инспекций – ассессмент. Существуют разнообразные инструменты, помогающие организациям проверить, насколько эффективно работают их Agile-команды [Cohn 2009: 430–438]. По существу, ассессменты будут инспекциями, поскольку они оценивают эффективность команд разработчиков после принятия ими Agile-практик. К сожалению, не существует способа внедрить Agile-методологии и не допустить при этом никаких ошибок, и это плохая новость для разработчиков, но хорошая для растущей индустрии консалтинга, включая семьи Гилб и Поппендик.

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

Проводите встречи с глазу на глаз

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

В своей книге «За закрытыми дверями» Джоанна Ротман и Эстер Дерби описывают, как нужно проводить индивидуальные встречи с сотрудниками [Rothman, Derby 11, 150]. C системной точки зрения регулярные встречи с глазу на глаз полностью оправданны. Они стимулируют обмен информацией в системе и ускоряют получение обратной связи.

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

1. Осознайте важность проведения встреч с глазу на глаз. Именно поэтому я выделяю для них специальный раздел в этой главе, а вы его читаете.

2. Решите проблему управления своим временем, зарезервировав в своем графике фиксированное время для этих встреч, например по полчаса на одного сотрудника. Проводите индивидуальные встречи в один и тот же день раз в две недели. По моему опыту, так легче не дать другим срочным делам вмешаться в ваши планы.

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

4. Мотивируйте себя, организуя индивидуальные встречи в разных интересных форматах. Например, можно сходить вместе с сотрудником в кафетерий во время обеденного перерыва, заняться с ним парным программированием и даже обмениваться текстовыми сообщениями, если вам вдруг приходится участвовать в безумно скучном совещании.

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

Встречи для обсуждения оценок 360°

Из упоминаемого в главе 4 закона требуемого разнообразия следует, что простые метрики никогда не смогут правильно оценить сложную систему. А принцип непрозрачности системы, описанный в главе 6 «Базовые принципы самоорганизации», объясняет, почему менеджер никогда не в состоянии точно оценивать сотрудников. Но тогда как же это делать?

Деминг и другие эксперты по управлению качеством подвергают сомнению объективность оценок работы членов команды с иных позиций. Они утверждают, что невозможно подобрать набор параметров, который охватывал бы все многообразие моделей поведения, которые нужны организации от ее сотрудников. ‹…› Эмпирические исследования показывают, что менеджеры не способны давать надежные оценки эффективности своих подчиненных в динамике[67].

В моей последней компании процедуру оценки персонала всегда оставляли на декабрь. Менеджеры, обреченные ее проводить, оказываются между молотом и наковальней: для них участие в этом – самый простой способ нарваться на неприятности. Поскольку в процедуре оценки участвует как старший менеджмент, так и рядовые сотрудники и все показывают пальцами в разные стороны, менеджеры среднего звена оказываются ровно посередине. Для них заниматься оценкой персонала такое же увлекательное занятие, как сидеть на границе между Израилем и Палестинской автономией, держа в руках плакат: «Я не поддерживаю ни ту, ни другую сторону. Может, просто обсудим ситуацию?»

Ежегодная процедура оценки персонала никуда не годится по целому ряду причин:

• Людей нельзя оценивать с помощью стандартизированных критериев вроде «пунктуальность», «коммуникационные навыки» или «энтузиазм». Сам характер таких критериев унизителен для оцениваемых и не в состоянии отразить присущую людям индивидуальность и разнообразие выполняемой ими работы [Bobinski 2010].

• Процесс оценки персонала один раз в год сильно запаздывает и поэтому теряет всякий смысл. Невозможно запомнить все, что происходило в течение двенадцати месяцев. А необходимость корректировать поведение людей возникает гораздо чаще [Derby 2010].

• При проведении ежегодной оценки персонала и менеджмент, и сотрудники имеют свои «тайные планы», что делает весь процесс «нечестным и мошенническим» [Culbert 2010].

• И наконец, «от него отдает старомодным, патерналистским и авторитарным управленческим подходом, который рассматривает сотрудников как собственность компании» [Heathfield 2010c].

К счастью, существует правильный метод оценки персонала. Для начала надо внутренне согласиться с принципами, лежащими в основе оценки 360° [Heathfield 2010b]. В первую очередь это утверждение, что ни одна отдельно взятая точка зрения не может объективно оценить работу сотрудника. Следовательно, для того, чтобы точнее измерить его вклад в работу организации, необходимо учитывать множественные оценки, вынесенные разными людьми [Dent 1999: 16].

К сожалению, многие руководители злоупотребляют оценкой 360° именно с точки зрения старомодности, патернализма и авторитарности (рис. 11.2). А это совсем не то, что нужно Agile-менеджеру.

Вот альтернатива получше.

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

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

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

Зачем вам вообще проводить совещания для обсуждения оценок 360°? Чем этот способ лучше, чем традиционные методы?

• Люди получают возможность обсудить проблемы с чьим-либо поведением, при этом становится очевидно, действительно ли большинство членов команды считают это проблемой. Не имеет смысла документировать «проблемы», которых большинство не видит.

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

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

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

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

Естественно, я советую проводить обсуждение в формате 360° только при условии, что члены команды относятся друг к другу с доверием и уважением. Если сотрудники не способны давать или принимать открытую, честную и конструктивную обратную связь, вам сначала нужно заняться решением других проблем.

Последнее такое обсуждение, которое я проводил со своей командой, оказалось одним из самых продуктивных событий за много месяцев. Сотрудники рассказали мне много такого, чего я за собой совершенно не замечал. В ходе совместного обсуждения мне удалось точнее сформулировать свои претензии к некоторым членам команды. Мы все были очень довольны, что нам удалось откровенно поговорить друг с другом. А заодно мы вместе поужинали, пережили возникавшие в ходе обсуждения неприятные моменты, выпили и повеселились.

Повышайте стандарты

Каждый раз, когда я приезжаю в Соединенные Штаты, мне приходится тратить время, а также физические и интеллектуальные усилия на перевод одних стандартов в другие. Я конвертирую доллары в евро и наоборот, мили в километры, галлоны в литры, а часы до и после полудня в 24-часовой формат. У меня скопилось уже по меньшей мере четыре электрических адаптера, потому что иногда я забываю взять их с собой в поездки. И это несмотря на то, что они указаны в чек-листе вещей, которые нужно взять с собой. (Возможно, вы задаете себе вопрос, зачем вам советы такого человека, когда речь идет о компетентности…)

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

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

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

При разработке ПО предметом обсуждения между лидерами компетенций и сотрудниками в этом случае становятся их собственные стандарты, а не те, что навязаны менеджерами. К числу стандартов, устанавливаемых командами самостоятельно, могут относиться протоколы взаимодействия с пользователями, система именования файлов, требования, предъявляемые к коду, структура файлов, используемые инструменты, протоколы регистрации ошибок, правила безопасности [Poppendieck 2007: 193]. Исчезает необходимость в стандартизации сверху вниз, проводимой менеджментом. Но стандартизация снизу вверх произойдет только в том случае, если цели и контрольные показатели не оставляют у сотрудников никаких сомнений, что оптимальнее будет внести изменения в процесс своей работы.

Управляйте системой, а не правилами или людьми

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

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

• Чтобы ускорить принятие лучших практик, вводите их в виде целостных мемплексов, а не по отдельности. Например, большинство идей, использованных Дэвидом Алленом в книге «Как привести дела в порядок» (Getting things done), существовало задолго до появления этого труда. Но в книге все идеи собраны в единый «пакет» под легко запоминающимся брендом, что облегчает задачу применения рекомендуемых автором практик.

• Разрешите людям фокусироваться на том, в чем они сильны, и не требуйте от них большего, чем «минимально необходимый уровень компетентности», в других областях. C точки зрения организации гораздо полезнее разрешить людям заниматься тем, что им нравится, и не заставлять их развивать свои компетенции в областях, к которым они безразличны. Не имеет никакого смысла превращать своих сотрудников в однородную массу. Гораздо лучше дать людям возможность проявлять свои индивидуальные таланты, тем самым компенсируя недостатки друг друга в прочих областях. Например, сотрудник со слабыми навыками вербальной коммуникации и межличностных взаимодействий может быть супергероем во всем, что касается системной архитектуры. Время, которое он проведет на тренингах по развитию «навыков коммуникации», можно использовать гораздо продуктивнее, отправив его на семинар, где будут обсуждаться «вопросы улучшения масштабируемости программных продуктов».

• Большие проблемы начинаются с маленьких. Нельзя фокусироваться только на крупных проблемах, поскольку за это время небольшие превращаются в огромные. Например, с самого начала установите требования, предъявляемые к качеству кода, чтобы под воздействием эффекта разбитых окон ваш проект не стал похож на местность, где похозяйничали сомалийские пираты [Hunt, Thomas 2000: 5].

Профессионально выстроенная организация представляет собой систему, которая подталкивает людей становиться все более компетентными в своей профессиональной области. Развитие компетенций – один из компонентов Менеджмента 3.0. Мне представляется, что самоорганизующаяся система развития компетенций – это и есть тот единственный уровень зрелости, который вам когда-либо понадобится.

Резюме

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

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

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

С точки зрения развития компетенций у менеджеров есть несколько функций, включая проведение индивидуальных встреч с сотрудниками, организацию встреч для обсуждения оценок 360°, повышение стандартов методом «снизу вверх» и воздействие на систему (но не на людей).

Подумать и сделать

Посмотрим, как можно применить некоторые идеи этой главы в вашей компании:

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

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

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

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

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

• Обсудите вместе с командой инструменты, которыми вы пользуетесь в работе. Будут ли основные инструменты, применяемые вами при разработке ПО, достаточно адаптируемыми?

• Нужны ли вашей организации супервайзеры? Находятся ли компетенции команд на достаточно высоком уровне, чтобы обходиться без супервайзеров и инспекций? Или все же есть смысл, чтобы супервайзеры на выборочной основе проверяли работу команд?

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

• Несколько раз в год проводите встречи для обсуждения оценок 360°. Разрешите членам команды самим документировать результаты, но не забывайте, что ответственность за результаты оценки лежит на вас.

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

Глава 12 Коммуникация в организационных структурах

Но также верно, что эта скорость может приумножить распространение информации, которая заведомо неверна.

Эдвард Р. Мэроу, журналист (1908–1965)

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

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

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

В общем, пристегните ремни и постарайтесь не выронить из рук то, что вы едите.

Это баг или фича?

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

Когда несколько лет назад я купил машину, я заметил, что ручка рычага переключения передач болтается. Ее можно было проворачивать на 360°. Я подумал, что неплохо было бы ее затянуть, но в целом не обратил на это особого внимания. Более того, отъездив около года, я настолько привык к этой «проблеме», что она мне даже начала нравиться. Ручку можно было крутить, и мне стало казаться, что это удобно. Например, мне нравилось крутить ее во время ожидания переключения светофора на зеленый. (Для чего в моей стране – с ее обилием светофоров – есть масса возможностей.)

Через год после покупки я отвез машину на плановый сервис. Получив ее обратно, я обнаружил по дороге домой – что-то не так… Ручка больше не поворачивалась! Ее затянули на сервисе. Я пришел в бешенство: эти ублюдки «исправили дефект»!

Это классический пример эффекта ложного консенсуса: люди склонны проецировать свой собственный способ мышления на других – им кажется, что они знают, чего хотят окружающие [Arrow 2000: 125]. Проблема в том, что ситуация, воспринимаемая одним человеком как неисправность, для другого может быть приемлемой или даже желательной особенностью.

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

Коммуникация и обратная связь

Конечно же, большинству людей хотелось бы, чтобы ручка на рычаге была зафиксирована. И многие поддержали бы механика из сервиса в его «справедливом предположении», что и я хочу того же. Но это было лишь его предположение. Он же не спросил, что об этом думаю я. Даже если бы мне на автосервисе заранее сказали, что «мы собираемся затянуть все, что разболталось», это не слишком изменило бы ситуацию, поскольку односторонняя коммуникация – вовсе не коммуникация в полном смысле этого слова. Как пишет Алистер Коберн в «Гибких методологиях разработки ПО» [Cockburn 2007: 8–13], традиционное представление, что «передача информации от одного человека другому» – это коммуникация, неверно.

Чтобы лучше понять, о чем идет речь, давайте рассмотрим, что происходит на самом деле, когда вы собираетесь «сообщить» мне что-либо (рис. 12.1). Соответствующие вашей внутренней модели мира мысли (то, что вы имеете в виду) определенным образом переводятся в некие физические действия с вашей стороны. Например, вы произносите какие-то слова, выбираете высоту тона, скорость и громкость произнесения, жестикулируете, в движение приходят ваши лицевые мышцы – либо просто вводите текст в какое-либо устройство или пишете его на листе бумаги. Но уже на этом первом этапе общения имеется много причин для возникновения коммуникационных проблем, поскольку в процессе перехода от мыслей к действиям порой возникают ошибки. Так, можно перепутать правую сторону с левой (как это обычно случается со мной). Или же в своем сообщении вы примените знаки, интерпретация которых зависит от контекста или культуры. Например, в некоторых странах не совпадают движения головой, означающие «да» и «нет», в результате чего привычная для вас коммуникация не работает [Adams 1986].

Затем ваши ошибочные или неоднозначные сигналы должны будут пройти через некую среду, например воздух, компьютерную сеть или систему почтовой доставки. Шумы и неисправные механизмы, которые присутствуют в данной среде, еще больше исказят ваше сообщение – прежде чем оно попадет ко мне на приемные сенсоры (искажения точно произойдут, если в качестве среды попадется моя домашняя сеть Wi-Fi).

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

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

Даже сигнал sos – это не коммуникация?

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

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

Реальная коммуникация подразумевает уверенность, что смысл сообщения одинаков для обеих сторон. Технические протоколы (например, применяемые в интернете TCP/IP и HTTP) используют различные методы, задача которых – убедиться, что информация, отправленная с одной стороны, должным образом принята другой. Такие же требования применимы к коммуникации между людьми. Коммуникацию можно признать состоявшейся, только если обе стороны согласны, что они должным образом произвели обмен информацией и присвоили сообщению один и тот же смысл. В этом одна из причин, почему Scrum-командам следует проводить личные встречи с владельцем продукта: только таким образом можно проверить, правильно ли они понимают друг друга.

Но разве возможно достичь полного согласия о смысле того или иного сообщения?

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

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

Передача искаженной информации – это норма

Неудовлетворительная коммуникация – настолько распространенное явление, что специалист в области сложных систем Ральф Стейси считает ее нормой для многих компаний. На плохую коммуникацию люди жалуются всегда. Независимо от количества внедренных в организации процедур прохождения информации или регулярных отчетов жалобы будут все те же. Неудовлетворительная коммуникация никуда не девается. Стейси полагает, что жалобы на «плохую коммуникацию» – неизбежный побочный эффект самых эффективных методов получения знаний [Stacey 2000а: 5].

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

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

Коммуникация = информация × взаимоотношения × обратная связь

Роджер Левин пишет, что большинство организационных проблем проистекает из чудовищных взаимоотношений между людьми внутри компании [Lewin 1999]. Я думаю, что он во многом прав, но это лишь одна часть нашего уравнения. В отсутствие качественной информации у нас не было бы ничего ценного, что нужно было бы передать. Без хороших отношений между людьми не было бы способа этой информацией поделиться. А без эффективных механизмов обратной связи было бы невозможно получить подтверждение, что информация должным образом преодолела расстояние от одного человека к другому.

А как это связано с идеей сотрудничества?

В данной главе так часто упоминается коммуникация, что может сложиться впечатление, что она никак не связана с сотрудничеством. Я полагаю, что коммуникация и сотрудничество – явления разных порядков. В различных источниках указывается, что коммуникация – это необходимое условие для сотрудничества и что сотрудничество, помимо коммуникации, предполагает также наличие определенного сообщества, связей между его членами, способности принимать решения и действовать в соответствии с ними, испытывать по этому поводу определенные эмоции и так далее [Cockburn 2007: 372].

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

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

Возможности коммуникаторов

В математике и социологии под системами со свойствами «тесного мира» подразумеваются такие системы, в которых связь одного агента с любым другим может быть установлена через минимальное количество шагов, при этом большинство агентов могут и не быть непосредственными соседями внутри данной системы. Примерами такого рода систем будут организации. Все знают всех напрямую или косвенно через одного-двух других сотрудников (довольно часто к числу последних относятся секретари, офис-менеджеры или даже вахтер на входе). Интересно, что все население Земли также представляет собой пример подобной «тесной» сети. В качестве доказательства часто приводят знаменитую теорию шести степеней удаленности, которая утверждает: все люди на нашей планете разделены максимум шестью переходами, или рукопожатиями [Gladwell 2002: 47].

Анализ социальных сетей – это раздел теории сетей, который занимается социально-сетевыми структурами и вопросами распространения в них информации. Карен Стивенсон, корпоративный антрополог, выделяет в социальных сетях три архетипа коммуникаторов [Stephenson 2005]:

• Хабы – люди, к которым из множества источников поступает информация, а они затем транслируют ее всем вокруг себя.

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

• Барометры – наблюдатели людей и тенденций. Они, как правило, становятся отличными наставниками и коучами.

Стивенсон пишет, что «концентраторы знают большинство людей в организации, привратники знают правильных людей, а барометры знают большинство людей, которые знают правильных людей».

В своем бестселлере «Переломный момент» Малкольм Гладуэлл предлагает иную категоризацию людей в социальных сетях [Gladwell 2002: 34]:

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

• Знатоки знают меньше людей, но, как правило, инвестируют больше времени в развитие с ними отношений, а потому знают их гораздо лучше.

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

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

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

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

• Соединение. Некоторые люди хорошо устанавливают связи с другими. Они создают множество маршрутов, по которым потенциально может проходить коммуникация. У таких людей обычно масса друзей в Facebook или на LinkedIn; они часто участвуют в совещаниях и конференциях и в своем офисе знают почти всех. Данная способность наиболее ярко выражена у хабов и соединителей.

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

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

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

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

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

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

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

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

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

Радио – отличная аналогия коммуникативных компетенций

Рецензировавший мою книгу Йенс Шаудер предложил интересную аналогию с принципами, по которым действует радио.

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

Вы должны точно понимать, чем распространение сигнала в диапазоне AM отличается от распространения в FM-диапазоне (понимание), вам потребуется усилить свой сигнал (развитие) и приобрести определенные навыки работы с эквалайзерами (управление).

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

Сетевые эффекты

Twitter изменил мою жизнь. Поскольку я интроверт, у меня никогда не возникала потребность говорить о себе. Но в Twitter все по-другому. Иногда мне кажется, что канал, связывающий мой мозг с моим каналом в Twitter, шире, чем тот, что разделяет Голландию и Великобританию. Мне приходится прилагать усилия, чтобы моя жизнь в социальных сетях не взяла верх над «нормальной» жизнью в физическом мире, где круг моих знакомств столь же скромен, как размер типичного гостиничного номера в Париже.

Исследования в области теории сетей в целом и сетевого анализа в частности позволили выявить ряд интересных эффектов в (онлайн и офлайн) социальных сетях. Например, может наступить переломный момент [Gladwell 2002] – это момент во времени, когда явление, до некоторых пор редкое, вдруг широко распространяется по всей сети. Примерами этого эффекта служат популярность фильма «Аватар», видео с выступлением Сьюзан Бойл, книг о Гарри Поттере, Scrum-фреймворк… или этой книги. (Я писал о ней в Twitter, пока у меня не посинели пальцы, так что я не виноват, если моя книга не станет сенсацией.) В физике переломный момент называют фазовым переходом, но смысл тот же самый: речь идет о внезапном переходе системы из одного состояния в другое.

Вторым примером сетевых эффектов будет сила слабых связей [Granovetter 1973]. Она проявляется в том, что информация распространяется лучше, если ее отправлять через множество слабых соединений, а не через несколько сильных. Прекрасным примером слабых связей будут мои связи с людьми, подписанными на мой канал в Twitter. Подписчики иногда не прочь поговорить со мной, но никогда не портят мне настроение назойливыми приглашениями на свой день рождения.

Сетям также свойственно явление, получившее название длинный хвост [Anderson 2008], которое утверждает, что ценность суммы редко встречающейся информации может быть больше, чем ценность информации, широко распространенной в социальных сетях. Другими словами, авторы в Twitter, у которых всего лишь по несколько подписчиков, совокупно могут представлять собой более ценную целевую аудиторию (в том числе и с коммерческой точки зрения), чем незначительное количество популярных авторов, имеющих массу подписчиков.

И наконец, в моем представлении одним из наиболее интересных явлений в системах со свойствами «тесного мира» будет эффект гомогенизации. Исследователи имеют основания утверждать, что эффект длинного хвоста вовсе не означает переноса внимания людей с наиболее популярной информации («голова») к «хвосту» (нишевая или наименее популярная информация). Напротив, в сетях с большим количеством соединений информация, которая уже многократно скопирована, имеет тенденцию к дополнительному копированию. То, что уже популярно, имеет тенденцию становиться еще популярнее. Данный эффект также известен как эффект Матфея, которому и принадлежит цитата из Евангелия: «Ибо всякому имеющему дастся и приумножится, а у неимеющего отнимется и то, что имеет» [Webb 2007: 54].

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

Становится ясно, что через сети, состоящие из друзей, передается целый ряд состояний, причем мы не до конца понимаем механизм такой передачи. Передается счастье и депрессия, ожирение, привычка курить и употреблять алкоголь, приходить на избирательные участки и определенным образом голосовать, вкус к определенной музыке и продуктам питания, стремление использовать скачанные в интернете пиратские копии и даже тенденция задумываться о самоубийстве или совершать его. Эти предпочтения распространяются по сети, как «круги от брошенного в воду камешка». ‹…› Но если мы осведомлены о существовании социального заражения, то можем найти способы борьбы с ним или направить его в полезное русло[68].

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

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

Теперь вы понимаете, почему я так часто пишу в Twitter о себе и своих проектах. «Сеансы связи» длиной 140 символов помогают мне нарастить количество слабых связей с теми, кто образует тот самый длинный хвост, и это существенно увеличивает число людей, находящихся от меня менее чем в трех степенях удаленности. И теперь я терпеливо жду наступления переломного момента…

Настройка соединения

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

Все это связано с балансировкой соединений. Чем больше связей между агентами в сложной системе, тем больше ограничений эти агенты накладывают друг на друга. Тем самым ограничивается их свобода передвижения и способность достигать максимальной производительности [Stacey 2000а: 114]. Представляется, что количество связей в сложной системе должно быть соответствующим образом настроено. Их не должно быть ни слишком много, ни слишком мало.

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

Представляется, что при превышении определенного числа соединений степень адаптации уменьшается. ‹…› По-видимому, размер сети не сильно влияет на оптимальное количество соединений на каждый узел (ими в данном случае могут быть люди или группы, которые в данной коммуникационной системе будут уникальными адресатами), и это оптимальное количество соединений относительно невелико. По мере роста сети и возникновения новых узлов количество соединений, ведущих к каждому из них, должно оставаться относительно постоянным[69].

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

Дефицитным ресурсом здесь будет не столько информация, сколько внимание. Учитывая естественные ограничения на обработку данных, агентам приходится активно игнорировать преобладающую часть информации, с которой они сталкиваются. ‹…› Не исключено также, что агенты способны функционировать более эффективно, когда в их распоряжении меньше данных[70].

Природа снабдила нас защитой от информационных перегрузок. Чем больше сигналов поступает извне, тем сильнее наш иммунитет к входящим данным [Gladwell 2002: 274]. Поэтому мне кажется, что информационную перегрузку вряд ли можно назвать такой уж серьезной проблемой. Посмотрите в окно в течение трех секунд, закройте глаза и постарайтесь вспомнить все, что вы увидели. Я уверен, что вам удастся вспомнить не так много. Наш мозг естественным образом приспособлен к тому, чтобы игнорировать почти всю входящую информацию. Единственная реальная проблема состоит в том, что люди плохо справляются с задачей фильтрации данных и в результате часто готовы слушать всякую ерунду и игнорировать ценный материал.

Некоторые команды обрабатывают входящие потоки информации лучше, чем другие. Сплоченные команды, члены которых проводят много времени вместе и регулярно сотрудничают, вырабатывают эффективные стратегии коллективной работы и навыки для решения даже самых сложных и связанных с информационной перегрузкой задач[71].

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

Конкуренция и сотрудничество

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

Ричард Докинз еще несколько десятилетий назад продемонстрировал, что эгоистичны даже гены [Dawkins 1989]. Но, несмотря на свойственный им эгоизм, сотрудничество 1195 генов, входящих в геном человека, позволяет нашему организму сформировать сердце, совместное функционирование 2164 генов имеет своим результатом белые клетки крови, а за формирование человеческого мозга отвечает набор из 3195 генов [Corning 2003: 107]. Все эти группы эгоистичных генов эволюционируют совместно потому, что при всем своем эгоизме они выяснили, что совместное развитие более выгодно. Сотрудничество повышает их шансы на выживание внутри генофонда, которому отнюдь не свойственны сантименты.

Интересную форму командной работы демонстрируют муравьи вида Pheidole pallidula, который состоит из маленьких рабочих муравьев и больших муравьев-солдат. Когда злоумышленник пытается проникнуть в муравейник, рабочие муравьи набрасываются на него, стараясь обездвижить, в то время как задача муравья-солдата – обезглавить жертву [Anderson, McMillan, 2003: 32]. (Не правда ли, командам есть чему поучиться у природы?)

Существует также много форм кооперации между различными видами. В качестве примера можно назвать лишайники, которые представляют собой партнерство, или симбиотическую ассоциацию водорослей и грибов. Водоросли осуществляют фотосинтез путем переработки солнечной энергии, а грибы накапливают необходимую влагу. Такой симбиоз позволяет лишайникам выживать в суровых природных условиях. Два вида вместе могут делать то, на что по отдельности ни один из них не способен [Corning 2002: 67].

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

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

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

Все мы эгоистичны. Но самые умные эгоисты понимают, что в их интересах сотрудничать с окружающими и быть по отношению к ним максимально вежливыми. Это хорошо согласуется с открытием математика Роберта Аксельрода, который заметил, что одной из самых успешных стратегий выживания как с точки зрения теории игр, так и в природе будет стратегия «Око за око». Она заключается в том, чтобы играть честно до тех пор, пока честно играют конкуренты [Mitchell 2009: 217]. Этот вывод также совпадает с наблюдением Кристофера Эвери, что «умение работать в команде – индивидуальный навык» [Avery 2001]. Примерно о том же писала в своих книгах и статьях философ Айн Рэнд, продвигавшая концепцию «добродетельного эгоизма» [Rand, Branden 1970]. И хотя ее жесткая доктрина подвергалась критике с многих сторон, на фундаментальном уровне она была права.

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

НО есть же люди, которые постоянно принижают своих коллег?

Способность сотрудничать не приходит автоматически. Некоторые люди вообще не способны ей научиться. И они не смогут достичь значительных успехов в личной жизни или профессиональной деятельности.

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

Группы и границы

Мы видели, что стремление к личному успеху порождает желание сотрудничать. Но что происходит потом?

Когда агенты в сложной системе начинают сотрудничать, они, как правило, образовывают подсистемы – в результате чего организации оказываются построенными по модульному принципу [Richardson 2004b: 79]. В работе «Малые группы как сложные системы» (Small Groups as Complex Systems) авторы описывают четыре способа формирования групп [Arrow 2000: 65]:

• Искусственные группы, создаваемые в плановом порядке какой-либо внешней силой. Например, формируется проектная группа, чтобы создать сайт для любимой собаки генерального директора, а руководители подразделений делегируют в такую группу «добровольцев».

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

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

• Ситуативные группы, возникающие под воздействием внешних по отношению к группе обстоятельств, при этом формирование группы носит внезапный характер. Например, сотрудники вместе застревают в лифте по пути на обед (который им только что доставил новый кейтеринговый сервис). (Было бы интересно посмотреть, что они напишут об этом в Twitter.)

Менеджерам часто поручается создание команд первого типа (искусственные группы). В таких условиях формирование команды и реальное сотрудничество иногда могут быть серьезно затруднены. В этом случае стоит попробовать делегировать ответственность за формирование команды под проект самим сотрудникам (сформировать «учреждаемую группу»).

Чтобы группа могла обоснованно называть себя «командой», необходимо выполнение двух важных условий: 1) у нее должна быть общая цель и 2) команда должна быть отграничена от других команд. Эта граница может быть пространственной, временной и психологической. Определить, кто именно входит в команду, можно по размещению людей в офисе (все члены команды работают в одном помещении), по продолжительности ее существования (например, предполагается, что команда будет действовать начиная с этого момента и до конца следующего года), по наличию в сознании людей общей концепции или объединяющей их предметной области (в команду со всей компании могут быть собраны специалисты по архитектуре ПО) [Arrow 2000: 79]. Когда не достигнуто согласие о границах команды и имеется серьезная неопределенность относительно того, кто входит в нее, а кто нет, – группа сотрудников не может считаться командой просто потому, что эта команда не существует [Hackman 2002: 44].

В своей статье «Управление командами» Хэкмен пишет, что ключом к успешному формированию команд будет наличие границы, которая не должна быть ни слишком закрытой (запрет на вход), ни слишком открытой (потеря сплоченности). Говоря об этом, он прибегает к термину проницаемые границы, который также применяется в теории систем (глава 3 «Теория сложности»).

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

Гиперпродуктивность, или Автокатализ

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

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

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

Все молекулы в бассейне участвуют в химических реакциях. Но каждая из них также будет продуктом другой химической реакции. Глядя на рис. 12.3, мы можем представить, как каждая реакция ускоряется одной из молекул (катализатором), в то время как сам этот катализатор возник как продукт предшествовавших химических реакций, на ускорение которых влияли другие катализаторы. Проще говоря, данная система катализирует себя сама (или является автокаталитической).

Биолог-теоретик Стюарт Кауфман показал, что формирование автокаталитических систем математически почти неизбежно в условиях, когда разнообразие и возможности установления новых соединений достигают определенного уровня – как это бывает в сетях. Такая гетерогенная система может поддерживать себя сама. Для этого ей не нужно ничего, кроме поступающего извне небольшого количества энергии. Существует предположение, что автокаталитические системы внесли значительный вклад в формирование жизни на Земле [Kauffman 1995].

Принцип автокатализа очень важен. Чем больше разных людей присоединяется к команде, тем выше ее гетерогенность. В результате все больше участников начинают играть роль катализаторов. Работа команды ускоряется, и в один прекрасный момент на действия каждого участника в качестве катализатора начинает влиять как минимум один из его коллег.

Не исключено, что при помощи автокатализа можно дать научное объяснение феномена «прошедших кристаллизацию» команд, описанных Демарко и Листером, а также «гиперпродуктивности» команд разработчиков ПО, о которой часто упоминает Джефф Сазерленд. Но даже если я ошибаюсь, существование автокатализа в любом случае будет сильным аргументом в пользу разнообразия, развитых соединений внутри системы и специализации.

Вы скажете, что нужно кое-что еще…

И окажетесь правы! Чтобы достичь гиперпродуктивности, недостаточно лишь катализировать работу друг друга.

Важны и другие факторы, такие как сотрудничество и компетенции. Некоторые полагают, что очень важна неявная координация, то есть способность членов команды предвосхищать потребности и действия друг друга без их обсуждения в явном виде.

В тот день, когда я работал над этой частью главы, мы вместе с командой провели очередное совещание по планированию. Всем было очевидно, что мы очень быстро двигаемся вперед и успеем завершить работу за три недели, оставшиеся до запуска продукта. Вероятно, никто из нас в этот момент не раздумывал о том, насколько круто быть автокаталитической командой, но мы, конечно же, чувствовали, что каждый из нас вносит серьезный вклад в общую производительность. Уверен, что ни у кого из нас не вызвал бы затруднений ответ на вопрос «Как я могу помочь остальным двигаться еще быстрее?».

Формирование паттернов

В 2009–2010 годах выдалась одна из самых холодных зим в Северном полушарии за последние десятилетия. Для меня это было время великой радости и великой скорби (фото 12.1). Радости, потому что мир прекрасен, когда вокруг все покрыто белым снегом. И скорби, потому что, как бы красиво ни выглядели кристаллы льда на окнах автомобиля, я не люблю при минус десяти градусах по Цельсию скакать вокруг своей машины со скребком.

Пока занимаешься размораживанием автомобиля, легко забыть, какое же это чудесное явление – снег.

Кристаллам льда, которые образуются в турбулентных воздушных потоках, присуща симметрия и случайность, а еще особая красота неопределенности, распространяющаяся в шести направлениях. ‹…› Пока растущая снежинка летит к земле (а обычно это занимает час или больше), формирование ее лучей в каждый момент зависит от температуры, влажности и загрязненности атмосферы. Размер каждой снежинки не превышает одного миллиметра, и на шесть ее лучей воздействует одна и та же температура. А поскольку законы роста снежинок детерминистские, они поддерживают в снежинках почти идеальную симметрию[72].

Снежинки – отличный пример самоорганизующихся паттернов (рис. 12.4). Природа изобилует и другими примерами, такими как полосы на зебрах, пятна на крыльях бабочек, дюны в пустыне Сахара и листья папоротника [Waldrop 1992: 65]. Паттерны образуются и в жидкостях. Так, было обнаружено, что в каждом океане имеются течения в виде полос шириной 150 километров, которые попеременно текут то с востока на запад, то с запада на восток со скоростью около 40 метров в час. Говорят, что ни одному ученому еще не удалось придумать объяснение этого феномена, охватывающего весь земной шар [Brahic 2008: 10].

Паттерны возникают не только в пространственной форме. Для живых систем решающее значение имеют циклические колебания, такие, например, как циркадные ритмы (или биологические часы), влияющие на сердцебиение, сон, а также периодические явления, происходящие в гормональных и ферментных системах [Lewin 1999: 29]. Еще одним красивым примером из мира природы, часто упоминаемым в литературе по теории сложности, будут светлячки, живущие в Юго-Восточной Азии. В брачный период они в невообразимых количествах слетаются на деревья и мерцают в гармоничном ритме [Gleick 1987: 293].

Случаи возникновения паттернов в сложных системах – это эмерджентные события. Невозможно указать, какой именно из агентов обуславливает возникновение того или иного паттерна, и тем не менее эти паттерны существуют.

С точки зрения теории сложности не все паттерны похожи друг на друга. Есть важное различие между листьями папоротника и дюнами в Сахаре. Или между гармоничным миганием светлячков на деревьях и расходящимися по поверхности бассейна концентрическими кругами после того, как я уронил туда свой мобильный телефон. Разница в том, что некоторые паттерны имеют практический смысл, в то время как другие существуют только как интересный побочный эффект. Формирование кристалликов льда на окнах моей машины не преследует никакой цели (если не считать целью заставить меня поработать скребком). Но есть вполне практические причины, почему мое сердцебиение ускоряется (оставаясь тем не менее регулярным) в ситуации, когда моя машина скользит по обледенелой дороге.

Совершенно очевидно, что и в вашей компании при формировании команд и осуществлении коммуникации образуются как пространственные, так и временны́е паттерны. Ими заполнена вся Вселенная, так почему же они не должны существовать в командах разработчиков? Однако, чтобы возникающие паттерны имели смысл, необходимо, чтобы менеджеры позволяли им возникать в результате самоорганизации. Отдельному менеджеру не под силу управлять командами так, чтобы те «прошли кристаллизацию», или заставить членов команды мерцать в гармоничном ритме. Конечный результат никогда не будет выглядеть так же хорошо, как в случае самоорганизации.

Прежде чем мы начнем обсуждать организационные модели в главе 13, нам необходимо рассмотреть вопросы, связанные с масштабированием систем.

Симметрия в масштабе: большие и маленькие паттерны

Математик Бенуа Мандельброт обнаружил, что колебания цен на хлопок носят абсолютно случайный и непредсказуемый характер, и вид, который принимают эти колебания, не зависит от масштаба: графики ежедневных, ежемесячных и ежегодных колебаний цен были идеально подобны друг другу. Более того, в книге «(Не)послушные рынки»[73] Мандельброт утверждает, что подобные колебания свойственны любым фондовым биржам: цены ведут себя неуправляемо, повышаясь и понижаясь вне зависимости от масштаба [Mandelbrot, Hudson 2006]. Мандельброт хорошо понимал, о чем говорит, потому что он был создателем фрактальной геометрии.

Фракталы – объекты, которые самоподобны во всех масштабах (рис. 12.5), то есть они выглядят одинаково независимо от того, под каким увеличением вы их рассматриваете [Gleick 1987: 86]. Такое самоподобие подразумевает рекурсию и паттерны внутри паттернов. Фракталоподобные объекты были обнаружены в классической музыке, где локальные музыкальные фигуры могут походить на фигуры на уровне всего произведения. Шумы, возникающие в телефонных линиях, обладают фрактальным характером, поскольку выяснилось, что картина распределения ошибок в каналах связи самоподобна на любых отрезках времени – секундах, минутах, днях или неделях [Solé 2000: 50]. Фракталы успешно применяются в кино при построении с помощью компьютерной графики изображений ландшафтов, растений и животных, поскольку основанные на фрактальной геометрии объекты выглядят одновременно и сложными, и естественными [Gleick 1987: 114].

В нашем теле тоже есть фракталы. Кровеносные сосуды в организме делятся и ветвятся почти бесконечно, и это ветвление имеет фрактальный характер. Причина в том, что кровь – это дорогой и дефицитный ресурс, она должна поступать в огромное количество клеток и питать их. Природа «поняла», что использование фрактальных структур будет наиболее эффективным способом достижения этой цели [Gleick 1987: 108].

Фракталы позволяют создавать сложные структуры на основе нескольких простых математических правил. А поскольку такие структуры масштабно инвариантны (то есть самоподобны как в мелком, так и в крупном масштабе), любые эффективные решения или высокая продуктивность, достигаемые на небольших масштабах, могут обеспечить такие же результаты в любых масштабах. Таким образом, чтобы большая система функционировала хорошо, необходимо, чтобы она была подобна хорошо работающей небольшой системе.

Установлено, что во всех без исключения случаях хорошо функционирующие сложные системы возникли из простых. Сложные (в данном случае этот термин имеет смысл «большие и запутанные». – Прим. авт.) системы, созданные с нуля, никогда не работают, и исправить их с тем, чтобы они заработали, невозможно. Вам придется начать заново и для начала создать простую систему, которая будет работать нормально[74].

И все же между математическими системами и реальными, пытающимися выживать и расти в физическом мире, есть ряд важных отличий.

Как расти: вертикально или горизонтально?

В качестве наемного работника я всегда предпочитал небольшие компании, потому что в них намного легче сделать что-то значимое. К тому же в небольшой компании гораздо проще вывести генерального директора из себя, поскольку он хотя бы знает, кто ты такой. В то же время я испытываю определенные проблемы, когда приходится работать в самой маленькой из всех возможных организаций – в которой, кроме меня, никого нет. Несмотря на то, что это самая естественная среда для того, чтобы добиться значимых результатов, ей присущи и определенные недостатки – например, как бы плохо вы ни работали, разозлить этим вы сможете только себя. Поэтому любой из тех, кто работает в одиночку, всегда ищет возможности для роста и стремится наладить сотрудничество с другими людьми. Но как это сделать? Разработчики программного обеспечения знают, что в принципе существует только два варианта масштабирования системы: вертикальное и горизонтальное.

Горизонтальное масштабирование заключается в создании множества небольших систем. Размер исходной системы остается тем же самым, а рост обеспечивается тем, что она производит на свет дополнительные версии самой себя. Биологи считают, что для многих биологических видов оптимален именно горизонтальный рост.

Известно, что коалиции, состоящие из самцов львов, способны контролировать целую стаю самок, что не под силу отдельно взятому льву. Рой пчел может напасть на человека и закусать его до смерти, хотя укус отдельной пчелы причиняет лишь небольшую боль. Среди морских львов значительно более низкие показатели смертности детенышей наблюдаются там, где молодняк воспитывается в группах, в то время как потомство пар, живущих отдельно, умирает гораздо чаще [Corning 2003: 17, 123].

Однако организмы не только научились сотрудничать в рамках групп и тем самым реализовывать экономию за счет увеличения масштаба. Многие виды имеют тенденцию со временем увеличиваться в размерах, как заметил еще более ста лет назад палеонтолог Эдвард Коуп. Вначале особи данного биологического вида могут иметь небольшой размер, но они дают постепенно увеличивающееся в размерах потомство – это утверждение теперь известно как правило Коупа [O’Donogue 2009: 39].

Вертикальный рост означает, что особи данного вида (или их потомки) со временем становятся крупнее. Увеличение размеров дает определенные эволюционные преимущества. Снижается вероятность стать жертвой хищников, а кроме того, крупным особям легче бороться с конкурентами за продовольственные ресурсы или за сексуальных партнеров. У очень крупных видов гораздо больше шансов добиться популярности, пугая посетителей музеев своими размерами.

Но увеличение размеров имеет и обратную сторону. Крупные виды потребляют больше ресурсов и медленнее размножаются, а это означает, что, когда наступают тяжелые времена, они становятся первыми кандидатами на вымирание. В этом еще одна причина, почему такие виды часто заканчивают свой путь в музее.

По-видимому, для биологических видов в природе и для организаций в экономике воздействие положительной обратной связи, работающей на увеличение размеров и снижение уязвимости, в конечном счете сводится на нет отрицательной обратной связью (снижение адаптируемости). Против экономии, связанной с увеличением масштаба, работает закон убывающей отдачи.

Вертикальный рост оказывается более хлопотным делом, чем стратегии, связанные с ростом горизонтальным. Если рассматривать общую биомассу на планете, то мы должны будем признать, что биомасса бактерий, растений, муравьев и антарктического криля в совокупности превосходит биомассу любого из более крупных видов – включая людей и крупный рогатый скот. Нам хотелось бы верить, что мы – доминирующий вид, но суммарный вес перечисленных выше организмов говорит сам за себя. С точки зрения теории сложности горизонтальный рост, без сомнения, более эффективен, чем вертикальный. Группы, состоящие из множества небольших систем, более гибкие и менее подвержены вымиранию, чем группы, в состав которых входит по нескольку больших систем. Может быть, все дело в том, что антарктическому крилю больше нравится плавать в океане, чем стоять заспиртованным в музейной банке.

В главе 13, посвященной практическим аспектам управления ростом организаций, мы увидим, как от теоретических представлений об оптимальном количестве соединений внутри системы, границах, паттернах и масштабировании можно перейти к полезным практическим идеям, позволяющим выращивать эффективные организационные структуры и улучшать коммуникации внутри компании.

Резюме

В организациях передача искаженной информации будет скорее нормой, чем исключением. Одна из причин этого явления в том, что коммуникация между людьми требует надлежащей обратной связи, а последняя зачастую отсутствует.

Можно выделить девять коммуникативных компетенций, обычно представленных в организациях. Все они проявляются у людей в разной степени. Это объясняет, почему организации – очень сложные коммуникационные сети.

Исследователи выявили целый ряд эффектов, возникающих в социальных сетях. Интересным примером будет эффект гомогенизации. Его суть в том, что информация, которая уже многократно скопирована, имеет тенденцию к дополнительному копированию, а это позволяет объяснить, каким образом происходит распространение культурных веяний, моды и тому подобного.

Чтобы оптимизировать коммуникацию, следует настроить соответствующие соединения. Также требуется сочетание конкуренции и сотрудничества. Оптимальный обмен информацией может приводить к возникновению автокаталитических (гиперпродуктивных) команд.

Структура организации в значительной степени предопределяет эффективность коммуникаций в ней. На материале фракталов становится ясно, что структуры, инвариантные к масштабу, более эффективны, к тому же их можно создавать на основе лишь небольшого количества правил. Еще один вывод состоит в том, что горизонтальный рост (создание множества небольших систем) работает лучше, чем вертикальный (наращивание размера одной системы).

Подумать и сделать

Давайте посмотрим, как вы можете применить некоторые идеи из этой главы в своей компании:

• Вместе с командой обсудите девять коммуникативных компетенций. Постарайтесь вместе выяснить, кто и какими из этих компетенций обладает. Какие компетенции недостаточно (избыточно) представлены в вашей команде? Можете ли вы что-нибудь предпринять, чтобы улучшить ситуацию?

• Обсудите со своими сотрудниками сложившуюся ситуацию с командной работой. Действительно ли люди сотрудничают друг с другом? Они делают это из альтруистических побуждений или потому, что думают, что сотрудничество – в их собственных интересах?

Глава 13 Как выращивать структуру

Все крупные корпорации испытывают всепроникающий страх, что кто-то из их сотрудников в рабочее время развлекается за компьютером. Существование социальных сетей превращает этот страх в панический.

Джон Чарльз Дворак, публицист,теле– и радиоведущий (род. 1952)

Я люблю структурированность. Это можно заметить по тому, как организованы папки на моем компьютере, мой блог, мои финансовые документы и бумажные архивы. У всего есть свое место и предназначение. У меня даже есть аккуратная белая коробка, подписанная «Всякая хрень – Юрген», позволяющая отделить мои вещи от «всякой хрени Рауля». Точно так же мне хочется знать все о структуре организации, в которой я работаю, – для чего предназначен тот или иной отдел или подразделение. Включая всякую хрень.

В этом и состоит цель данной главы. Она даст вам общее представление об адаптивных принципах организационного дизайна и некоторых идеях, как выращивать структуру в вашей компании. Я уверен, что лучшая коммуникация следует за лучшей структурой, поэтому в этой главе фокус на структуру. Мы увидим, что не существует универсальной структуры и что менеджерам необходимо фокусироваться на поддержании способности компании к постоянной реорганизации.

Модель Менеджмента 3.0 включает специальный компонент, отвечающий за рост организационных структур. В сложных системах структура возникает сама собой. Но поскольку вы как менеджер отвечаете за направление, в котором движется компания, то должны осознавать, что одни типы структур полезны, а другие – нет. Необходимая степень управления и вмешательства со стороны менеджмента зависит от зрелости и компетентности людей, входящих в вашу команду.

О внешней среде, продуктах, размерах организаций и людях

Меня часто спрашивают: «Как мне структурировать мой бизнес и мои команды»? (Вообще-то меня никто не спрашивает, но, может быть, такие вопросы появились после прочтения предыдущей главы.) К сожалению, простого ответа на них не существует. По крайней мере правильного простого ответа. С таким же успехом можно спросить: «Как выглядит оптимальная форма для биологического вида?» Сама постановка вопроса бессмысленна. Нельзя утверждать, что форма морских звезд имеет преимущества перед формой паука. Оба вида существуют и нашли себе нишу, обеспечивающую их выживание. Паук не может жить в море. А морская звезда не выживет у меня в подвале. То же самое относится к организациям. «Оптимальная» структура зависит от внешней среды, в которой компании необходимо выживать.

Таким образом, мы видим, что в современных условиях не существует решений, не зависящих от времени или контекста. Это также распространяется на организационные структуры. В той же степени, насколько верен этот тезис в целом, не существует – и, скорее всего, никогда не будет существовать – универсальной организационной структуры, обеспечивающей максимальную общую эффективность[75].

Но структура компании зависит не только от среды, в которой эта компания функционирует. Вторым фактором организационных изменений будет производимый ею тип продуктов. Закон Конвея гласит:

Организации, занимающиеся проектированием систем… обречены производить системы, являющиеся копиями коммуникационных структур этих организаций[76].

Из этого интересного наблюдения Конвея легко сделать вывод, что организации должны быть адаптированы к тем типам продуктов, производством которых они занимаются [Poppendieck 2009: 67]. Следовательно, вторым драйвером организационной структуры будут разрабатываемые данной компанией продукты.

Третьим фактором, влияющим на организационную структуру, будет размер компании. По мере роста компании периодически нуждаются в реструктуризации, чтобы своевременно приводить организационную структуру в соответствие со своим размером, в том числе в случаях, когда внешняя среда и тип производимых продуктов остаются неизменными.

Как правило, каждый раз, когда размер компании увеличивается на 50 %, необходимо задуматься, не появилась ли необходимость в структурных изменениях. К моменту, когда размер компании увеличился вдвое, соответствующие структурные изменения должны быть уже завершены[77].

И наконец, последним фактором, влияющим на организационные изменения, будут люди. Не случайно появление новых менеджеров и новых команд (даже если больше ничего не изменилось) часто имеет своим результатом реструктурирование компании. Разным людям нужны разные структуры.

Изменения во внешней среде, типах продуктов, размере компании и привлекаемых людях – все это приводит (или должно приводить) к изменениям в структуре организации. Бизнес, который не меняется вместе с обстоятельствами, оказывается заключенным в своем мире внутри непроницаемой капсулы, и в этом мире масса усилий расходуется на выполнение действий, не имеющих никакой ценности. Знаменитым примером этого феномена будет закон Паркинсона, в соответствии с которым «работа заполняет все время, отведенное на нее». Если вовремя не отказаться от структур, существующих в организации по привычке, они будут продолжать придумывать для себя новую работу только потому, что располагают мощностями для ее выполнения.

Люди, с которыми я работаю, знают, что я не против регулярных изменений команд и подразделений. Это, конечно, не значит, что изменения должны превратиться в самоцель. Но я также не считаю, что структуре нужна стабильность ради стабильности. Когда я перехожу на другую работу и покидаю компанию, меня не слишком беспокоит, что сменивший меня менеджер захочет пересмотреть мое «наследие» и внести организационные изменения. Времена меняются вместе с новыми конкурентами, новыми продуктами, новыми сотрудниками и новыми менеджерами. Я бы забеспокоился, если бы мой бизнес вдруг перестал реагировать на такие изменения.

Я не думаю, что менеджерам требуется обзор лучших организационных диаграмм. Что им действительно нужно – это совет о том, как добиться приспособляемости. Все виды различны, но объединяет их одно: принцип приспособляемости встроен в их ДНК. Вот то, что мы ищем. Мы хотим знать, как сделать бизнес приспособляемым, так чтобы организация могла приобретать разные структурные формы в зависимости от контекста, продуктов, размеров и людей.

При чтении книг, посвященных организационным структурам, я заметил, что многие из них включают описание «стандартной» иерархической функциональной организации, а затем переходят к обсуждению «альтернативных» структур, которые, по мнению авторов, более эффективны [Augustine 2005]. В других книгах порой приводятся различные организационные архетипы или «формы», возникающие под воздействием внешней среды [Mintzberg 2009: 106]. Я попытаюсь применить другой подход и приведу несколько рекомендаций для адаптивных организаций, которые вы сможете использовать для выращивания собственных организационных структур.

По моему мнению, ситуация аналогична тому, как существует несколько удачных базовых биологических форм, имеющих огромное количество вариаций. Ни одна из них сама по себе не будет предпочтительной. Морская звезда не лучше, чем паук. Хотя должен признаться, что пудели мне нравятся больше, чем чихуа-хуа.

Сначала подумайте о специализации…

Предположим, вы издатель журнала о кулинарии. Это глянцевый журнал с рецептами, обзорами ресторанов, множеством фотографий дорогой посуды и столовых приборов, а также звезд, занятых поеданием устриц. Журнал выходит ежемесячно, и огромное количество рецептов, обзоров и фотографий стоят в очереди на появление в следующем выпуске. Сдача номера в печать всегда вызывает стресс у всех участников процесса. Звезды все никак не могут назначить время для кулинарной фотосессии. Шеф-повара жалуются на качество фотографий с их кулинарными шедеврами. А некоторые рецепты настолько плохи, что вы не стали бы их готовить даже для соседской собаки.

И вот к вам подходит главный редактор и говорит, что у него есть решение всех проблем. По его словам, оно очень простое и эффективное. Оно называется генерализация. Различные роли, которые исполняют сотрудники журнала, сольются в единую роль с названием «член команды». Никаких специалистов больше не будет, а все станут делать то, что необходимо, чтобы журнал выходил в срок. Авторам статей отныне будет разрешено проводить фотосессии, если они вдруг окажутся поблизости от какой-нибудь звезды. Любой шеф-повар (при условии, что у него остался хотя бы один палец на руках) сможет писать ресторанные обзоры. А если фотографам удастся закончить свою работу пораньше, они могут помочь с написанием статей и рецептов. С такой командой специалистов широкого профиля никаких проблем с выходом очередного номера больше не будет (рис. 13.1). Ну как? Вы согласны?

Я бы сказал главному редактору, что он рехнулся. Если я лежу на операционном столе и мне делают подтяжку глаз, буду ли я просить операционную сестру заняться мной, потому что хирург опаздывает? Скажу ли я ей «А заодно удалите мне гланды»?

В принципе, генерализация – прекрасная идея. Но специализация – это ваш первый друг. Исследования подтверждают, что команды специалистов эффективнее, чем команды, составленные из генералистов [Anderson 2004: 271]. Если мы включаем в команду только последних, то игнорируем все, чему человечество научилось за последние 235 лет – с того самого момента, когда Адам Смит показал, что специализация ведет к повышению производительности и процветанию. Специализация объясняет, почему разработчики софта сами не пекут себе хлеб, не шьют одежду и не выращивают еду (конечно, бывают исключения, но их не так много). Чем крупнее экономика или организация, тем больше людей хочет (и может) специализироваться в той области, к которой у них больше всего способностей. Этот механизм доказал свою эффективность, причем не только в случае отдельных индивидуумов, но и в масштабах всего мира.

… И только потом о генерализации

С другой стороны…

У специализации свои проблемы. Порой она приводит к возникновению узких мест, если специалисты не справляются со свалившимся на них объемом работы, а заменить их некем. Однажды мне пришлось самому заниматься дизайном корпоративного сайта, включая интерактивный и графический дизайн, поскольку наши обычные дизайнеры были расписаны на недели вперед. Специализация также может приводить к застою, если специалисты не могут (или не хотят) браться за работу, с которой незнакомы. Например, однажды я был вынужден просить разработчика ПО помочь мне решить несколько маркетинговых задач. Просто повезло, что он охотно согласился, иначе бы проект застопорился.

Я не люблю, когда люди говорят мне, что они обладают «широким набором умений», имея в виду, что они никогда не специализировались в конкретной области. Я совершенно определенно предпочитаю специалистов генералистам. Но еще больше мне нравится, когда у специалиста есть еще парочка областей, в которых ему удалось набраться кое-какого опыта. К счастью, я не одинок в этом мнении.

Специалист со склонностью к генерализации 1) имеет одну или две технические специализации… 2) обладает как минимум общими знаниями в области разработки ПО; 3) обладает как минимум общими знаниями индустрии, в которой данное ПО применяется; 4) стремится активно расширять свои знания как в области своей специализации, так и в других областях, включая технические и предметные[78].

Специалист со склонностью к генерализации выполняет один вид работы очень хорошо и еще несколько с приемлемым качеством. Если у вас в команде есть такие люди, повышается ее эффективность и снижается риск возникновения узких мест. Специалистов со склонностью к генерализации иногда называют Т-специалистами. Их основная специализация выглядит как вертикальная палочка, но они также любознательны и готовы развиваться в других направлениях. Такие люди являются ценным приобретением, поскольку они видят проблему с нескольких точек зрения [Brown 2005].

Нанимая людей и комплектуя команды, ищите Т-специалистов. Сначала всегда проверяйте, действительно ли они серьезные профессионалы в одной из нужных вам областей, а затем убедитесь, что они готовы брать на себя и другие виды работ. Если вам нужен разработчик ПО, удостоверьтесь, что он хороший специалист. Но также не забудьте задать ему несколько вопросов по компьютерной графике, дизайну, а может быть, даже и из области маркетинга.

А генералисты со склонностью к специализации? Они вообще существуют?

Да, определенно существуют. Это люди, которые с приемлемым качеством решают многие задачи, но обычно у них лучше получается справляться с задачами одного или двух видов. Они похожи на специалистов со склонностью к генерализации, но все же они лишь во вторую очередь специалисты, а в целом остаются генералистами. Я их ценю почти столь же высоко, как специалистов со склонностью к генерализации.

Расширьте названия должностей

Когда я работал директором по IT-технологиям, у меня бывали конфликты с HR-отделом по поводу хаоса, царящего в названиях должностей в некоторых подразделениях нашей компании. В командах, насчитывающих не более десяти человек, можно было обнаружить разработчиков контента, менеджеров контента, веб-редакторов, веб-дизайнеров, дизайнеров интерактивных интерфейсов, дизайнеров пользовательских интерфейсов, разработчиков пользовательских интерфейсов, веб-менеджеров и специалистов по пользовательским интерфейсам. В чем смысл всех этих названий? Не знаю. Так же как не знают и сами их носители. Я много раз всем говорил, что чем меньше названий должностей используется, тем лучше. И всех этих разработчиков и дизайнеров можно было бы назвать Восточные служащие, насколько я могу судить.

Команда, в которой я работал, когда писал эту главу, состояла из четырех отличных человек. Один из нас знал все об API, разработкой которого мы занимались. Он решал, как должен выглядеть этот интерфейс, как его деплоить и сохранять преемственность между разными релизами. Он был нашим лидером во всем, что касалось этой темы. Второй член команды был самым молодым. Но у него были явные способности в области системной архитектуры. Наш третий коллега знал все о социальных медиа и электронной коммерции. Он был нашим лидером, когда речь шла об онлайн-маркетинге и коммуникативных стратегиях. И наконец, я выполнял функции Владельца проекта и принимал решения, касающиеся функциональности, приоритетов и загрузки остальных работой, чтобы они не скучали и не начинали усложнять то, что в этом не нуждается.

Каждый из членов команды был лидером. Мы выполняли роли, соответствующие нашей специализации, но отнюдь не названиям наших должностей. У нас не было программиста интерфейсов, системного архитектора, консультанта по маркетингу или владельца продукта. При необходимости нам приходилось выполнять обязанности друг друга. (А такая необходимость возникала часто, поскольку я довольно много выступаю на конференциях по всему миру.)

Я уверен, что для лучшей приспособляемости компании не надо ограничивать зону ответственности названием должности. Название должности должно подразумевать достаточно широкий круг обязанностей. Меняются они нечасто (иногда раз в несколько лет), поэтому связь между названием позиции и кругом повседневных обязанностей не должна быть слишком жесткой. Так, название должности «разработчик ПО» оставляет вам больше свободы для перераспределения обязанностей, чем «аналитик». Даже если кто-то из сотрудников будет просить вас, чтобы его позиция называлась «аналитик», скажите ему, что в его контракте должность будет называться «разработчик программного обеспечения», а его роль будет состоять в том, чтобы быть аналитиком. На данный момент.

Расширенные названия должностей могут использоваться для обозначения нескольких ролей. Позиция «разработчик программного обеспечения» может включать широкий диапазон функций, начиная с дизайна, разработки и тестирования и заканчивая проектным менеджментом и техподдержкой [Abran 2004]. Поэтому «разработчик» в вашей организации может выполнять, например, роль программиста, тестировщика, специалиста по техподдержке и бизнес-аналитика. При этом сотрудникам, определение должностей которых далеко выходит за рамки позиции «разработчик» (например, менеджерам по работе с клиентами или системным администраторам), данные роли никогда поручаться не будут.

Гибкость людей – причина, почему в Scrum все сотрудники именуются просто «членами команды». Этим подчеркивается ответственность каждого человека за своевременное завершение проекта независимо от официального названия должности. Никто не может заявить: «Не буду это делать. Это не моя работа». Если для того, чтобы программный продукт вышел в срок, понадобится почистить клавиатуру, на которой работает клиент, значит, ваша работа в данный момент в этом и состоит. Некоторые организации заходят настолько далеко, что в них все позиции называются «партнеры». Это прививает привычку к гибкости и стремление работать на результат.

Обратите внимание на то, что расширенные формулировки названий должностей хорошо поддерживают концепцию специалистов-генералистов. Каждый должен специализироваться в какой-то области и при этом сохранять гибкость. Сотрудники должны быть лишены возможности апеллировать к названиям своих должностей для оправдания своей узкой специализации. Это совсем не то, что требуется в адаптивной организации.

Вам нужен ограниченный набор названий должностей плюс некоторые правила, устанавливающие, какие неформальные роли могут выполняться в рамках той или иной позиции. Любые инициативы по расширению набора должностей и просьбы формализовать роли и обязанности необходимо пресекать в зародыше.

Уже многие годы моя должность называется CIO. Это прекрасное название, потому что эти буквы могут означать почти все что угодно. (Например, в зависимости от контекста буква I может обозначать такие слова, как «информация», «интерактивность», «инновация», «иллюстрация», «идеализация», «итерация», «ирригация», «интонация», «имитация» и так далее.) Очень часто моя текущая деятельность или проекты, которыми я в данный момент занимаюсь, не имеют никакого отношения к этому названию. Просто есть некий объем работы, который должен быть выполнен, вот и все.

Культивируйте неформальное лидерство

Лидеров, которые появляются внутри команд, иногда называют лидами или ведущими специалистами. Например, они могут называться техлидами, ведущими разработчиками, ведущими программистами и ведущими архитекторами. Общее у таких людей то, что они не будут линейными менеджерами своих коллег по команде. Неформальными лидерами становятся благодаря своим заслугам или принятым на себя обязательствам. Это предполагает ответственность, не имеющую ничего общего с ответственностью линейных менеджеров [Testa 2009: 53]. Когда подобные лидеры возникают сразу в нескольких местах, такое неформальное лидерство называется распределенным. Его возникновение логически связано с наличием в командах специалистов со склонностью к генерализации и расширенной трактовкой названий должностей.

Вы можете активно культивировать неформальное лидерство в своих командах, поддерживая зарождающихся лидеров (но не пытайтесь назначить кого-то на эту позицию!). Разрешите командам самим решать, нужны ли им техлиды, ведущие разработчики или другие лидерские роли. (Обратите внимание, что многие команды при отсутствии в их составе сильных лидеров могут проявлять признаки дезорганизованности. Возможно, вам понадобится подталкивать свои команды и помогать им решать проблемы с лидерством.)

Ни одна из упомянутых здесь ролей не затрагивает управленческий уровень. Именно благодаря этому неформальное лидерство позитивно сказывается на адаптивности организации. Воздерживаясь от появления очередного иерархического уровня для разнообразных ведущих специалистов, организация сохраняет гибкость при создании, перемещении и ликвидации этих ролей. Когда возникает потребность в ведущем графическом дизайнере, эту роль можно создать немедленно, а если потребность в соответствующих услугах со временем исчезнет, исчезнет и сама эта роль. При этом сотрудник остается. Но если роль точно эквивалентна должности, то для занимающего эту должность сотрудника пришлось бы искусственно придумывать нагрузку либо просить его перейти на другую должность, а то и вовсе уволить в связи с отсутствием для него объема работ. Необходимость принимать такие неприятные меры плохо сказывается на продуктивности компании.

Специалисты со склонностью к генерализации, расширенные названия должностей и неформальное лидерство – разные, но тесно связанные понятия (рис. 13.2). Хотя они склонны усиливать друг друга, вы можете вводить их одно за другим, что особенно важно, если вы постепенно делаете из бюрократической организации более гибкую. Но не спрашивайте меня, в каком порядке их следует вводить. Мой опыт ограничивается компаниями, где сотрудники относились к работе с энтузиазмом и были готовы проявлять гибкость, так что все три идеи находили себе применение одновременно.

Поддерживайте границы между командами

В главе 12 мы видели, что люди проявляют тенденцию к созданию групп. Когда группа небольшая и имеет разделенную цель, ее можно назвать командой. Само понятие команды очень полезно, поскольку позволяет установить идентичность единого целого, состоящего из отдельных людей. В психологии это называется укрупнением.

Идея укрупнения: группа объектов воспринимается как единый блок. Граница этого блока немного похожа на клеточную мембрану или границу государства. Она определяет идентичность блока, состоящего из группы объектов. В зависимости от контекста мы можем игнорировать внутреннюю структуру блока либо учитывать ее[79].

На моем последнем месте работы нам приходилось иметь дело со множеством небольших проектов и десятками разработчиков и тестировщиков, работающих из разных мест. Постоянным кошмаром была необходимость формировать из них команды под конкретные проекты. Мы меняли подходы к созданию команд чаще, чем Мадонна меняет свой имидж. Но управление границами команд – важная часть обязанностей менеджера, и тут нужно все делать правильно. Команды не очень хорошо работают, когда люди не понимают, в какую команду они входят и на кого можно положиться.

При управлении границами команд надо обращать внимание на три аспекта: как именно структурированы команды, как соотносятся отдельные сотрудники и команды и как команды меняются со временем. В организациях, сотрудники которых находятся на высоком уровне в плане зрелости и наделены широкими полномочиями, возможен самоотбор людей в команды (см. главу 7). В такой компании вы создаете пул кандидатов на вхождение в команду, а затем предоставляете людям самим сформировать ее. Есть проекты, участвовать в которых хотят все, а есть и такие, для которых трудно найти желающих. Очень интересно со стороны наблюдать за горячими спорами, в ходе которых группа сотрудников пытается выработать правила формирования команд. Но в реальных условиях увидеть процесс самоотбора в действии удается лишь изредка. Об этой практике стоит подумать, но вы должны быть уверены, что люди действительно понимают, как правильно формировать команды. Получить на выходе команду из тридцати разработчиков и еще одну, в составе которой двадцать тестировщиков, – не самый лучший вариант. Возьмите, к примеру, какой-нибудь бойз-бенд: в теории в ее состав, конечно, может входить тридцать человек, но тогда это будет скорее хор мальчиков, и с такой численностью вряд ли они будут обладать достаточной гибкостью, чтобы оставаться в тренде индустрии развлечений, как это удается небольшим музыкальным группам. Чтобы повысить шансы команды добиться успеха, вам понадобится вначале наложить определенные ограничения на ее численный состав, необходимость включения разных специалистов и некоторые другие.

Еще одна связка, которую нужно брать в расчет, – то, как отдельные люди соотносятся с командами. Может ли один и тот же сотрудник входить более чем в одну команду? Когда людей просят уделять силы нескольким командам, это, как правило, отрицательно сказывается на продуктивности. Мик Джаггер не пытался в дополнение к The Rolling Stones подрабатывать в группе Jackson Five, и на это есть веские причины. Такие ситуации приводят к тому, что люди разрываются между разными задачами, возникает конфликт интересов, размываются обязательства и пропадает мотивация. Сделайте все возможное, чтобы конкретный сотрудник был членом только одной команды. Люди не будут эффективно действовать как часть команды, если не знают, кто в нее входит. Они могут время от времени помогать сотрудникам из других команд с их проектами или время от времени исполнить дуэт, но у каждого сотрудника должна быть только одна своя команда, в которую он возвращается с подобных заданий.

И наконец, важной темой будет жизненный цикл команд. Исследования показывают, что команды более эффективны, когда они достаточно долговечны. И не только при разработке ПО [Larman, Vodde 2009: 149/153], но и в других видах бизнеса, например в авиакомпаниях [Hackman 2002]. Так что лучше, чтобы команда существовала настолько долго, насколько это возможно, потому что для возникновения устойчивых правил и каналов связи требуется время. Оно также необходимо, чтобы люди как команда научились отличать, какая информация для них важна, а какая – нет. И еще подумайте вот о чем: какая поп-группа была самой знаменитой за всю историю? И как долго они были вместе? Больше, чем несколько лет? Я так и думал. Если ваши проекты по своей природе краткосрочны, постарайтесь сделать так, чтобы жизненные циклы команд были длиннее, чем жизненные циклы проектов. Так вы дадите одной и той же команде возможность выполнять несколько проектов один за другим.

Оптимальный размер команды – пять человек (скорее всего)

Каков оптимальный размер команды? Это один из самых интересных вопросов, который обсуждается с того самого момента, когда люди впервые объединились и убили мамонта.

Однажды я участвовал в конференции, где одну из сессий проводил Джозеф Пелрайн, эксперт в области сложных социальных систем. Он сообщил нам, что в качестве оптимальной численности социальных групп в исследованиях упоминаются (или это так или иначе следует из содержания соответствующего исследования) группы, состоящие из 5, 15 и 150 человек.

В Agile-методологиях, ведущей из которых на момент написания этой книги стал Scrum, в качестве предпочтительной численности команд часто указывается «семь человек плюс-минус два» (разработчики предпочитают именно так обозначать диапазон от пяти до девяти человек).

Исследования оптимальной численности групп для принятия решений позволяют сделать вывод, что эффективными будут группы, насчитывающие менее двадцати человек [Buchanan 2009: 38–39]. Группы от двадцати человек и более вряд ли можно называть командами. Если численность превышает двадцать, такое сообщество людей следует называть просто группой. (Я пишу этот текст тайком во время Скандинавской конференции разработчиков ПО, в которой участвует 600 человек. Это группа, а не команда.)

В статье этого автора отдельно упоминаются восемь человек в качестве примера неудачной численности команды, поскольку в этом случае мнения часто разделяются поровну. В ней даже утверждается, что Карл I, единственный британский монарх, работавший с тайным советом, состоящим из восьми членов, принимал настолько плохие решения, что в конечном счете это стоило ему головы [Buchanan 2009: 39].

С учетом всех этих данных мы приходим к выводу, что есть только одна конфигурация, которая удовлетворяет всем условиям: в составе команды должно быть пять человек.

Пять человек – один из трех вариантов оптимальной численности, упомянутых Джозефом Пелрайном. Эта численность также находится в диапазоне, рекомендуемом для Scrum-команд. Пять меньше двадцати и не равно восьми. Это число также приблизительно равно среднему значению 4,6, которое было определено как оптимальная численность команд в исследовании, проведенном профессором Ричардом Хэкменом [Hackman 2002: 116–122]. Но лучше всего, что это мое любимое число. Так что все правильно.

Пять – это ответ, который я даю по умолчанию, когда могу ответить на вопрос, не имея доступа к дополнительной информации. Видите ли, на самом деле я не могу сказать вам, какова оптимальная численность команды. Поэтому предлагаю вернуться к уравнению Курта Левина (мы обсуждали его в главе 10 «Искусство создавать правила»). Сейчас вы поймете почему.

B = f(P,E).

Как мы говорили ранее, это уравнение означает, что поведение человека является функцией личности и внешней среды. Поскольку коммуникация – это часть поведения, то уравнение можно переписать в следующем виде:

C = f’(P,E).

Это означает, что коммуникация человека является функцией личности и внешней среды. А если мы будем говорить о группе людей, имея при этом в виду, что численность команды будет в том числе и вопросом коммуникаций, то уравнение примет такой вид:

S = f’’({P},E).

Эта версия уравнения говорит о том, что оптимальная численность команды является функцией от набора имеющихся личностей и внешней среды.

Другими словами, S (численность команды) может принимать любые значения! Для лунной программы «Аполлон-11» оптимальная численность команды составляла три человека. В регби играют команды по пятнадцать человек. Очевидным образом, оптимальная численность зависит от проекта, людей и внешней среды. И тем не менее статистически оптимальная численность команд может составлять пять человек. Можно обозначить это в виде интервала от трех до семи. Ну или на языке разработчиков как «пять плюс-минус два». При этом оптимальная численность, к счастью, не дотягивает до восьми (рис. 13.3).

Так что мы из всего этого узнали?

Моя рекомендация – не навязывать одну конкретную численность команды в качестве предпочтительной; при этом неплохо заранее ввести несколько ограничений. Например, скажите своим сотрудникам, что не разрешается создавать команды, насчитывающие более двадцати человек, и одновременно посоветуйте им ограничиться численностью пять плюс-минус два человека на одну команду. Затем пусть самоорганизация сделает свое дело и люди сами определят (в реальной операционной среде), какая численность для них оптимальна. Они хотят вместо одной команды из семи человек создать две по три и четыре человека? Почему бы и нет? Они хотят объединиться в одну команду из пятнадцати человек? Прекрасно, пусть сами убедятся, будет ли это работать. Только предупредите, что им может понадобиться все переосмыслить, когда обстановка или набор людей в команде изменится. И последний совет: будьте готовы вмешаться, если они хотят организовать команду из восьми человек (плюс-минус ноль).

Функциональные и кросс-функциональные команды

Независимо от того, создается ли команда менеджером или путем самоорганизации, необходимо ответить на важный вопрос: «Каким именно образом люди должны быть собраны в команды?» Фактически здесь есть два варианта: объединять людей по функциональному признаку или по бизнесу.

Первый вариант предполагает, что вы собираете разработчиков вместе с разработчиками, тестировщиков вместе с тестировщиками, а проектных менеджеров вместе с другими проектными менеджерами. Такие группы называются функциональными подразделениями, а основная мотивация этого способа организации – эффективность и возможности взаимного обучения в рамках данной функции [Larman, Vodde 2009: 243]. Сотрудникам, ответственным за пользовательские истории, легче всего научиться профессии, когда они входят в состав отдела, который может так и называться: «Отдел пользовательских историй».

При объединение по бизнесу в составе команды оказываются люди, работающие над созданием одной и той же бизнес-ценности, включая создание одной и той же функциональности, одних и тех же продуктов, или работающие на одного и того же клиента. Такие команды иногда называют кросс-функциональными, потому что все сотрудники заняты в одном и том же проекте (или проектах), в результате в составе группы оказываются специалисты в широком диапазоне областей – начиная с пользовательских историй и заканчивая бинарной сборкой.

В главе 12 мы говорили, что организовать в компании хорошую коммуникацию – очень важное и чрезвычайно нелегкое дело. Поэтому данное соображение должно приниматься во внимание при выборе того или иного варианта. Кто из сотрудников наиболее часто нуждается друг в друге? Те, у кого должности называются одинаково? Или те, кто работает над одним и тем же проектом?

Если вы проанализируете ежедневный поток коммуникации между сотрудниками, быстро станет ясно, что преобладающая часть коммуникации происходит между теми, кто ориентирован на один и тот же бизнес или проект, а не между теми, кто выполняет одинаковые функции.

Люди, работающие над одним и тем же проектом и выполняющие разные функции, испытывают бóльшую потребность в общении друг с другом, чем люди, выполняющие одну и ту же функцию, но работающие над разными проектами (рис. 13.4). Поэтому мы можем сделать вывод, что при реализации проектов кросс-функциональные команды будут наиболее подходящим решением.

Отмечается, что организации, в которых люди организованы по функциональному признаку, страдают от чрезмерной зависимости подразделений друг от друга (иногда такие подразделения называют функциональными колодцами). Создание даже самой незначительной бизнес-ценности (например, одной характеристики продукта) требует коммуникации и координации действий множества команд [Poppendieck 2009: 68]. По этой причине наличие функциональных колодцев оборачивается высокими затратами на осуществление взаимодействий [Augustine 2005: 26].

Когда вы строите команды вокруг функциональных колодцев, а не внутри них, затраты на взаимодействие ниже, но не равны нулю. Дональд Райнертсен перечисляет три недостатка, свойственные кросс-функциональным командам: субоптимизация на уровне проектов, потери в эффективности вследствие недостаточной координации между проектами и ограниченный обмен опытом между специалистами в одной области, работающими в разных проектах [Reinertsen 1997: 104]. Таким образом, представляется, что в случае с кросс-функциональными командами расходуются дополнительные ресурсы в связи с необходимостью синхронизировать стандарты, методы и подходы в рамках одинаковых функций в организации в целом. Например, менеджеру по обеспечению качества может потребоваться больше усилий, чтобы добиться применения лучших практик в тестировании, если тестировщики и другие специалисты, отвечающие за качество, разбросаны по разным командам. Но даже в этом случае цена, которую приходится платить за кросс-функциональность, обычно ниже, чем при функциональных командах.

У кросс-функциональных команд (их также называют проектными, органическими или продуктовыми) есть еще несколько дополнительных преимуществ. Среди них эксперты называют более качественные решения в области дизайна, снижение непродуктивных затрат при передаче частично готового продукта далее по производственной цепочке, более высокую скорость реализации проектов, адаптивность, упрощенное планирование и сфокусированность на результатах [Cohn 2009: 182–188], [Larman 2009: 154].

Два принципа организационного дизайна

Если в составе организации больше одной команды, возникает необходимость в координации. Идет ли речь о том, какой подход для логов выбрать, где в офисе поставить холодильник или каков должен быть порядок использования зала для демо, необходимо достичь согласия относительно того, как будут использоваться ресурсы, находящиеся в совместном пользовании нескольких команд.

Психолог Фред Эмери различает два базовых принципа координации деятельности команд. Он называет их первым и вторым принципами организационного дизайна.

В соответствии с первым из них местонахождение холодильника определяется людьми, которые в организационной иерархии находятся на один уровень выше, чем сами команды. Эти люди – либо линейные менеджеры команд, либо специально назначенный ими менеджер холодильника. Только он уполномочен решать такие вопросы (рис. 13.5).

Второй принцип предполагает урегулирование вопроса о местонахождении холодильника самими командами, то есть команды сами заботятся о согласовании границ. На практике это выглядит как переговоры. Например, команды могут договориться решать этот вопрос путем голосования, введения оплаты за пользование холодильником, ежедневной ротации права доступа к нему или просто подбрасывая монетку. Команды могут даже назначить менеджера холодильника и наделить его полномочиями принимать решения вместо себя. В рамках данного принципа решение в конечном итоге остается за командами (рис. 13.6). (И в таком случае неформальный лидер может оказаться необходим команде для того, чтобы предотвратить бесконечные обсуждения.)

Второй принцип организационного дизайна очень напоминает решение, которое специалист по сложным системам Стюарт Кауфман описывает как «участки»:

Кауфман говорит: разбейте организацию на участки, подчеркнув при этом, что участки должны взаимодействовать. Это совсем не то же самое, что создавать независимые, самодостаточные подразделения в традиционном менеджменте. Кауфман считает, что характер и частота взаимодействий между участками позволят сдвинуть всю систему к глобальному оптимуму, несмотря на то что каждый участок будет действовать исключительно в своих интересах. Для осуществления взаимодействий требуется язык или какой-либо другой механизм регулярной коммуникации. Кауфман подчеркивает, что участки должны быть связанными. Если говорить на управленческом жаргоне, участки должны общаться, и не только во время ежеквартального подведения итогов[80].

В этой аналогии участками будут самоорганизующиеся команды, а не управляемые подразделения. Их повышенная адаптивность (второй принцип организационного дизайна) в сравнении с участками, организованными согласно иерархическому менеджменту (в соответствии с первым принципом), напрямую вытекает из органического подхода к решению проблем. Каждая из команд пытается решить часть более крупной проблемы. Но из-за связанности команд решение, найденное одной командой, привносит изменения в проблему, решением которой занимаются соседние команды. Адаптивные действия соседних команд в свою очередь изменяют проблемы, решаемые остальными командами. В конечном итоге мы получаем экосистему, в которой команды (или участки) совместно занимаются решением одной крупной проблемы [Kauffman 1995: 252].

Очевидно, что принцип деления компании на участки (второй организационный принцип) – это оптимальный вариант при решении задач, связанных с выбором подходом к логированию, места для холодильника, порядка использования зала для демо и любых других вопросов, требующих координации команд. В случаях, когда решение требует координации команд, дайте им возможность осуществить ее самостоятельно. Первый принцип организационного дизайна (его воплощением будет человек – вы или другой менеджер, – принимающий решение вместо команд) становится оправданным только в том случае, если еще не решены все вопросы с компетентностью команд.

Выберите свой организационный стиль

В литературе и блогосфере можно найти огромное количество хвалебных отзывов о продуктивности кросс-функциональных команд. Иногда возникает ощущение, что это чуть ли не лучшая идея, которую человечеству удалось придумать с момента возникновения межличностного взаимодействия. Они-то уж точно отличная идея, пока вы не обнаружите, что подхватили какое-нибудь ЗППП, что совершенно не входило в ваши планы.

Я рад, что у меня нет опыта, связанного с такими ЗППП, но я точно знаю, что по крайней мере часть похвал в адрес кросс-функциональных команд совершенно незаслуженна. Существует ряд распространенных заблуждений, которыми мы обязаны авторам, в чьих работах функциональные команды ассоциируются с иерархиями, а кросс-функциональные – с органическими сетевыми структурами. Такая точка зрения как нереалистична, так и несправедлива.

В случае функциональных команд необходима координация между ними при реализации проектов, направленных на создание бизнес-ценности для клиентов. В то же время необходимость в координации между кросс-функциональными командами возникает в случаях, когда нужно распространить на них лучшие практики и одинаковые стандарты, урегулировать вопросы, связанные с использованием общих ресурсов, привести к общему знаменателю какие-то виды деятельности. Поэтому возникает вопрос: «Как именно должна осуществляться такая координация между командами?»

В предыдущем разделе мы видели, что у вас есть две возможности организовать координацию: применить либо первый, либо второй принцип организационного дизайна. Оба подходят как функциональным, так и кросс-функциональным командам. Возможные комбинации типов команд и организационных принципов дают четыре организационных стиля, показанных в табл. 13.1 и на рис. 13.7.

В целом кросс-функциональные команды работают лучше, чем функциональные, а второй принцип организационного дизайна удачнее первого. По этим причинам многие консультанты по Agile-методологиям предпочитают организационный стиль № 4. Но, как всегда, все зависит от контекста. Вам может потребоваться выбрать одну из двух других разумных альтернатив, представленных организационными стилями № 2 или № 3, – либо потому, что этого требует недостаточная зрелость команд или порядок коммуникаций, либо для того, чтобы осуществить постепенный переход от организационного стиля № 1 к № 4 (рис. 13.7).

Мне приходилось видеть кросс-функциональные команды, составленные из настолько молодых и неопытных (и даже безответственных) сотрудников, что они могли заразить своими проблемами половину компании, если бы менеджмент им это позволил. К счастью, в данной ситуации был выбран организационный стиль № 3, который и спас положение. Я также наблюдал продуктивные функциональные команды, состоящие из специалистов в одной области, которым была поручена разработка компонентов или продуктов, которые было бы слишком рискованно распределить между несколькими командами (речь шла о доступе к банковским счетам клиентов). И тем не менее такие функциональные команды были достаточно зрелыми, и им удавалось наладить эффективную координацию между собой без участия менеджеров.

Кросс-функциональные команды без координации со стороны менеджеров – отличная идея. Но они могут как решать, так и создавать проблемы. Хорошие менеджеры должны быть в состоянии самостоятельно выбирать оптимальный организационный стиль, который обеспечит как адаптивность, так и безопасность.

Превратите каждую команду в небольшую бизнес-единицу, создающую ценность

Последняя команда системных администраторов, с которой мне пришлось работать, была очень профессиональной. Они мне действительно нравились, но, по-видимому, я был их худшим клиентом. Не то чтобы я плохо себя вел. Просто моя аура оказывала непредсказуемое воздействие на электромагнитные поля. Были случаи, когда надежнейшее программное обеспечение давало сбои, если я просто проходил мимо, а самые устойчивые операционные системы имели тенденцию без видимых причин внезапно перезагружаться в моем присутствии. Поэтому мне так нравилось работать с этой командой сисадминов. Независимо от количества проблем, которые я им создавал, они неизменно относились ко мне как к клиенту.

Часто утверждают, что кросс-функциональные команды помогают избежать проблемы локальной оптимизации. Имеется в виду тенденция функциональных команд оптимизировать свою собственную эффективность, снижая при этом эффективность бизнеса в целом. Например, команда тестировщиков реализовала серьезную оптимизацию процедур, до минимума сократив время тестирования продуктов. Эта «эффективная» практика может иметь серьезные последствия для других фаз проекта, например связанных с разработкой продукта и его технической поддержкой после релиза. Но действительно ли эта проблема возникает из-за того, что команда тестировщиков организована по функциональному признаку? Или дело просто в том, что тестировщики не рассматривают разработчиков и специалистов по технической поддержке в качестве своих клиентов?

С кросс-функциональными командами возникает другая проблема. Они оптимизируют свою эффективность в рамках отдельных проектов, но и это порой приводит к снижению общей эффективности бизнеса. Например, возможны проблемы, если все проектные команды решат выбирать совершенно разную архитектуру для своих продуктов и разные средства разработки. Такой разброс в применяемых технологиях может серьезно затруднить одновременную поддержку всех этих проектов. Я уверен, что если бы я разрешил командам самостоятельно закупать компьютеры по своему выбору и устанавливать на них любимые операционные системы и средства разработки, то системные администраторы просто содрали бы с меня кожу живьем.

Большинство разработчиков ПО, с которыми мне приходилось работать, даже и не думают приглашать в свои команды системных администраторов. И не потому, что их не любят. Просто коммуникация внутри группы системных администраторов происходит гораздо более интенсивно, чем их коммуникация с проектными командами, даже если инфраструктура – важный компонент того или иного проекта. Поэтому гораздо разумнее, чтобы системные администраторы были организованы в свою функциональную группу, несмотря на дополнительные издержки при коммуникации, возникающие в этом случае.

Самое главное – чтобы функциональные и кросс-функциональные команды воспринимали себя в качестве бизнес-единиц, создающих ценность для своих клиентов независимо от того, внешние это клиенты или внутренние. Наша команда системных администраторов считала себя бизнес-подразделением, задача которого состоит в обслуживании клиентов и создании для них определенной ценности. Поэтому они нам так нравились. Они давали нам понять, что мы важны для них в качестве клиентов, независимо от того, сколько раз у нас падают операционные системы или серверы. Функциональные и кросс-функциональные команды должны управляться как небольшие бизнес-подразделения. Тогда они действительно становятся фрактальными группами, и их число в организации может быть неограниченным [Leffingwell 2007: 96].

Создавайте отдельные команды для решения однотипных задач

Если ты не официальный сторонник какой-либо методологии и не участвуешь ни в каких ассоциациях, альянсах и консорциумах, то можно позволить себе еретические высказывания. Самое худшее, что с тобой могут сделать, – это подвергнуть метафорическому сожжению на какой-нибудь индустриальной конференции. Именно поэтому я пользуюсь огнеустойчивым гелем для волос. Но я заметил, что еретические идеи пользуются спросом. Будучи твердым сторонником рыночных подходов, я люблю использовать малейшие возможности для высказывания диссидентских идей вроде тех, что изложены ниже.

Я считаю, что иногда целесообразнее поручать работу, требующую однотипных профессиональных знаний, отдельным функциональным командам, которые состоят из соответствующих специалистов. Этот подход может оказаться необходимым для проектного менеджмента, разработки отдельных компонентов архитектуры, дизайна пользовательских интерфейсов, конструирования оборудования, тестирования или какой-либо другой работы, выходящей за рамки стандартных видов деятельности в границах проектов. Это идет вразрез с «принятым» в Agile-сообществе способом мышления, выразителями которого стали авторитетнейшие специалисты, полагающие что кросс-функциональные команды эффективнее справляются с любыми видами работ – от создания пользовательских историй до бинарной сборки. Хороший пример – Scrum Of Scrums. Он предусматривает участие представителя каждой команды в ежедневных Scrum-совещаниях, а затем эти представители осуществляют координацию между командами. Такие же рекомендации высказывались в отношении Scrum-мастеров, технических лидов, дизайнеров пользовательских интерфейсов и ведущих тестировщиков.

Мне же кажется, что это просто вопрос баланса коммуникаций. Если выясняется, что дизайнерам пользовательских интерфейсов необходимо общаться друг с другом чаще, чем с членами своих проектных команд, то будет правильным объединить этих дизайнеров в отдельную команду и разместить их в одном помещении. Точно так же динамика проектов, реализуемых компанией, может оказаться настолько интенсивной или сложной, что проектные менеджеры вынуждены будут теснейшим образом сотрудничать. В этом случае оптимальным вариантом будет собрать их вместе и дать им возможность создать свою отдельную команду. Может быть, даже целый проектный офис.

Но… при этом необходимо учитывать пять важных факторов:

• Во-первых, когда какая-то работа (например, проектный менеджмент, создание архитектуры или дизайн графических пользовательских интерфейсов) передается отдельным функциональным командам, должен быть создан механизм коммуникации между кросс-функциональными командами и данной функциональной командой [Leffingwell 2007: 108]. В качестве такого механизма можно предложить регулярное участие представителя функциональной команды в стендапах проектной команды и/или назначение представителя от кросс-функциональной команды, который будет отвечать за коммуникацию с командой специалистов. Есть много вариантов обеспечить беспроблемную коммуникацию между кросс-функциональными командами и командами-специалистами.

• Во-вторых, люди, которых переводят в функциональную команду, должны воспринимать себя частью бизнес-подразделения, создающего ценность для клиентов; системные администраторы должны обслуживать проектные команды, а не контролировать их. Команды-специалисты должны считать проектные команды своими клиентами, а не подчиненными и организовывать свои рабочие процессы исходя из этого представления. Они продают свои услуги коллегам из других команд точно так же, как я пытаюсь продать вам свои диссидентские взгляды. (Все-таки хорошо, что вам пришлось купить эту книгу до того, как вы дочитали до этого места.)

• В-третьих, именно проектные команды должны решать, создает ли для них данная функциональная команда какую-либо ценность. Такой рыночный подход позволяет уравновесить тенденцию команд-специалистов к оптимизации своей деятельности в ущерб интересам организации как единого целого. Например, на моей последней работе у меня был выбор – обратиться к нашим специалистам по интерактивному веб-дизайну или заняться этим дизайном самому. Все зависело от того, насколько качественно (и насколько оперативно) они были в состоянии реагировать на потребности моего проекта. (Обратите внимание, что мне пришлось развивать свои навыки не только в диссидентстве, но и в дизайне.)

• В-четвертых, мы знаем, что объем коммуникации, осуществляемой в сложных системах, остается более или менее постоянным независимо от того, как эта система себя организует. Следовательно, задача команд и их менеджеров – выяснить, каким количеством контактных точек они в состоянии эффективно управлять. Слишком малое или слишком большое количество таких точек снижает адаптивность компании.

• В-пятых, команда-специалист бывает виртуальной. Может оказаться достаточным время от времени собирать вместе специалистов по интерактивному веб-дизайну и давать им возможность согласовывать общие стандарты и подходы для применения кросс-функциональными командами, в состав которых они входят. Такие виртуальные команды называются сообществами практикующих или сообществами экспертов. Они представляют собой неплохой компромисс, позволяющий сочетать кросс-функциональные команды с необходимостью координации между специалистами [Augustine 2009: 71–73], [Larman, Vodde 2009: 252/253]. (Примечание: некоторые организации с теми же целями поддерживают центры передового опыта, хотя такие центры обычно имеют более формальный характер.)

Возможной или даже предпочтительной будет ситуация, когда функциональная команда возникает в результате самоорганизации. Команды-специалисты могут формироваться органически с целью решить общую для нескольких команд проблему. Например, возможно объединение в одну команду специалистов по непрерывной интеграции, чтобы на более высоком профессиональном уровне оказывать соответствующие услуги другим командам. Члены проектных команд могут входить в функциональную команду на условиях полной или частичной занятости, также возможна их ротация [Highsmith 2009: 272/280]. Могут создаваться команды, отвечающие за отдельные компоненты, – например, команда будет специализироваться на разработке архитектуры ПО и передавать готовую архитектуру проектным командам. В этом случае проектные команды выступают по отношению к ней в роли заказчиков [Cohn 2009: 185]. Главная причина формирования команд специалистов – повышение эффективности (в результате разделения труда).

Можно даже представить, что эти команды специалистов растут и формируют свои собственные маленькие иерархии. У них даже может быть несколько правил, которые применяются к проектным командам, если эти команды решают воспользоваться их услугами. Как и в любой рыночной среде, команды-специалисты (вместе со своими иерархиями и регламентами) могут и должны быть распущены, как только потребность в них исчезает.

В каждом из этих примеров понятно, что проектные команды будут потребителями, а команды-специалисты – провайдерами услуг (рис. 13.8). То же самое относится к проектному офису, если он существует. Задача проектного офиса – обслуживание проектных команд и помощь им в организации работы. Проектные менеджеры наряду с дизайнерами пользовательских интерфейсов, архитекторами и системными администраторами не относятся к категории линейных менеджеров. И никто не должен «подчиняться» проектному офису. Наоборот, проектный офис должен в уважительной манере запрашивать информацию у проектных команд, а в качестве результата предоставлять проектным командам услуги, в которых у последних есть реальная потребность.

А что если проектный офис работает на топ-менеджмент?

Это противоречит изложенной здесь философии. Проектный офис не может иметь в качестве клиентов одновременно команды и топ-менеджмент. Это приводит к конфликту интересов, в результате чего обычно страдают проектные команды.

Я убежден, что за результаты проекта ответственность должны нести команды, а не менеджеры. Это означает, что топ-менеджмент должен работать с командами непосредственно или через линейных менеджеров, минуя проектный офис. Подобно системным администраторам и отделу кадров проектный офис существует для того, чтобы помогать и координировать, а не контролировать.

Каждый иерархический уровень должен создавать дополнительную ценность

Организационные иерархии – необходимое зло. Они нужны, поскольку должны существовать четкие линии подчиненности между сотрудниками и владельцами компании. Иерархии – это плохо, потому что ими очень легко злоупотреблять, а это имеет ужасные последствия для потока информации. Такие выводы вытекают (теоретически) из первого принципа организационного дизайна Эмери и подтверждаются (практически) эмпирически. Пример можно найти в книге Малкольма Гладуэлла «Гении и аутсайдеры»[81], в которой он пишет о наличии сильной корреляции между авиакатастрофами и иерархическими культурами (из-за плохой коммуникации в кабине пилота) [Gladwell 2008]. Но это не значит, что иерархий быть не должно. Если бы иерархии были злом по определению, мы не наблюдали бы их повсюду в природе (принцип иерархии):

Сложные природные явления организованы иерархически, и каждый уровень состоит из нескольких интегрированных систем[82].

Вопрос заключается в том, как воспользоваться преимуществами иерархий, не позволяя им работать против нас. С моей точки зрения, существование организационных иерархий диктуется необходимостью иметь четко определенную цепочку подчиненности. Владельцы компании нанимают человека, чтобы управлять своим бизнесом. Тот нанимает других людей, чтобы делегировать им часть своей работы, и так далее. Это и есть иерархия. От нее невозможно отказаться. Она представляет собой древообразную структуру и делает возможными систематический обмен информацией и разделение полномочий.

Цель создания организации – снизить необходимое количество коммуникации и координации; поэтому организация сама по себе представляет собой радикальный способ решить проблему коммуникации…Организации с древовидной структурой возникают как реакция на потребность структурировать полномочия и ответственность. Поскольку невозможно одновременно служить двум хозяевам, организации и приобретают древовидную структуру. Но каналы, по которым осуществляется коммуникация, не до конца подчиняются налагаемым этой структурой ограничениям, поэтому организационное древо лишь весьма приблизительно отражает реальные процессы коммуникации, которая по своей природе будет сетевой[83].

Нам необходимо оптимальное переплетение формальной иерархической и неформальной сетевой структур [Augustine 2005: 48]. Менеджеры должны понимать, что информация движется в первую очередь по сетевой структуре, а не по иерархическим линиям. Но не нужно пытаться заблокировать или контролировать неформальные потоки информации. Наоборот, им следует всячески способствовать. Иерархия определяет распределение полномочий; роль сетевой структуры – гарантировать эффективную коммуникацию (рис. 13.9).

Организационный психолог Эллиот Жак, автор концепции реквизитной организации, в своих работах указывает, что у иерархий есть полезные функции, хотя их структура обычно оставляет желать лучшего [Jaques 1998]. Важное требование для каждого уровня иерархии – он должен привносить в организационную структуру дополнительную ценность. Подобно тому, как каждый более высокий уровень в иерархических структурах, существующих в природе, ведет к появлению новых эмерджентных свойств, которых не было у более низких уровней, так и каждый новый уровень в организационной структуре должен выполнять функцию, которая не выполняется на более низких уровнях.

В качестве примера Жак приводит разные горизонты планирования для разных уровней организации [Jaques 1999]. Проблемы, решение которых занимает от одного дня до трех месяцев, находятся в ведении самого нижнего уровня; второй уровень занимается вопросами с горизонтом планирования от трех до двенадцати месяцев; на третьем уровне решаются вопросы с горизонтом планирования от одного года до трех лет и так далее. У проектных команд (обычно) нет времени раздумывать о том, что необходимо для того, чтобы компания и через пять лет оставалась успешной. Есть и другие примеры: наем сотрудников, создание стратегических альянсов, сведение бюджетов – все это задачи, которыми проектные команды, как правило, сами не занимаются. Правда, стоит отметить, что не все эксперты в области менеджмента согласны с таким подходом. Некоторые из них пишут о том, что даже президенты компаний иногда вынуждены заниматься повседневными проблемами [Mintzberg 2005: 110].

В моем представлении суть в том, чтобы между различными уровнями в организации существовало некоторое разграничение функций независимо от того, основано ли оно на разных горизонтах планирования. Жак в своих работах показал, что причиной организационных проблем зачастую становится именно тот факт, что некоторые уровни в организации не создают никакой дополнительной ценности. Требование, чтобы каждый уровень привносил свою ценность, это прекрасная отправная точка при принятии соответствующих организационных решений. Когда кто-нибудь предлагает создать еще один управленческий уровень, спросите себя: «Какие проблемы он призван решить? Проблемы, которые не могут быть решены на уже существующих более высоких или более низких уровнях в нашей организации?» Если четкого ответа на этот вопрос нет, не добавляйте новых менеджеров!

Сколько нужно менеджеров, чтобы изменить организацию?

Сейчас модно рассуждать о том, что «чем меньше менеджеров, тем лучше», а у организаций должна быть максимально «плоская» структура. Так и есть. Мы все об этом знаем. И первый вопрос, который задается в этой связи, таков: «Сколько всего менеджеров должно быть?» Ответы на него, которые мне удалось найти в источниках, располагаются в диапазоне от «один менеджер на команду» [Testa 2009: 52] до «один менеджер на каждые сто сотрудников [Larman 2009: 241].

Мне кажется, что сам вопрос некорректен. Соотношение числа менеджеров и числа подчиненных не может быть некоей константой. Оно должно стать результатом организационных измерений, проводимых менеджерами по мере роста компании. Сколько у нас кросс-функциональных команд и сколько команд-специалистов? В каких частях компании применен первый принцип организационного дизайна, а в каких – второй? Насколько сотрудники свободны выбирать команды, в составе которых хотели бы работать? Ответы на эти вопросы зависят от менеджеров, и именно они должны нести ответственность за последствия своих решений.

Это, конечно, фантазия – соблазнительная и распространенная, но от этого она не перестает быть фантазией, – что можно создать эффективные команды без создания высвобождающих инициативу структур. Мы надеемся, что рыночные факторы сделают иерархии ненужными. Что на месте прежних организаций возникнут сетевые структуры. Что не имеющие четких границ сетевые социальные системы смогут эффективно и экономно справляться с работой. И что, если какая-то структурированность все же понадобится, она возникнет автоматически в результате самоорганизации, так широко разрекламированной теорией сложности[84].

Первостепенная задача менеджеров – создание эффективных команд и структур. При этом нет никакого смысла обсуждать оптимальное соотношение между числом менеджеров и сотрудников. Обсуждать следует, какие рациональные соображения должны лечь в основу организационного дизайна в каждом конкретном случае. В результате вы выйдете на правильное соотношение.

Создавайте гибридные организации

Компании, в которых проектные команды сосуществуют с командами-специалистами, а иерархии – с сетевыми структурами, можно отнести к категории гибридных организаций. Они, как утверждается, позволяют одновременно избежать недостатков, присущих функциональным командам в чисто иерархических структурах, и недостатков, типичных для автономных проектных команд в составе сетевых структур. Компании с достаточно гибкой организационной культурой и множеством одновременно реализуемых проектов обычно приходят к гибридной форме организации [Testa 2009: 370, Reinertsen 1997: 106].

При описании некоторых видов гибридных компаний говорят о матричных организациях. Хотя раньше я и сам пользовался этим термином, с некоторых пор я все же предпочитаю его избегать. В литературе под матричными организациями часто понимаются компании, в которых присутствуют оба организационных измерения – линейный и проектный менеджмент. Некоторые авторы пишут о «проблемах» матричных организаций, включая конфликт полномочий между линейными и проектными менеджерами, нерешенный вопрос о том, кто же будет настоящим начальником, политиканство и общее ощущение, что менеджеров в таких организациях слишком много [Jones 2001].

Некоторые авторы сообщают, что в матричных организациях у менеджеров бывают психологические проблемы. Если проектные менеджеры контролируют все и вся, то линейные менеджеры чувствуют себя деморализованными, поскольку у них есть ответственность, но отсутствуют необходимые полномочия. Дело обстоит так же, если в компании, наоборот, сильный линейный менеджмент и слабый проектный. По-моему, все это результат недоразумения. Нельзя во всем обвинять цепную пилу, если берешься за нее не с того конца.

Проблемы, о которых идет речь, являются результатом неправильного построения гибридной организации. Когда все сделано правильно, у каждого сотрудника компании должна быть одна и только одна линия подчинения, и она реализуется через соответствующих линейных менеджеров. Роль проектных менеджеров состоит в том, чтобы обслуживать проектные команды, а не контролировать их. Они управляют проектами, а не людьми. Я убежден, что положение проектных менеджеров ничем не должно отличаться от положения, скажем, архитекторов программного обеспечения или менеджеров, занимающихся вопросами обеспечения качества – у всех свой специфический набор функций. Между прочим, отсюда становится ясно, что у гибридных организаций обычно бывает более двух «измерений». Только одно из них ведет наверх (линия подчинения через линейных менеджеров), а остальные измерения направлены в стороны.

Анархия мертва, да здравствует панархия

У крупных проектов больше шансов потерпеть неудачу, чем у более мелких. Это в первую очередь обусловлено социологическими и коммуникативными причинами [DeMarco, Lister 1999: 4]. В некоторых источниках даже утверждается, что шансы на успешное завершение особо крупных проектов стремятся к нулю [Yourdon 2004: 4].

Но я анархист и оптимист. Я полагаю, что мы вполне в состоянии справиться со всеми проблемами – сначала расчленив их, а затем поместив под увеличительное стекло (фигурально выражаясь, конечно).

Сторонники Agile-методологий и анархисты разбивают крупные проекты на несколько мелких, а большие организации – на несколько небольших. Затем они решают проблемы в рамках мелких проектов, перенося опыт на похожие более крупные проекты [Highsmith 2009: 272]. В этом смысле они являются противоположностью бюрократий, в которых планирование осуществляется сверху вниз. Организациям, выстроенным по принципам Agile, присущ рост снизу вверх и связанная с этим адаптивность.

Развитие глобальных рынков, интернета, социальных сетей и других сетевых структур привело к возникновению глобальной тенденции, сходной с теми, что вызвали к жизни Agile-организации. Сети, достигшие транснациональных масштабов, называют панархиями. Мне нравится слово «панархия», потому что оно всего на одну букву отличается от названия нормального состояния моего сознания.

Возрастающая сложность наших социальных и политических структур, состоящих из множества взаимодействующих агентов, в сочетании с возрастающей ролью, которую играют сетевые формы организации, ставшие возможными благодаря развитию технологий, улучшивших связь между людьми, подталкивает мировую систему к серьезной трансформации. Пиком этой трансформации стало возникновение глобальной политической среды, состоящей из разнообразных структур с различными формами управления, которую можно назвать панархией. Поясняя эту мысль, можно сказать, что глобальные связи между индивидуумами и группами создают транснациональные сети, участники которых разделяют определенные нормы и цели… Панархия – это форма управления сложной адаптивной системой, состоящей из анархических сетей, для существования которой необходимо разнообразие входящих в ее состав элементов и которая сопротивляется попыткам навязать ей иерархичность[85].

Панархия – это система перекрывающих друг друга сетей взаимодействия и подчинения. Как индивидуум я подчиняюсь (неохотно) не только правительству моей страны, но и (охотно) власти, которую имеют надо мной банк, интернет-провайдер, компания, поставляющая в мой дом электроэнергию, Twitter, Facebook и LinkedIn, спортивные и игровые клубы, некоммерческие и благотворительные организации, а также правительства других стран, если я решаю в эти страны поехать (другие люди добавляют к этому списку религиозные организации).

В мире множество источников власти, и как индивидуум я могу выбирать группы или организации, нормы и правила которых меня устраивают. Единственный источник власти, который я не могу выбрать напрямую, – система государственного управления в моей стране (если только не собрать вещи и не переехать).

Конечно, быть анархистом в современных условиях – далеко не то, что было раньше. Сейчас я называю себя панархистом. Это анархист, действующий ненасильственными методами. Брайан Мэрик, один из подписантов первого Agile-манифеста, придерживается сходной идеологии и называет ее ремесленным ретрофутуризмом, скрещенным с командным анархо-синдикализмом. Мне кажется, проще называть это панархией. Да и стикеры в изготовлении обойдутся дешевле.

Возникновение и развитие глобального управления через сети – это процесс, на который влияют государства, но они не в состоянии его контролировать. На него также влияют корпорации, отдельные личности, неправительственные организации и другие группы. Пока неясно, чье влияние будет решающим. Реалисты скажут, что ведущую роль все же играют государства, а марксисты станут утверждать, что и здесь всем правит капитал. Но история показывает, что в конечном счете решающее воздействие остается за людьми, а новые коммуникационные технологии лишь усиливают их влияние и способность организовываться для коллективных действий[86].

Теперь нам понятно, почему организации, действительно построенные в соответствии с принципами Agile, это панархии. А поскольку они представляют собой объединения бизнес-единиц, каждая из которых создает ценность, их можно также назвать «сетями создания ценности». Внутри организаций этого типа существует множество носителей полномочий, включая команды, занимающиеся архитектурой ПО, графическим дизайном, проектным менеджментом и инфраструктурой. Каждая создающая ценность бизнес-единица сама решает, хочет ли она добровольно принять нормы и правила тех или иных команд-специалистов. Решения относительно того, формировать ли вообще функциональные команды или же все функции оставить внутри проектных команд, принимаются проектными командами самостоятельно. Полная свобода выбора: можно быть анархо-синдикалистом или мирным анархистом. Единственное, что люди не могут выбирать для себя сами, это линейный менеджмент. Но на этот случай за ними остается право перейти на работу в другую компанию.

При формировании сетей создания ценности реализуется органический подход к организационному дизайну. В результате возникает фракталоподобная структура, состоящая из небольших иерархий, которые накладываются друг на друга, образуя одну большую сеть. А поскольку такой дизайн предпочитает горизонтальный рост вертикальному, снимаются любые ограничения на рост панархии.

Не имейте секретов

Теперь, когда вы знаете, какие варианты организационного дизайна у вас есть в распоряжении, можно посвятить несколько последних страниц этой главы процессу прохождения информации в созданной вами структуре.

Как я ранее упоминал, большинство проблем, которые возникают в проектах по разработке ПО, становятся результатом неудовлетворительной коммуникации. Для эффективной же коммуникации люди должны иметь в своем распоряжении качественную информацию, хорошие отношения и получать качественную обратную связь.

Во многих организациях люди испытывают нехватку качественной информации и вследствие этого зачастую начинают придумывать ее сами. Если они не знают, насколько хорошо обстоят дела с их проектом, то попытаются это угадать. Если они не знают, как идут дела у других команд, то начнут строить предположения. Если они не понимают, в чем состоит вклад их коллег в успех компании, то начнут предлагать собственные интерпретации. Ну а когда они ничего не знают о личной жизни своего менеджера, то начинают сплетничать.

Чтобы предотвратить такие проблемы, необходимо сделать информацию доступной. Общее правило: чем больше информации, тем лучше. Дайте всем доступ в интернет, ко всем сетевым директориям, базам данных проектной информации и к системам контроля версий кода. Пропагандируйте корпоративный интранет, сделайте доступными книги и профессиональные журналы и общедоступными – отчеты об использовании времени, диаграммы сгорания задач, финансовые результаты и другую корпоративную информацию. Придерживание сведений (в большинстве случаев) играет отрицательную роль. Не считайте, что какая-то информация никому не интересна. Вы можете оказаться правы, но если вы будете ее скрывать, то люди заполнят линии коммуникации искаженными данными, поскольку им надо что-то друг другу передавать. Открытость относится не только к информационным системам. Вы и сами должны демонстрировать ее, потому что талантливые люди хотят слышать правду о себе и своей компании [Kaye, Jordan-Evans 2008: 204].

Я часто прилагаю усилия, чтобы всем было доступно как можно больше информации. Я хочу, чтобы люди были в курсе, кто и над какими проектами работает, созданием какой функциональности кто занят, кто именно исправляет какие ошибки и решает какие задачи и как команды оценивают свои проекты.

В трудные экономические времена особенно важно, чтобы все сотрудники понимали, как в компании обстоят финансовые дела. Как пишет Джек Стэк в книге «Большая игра в бизнес»[87], только когда сотрудникам небезразличны финансовые результаты компании, они смогут придумать способы их улучшить [Stack 1994].

Некоторые выдающиеся менеджеры полагают, что публичной должна быть даже информация о зарплатах сотрудников, включая руководителей. В конце концов, если вы не в состоянии объяснить зарплату сотрудника всем остальным, то как вы можете рассчитывать на доверие команды?

Я могу с этим согласиться. Но я также понимаю, что нельзя изменить культуру организации в одночасье. Было бы неразумно внезапно обнародовать конфиденциальную информацию, если в компании еще не создана соответствующая культура. Но надо же с чего-то начинать. Джек Стэк перечисляет «Десять высших законов бизнеса», последний из которых звучит так: «Дерьмо течет под гору». Это значит, что изменения в организации начинаются с изменений в менеджменте.

Что ж, я надеюсь когда-нибудь стать выдающимся менеджером. Поэтому я и позаботился о том, чтобы все мои личные секреты были опубликованы в этой книге. Вам удалось их обнаружить?

Сделайте все заметным

Было время, когда я отслеживал посты Эштона Кутчера в Twitter. Решение пришло практически спонтанно. Дело в том, что Эштон был первым человеком в мире, у кого появился реальный шанс набрать 1 000 000 подписчиков. Следовательно, помимо внешности, должно же быть в этом парне что-то интересное?

Эштон Кутчер был заметным. Интернет был переполнен историями о его соперничестве с CNN, когда было еще неясно, кто из них первым наберет в Twitter миллион подписчиков. Люди вроде меня, читающие массу блогов, просто не могли не заметить эти истории. Только поэтому я и стал подписчиком Эштона Кутчера.

Так что делать, чтобы люди внедряли у себя передовые практики? Это очень просто. Нужно сделать эти практики заметными.

В прошлом году я и еще несколько менеджеров решили развесить в офисе доски задач каждой проектной команды в виде «больших и наглядных диаграмм». Каждый сотрудник, перемещающийся по офису, не мог их не увидеть. Поэтому, когда другие команды (не связанные напрямую с разработкой софта) увидели эти доски задач, им захотелось внедрить нечто подобное у себя. Они их увидели и последовали примеру. Этот принцип универсален. Любой заметный процесс – излучатель информации.

Команда, с которой я работал на последнем проекте, проводила свои стендапы прямо в нашем офисе с открытым пространством. Поначалу мы подумывали о том, чтобы встречаться в более уединенном месте, чтобы не беспокоить остальных сотрудников те пятнадцать минут, что длится такое совещание. Но затем решили, что это будет неправильно. Вскоре выяснилось, что нашему примеру последовали и другие команды (включая даже те, которые не занимались разработкой ПО). Они просто увидели, что мы проводим такие совещания каждое утро, и тоже решили применить эту интересную практику.

Увидеть – часто означает скопировать.

Люди копируют поведение друг друга, и часто единственная причина этого – то, что им удалось что-то подсмотреть у других. Это свойственно человеку. Из-за этого я стал подписчиком Эштона Кутчера. По этой же причине подростки начинают курить. Ученые считают, что люди подсознательно копируют поведение друг друга. Но тот же самый феномен можно использовать и осознанно. У подражания огромный потенциал убеждения и коммуникации. Вы можете использовать этот механизм себе во благо, сделав желательные виды поведения заметными. Если вы хотите, чтобы люди писали более качественный код, обклейте примерами отлично написанного кода все стены возле кофемашины. Если хотите, чтобы сотрудники внедрили у себя Scrum, заявляйте время и место проведения совещаний по планированию и обзору итогов спринтов в общедоступном календаре. Если нужно, чтобы сотрудники правильно пользовались системой управления версиями кода, нарисуйте дерево файлов и ветки на стенах офиса.

Люди следуют тому типу поведения, который видят, и вы должны демонстрировать им примеры.

Наверное, вы также должны воздерживаться от демонстрации примеров нежелательного поведения. Окружающие также могут начать им следовать (ненамеренно).

Связывайте людей

В своей книге «Либо энтузиазм, либо выгорание» (Fired Up or Burned Out) Майкл Стэллард показал, что один из лучших способов для организаций достичь преимущества – «наладить с людьми настоящий контакт». А Беверли Кей и Шерон Джордан-Иванс в своей книге «Любите их или потеряете» (Love 'Em or Lose 'Em) описывают свою концепцию «создания связей», которую они называют одной из 26 стратегий, направленных на повышение вовлеченности сотрудников [Kaye, Jordan-Evans 2008: 113–122].

Создание и поддержание осмысленных контактов с сотрудниками (и между ними) – это не просто модная фишка, преследующая цель «очеловечить» менеджеров в восприятии подчиненных. Как мы видели в главе 12, необходимость поддержания контактов напрямую вытекает из теории сложности.

Жизнестойкость и способность организаций к инновациям – результат хороших взаимоотношений между сотрудниками, поскольку это позволяет информации циркулировать свободно и без искажений. Вам необходимо добиться, чтобы людям нравилось работать друг с другом. Уберите в офисе все перегородки, проводите неформальные совещания и стимулируйте сотрудников получать удовольствие от общения друг с другом во время кофе-брейков, перекуров и обеденных перерывов.

И постарайтесь создать более значимые отношения со своими сотрудниками. Это не означает, что вы должны стать им закадычным другом. Да это и невозможно. Для начала просто узнайте чуть больше об их жизни, семьях, домашних делах и хобби (и дайте им возможность узнать о себе побольше).

Стремитесь к адаптивности

В начале этой главы я говорил, что не существует универсальной структуры, которая подходила бы всем компаниям. Саму по себе задачу создания адаптивной организации не в состоянии решить ни кросс-функциональные команды, ни матричный подход, ни любые другие методы. Самый важный вывод, который вы должны для себя сделать, – задача менеджера состоит в том, чтобы повышать способность организации к изменениям. Должно стать нормой превращение функциональных команд в кросс-функциональные и обратно. В качестве стандартной должна восприниматься ситуация, когда при необходимости создается команда-специалист, а затем она расформировывается, если необходимость в ней отпадает. Нормально, если менеджмент пробует применить второй принцип организационного дизайна в какой-либо части компании, а затем возвращается к первому, если выясняется, что второй пока не работает. Абсолютно естественно, когда по мере накопления опыта сложные адаптивные системы пересматривают и реорганизовывают свои составные элементы. Организации в этом смысле ничем от них не отличаются [Waldrop 1992: 146].

Чтобы организация оставалась адаптивной, лучше ограничиться минимумом фиксированных элементов. Чем меньше таких элементов будут заморожены в виде органиграмм, контрактов и процедур, тем лучше.

Применение принципа «минимальной достаточности» при организации команды обеспечит ей необходимую гибкость и свободу для самоорганизации. Временами менеджеры из кожи вон лезут, чтобы зафиксировать все без исключения организационные элементы – роли, обязанности, политику и процедуры. Напротив, в холакратических структурах количество элементов организационного дизайна сведено к необходимому минимуму[88].

Вы поймете, что ваша компания стала адаптивной, когда сотрудники перестанут жаловаться на постоянные реорганизации и начнут сами предлагать идеи по внесению изменений. И тогда вы будете с удовольствием наблюдать, как растет ваша компания благодаря тому, что вы справились с пятым компонентом Менеджмента 3.0.

Резюме

Поскольку операционная среда, размер компании, разрабатываемые продукты и состав сотрудников часто меняются, очень важно регулярно вносить изменения в организационную структуру. Преимущественная опора на специалистов со склонностью к генерализации, расширенная трактовка названий должностей и неформальное лидерство значительно повышают адаптивность организации.

Важно поддерживать четкие границы между командами, так как людям трудно идентифицировать себя с командой, границы которой расплывчаты или нестабильны. Из результатов исследований следует, что оптимальный размер команды – от трех до семи человек.

Команды могут быть организованы по функциональному или кросс-функциональному принципу, при этом последние (за некоторыми исключениями) эффективнее с точки зрения коммуникаций. Коммуникация между командами может осуществляться либо через менеджеров, либо по преимуществу самими командами. Здесь также предпочтителен второй вариант.

Организационная структура наиболее адаптивна, когда команды считают себя создающими ценность бизнес-подразделениями и рассматривают остальные команды в качестве клиентов, которым они предоставляют услуги. Если в организации возникает спрос на специализированные услуги, могут создаваться команды-специалисты, но они должны расформировываться, если потребность в их услугах со стороны других команд исчезает. Дополнительные уровни менеджмента могут быть полезны только при условии, что они действительно создают новую ценность.

Когда полномочия между командами распределены горизонтально, мы имеем дело с гибридной организацией. Если такая организация имеет преимущественно сетевую структуру, составленную из необязательно множественных перекрывающих друг друга иерархий, ее также можно называть панархией или сетью создания ценности.

И последний важный момент. Чтобы коммуникация была эффективной, важно, чтобы менеджеры не придерживали информацию, а делали ее доступной и заметной, а также прилагали добросовестные усилия по выстраиванию отношений со своими сотрудниками.

Подумать и сделать

Давайте посмотрим, какие идеи из этой главы вы можете применить в своей компании:

• Подумайте о людях, входящих в вашу команду. Кто они: специалисты со склонностью к генерализации или, наоборот, генералисты, склонные к специализации? Что вы будете делать, чтобы специалистов со склонностью к генерализации стало больше?

• Посмотрите список названий должностей, существующих в вашей компании. Достаточно ли широко сформулированы эти названия, чтобы включать в себя несколько ролей? Если нет, составьте план перехода к расширенным названиям должностей.

• Подумайте о лидерстве в применении к своей команде. Есть ли в ней неформальные лидеры? Достаточно ли эти лидерские роли динамичны – могут ли они при необходимости легко изменяться?

• Как в вашей организации структурированы команды? Достаточно ли они невелики, чтобы люди могли действительно ощущать себя членами команды? Достаточно ли устойчивы ваши команды, достаточно ли у них времени, чтобы выработать свои правила и дать возможность проявиться неформальным лидерам?

• Взгляните еще раз на матрицу организационных стилей. Какие из них присутствуют в вашей организации? Если стиль № 4 вообще не представлен, есть ли у вас план перехода к нему?

• Поговорите со своей командой о создании бизнес-ценности. Воспринимает ли себя ваша команда как бизнес-единицу, создающую такую ценность? Считает ли она, что другие подразделения также создают ценность? Если нет, можете ли вы что-то предпринять, чтобы изменить ситуацию?

• Проверьте менеджерские позиции в вашей организации. Все ли они добавляют настоящую ценность? Если нет, можете ли вы что-то с этим сделать или как-то на это повлиять?

• Нарисуйте организационную структуру своего бизнеса. Ваш бизнес выглядит скорее как иерархия или как сеть создания ценности?

• Проверьте свои навыки общения. Вам удается выстраивать отношения с людьми регулярно? Если нет, то как вы собираетесь изменить эту ситуацию?

Глава 14 Ландшафт изменений

То, что мы называем прогрессом, всего лишь замена одних неприятностей на другие.

Генри Хэвлок Эллис,сексолог, врач (1859–1939)

Мы с моим партнером однажды отправились отдохнуть на неделю в Швецию. И заметили, что, даже если у вас есть «вольво» большого размера, доверху набитый туристским снаряжением, едой, одеждой и предметами личной гигиены, все равно адаптироваться к новой обстановке крайне непросто.

Шестой компонент модели Менеджмента 3.0 – улучшение всего. Это и будет темой данной и последующей глав. Как и попытка отдохнуть на севере Швеции, это начало конца. В данной главе мы сделаем обзор концепций, которые касаются выживания систем в изменяющейся внешней среде, а затем в следующей главе обсудим некоторые практические аспекты этих концепций. В финальной главе я представлю свои выводы.

Так что берем туристское снаряжение и начинаем подъем на эту последнюю гору.

Внешняя среда находится вовсе не «где-то там»

Говорят, что на севере Швеции живут миллиарды комаров. Не думаю, что это правда. По моему мнению, там живет только 1217 особей. Но они обладают невероятным обонянием и скоростью полета.

Я в этом уверен, потому что, куда бы в Швеции вы ни поехали, комаров не видно до тех пор, пока вы не выйдете из машины и не подставите открытые участки кожи прохладному ветерку. И вот тогда они налетят. Со всей Швеции. Через несколько минут все 1217 комаров будут с жужжанием виться над вами, пытаясь добраться до открытых участков кожи, которые они учуяли с другого конца страны. Шведские комары летают со сверхзвуковой скоростью, поскольку на севере страны практически нет людей. Для меня очевидно, что миллиардам комаров там просто не выжить. Людей еле хватает, чтобы прокормить 1217 комаров. И я кормил их всех в течение пяти дней.

Куда бы я ни поехал на севере Швеции, повсюду видел облако комаров, возникающее потому, что появился я. Мое появление в этой среде вызывало изменения в самой среде. А когда меня не было, не было и комаров. Другими словами:

Когда система попадает в определенную среду, это вызывает изменения в самой этой среде.

Я вынес эти слова отдельно, поскольку считаю, что в них заключено одно из важнейших понятий теории сложности. Среда, с которой системе приходится взаимодействовать, – это уже не та среда, которая существовала до контакта системы с ней. И это самая главная причина, почему так трудно «планировать» нововведения, исходя из описания текущего состояния среды. Появление нового элемента изменит само состояние этой среды и может сделать первоначальный план бесполезным.

Некоторое действие должно предшествовать планированию, поскольку таким образом мы участвуем в создании внешней среды. Окружающая среда вовсе не находится «где-то там», существуя отдельно от нас. Мы можем помочь в создании среды. ‹…› В испанском языке на этот счет существует удачная фраза: «Compañero, no hay camino. Se hace camino al andar». Она переводится так: «Мой друг, дороги нет. Дорога возникает, когда ты по ней идешь»[89].

Внешняя среда, существующая «где-то там» до того, как появится ваш программный продукт, отличается от среды, в которой этот продукт уже появился. Пользователи изменят свои рабочие привычки, когда возьмут его в оборот. Им будет хотеться что-то изменить, и появятся новые потребности. Другие программные продукты придут во взаимодействие с вашим, возможно, даже образуют с ним симбионты. Прибегут паразиты и попробуют обескровить продукт. Конкуренты начнут адаптировать свои стратегии и попытаются утопить ваш продукт. Может случиться, что я тоже попробую. Конечно же, совершенно непреднамеренно.

Невозможно заранее запланировать, какой метод нужно будет взять на вооружение при разработке конкретного продукта (в смысле использования той или иной типологии проекта и соответствующих подходящих моделей). Мы должны сначала почувствовать реакцию среды на новую систему, прежде чем поймем, как ею в этой среде управлять.

Именно среда определяет, как ей реагировать на вторжение. Поэтому любой подход к разработке ПО должен учитывать особенности реальной и вполне конкретной среды. Для этого ее необходимо почувствовать. И использовать полученную таким образом информацию в ходе проекта.

Таким образом, становится очевидно, что проект не может рассматриваться независимо от среды, контекста и своей истории. Более того, понимания контекста само по себе недостаточно для выбора метода (как это диктуется стандартной типологией проектов). Скорее, метод управления проектом оказывается встроенным в контекст и проявляется в результате взаимодействия между действующими лицами и средой, в которой они функционируют[90].

До наших приключений в Швеции мы с моим партнером купили средство для отпугивания насекомых в количестве нескольких литров, рубашки с длинными рукавами и толстые носки. Все эти меры, основанные на советах бывалых путешественников, должны были подготовить нас к встрече с густыми облаками комаров. Но в следующий раз я поеду в Швецию в стальных штанах.

Страх неопределенности

Кстати о путешествиях и планировании… Годом раньше мы с моим партнером были на Кубе, где нам неожиданно удалось посетить знаменитую табачную плантацию. Это произошло потому, что мы подобрали молодого парня, который голосовал на обочине и оказался одним из рабочих с этой плантации. Мы подвозили его неохотно и немного нервничали, потому что туристов в поездках по острову регулярно предупреждают не брать попутчиков. За два года до этого мою приятельницу Надиру на Кубе ограбили после того, как она подобрала попутных пассажиров. Все это говорит о том, что путешественникам приходится иметь дело с неопределенностью. Вас либо ограбят, либо вознаградят. Но как узнать это заранее?

В своей книге «Сложность: Экскурсия с гидом» (Complexity: A Guided Tour) Мелани Митчелл объясняет, что на решающую роль неопределенности в сложных системах влияют два важных фактора: [Mitchell 2009: 20]. Первый из них – принцип неопределенности Гейзенберга. Он устанавливает предел точности одновременного определения пары характеристик элементарной частицы, например ее положения и импульса. Чем точнее известно положение частицы, тем менее точно можно измерить импульс, и наоборот. Этот принцип показывает, что неопределенность вплетена в ткань реальности. Но все это имело бы не большее значение, чем незначительные статистические отклонения, если бы не второй фактор: эффект бабочки.

Эффект бабочки, открытие которого приписывают Эдварду Лоренцу, это метафора чувствительности системы к отклонениям в ее начальных параметрах. Он утверждает, что порхание крыльев бабочки в Китае может вызвать ураган в США. Я заметил, что эта метафора приводится во многих книгах по теории хаоса и теории сложности. Иногда эта бабочка машет крыльями в Китае, иногда в Индии, а иногда и в Бразилии. Но странным образом ураган при этом всегда случается в Соединенных Штатах. Напрашивается вопрос: не обнаружили ли теоретики хаоса глобальную сеть бабочек-террористок, цель которых – организация ураганов на территории США? (Во время отпуска на Кубе мы стали свидетелями урагана, пронесшегося над островом. Могу подтвердить, что он направлялся в сторону Флориды. Судя по его траектории, бабочка находилась на острове Аруба.)

Мы должны принять за данность, что бизнес-ландшафт в XXI веке характеризуется как неопределенностью, так и сложностью. И ситуация не становится лучше. И хотя неопределенность – естественный феномен, многим она не нравится. Всем хочется в своем будущем видеть определенность и безопасность. Попытки достигнуть такой определенности могут приводить к параличу анализа [Heath 2007: 34–37]. Мы не знаем, какое решение принять, потому что не уверены в результате. Внедрять масштабируемую архитектуру сейчас или позже? Использовать при разработке HTML5 или Flash? Подобрать попутчика или нет? Закончится все это на сигарной фабрике или в полицейском участке?

Когда люди наконец-то набираются смелости, чтобы принять решение, они часто предпочитают избежать рисков, а не воспользоваться потенциальной возможностью. Они склонны полагать, что неопределенность скорее будет иметь негативные последствия, чем позитивные. (Они также могут считать, что последствия потенциальных проблем будут более значительными, чем выгоды от позитивного исхода.) Хорошим примером служит часто упоминаемая «угроза», которую несет для экосистем завоз человеком неместных биологических видов. Многие экологи пытаются активно противостоять этой «угрозе». Но исследования говорят о том, что лишь в нескольких процентах случаев завезенные виды оказывают значительное и негативное воздействие на существующие экосистемы [Davis 2009: 26]. В большинстве остальных случаев воздействие «чужеродных» видов на местные экосистемы было нейтральным или даже положительным. (Интересно, что медоносная пчела стала официальным символом нескольких штатов в составе США, но это не местный вид: он попал в Америку только в 1600-х годах. Наверное, этих пчел занесло в Штаты ураганом.)

Неопределенность обнаруживается в реальности повсеместно, а чувствительность сложных систем к отклонениям в начальных параметрах порой имеет далекоидущие последствия. Страх, который люди испытывают перед этой неопределенностью, широко распространен, понятен, а иногда даже необходим. Но мы не должны позволять ему превращаться в страх перемен.

Законы изменений

Фразу «постоянны только изменения» приписывают древнегреческому философу Гераклиту. Также часто говорят, что выживают только те, кто способен «приветствовать изменения». Кент Бек использует эту фразу в качестве подзаголовка к своему бестселлеру «Экстремальное программирование» (Extrame Programming) [Beck 2005].

Программные продукты часто приходится адаптировать к изменениям во внешней среде. Введение евро в качестве официальной валюты Европейского союза потребовало от компаний на всем континенте инвестировать миллионы французских франков, немецких марок, итальянских лир, испанских песет, австрийских шиллингов, португальских эскудо и голландских гульденов, чтобы внести соответствующие изменения в программное обеспечение.

Некоторые авторы утверждают, что успешное программное обеспечение требует больше технической поддержки, чем неудачное [Brooks 2005, Glass 2003]. Одна из причин – стремление людей использовать любимое ПО в неожиданных ситуациях. Например, в Африке те, у кого нет банковских счетов, рассчитываются друг с другом, переводя деньги с мобильных телефонов. Еще одна причина состоит в том, что успешное ПО часто живет дольше, чем то поколение «железа» и бизнес-процессы, для которых оно первоначально предназначалось. Так, например, ожидалось, что многие программные продукты не переживут XX век, поскольку их придется серьезно модифицировать в связи с проблемой 2000 года (ее еще часто неправильно называют «ошибка миллениума»).

Необходимость учитывать изменения в окружающей среде при разработке ПО настолько фундаментальна, что рано или поздно в литературе мне должны были попасться соответствующие законы. Их предложил профессор Меир Леман:

1. Непрерывные изменения: система, используемая в изменяющейся среде, нуждается в постоянной модернизации, в противном случае удовлетворенность пользователей будет прогрессивно снижаться.

2. Увеличение сложности: если не предпринимать усилий по ее упрощению, то по мере своего развития система будет становиться все сложнее.

3. Саморегулирование: эволюция системы – саморегулируемый процесс, при этом темпы изменения атрибутов системы в течение ее жизненного цикла близки к нормальному распределению.

4. Влияние организационной стабильности: среднее количество усилий, прилагаемых при поддержании развивающейся системы, в течение ее жизненного цикла остается примерно постоянным.

5. Сохранение преемственности: в то время как система развивается, все связанные с ней люди должны обеспечивать господство ее содержания для достижения удовлетворительной эволюции.

6. Непрерывный рост: чтобы удовлетворенность пользователей не снижалась на протяжении жизненного цикла системы, ее функциональные возможности должны постоянно расширяться.

7. Ухудшение качества: воспринимаемое качество системы будет снижаться, если не предпринимать специальных мер по ее сопровождению и адаптации к изменениям во внешней среде.

8. Система обратной связи: эволюционные процессы представляют собой сложные системы обратной связи и должны рассматриваться как таковые для достижения значительных улучшений.

У меня имеются мелкие разногласия с некоторыми из законов Лемана (в особенности с третьим[91]), но в любом случае их смысл понятен и верен: система должна постоянно изменяться, иначе ее эффективность снижается. А когда система изменяется, то она становится более сложной, если не предпринимать мер по ее упрощению.

Может быть, самое интересное наблюдение Лемана состоит в том, что количество усилий по внесению изменений в систему и ее адаптации остается (приблизительно) постоянным в течение всего жизненного цикла. Мы вернулись к тому, что постоянны только изменения…

Каждый продукт успешен… пока не потерпит неудачу

Каким образом мы судим об успешности продукта?

Индустриальные отчеты, такие как, например, известный (или печально известный) CHAOS, выпускаемый компанией Standish Group, утверждают, что лишь незначительное число проектов по разработке ПО будут «успешными». Но что это означает? За последние годы было много попыток найти правильное определение успешности проектов, но согласие до сих пор не достигнуто. Согласно традиционной точке зрения, проект успешен, если он завершен вовремя и в рамках бюджета, а готовый продукт соответствует спецификациям. Другие говорят, что успешный продукт соответствует ожиданиям заказчика или обеспечивает соответствующий возврат инвестиций с точки зрения созданной ценности. Существует также точка зрения, что проект успешен в том случае, когда удовлетворены все заинтересованные стороны.

Как вы думаете, динозавры были успешны? А люди как биологический вид? Подозреваю, что многие ответят «нет» на первый вопрос и «да» на второй. Однако динозавры господствовали на Земле 160 миллионов лет, в то время как семейство гоминид (все виды, относящиеся к отряду приматов) существует только 6 миллионов лет. И при этом люди наносят ущерб поверхности планеты своим присутствием всего лишь 200 000 лет. С моей точки зрения, нам еще предстоит доказать, что мы успешнее динозавров (рис. 14.1).

А как вы думаете, успешны ли лошади как биологический вид? Скорее всего, моя дочь была бы с этим согласна, но ее мнение вряд ли поддержал бы великий палеонтолог Стивен Джей Гулд. В своих работах Гулд несколько раз отмечал, что почти все виды диких лошадей (Equus ferus) исчезли с лица Земли [Gould 2002]. Успешными можно признать только представителей вида Equus ferus caballus (домашняя лошадь) в том смысле, что они адаптировались и позволили Homo sapiens залезть себе на спину. Скорее всего, именно этому они и обязаны своим выживанием.

Мне кажется, есть основания утверждать, что любой биологический вид успешен до тех пор, пока не вымрет. Если учесть, что 99,9 % всех видов из когда-либо существовавших вымерли, то мы располагаем массой примеров неудачных биологических проектов. Вследствие этого я предпочитаю такое определение успешности проектов по разработке ПО:

Программный продукт успешен до тех пор, пока не потерпит неудачу.

Да, я знаю, что это звучит по-дурацки. Но мир в целом иногда выглядит по-дурацки.

Некоторые продукты, в разработке которых я принимал участие, были успешными только в течение короткого промежутка времени – до тех пор, пока клиенты не отменяли заказ, поняв что им действительно нужно (оказывалось, что нужно им нечто совершенно другое). И хотя эти продукты не доживали даже до первого релиза, команды разработчиков и представители клиентов работали над ними к обоюдному удовлетворению до тех пор, пока не изменялась ситуация или не заканчивались деньги. Я знаю и другие продукты, которые были переданы клиентам в оговоренные сроки, в рамках бюджетов и в соответствии со спецификациями, и тем не менее сразу же после первого релиза выяснялось, что они не соответствуют клиентским ожиданиям. Были ли эти проекты неудачными? На самом деле нет, поскольку обычно нам удавалось найти способы исправить свои ошибки, адаптировать продукты в соответствии с полученной обратной связью и предоставить клиенту версии, которые позволяли восстановить доверие. Мне также приходилось видеть проекты, которые получали финансирование даже через несколько лет после выпуска первого релиза, хотя было очевидно, что эти инвестиции себя уже никогда не оправдают. Видимо, в подобных случаях удается временно отложить провал, поскольку в организации клиента есть какие-то заинтересованные лица, готовые продолжать поддерживать проект. Или, может быть, некоторым клиентам просто нравится тратить деньги.

Успех – это длительное отсутствие неудач. С моей точки зрения, продукт может представлять ценность, даже если процесс его разработки не уложился в график и вышел за пределы бюджета; даже если имеет место неудовлетворительный возврат инвестиций и даже если не все заинтересованные стороны довольны. Биологические виды успешны, пока не вымрут. Мой автомобиль успешен до тех пор, пока он мне не разонравится. Программные продукты успешны, пока не потеряют всех своих пользователей. Принципы принятия изменений и непрерывного улучшения направлены на то, чтобы отложить неизбежный момент потери последнего пользователя. Рано или поздно все программные продукты постигает неудача. Я на 99,9 % в этом уверен.

Успех и степень приспособленности: все относительно

Продукт успешен, пока не потерпит неудачу. В настоящий момент я считаю, что мой автомобиль вполне успешен. Не последнюю роль в этом играет наличие подсветки педалей и качество звучания стереосистемы, которая убивает мои барабанные перепонки. Но я уверен, что какой-нибудь другой автомобиль с еще более красивыми огоньками и еще более мощной стереосистемой был бы еще успешнее, если бы я мог его себе позволить. Я также знаю, что есть люди, которым моя машина не понравилась бы ни при каких обстоятельствах. Они пользуются другими критериями при оценке автомобилей. Некоторые водят подержанные минивэны розового цвета без стереосистемы и при этом счастливы. Есть даже те, кому не нужна подсветка педалей.

Обсуждая выживаемость видов в природе, биологи иногда говорят о приспособленности. Это слово обозначает способность системы существовать и процветать. Как и успешность, приспособленность относительна. В природе не существует абсолютной приспособленности, потому что нет универсальной шкалы, с помощью которой ее можно было бы измерить. Приспособленность зависит от ниши, которую занимает данный биологический вид, от условий окружающей среды, в которой ему необходимо выживать, и от наличия поблизости других видов. Пингвины успешны в суровом климате Антарктики. А коровы успешны в контексте молочной фермы.

Приспособленность биологического вида определяется не тем, насколько хорошо устроены его конечности, глаза, крылья, плавники или вымя, а тем, насколько он соответствует условиям среды, в которой оказался. Точно так же успешность программного обеспечения определяется не тем, что оно функционирует в соответствии с намерениями своих создателей, а его способностью в определенном контексте трансформировать время и денежные ресурсы в ценность для каких-то заинтересованных лиц. Приспособленность моего автомобиля определяется не его умением хорошо ездить, а тем, насколько я им доволен. Это большая разница.

Как адаптироваться к изменениям

На протяжении нескольких страниц я пытался показать, что неопределенность будет всегда и что необходимо адаптироваться к изменениям. Не исключено, что вам все это надоело до слез и вас клонит в сон. Попробуем разбудить вас и обсудить практические аспекты неопределенности. Как вести себя в среде, характеризующейся неопределенностью? Как управлять непрерывными изменениями? Увы, универсального рецепта не существует. Управление изменениями в значительной степени будет ситуационным и зависит как от операционной среды, так и от характеристик самой организации [Bennett 2004: 10].

Многие полагают, что изменения можно поставить под контроль, внедрив соответствующие процессы. Отсюда возникла концепция непрерывного улучшения, на которой базируются многие модели и стандартизированные подходы.

По моему мнению, такой подход при управлении изменениями слишком ограничен. Необходима постоянное улучшение бизнеса, а не только процессов. С точки зрения теории сложности внедрение тех или иных процессов не снимет проблему неопределенности, так как она относится ко всей системе и исполнение каких бы то ни было процессов будет лишь ее частью. Но как оптимизировать систему, в которой все непредсказуемо, включая процессы?

Сложные проблемы обычно связаны с непредсказуемостью. Они не просто непредсказуемы – невозможно предсказать, в чем именно проявится их непредсказуемость[92].

Решение проблемы кроется в критическом анализе всей системы, а не только процессов. В главе 11 мы обсудили семь измерений проектов по разработке ПО: функциональность, качество, инструменты, люди, расписание, процессы и бизнес-ценность. Я убежден, что все семь измерений являются кандидатами на оптимизацию в изменяющейся операционной среде. Управление изменениями достигается не только посредством улучшения процессов. Необходимо постоянное внимание к функциональности, качеству, инструментам, людям, срокам и бизнес-ценности.

Управление изменениями требует от менеджеров способности переосмысливать свою роль. Если изменять только процессы (или только функциональность, как это предусмотрено в некоторых методологиях разработки), то это напоминает попытку ходить с костылем в одной руке, в то время как вторая прикована к скале.

Адаптация, исследование, прогнозирование

Стартап, который я возглавлял во время написания этой главы, был прекрасным примером системы, пытающейся выжить. Первостепенной задачей было найти клиентов, готовых платить за наши услуги. Мы пытались предугадать, где могут обитать такие клиенты, и адаптировали свое поведение, если выяснялось, что их там нет. (К сожалению, часто второе следовало за первым. Для многих стартапов процесс выживания заключается в выяснении, что работает, а что – нет.) Иногда мы просто экспериментировали, не зная, каким окажется результат. Нам важно было понять, что в конечном итоге сработает.

В большинстве Agile-методов цикл обучения системы реализуется через инкременты и ретроспективы, которые происходят итеративно. Инкремент – новый релиз продукта, помещаемый в целевую среду. Основная задача очередного инкремента – получение обратной связи, чтобы на этой основе провести необходимую адаптацию продукта (взгляд назад) и исследование (проба) и снизить до приемлемого уровня необходимость предвидеть изменения, которые могут потребоваться в будущем. Выпущенный продукт влияет на среду, а среда отвечает на это какими-то (возможно, непредвиденными) способами. Полученные знания исспользуются для того, чтобы адаптировать, предсказать, что понадобится для следующего релиза или для продолжения исследований, если мы все еще ничего не знаем.

Ретроспективы необходимы, чтобы лучше понять, развивается ли проект в нужном направлении и какие улучшения необходимо внести в его компоненты, чтобы в итоге добиться успеха. Последняя команда, с которой я работал, постоянно предоставляла клиенту новые инкременты наших продуктов, и некоторые были успешными, а другие с треском проваливались. Мы также постоянно проводили совещания-ретроспективы, на которых обсуждалось качество нашего управления проектом, и многие из этих обсуждений были весьма болезненными.

Инкременты и ретроспективы – это вариант двойного цикла обучения, концепцию которого предложили Крис Аргирис и Дональд Шон. В качестве примера двойного цикла обучения часто приводят простой термостат, управляемый оператором (за неимением вдохновения я повторю этот пример). Термостат регулирует себя сам на основе поступающей из внешней среды информации о температуре воздуха (это первый цикл, использующий модель внешней среды). Но у термостата также есть оператор, который корректирует его установки, основываясь на своем опыте и ожидаемых изменениях, которые могут быть вызваны, например, праздниками или прогнозом погоды (второй цикл, уточняющий модель окружающей среды) [Augustine 2005: 170].

Я думаю, что непрерывное улучшение в бизнес-контексте тоже происходит в два цикла и включает в себя адаптацию, исследование и прогнозирование (рис. 14.2).

Хотя адаптация часто упоминается в качестве ключевого компонента Agile-методологий, не следует забывать о роли исследования и прогнозирования. Наша задача не только решать текущие проблемы. Мы также должны пробовать решения, которые, как мы думаем, могут стать важными в ближайшем будущем (в следующем релизе и вскоре после него).

Мы готовы к неопределенности и контролируем ее путем итераций, прогнозирования и адаптации (Декларация взаимозависимости).

Но разве сама идея прогнозирования не противоречит философии Agile?

Прогнозирование можно сравнить с алкоголем. Оно полезно для здоровья только в малых дозах. Оно точно так же вызывает привыкание, и большинство людей слишком полагается на свою способность предвидеть.

При разработке программных продуктов с помощью Agile-методов мы не отказываемся от прогнозирования вовсе. Но мы стремимся использовать его по минимуму, пока вред от него не начал перевешивать полезность.

В моем предыдущем маленьком стартапе нам приходилось прибегать как к адаптации и исследованию, так и к прогнозированию. Откровенно говоря, мы вместе с командой прошли столько двойных циклов обучения, что иногда у меня голова шла кругом. Но время от времени у всех нас возникал вопрос: «Действительно ли нам удается усовершенствовать продукт? Или мы просто еле-еле успеваем не отстать от остального мира?»

Гонка Черной Королевы

Несмотря на все наши попытки внести улучшения, иногда усилия оказываются бесплодными. Разработчики никогда не бывают до конца довольны инструментами, которые они применяют. Пользователи никогда не бывают полностью удовлетворены программными продуктами, которые мы для них создаем. А члены команд никогда не бывают на 100 % довольны процессами, применяемыми в проектах. Почему? Ответ можно найти в детской книжке, впервые опубликованной в XIX столетии.

Успех – способность отсрочить неудачи на будущее. Ученые выяснили, что, поскольку вероятность вымирания в конкретной экосистеме случайна, способность биологических видов к выживанию не улучшается с течением геологического времени. Похоже на то, что повысить потенциальные шансы вида на выживание не будет целью эволюции, а изменения возникают только тогда, когда это действительно необходимо. Многие виды, такие как крокодилы, панды, акулы, осетры и крабы-мечехвосты, часто называют живыми ископаемыми, потому что они практически не изменились за миллионы лет. По-видимому, из-за того, что окружающая их среда серьезно не менялась. А если среда не меняется, то и организмы не меняются.

Но если уж в биологическом виде происходят изменения, то обычно на это есть причины более серьезные, чем изменение погоды. Кроме того, виды неразрывно связаны друг с другом, и им необходимо адаптироваться к взаимным изменениям. Например, для борьбы с насекомыми поверхность листьев растений может стать более прочной, также может появиться способность производить отпугивающие насекомых вещества. В то же время насекомые обзаводятся более прочными челюстями и химической устойчивостью к вырабатываемым растениями репеллентам. Биологические виды изменяются, чтобы остаться в игре. Это эволюционная гонка вооружений получила выразительное название Гонка Черной Королевы – оно взято из книги Льюиса Кэрролла «Алиса в Зазеркалье», где Черная Королева говорит Алисе (рис. 14.3):

Нужно бежать изо всех сил, чтобы остаться на том же самом месте.

Гонка Черной Королевы – эволюционная гипотеза, предполагающая, что сложные системы нуждаются в постоянных улучшениях, чтобы просто поддерживать свое существование в условиях, когда рядом коэволюционируют другие системы. По мнению некоторых ученых, Гонка Черной Королевы, или принцип коэволюции видов, это еще более важный драйвер эволюции, чем любые изменения внешней среды.

Гонка Черной Королевы объясняет, почему пользователи никогда не бывают полностью удовлетворены программным обеспечением. В конце концов, даже если в программные продукты с каждым новым релизом добавляются новые функциональные возможности, у пользователей параллельно появляются новые потребности. Это очень похоже на шестой закон Лемана: чтобы удовлетворенность пользователей не снижалась на протяжении жизненного цикла системы, ее функциональные возможности должны постоянно расширяться. Этот феномен также отражен в модели качества Кано, которая говорит, что те новые функциональные возможности продукта, которые поначалу потребители воспринимают с восхищением, достаточно быстро становятся частью стандартного набора функций.

Многие программные продукты не становятся лучше просто ради того, чтобы стать лучше. Они развиваются, чтобы отсрочить неизбежное наступление момента, когда пользователи от них откажутся. Успех – способность отсрочить неудачи на будущее. И если внешняя среда не изменяется, то создатели продолжают поставлять свой продукт без изменений. Зачем им вносить в него изменения? Отсутствие сильных конкурентов было причиной того, почему Microsoft в течение пяти лет после появления версии 6.0 не выпускал обновлений браузера Internet Explorer. Можно даже утверждать, что угроза быть вытесненным с рынка конкурирующими продуктами – это куда более сильный драйвер эволюции программных продуктов, чем новые потребности уже существующих пользователей. Провайдер может игнорировать своих клиентов, но не действия конкурентов.

В ближайшие несколько десятилетий способность каждого общества, организации и индивидуума адаптироваться подвергнется небывалым прежде испытаниям. ‹…› Отсюда важнейшим вопросом для каждой компании в XXI веке будет: «Меняемся ли мы столь же быстро, как мир вокруг нас?» Как мы уже видели, для многих компаний этот ответ – нет[93].

Автомобиль, на котором я езжу сейчас, стоил мне в два раза больше, чем тот, на котором я начинал водить, и у него в десять раз больше опций. Сделало ли это меня счастливее? Боюсь, лишь ненадолго. Дело в том, что у него парковочный радар только сзади, а не со всех сторон, что для меня проблема. Обогрев сидений слишком медленно набирает нужную температуру. К тому же нельзя регулировать подсветку педалей… День за днем мой автомобиль все больше и больше отстает в Гонке Черной Королевы.

Можно ли измерить сложность?

Шестой закон Лемана гласит: «Если мы хотим, чтобы удовлетворенность пользователей не снижалась, в программных системах должна появляться новая функциональность». А согласно второму закону, если не предпринимать усилий по упрощению системы, то по мере своего развития она будет становиться все сложнее. Мой личный опыт это подтверждает. Когда-то я более пяти лет работал над интранет-приложением. Со временем оно стало жить своей жизнью, и даже я уже с трудом понимал его. Будет ли такое увеличение сложности тенденцией любых сложных систем? Нормально ли, что системы со временем становятся все более сложными?

Проблема возрастающей сложности не раз становилась предметом горячих дебатов среди ученых. Некоторые из них утверждают, что нет никакого внутреннего механизма, заставляющего системы в обязательном порядке становиться сложнее. Другие говорят, что развитие жизни на Земле, и в особенности человеческого общества, доказывает: все постоянно усложняется. Есть и третья группа, считающая, что мы не представляем себе, как измерить сложность, и поэтому не можем определить, будет ли одна система сложнее другой.

Давайте присоединимся к этой дискуссии с ее конца, а именно с измерения сложности. Действительно, нет единого мерила сложности, с которым были бы согласны все исследователи. Предлагалось много различных параметров, начиная от количества агентов и связей в системе до количества ее возможных состояний, от уровня энтропии в системе до ее вычислительной мощности, а также от количества уровней в ее иерархии до «фрактальной размерности» [Mitchell 2009: 94–111]. Как и в случае с моим интранет-приложением, во всех подходах были недостатки.

И тем не менее отсутствие единого метода измерения сложности вовсе не означает, что мы не можем сказать об одной системе, что она сложнее другой. Как сказал судья Верховного суда США Поттер Стюарт, говоря о жесткой порнографии, «я узнаю ее, когда увижу». По его словам, он не смог бы дать точного определения порнографии, но безошибочно определит, что это она, когда увидит ее. То же самое относится к сравнению мозга человека с мозгом, например, цыпленка. Или к сравнению моего интранет-приложения с Центром управления полетами НАСА. Я не знаю, как доказать, что одно сложнее другого. Но «я узнаю это, когда увижу».

Становятся ли программные продукты более сложными?

Вернемся к первоначальному утверждению: действительно ли системы имеют тенденцию к усложнению? Некоторые ученые отрицают это. Существует масса примеров, когда биологические виды со временем утрачивали некоторые свои характеристики. Например, предки морских звезд имели мозг. У современных морских звезд мозг отсутствует, и никто не знает почему [Le Page 2008: 29]. (Некоторые полагают, что то же самое относится к менеджерам.) Также известно, что приматы потеряли способность синтезировать витамин C примерно в то же самое время, когда начали питаться фруктами. И параллельно они вновь приобрели цветное зрение, которое ранее ими было утрачено [Corning 2003: 176]. Так что несмотря на то, что в настоящий момент на планете обитает множество более сложных видов, чем ранее, с точки зрения биомассы наиболее успешными оказались несколько видов бактерий.

Хорошо известна позиция, которой придерживался Стивен Джей Гулд, решительно отвергавший точку зрения, что биологическим видам присуща имманентная тенденция к «возрастающей сложности» [Gould 1997]. Чтобы проиллюстрировать свою мысль, что биологические виды не имеют встроенной тенденции к усложнению, он использовал в качестве метафоры «путь пьяницы», который может случайным образом отклоняться то вправо, то влево. Гулд указывает, что слева имеется «стена», поскольку размер, вес и сложность биологических организмов не могут принимать отрицательные значения (рис. 14.4). Следовательно, если сотни пьяниц начнут свой путь от двери, расположенной рядом со стеной (состояние, характеризующееся минимальной сложностью), то усредненным направлением их движения неизбежно будет вправо – несмотря на то, что любого из них в любой момент с одинаковой вероятностью может повести как вправо, так и влево.

Несмотря на использованную Гулдом прекрасную метафору, я считаю, что тенденция к усложнению систем реально существует. Все аргументы против этого утверждения основаны на недоразумениях.

Во-первых, возрастающая сложность еще не означает прогресса. Как мы отмечали ранее, увеличение сложности не всегда сопровождается ростом приспособленности. Увеличение сложности – просто один из способов не отстать в Гонке Черной Королевы. На протяжении всей своей истории люди верили в существование биологического «прогресса», то есть стремления видов к совершенству, кульминацией которого стало появление «самого развитого» из всех биологических видов – человека. Гулд и другие ученые правильно возражали против этой точки зрения. Но при этом они, по-видимому, напрасно игнорируют внутренне присущую системам тенденцию к усложнению. И здесь нет никакого противоречия.

Во-вторых, не существует единого мерила сложности. Размеры мозга и интеллект биологических видов – лишь один из аспектов. Но сложность бактериального и вирусного миров развивалась в течение геологических эпох, хотя отдельные виды относительно просты. Но мы знаем, что до сих пор доминирующая форма жизни – это микроорганизмы. Всего лишь вопрос горизонтального роста вместо вертикального. Возможно, микробиологические формы достигли уровня сложности, сравнимого с нашим, – только в другом измерении.

В-третьих, будет ли рост сложной системы столь же вероятным, как и уменьшение? Когда пьяница пересекает улицу, действительно ли его ведет влево с такой же вероятностью, как и вправо? Мне трудно судить об этом по своему опыту, но, если говорить об эволюции, шаг вправо более вероятен, чем шаг влево. Давайте подумаем вот о чем: откуда ученые узнали, что у морских звезд раньше был мозг? Или что раньше организм приматов мог синтезировать витамин C? Они узнали об этом, потому что следы этих признаков сохраняются в ДНК в виде псевдогенов. Функции утрачены, но код все еще доступен, хотя и находится в спящем состоянии. Но он может быть вновь активирован. Именно так в ходе эволюции некоторые виды «повторно» приобрели характеристики, которые ранее были утрачены. Просто происходит повторное включение генов, которые ранее были отключены! Поэтому утрата системой какой-либо функции не означает, что система стала менее сложной. Возможно, она даже усложнилась, поскольку добавилась новая функция отключения/включения определенных генов.

В-четвертых, согласно второму закону термодинамики энтропия (или беспорядок) в системе со временем возрастает. И хотя, строго говоря, это верно лишь для закрытых систем, мы можем видеть проявления энтропии в нашем геноме в виде мусорной ДНК. И я уверен (хотя не могу это доказать), что наличие мусорной ДНК увеличивает сложность системы. Достаточно нескольких генетических мутаций, чтобы реактивировать эту мусорную ДНК с непредсказуемыми последствиями.

И наконец, последним аргументом в пользу тенденции систем к усложнению будет уже сделанное нами наблюдение, что внутренние модели, создаваемые системой, должны отражать характеристики среды, в которой данная система пытается выжить. Если среда усложняется, то обитающие в ней системы со временем также эволюционируют в сторону большей сложности. В общем, адаптироваться к сложной среде могут сложные системы, и высока вероятность, что естественный отбор оказывает сильное давление именно в пользу более сложных систем [Gell-Mann 1994: 245].

С учетом этих пяти аргументов я беру на себя смелость утверждать, что многие живые системы действительно со временем становятся более сложными. Мне никогда раньше не приходило в голову, что я когда-нибудь буду несогласен с Гулдом, поскольку мне он всегда казался одним из самых умных людей на планете. И все же я вынужден с ним не согласиться. Так что вполне возможно, что прогресс все-таки существует.

Форма вещей: фазовое пространство

Когда мне было пятнадцать, я увлекался чтением книг, в которых рассказывалось о пространстве и форме Вселенной. (Мои сверстники больше интересовались совсем другими формами, но мне всегда хотелось разобраться в общей картине.) То, что я прочитал о специальной теории относительности и расширяющейся Вселенной, побудило меня нарисовать на листе бумаге свой собственный четырехмерный объект (рис. 14.5).

Я построил объект, изображенный на рис. 14.5, переместив обычный куб в воображаемом четырехмерном пространстве и соединив шестнадцать углов линиями, точно так же, как мы можем построить обычный куб, сдвинув квадрат в трехмерном пространстве и соединив линиями восемь углов. Я был упоен тем, что так просто нарисовать 2D-проекцию 3D-проекции 4D-объекта. В то время данная фигура мне нравилась больше всего. Но когда я показал свой рисунок учителю физики, тот сказал мне, что все нарисовано неправильно. Мне казалось, что меня не поняли. Годы спустя я узнал, что объект, который я «изобрел», называется гиперкуб и что учитель физики упустил прекрасную возможность чему-то научиться у одного из своих учеников.

Но гиперкуб – ничто в сравнении с «формой улучшения» сложной системы. Оценивая разные состояния динамической системы, исследователи представляют каждую переменную систему как ось многомерной Вселенной. Небольшая система с тремя переменными отображается в виде фазового пространства с тремя измерениями; у системы с двадцатью переменными фазовое пространство имеет не менее двадцати измерений. Боюсь, что даже я не смогу нарисовать такой объект. И это еще не предел. Многие сложные системы содержат тысячи и более переменных и соответствующее ошеломляюще сложное фазовое пространство.

Например, у водорослей порядка 1000 генов. Предположим ради простоты, что каждый из этих генов отвечает за два признака: листья могут быть зелеными или коричневыми, маленькими или большими, плоскими или морщинистыми и так далее. В этом случае число возможных состояний конкретного растения будет составлять 21000, или тысячу измерений по два возможных значения в каждом из них [Waldrop 1992: 167]. (ДНК человека состоит примерно из 25 000 генов – и более чем двух вариантов каждого. Можете себе представить гиперкуб, нарисованный в таком фазовом пространстве?)

Конкретное состояние системы отображается одной точкой в ее фазовом пространстве. (У каждой переменной в данный момент может быть только одно значение.) Когда одна из переменных изменяется, говорят, что система движется в своем фазовом пространстве. Переключение одного гена в ДНК водорослей (например, переход с зеленых листьев на коричневые) сдвигает ДНК из одной точки в ее фазовом пространстве в соседнюю. А одновременное изменение многих переменных (например, в случае смешивания цепочек ДНК из женского организма и мужского с получением на выходе новой ДНК) будет уже гиперпрыжком в фазовом пространстве.

Представляя изменения в виде перемещения в пространстве, легче визуализировать и обсуждать закономерности непрерывной оптимизации. Также становится яснее, какие формы важны, а какие – нет.

Аттракторы и конвергенция

Усложним немного нашу математику. Наберитесь терпения, я постараюсь помочь вам пройти этот нелегкий путь. Пейзаж, который откроется вашему взору, оправдает приложенные усилия.

Когда сложные системы изменяются, их путешествие в соответствующем обширном фазовом пространстве обычно попадает в одну из нескольких категорий. Вспомните пример с игрой «Жизнь», описанной в главе 8. Независимо от исходной конфигурации, через несколько этапов система в большинстве случаев приходит в устойчивое состояние, которое будет либо стационарным («натюрморт»), либо бесконечно повторяющимся циклом небольшого числа состояний. Мы говорим, что устойчивое состояние – это аттрактор для всех других состояний, которые к нему приводят. Набор всех траекторий, которые приводят к данному аттрактору, называется областью притяжения аттрактора (рис. 14.6). Поскольку каждая система обычно следует по траекториям, которые ведут к аттракторам, аттракторы затягивают систему в один небольшой регион ее фазового состояния. Несмотря на огромное число возможных состояний системы, она в конечном итоге оказывается лишь в одном из немногих упорядоченных состояний.

Вы все еще со мной? Отлично. Конкретизируем все это на том же примере с водорослями.

Теоретически у водорослей может существовать 21000 версий ДНК. Вообще-то это очень много. Это больше, чем количество атомов во Вселенной. Однако реально наблюдаемых форм водорослей совсем мало, потому что все остальные нестабильны и через несколько поколений либо вымирают, либо трансформируются в одну из стабильных форм. Не имеет значения, что теоретически водоросли могут принимать одну из бессчетных возможных форм. На практике среда обитания заставляет водоросли принять одну из форм, которые могут существовать в этой среде.

Некоторые ученые полагают, что конвергенция, заключающаяся в том, что такие биологические решения, как глаза и крылья, в ходе эволюции были полностью независимо «изобретены» несколько раз, это хорошая иллюстрация аттракторов [Lewin 1999: 73]. С точки зрения биологической морфологии существуют аттракторы «четырехногого существа», «существа с двумя крыльями» и так далее. Формы с пятью ногами или одним крылом имеют право на существование, но они неустойчивы (за исключением, пожалуй, района вокруг АЭС с неустойчивым реактором).

Как мне представляется, чтобы программный продукт хорошо работал в соответствующей среде, он тоже должен быть устойчивым. Продукты в целом конвергируют к устойчивым формам, но это не значит, что такие формы непременно хорошо работают.

Устойчивость и возмущения

Ниже приведены три типа аттракторов, существующих в сложных системах [Gleick 1987: 269]:

• Фиксированные точки. Система сохраняет одно определенное состояние. Хорошим примером такого аттрактора служит организационная иерархия. Почти все компании принимают структуру такого типа, а затем остаются в этом состоянии навечно [Waldrop 1992: 169].

• Замкнутые циклические. Система постоянно повторяет одну и ту же последовательность состояний. Одним из примеров будет динамика развития групп, проходящая стадии формирования, конфликта, нормализации, исполнения работы и расформирования [Arrow 2000: 152].

• Хаотические, или «странные», аттракторы. Примером странного аттрактора служит ведущий себя хаотически стартап, перескакивающий от одной бизнес-возможности к другой и не останавливающийся ни на одной из них, пока среда, в которой он функционирует, не позволит ему сделать окончательный выбор.

Как правило, аттрактор имеет обширную область притяжения. Теперь предположим, что на устойчивую систему начинает воздействовать какое-либо возмущение. Внезапно одна из ее переменных произвольно перескакивает с одного значения на другое. (Например, один метод развития сменяется другим.) На рис. 14.6 показано, что большинство таких пертурбаций не оказывает значительного воздействия на систему. Она или остается притянутой к аттрактору (S1), или же, если ее оттянуло от аттрактора, но при этом она осталась в его области притяжения (S2), она все равно возвращается в свое конечное состояние. Только когда значение переменных в системе изменилось достаточно сильно, систему может вытолкнуть из области притяжения одного аттрактора в другую область (S3).

Устойчивость, или гомеостаз, это важное свойство сложных систем. Независимо от интенсивности применяемых к ним воздействий, некоторые системы упорно сохраняют свое состояние. Звучит знакомо? Разве это не похоже на тот случай, когда вы пытались внедрить Agile-методологии в своей команде, но она в конечном итоге вернулась к привычным методам работы? Не напоминает ли это вам о том, как вы пытались изменить организационную культуру, но все ваши усилия натыкались на сопротивление?

Как и любые другие сложные системы, группа людей может стать пленницей какого-либо аттрактора. Это может быть хорошо или плохо. Прекрасно, если для данного устойчивого состояния характерна высокая производительность. Хуже, если другие факторы, например организационная культура, удерживают группу возле «плохого» аттрактора и повысить ее производительность никак не удается. Насильственное внедрение «улучшений» лишь в редких случаях дает желаемый результат. Даже если вы сможете отодвинуть группу от ее аттрактора, обширная область притяжения вокруг него все равно заставит ее вернуться в прежнее состояние.

Так в чем же состоит решение? Как эффективно управлять изменениями? Я считаю, что решение следует искать не внутри системы, а во внешней среде. Аттракторы зависят от среды, в которой находится данная система. Когда изменяется окружающая систему среда, изменяются и они. Некоторые изменения, вносимые во внешнюю среду, настолько сильно воздействуют на аттракторы, что те просто исчезают, а система автоматически находит для себя траекторию, ведущую к другому аттрактору. Это даже может быть аттрактор, которого ранее не существовало.

При внесении изменений в команды и организации не следует пытаться вытолкнуть их из колеи, в которой они оказались. Это потребует огромных усилий и принесет более чем скромные результаты. Гораздо лучше изменять параметры среды, в которой функционирует данная организация или команда, пока ее текущее положение не утратит устойчивость и в конечном итоге вообще не станет невозможным.

Давайте я приведу пример… Я пробовал внедрить методы разработки с ориентацией на тестирование (TDD) в нескольких командах, но безрезультатно. Казалось, что все сговорилось против меня – старые версии кода, технические платформы, культура команд и контракты с клиентами. Даже в тех случаях, когда сотрудники хотели перейти на эти методы, им не удавалось довести свои героические усилия до конца. Тогда я решил начать с нуля с новой бизнес-моделью, другими технологиями, другой архитектурой и (что очень важно) с другими клиентскими контрактами. В команду были набраны те же люди, с кем я работал раньше. Но я изменил внешнюю среду вместо того, чтобы пытаться изменить саму команду. В этой ситуации команде удалось найти устойчивое состояние, которое включало методы разработки через тестирование. Внезапно использование этих методов перестало вызывать какие-либо затруднения.

Адаптивный ландшафт

Сейчас я попытаюсь еще сильнее напрячь ваше воображение. Представьте себе еще одно измерение, которое мы добавим к фазовому пространству. Это дополнительное измерение будет соответствовать степени «приспособленности» системы к определенной среде. (Естественно, абсолютной шкалы, которая позволяла бы измерить этот параметр, не существует [Waldrop 1992: 259]. Но, как уже бывало ранее, мы вполне в состоянии определить, что одна система лучше приспособлена к определенной среде, чем другая. «Я узнаю ее, когда увижу!»)

На рис. 14.7 в двух измерениях показана комбинация степени приспособленности и фазового пространства. Горизонтальная ось показывает местонахождение в фазовом пространстве системы (все измерения фазового пространства свернуты в одну линию). Вертикальная ось соответствует степени приспособленности. В результате мы получили то, что системные теоретики называют адаптивным ландшафтом. Он показывает, насколько хорошо функционирует система относительно своего текущего состояния. Немного похоже на Альпы, но без будок, в которых собирают деньги за проезд по платным дорогам.

Когда мы вносим изменения в какой-либо элемент системы (один ген, один сотрудник, один член команды, одна практика), система сдвигается влево или вправо в нашем ландшафте, что либо повышает, либо понижает степень ее адаптированности. Системы, способные достичь самых высоких точек в этом ландшафте, обладают максимальными шансами на выживание. Системы, обладающие способностью раз за разом перенастраивать свою внутреннюю организацию, совершают адаптивную прогулку по соответствующему ландшафту. Адаптивная прогулка – это процесс, с помощью которого система переходит из одной конфигурации в другую с целью сохранить свою приспособленность к обстоятельствам. Проекты по разработке ПО совершают адаптивные прогулки, вновь и вновь изменяя требования к функциональности продуктов, заменяя людей и инструменты, пересматривая графики и внося изменения в процессы. Это вроде похода в Швейцарских Альпах. И требует не меньшего количества усилий.

Форма адаптивного ландшафта зависит как от системы, так и от окружающей ее среды. По этой причине стратегии выживания одной системы не очень легко переносятся на другие. Консультанты со стороны, привыкшие полагаться на решения, которые сработали для одних групп и организаций, могут ошибаться, пытаясь перенести те же самые подходы на группу с совершенно иным адаптивным ландшафтом [Arrow 2000: 182].

Смысл вышесказанного – никогда не следует слепо доверять советам других, как оптимизировать ваш проект. По определению адаптивные ландшафты других людей отличаются от вашего. Это ваша прогулка. Пройти ее за вас никто не сможет.

Системы адаптируются к внешней среде и друг к другу. Когда два или более биологических вида, бизнеса или продукта постоянно адаптируются к взаимным передвижениям по соответствующим адаптивным ландшафтам, мы говорим, что они коэволюционируют. Таким образом, мы можем предположить, что во внутренней структуре каждой системы закодирована информация о характеристиках среды и других систем, с которыми она коэволюционирует.

Среда обитания любого биологического вида включает большое число других видов, которые сами находятся в процессе эволюции. Генотип каждого организма или набор генотипов, характерных для каждого вида, можно рассматривать в качестве схемы, включающей в том числе и описание многих других видов и характерных для них типов поведения. Таким образом, экологическое сообщество состоит из множества биологических видов, каждый из которых создает модели привычек других видов и способов реагирования на них[94].

Мы должны понимать, что из-за изменчивости среды обитания и систем, эволюция которых протекает бок о бок, адаптивные ландшафты никогда не бывают статичными. Они как будто бы сделаны из резины [Waldrop 1992: 310]. Пока вы совершаете свою адаптивную прогулку по этому пейзажу, вы видите, как некоторые вершины исчезают и возникают другие, долины могут передвинуться в другое место, а у каждого вашего шага возможны непредвиденные последствия – например, перед вами вдруг вырастет стена, а скалы позади исчезнут. В этом и состоит основная причина, почему необходимо постоянно подвергать свою стратегию переоценке.

Похоже ли это на Швейцарские Альпы? Не очень. Если, конечно, вы не употребили слишком много вина со своим фондю.

Формируем ландшафт

Легко ли передвигаться по адаптивному ландшафту? Трудно ли найти вершину? Что взять с собой из инструментов – палки для скандинавской ходьбы или швейцарские армейские ножи?

Форма адаптивного ландшафта зависит от степени взаимосвязанности компонентов системы. Это легко показать на примере. Представьте себе, что все элементы проекта (люди, инструменты, практики и все остальное) вообще никак не влияют друг на друга. В этом гипотетическом случае замена одного человека, инструмента или процесса на другой не будет иметь никаких последствий для других элементов. Влияние (в лучшую или худшую сторону) изменений в одном из элементов на приспособленность системы будет абсолютно изолированным. Это означало бы, что у проекта есть одна и только одна оптимальная конфигурация, а именно та, при которой влияние каждого элемента будет максимально положительным. Такая конфигурация соответствовала бы единственному и самому высокому пику в ландшафте (рис. 14.8а).

К сожалению, такая ситуация маловероятна. Между агентами в сложной системе всегда существует определенное взаимодействие. Гены, отвечающие за наличие перьев и крыльев, связаны и совместно влияют на приспособленность организма. То же самое относится к разным комбинациям функциональности продукта, состава разработчиков, инструментов и процессов в рамках проекта. Уберите один из компонентов, и остальные тоже перестанут работать.

Исследователи обнаружили, что при наличии большого числа взаимозависимостей между компонентами системы ее адаптивный ландшафт выглядит как сильно пересеченная местность со множественными пиками, высота которых варьируется в небольшом интервале (рис. 14.8b). Они называют такую ситуацию «катастрофа сложности», и это снижает шансы системы достичь оптимальной адаптации. Внесение простых изменений в подобную систему приводит к хаотическим колебаниям в ее поведении, а шаг влево или вправо часто заканчивается падением со скалы. Поэтому представляется, что степень пересеченности адаптивного ландшафта (определяемая количеством взаимодействий между компонентами системы) серьезным образом влияет на стратегии выживания системы.

Для нас практический вывод состоит в том, что в системе не должно быть слишком много взаимозависимостей, а предпочтительным будет умеренно пересеченный ландшафт (рис. 14.8c). Изменения в одной части системы будут оказывать некоторое воздействие на остальные части системы, но это воздействие не будет иметь слишком драматических последствий. Отсюда также вытекает, что методы, используемые при разработке ПО, должны состоять из слабо связанных между собой практик. В этом случае процесс непрерывной оптимизации не будет на каждом шагу вызывать падение с Маттерхорна.

Направленная и ненаправленная адаптация

В своей книге «Малые группы как сложные системы» (Small Groups as Complex Systems) авторы различают два вида адаптации – направленную и ненаправленную [Arrow 2000: 175–176]. Ненаправленная (в моей терминологии ей соответствуют адаптация и исследование) происходит в биологических системах. ДНК мутирует случайным образом, и биологические виды совершают свои адаптивные прогулки во всех направлениях, в том числе и в неправильных. Но естественный отбор отсеивает организмы, унаследовавшие вредные изменения. (Если бы руководить людьми было так же легко…)

Проявления направленной адаптации (в моих терминах ей соответствует прогнозирование) можно наблюдать в системах, в которых участвуют люди. Команда разработчиков не может себе позволить испробовать все возможные комбинации функциональных возможностей продукта, людей, инструментов и процессов. В этом случае на помощь призывается сознательная селекция. Люди обладают интеллектуальной возможностью обоснованно предвидеть, где на их пути по адаптивному ландшафту могут встретиться наиболее высокие вершины. Они стараются сбалансировать число функциональных возможностей и качество, нанимают и увольняют людей, выбирают и отбрасывают инструменты, а также учатся на опыте других.

Помимо направленной адаптации, команды ненамеренно осуществляют действия, которые будут ненаправленной адаптацией. Они могут постепенно вносить изменения в применяемые процессы, не имея при этом осознанного плана. Они также могут изменить свой подход между итерациями, хотя это не будет частью осознанной стратегии изменений. Со временем все эти небольшие изменения могут накапливаться [Arrow 2000: 175] и становиться причиной существенных перемещений в рамках соответствующего адаптивного ландшафта.

Интересно, что генная инженерия преднамеренно привнесла направленную адаптацию в биологический мир, посредством искусственной эволюции существенно ускорив изменение сельскохозяйственных культур и скота [Kelly 1994: 3].

В научной литературе адаптивные изменения в сложных адаптивных системах обычно ассоциируются с ненаправленной адаптацией. Единственная причина, почему это происходит, – тенденция ученых предпочитать в качестве объекта изучения то, что можно засунуть под микроскоп. Это не означает, что теория сложности применима только к системам, в которых действуют не обладающие сознанием агенты. Наоборот, с точки зрения динамики адаптивных ландшафтов и выбора стратегий практически безразлично, какому именно механизму системы обязаны своим движением по адаптивному ландшафту – естественному или осознанному отбору.

На этом месте мы вполне осознанно и завершаем данную главу. В следующей речь пойдет о методах непрерывной оптимизации.

Резюме

Вопреки убеждению многих, внешнюю среду нельзя рассматривать отдельно от населяющих ее систем. Если в определенную среду привносится новый программный продукт, среда изменяется, а вместе с ней изменяются и требования к программному продукту.

Люди от природы настроены сопротивляться изменениям и в большинстве случаев считают их негативными. Однако изменения могут быть как негативными, так и позитивными, а количество усилий, направляемых на преодоление последствий, вызванных изменениями во внешней среде, для данной системы будет более или менее постоянным. В конечном счете любой продукт оказывается обреченным на неудачу, а успех может быть определен как способность максимально отсрочить момент наступления этой неудачи.

Существует три подхода, применяемых при проведении непрерывного улучшения: адаптация, исследование и прогнозирование. При реализации проектов необходимо пользоваться всеми тремя в виде непрерывного цикла. Процесс непрерывного улучшения иногда называют Гонкой Черной Королевы: необходимо постоянно совершенствоваться, чтобы не отстать.

Иногда организации или команды не в состоянии измениться. В таких случаях говорят, что систему необходимо освободить от некоего аттрактора. Лучшим способом вывести ее из этого состояния может оказаться внесение изменений в параметры внешней среды, что позволяет дестабилизировать соответствующий аттрактор.

Усилия по поиску оптимальной конфигурации для проекта можно рассматривать как прогулку по адаптивному ландшафту. Лучше всего, если проект состоит из слабосвязанных элементов (людей, инструментов и практик), поскольку непрерывное улучшение легче проводить, если изменения, внесенные в часть системы, не вызывают слишком серьезных возмущений во всей системе.

Подумать и сделать

Посмотрим, сможете ли вы применить некоторые идеи из этой главы в своей компании:

• Проанализируйте применяемый вами процесс непрерывного улучшения. Используете ли вы все три доступных подхода (адаптация, исследование, прогнозирование)?

• Подумайте о своей команде и практиках, применяемых в процессе разработки. Не слишком ли велика степень взаимозависимости (когда люди или процессы хорошо работают только в комбинации с определенными людьми или процессами)? Возможно ли ослабить эту взаимозависимость, чтобы было легче заменять элементы и вносить улучшения?

Глава 15 Как улучшить всё

Разумный человек приспособляется к миру; неразумный пытается приспособить мир к себе. Поэтому прогресс всегда зависит от неразумных.

Джордж Бернард Шоу,драматург (1856–1950)

Читая литературу, посвященную проблемам улучшения процессов или повышения качества, с неизбежностью наталкиваешься на те или иные модели. Вообще в этом бизнесе моделей такое множество, что меня не удивило бы появление модельного агентства. Большая часть выглядит весьма привлекательно на картинках. Однако при знакомстве с ними возникает впечатление, что им не хватает глубины.

В таблице 15.1 в обобщенном виде показаны пять наиболее известных моделей улучшения. Я называю этот обобщенный процесс простым линейным процессом улучшения (SLIP, Simple Linear Improvement Process). Он предусматривает восемь этапов.

ПРИМЕЧАНИЕ: я сам составил приведенную здесь таблицу соответствий между распространенными моделями других авторов и моей собственной, поэтому она субъективна. У других сравнение этих моделей могло бы выглядеть иначе.

Вполне очевидно, что все эти модели имеют сходную логику, и в том виде, как это показано у меня, предполагают выполнение восьми этапов:

1. Мы анализируем текущую ситуацию и определяем, в чем состоит самая насущная проблема. (Например, мы толстеем.)

2. Формулируем цель, достижение которой поможет нам выбраться из данной проблемной ситуации. (Хотим похудеть на четыре килограмма.)

3. Выбираем показатель, по которому будем судить о том, удалось ли нам этой цели достичь. (Достаем с чердака старые весы.)

4. Определяем желательное улучшение в поведении, которое продвинет нас к поставленной цели. (Решаем делать пробежки и есть более здоровую пищу.)

5. Проводим внедрение, желательно в рамках небольшого контролируемого эксперимента. (Покупаем кулинарную книгу и кроссовки.)

6. Затем следует этап повседневного исполнения, результаты которого подвергаются измерениям. (Ежедневно бегаем и едим здоровую пищу.)

7. Проводим анализ проведенных измерений, чтобы узнать, наступили ли желаемые улучшения. (О боже, всего полкило за три недели?)

8. И наконец, в результате проведенного анализа у нас появляется новая информация – как о проблеме, так и об эффективности применяемого решения и используемых показателях. Эту информацию мы можем использовать при следующей итерации. (Внезапно выясняется, что старые весы все это время показывали неверный вес.)

Завершив этап 8, мы возвращаемся к этапу 1 – либо для того, чтобы убедиться, что проблема все еще существует (лишний вес никуда не делся), либо чтобы решить новую, более насущную проблему (купить новые весы).

Работая с такими моделями улучшений, люди исходят из неявной гипотезы, что каждая итерация, в принципе, должна улучшать текущее состояние системы. Намеренно или нет, все модели этого типа шаг за шагом прокладывают линейный маршрут по адаптивному ландшафту. При этом предполагается, что каждый шаг приводит к улучшению нашего положения в адаптивном ландшафте, повышая нашу приспособленность и уменьшая объем талии.

Линейные улучшения в сравнении с нелинейными

Адаптивные ландшафты далеко не всегда способствуют линейным изменениям. Осуществляя пошаговые улучшения, легко застрять в точке локального оптимума. Но как перейти из состояния, когда уже достигнута определенная эффективность, в состояние, где эта эффективность гораздо выше, если между этими точками сплошные овраги (см. рис. 15.1)?

Это стандартная проблема для многих программ улучшения. В результате возникают фразы вроде «шаг назад – два шага вперед» или «прежде чем станет лучше, временно будет хуже». Адаптивная прогулка сложной системы по адаптивному ландшафту не всегда проста. Стандартные процессные модели не принимают во внимание (по крайней мере в явном виде) тот факт, что множественные итерации, даже если они, по идее, должны способствовать движению в правильном направлении, могут сделать ситуацию только хуже. Хочется верить, что ненадолго.

Эта особенность изменений – отсутствие линейности – вторая причина, почему большинство методологий «управления изменениями» неэффективны. Неизбежные попытки втиснуть непредсказуемость в рамки линейных подходов оказывают разрушительное воздействие на управление жизненными циклами продуктов, циклы разработки систем и тому подобное. ‹…› Теория бизнеса переполнена моделями жизненных циклов продукта, большинство из которых не в состоянии описать нелинейную и непредсказуемую природу этих циклов, особенно в условиях, когда рынки, запросы потребителей, бизнес и экономика в целом постоянно усложняются[95].

Осуществлять линейные изменения относительно легко. Но что если высота, которую намеревается покорить команда, это всего лишь небольшой холм? Что если команда оказалась в низкорослых Арденнах на территории Бельгии вместо высоких Швейцарских Альп? Команды нуждаются не только в методиках пошаговых улучшений. Во многих ситуациях сначала нужно за пару радикальных прыжков преодолеть расстояние до самого горного хребта и лишь затем шаг за шагом постепенно добраться до вершины.

В книге «Как привести в действие процесс инноваций»[96] авторы отмечают, что бизнес может нуждаться не только в постепенных инновациях, но и в радикальных (Davila 2006: 51–55]. И тем не менее большая часть литературы по бережливым методологиям в основном проповедует кайдзен (постепенные улучшения) и почти не упоминает ситуации, когда необходимы принципы кайкаку (радикальное улучшение процессов) [Middleton, Sutton 2005: 31].

Таким образом, при возникновении проблемной ситуации вначале могут потребоваться радикальные улучшения (кайкаку) и лишь затем серия постепенных (кайдзен).

А в чем тогда состоит роль адаптации?

Как мы знаем, когда речь идет о непрерывном улучшений, имеются в виду процессы адаптации, прогнозирования и исследования. Адаптация по своей сути реактивна: она заключается в реагировании на изменения внешней среды. Прогнозирование проактивно: мы представляем в своем воображении наиболее оптимальную точку в адаптивном ландшафте и начинаем двигаться к ней. Исследование интерактивно: мы делаем что-либо в пробном режиме, чтобы выяснить, какой эффект получим на выходе. Однако мы делаем это не потому, что того требует внешняя среда или мы уже представили себе, как должны выглядеть оптимальные результаты.

Системы, в которых люди не участвуют, улучшаются исключительно путем приспособления к внешней среде (адаптация) и методом случайных проб (исследование). Но группы людей могут прибегнуть к своему воображению, чтобы представить себе оптимальные результаты (прогнозирование). Процесс непрерывного улучшения подразумевает использование всех трех методов.

Я не буду возвращаться в этой главе к существующим моделям улучшения. Вместо этого мы сосредоточимся на тех аспектах, которые, по всей видимости, в данных моделях отсутствуют. То есть на подиуме появится более сложная модель. Совместными усилиями мы разберемся, как трансформировать наши теоретические взгляды в практические методы непрерывного улучшения и с какой именно моделью предпочтительнее работать на повседневной основе.

Определите свое местоположение

Когда во время отпуска мы с моим партнером путешествуем на автомобиле по незнакомой стране, то обычно у меня лучше получается находить дорогу до очередной достопримечательности, рассчитывать время, необходимое, чтобы добраться в пункт назначения, и расшифровывать дурацкие символы на картах. К сожалению, меня легко вводят в заблуждение неожиданные повороты, незаметные съезды с дороги и невидимые знаки. Мой партнер, наоборот, обычно не имеет ни малейшего представления о том, куда мы едем, и пару раз мне приходилось видеть, как он держит карту вверх ногами. Но поскольку он несколько умнее меня, то понимает, что совсем не разбирается в таких делах. Я же всегда уверен, что точно знаю, куда мы едем и как пользоваться картой. В результате я слишком поздно осознаю, что дорога в очередной раз сыграла с моей самоуверенностью злую шутку. Так что не имеет значения, кто из нас в данный момент за рулем. Все равно рано или поздно мы заблудимся.

Пытаясь улучшить ситуацию первое, что нужно знать наверняка, – это ваше текущее положение. Вам не удастся найти дорогу до следующего отеля или дожить до следующего успешного релиза продукта, если вы не имеете представления о том, где в данный момент находитесь. Майк Кон называет это развитием осведомленности [Cohn 2009: 23–26], а Мэри и Том Поппендик – представлением проблем в явном виде [Poppendieck 2009: 169–172]. Чтобы определиться со своим местонахождением, необходимо посмотреть по сторонам и распознать наиболее насущные проблемы. В противном случае вы обречены вечно блуждать в темноте, не представляя, приближаетесь ли вы вообще к своей цели. В такой ситуации улучшение будет зависеть исключительно от удачи и совпадений.

Литература по гибким методологиям изобилует рекомендациями, как оценивать свою текущую ситуацию. Существует огромное количество инструментов – диаграммы сгорания задач (Burn-Down), карты потока ценности, метод пяти «почему», ретроспективы и десятки других. Все они помогают разобраться с тем, насколько мы продвинулись вперед и какие при этом обнаружились проблемы. В дополнение к этой книге потребовалось бы сочинить еще несколько томов, чтобы описать все имеющиеся в вашем распоряжении опции. Но мне приходится себя ограничивать. Я очень хорошо понимаю, в чем состоит цель этой книги, поэтому любой уход в сторону значительно замедлил бы наше движение. Пока я ограничусь советом отправиться туда, где живут и работают ваши команды, чтобы узнать и лично увидеть, какие из существующих проблем наиболее важны [Poppendieck 2009: 172].

Однажды мы путешествовали в горах между Аргентиной и Чили. Для начала мы проехали озеро, которое – видимо, для того, чтобы запутать меня, – находилось не на той стороне дороги, как это было показано на карте (как выяснилось, это произошло потому, что мой партнер держал карту вверх ногами). Вскоре после этого нам повстречался человек с машиной, застрявший в этой глуши, потому что кончился бензин. До ближайшего форпоста цивилизации оставалось несколько часов пути. Но мы-то провели предварительные расчеты и точно знали, где находимся. Мы представляли, где наша точка назначения и сколько времени до нее ехать. Поэтому мы могли спокойно поделиться половиной бензина, который имелся у нас в запасной канистре. Заправив машину, незнакомец помчался дальше, причем на дикой скорости. Нам едва удавалось не отстать от него, так он торопился добраться до следующей заправки, и в итоге у него снова кончился бензин. Судя по всему, этот человек так и не понял, почему у него возникли проблемы и как избежать подобных ситуаций в будущем.

Советы путешествующим по зыбкому ландшафту

В предыдущей главе мы видели, что адаптивные ландшафты имеют тенденцию изменяться. Трудно дать точные указания, как попасть в определенное место, если горы бегут быстрее, чем альпака и викуньи. Но если вы готовы принять, что пейзаж может ни с того ни с сего передвинуться на противоположную сторону дороги, то не так трудно усвоить несколько базовых принципов непрерывного улучшения:

• Если смотреть из долины, часто видишь только ближайшие горы, а другие (иногда гораздо более высокие) пики, расположенные за ними, совсем не видны. Об этом не стоит беспокоиться. Когда вы заберетесь на ближайшую вершину, то окажетесь в лучшем положении (и в лучшей форме), чтобы увидеть открывшийся более широкий пейзаж.

• Чем больше времени требуется, чтобы добраться до любого из удаленных пиков в адаптивном ландшафте, тем выше шансы, что к моменту, когда вы туда доберетесь, его уже не будет на месте.

• Скорее всего, вы не сможете сразу увидеть самые лучшие вершины. Но по крайней мере вы поймете, где находятся основные горные хребты. Кроме того, в горах даже долина может располагаться выше, чем холм на равнине.

• Можете быть уверены, что в горах все пики достаточно высокие. Не имеет значения, на какой из них вы собираетесь забраться, ваша цель – просто карабкаться.

• Только когда вы окажетесь на вершине, будет легче увидеть, какой из пиков действительно самый высокий.

Давайте проверим эти идеи на практическом примере (рис. 15.2). Предположим, вы отвечаете за команду, которая использует устаревшие процессы, и ее эффективность в результате находится на ужасающе низком уровне…

1. Прежде чем радикально менять команду и процессы, выполните ряд мелких шагов, чтобы несколько улучшить ее положение в адаптивном ландшафте (через повышение дисциплины, принятие стандартов по написанию кода, улучшение ежедневной коммуникации и так далее). Когда команда окажется в лучшей форме, ее членам будет легче увидеть, понять и принять радикальные изменения.

2. После этих небольших изменений команда будет лучше подготовлена к более радикальным реформам (вроде внедрения Экстремального программирования, Scrum или канбана). Эти реформы должны быть реализованы небольшими «прыжками» в течение нескольких дней или недель. Не затевайте крупную реорганизацию, на которую уйдет несколько месяцев: за это время оптимальное положение в адаптивном ландшафте, к которому вы стремитесь, может исчезнуть.

3. Не стоит ожидать, что совершенный командой «радикальный прыжок» (например, внедрение Scrum в полном объеме) сразу же значительно повысит ее эффективность. На некоторое время может возникнуть ситуация, когда эффективность даже снизится. Если вы все сделали правильно, проведенная вами радикальная реформа (кайкаку) будет прыжком в правильном направлении и вы, скорее всего, окажетесь поблизости от горного хребта. Теперь при помощи ретроспектив вам предстоит провести постепенные пошаговые улучшения (кайдзен), чтобы взобраться на ближайшую вершину. Есть много способов постепенно повысить эффективность команды. И не слишком беспокойтесь в этот момент, правильный ли выбор вы сделали, решив внедрить Scrum. Если вы выбрали хорошую методологию и на этой основе постепенно оптимизируете эффективность команды, то все в порядке.

4. После того как данный этап оптимизации будет завершен, у команды появится возможность осмотреться в адаптивном ландшафте. Команда может даже захотеть провести еще одну полурадикальную реформу и перейти на Экстремальное программирование или канбан, если считает, что это позволит ей еще больше повысить свою эффективность.

5. После прыжка на очередной многообещающий пик команде опять предстоит заняться постепенной оптимизацией, которая даст ей возможность еще больше повысить свою глобальную приспособленность к реализации проектов.

Если команде в конце концов удастся достичь самой высокой вершины в адаптивном ландшафте, ей все равно не стоит терять бдительность. Поскольку либо эта вершина может изменить свое местоположение, и в этом случае нужно будет передвинуться вместе с ней, либо эта вершина начнет постепенно снижаться, и в этом случае надо будет начинать готовиться к штурму другого пика.

Снижение производительности, которое наблюдается в командах после любых изменений, отображено на кривой изменений, предложенной Вирджинией Сатир (рис. 15.3) [Satir 1991]. С точки зрения сложности это явление можно визуализировать как попадание после прыжка в долину в адаптивном ландшафте. С этого момента должно начаться регулярное, непрерывное улучшение. Низкая эффективность – не более чем временный эффект, который достаточно трудно предотвратить.

Похожие результаты были получены Робертом Глассом, который также обнаружил, что в процессе научения пользованию новыми инструментами или техниками качество и эффективность сначала снижаются, прежде чем вновь вырасти [Glass 2003: 23].

Измените внешнюю среду: пусть гора придет к вам

«Если Магомет не идет к горе, то пусть гора идет к Магомету». В этом виде цитата из истории Магомета, конечно, неверна, поскольку в правильном виде она звучит так:

Если гора не идет к Магомету, то Магомет пойдет к горе[97].

Интересно, что первая формулировка подчеркивает способность людей совершать невозможное и изменять внешнюю среду (и цитаты) по своему усмотрению.

Обсуждая путешествия по адаптивному ландшафту, легко забыть, что мы в состоянии изменять последний, тем самым значительно сокращая путь от точки, где в данный момент находимся, до пика самой высокой эффективности. Мы можем заставить гору прийти к нам, вместо того чтобы самим преодолевать расстояние до нее. (Или по крайней мере достичь компромисса и встретиться с ней посередине, например на парковке у KFC.)

Если вы менеджер, то у вас действительно есть возможность изменять внешнюю среду так, чтобы командам было легче достигать более высокой эффективности. Можно проанализировать и путем переговоров изменить контракты с клиентами и поставщиками. Не исключено, что понадобится поработать с административным и финансовым отделами, а также с отделами HR и маркетинга, чтобы их политика начала поддерживать самоорганизующиеся гибкие команды, а не устраивать им обструкцию [Cohn 2009: 38–39]. Также важным аспектом внешней среды будет организационная структура, которую мы обсуждали в главе 12 и главе 13. С точки зрения трудности перейти от функциональных команд к кросс-функциональным и от иерархического принятия решений к сетевому – это все равно что передвинуть вулкан Охос-дель-Саладо из Анд в Амстердам.

Но есть один аспект, который может компенсировать любые негативные последствия и трудности. Это желание меняться.

Мне слишком часто доводится слышать жалобы сотрудников разных компаний на то, что все постоянно меняется и ничто «не остается по-старому». Не успевает закончиться одна реорганизация, как на очереди стоит следующая. Однако проблема не в реорганизациях как явлении. Проблема в негативной реакции людей на изменения. И менеджмент может помочь им понять, что изменения – это необязательно плохо.

Люди должны хотеть меняться. И вы можете им в этом помочь, создав внешнюю среду, которая поощряет непрерывные изменения, а не стоит у них на пути. Начните думать об открытой планировке офиса и передвижных столах, которые сотрудникам будет легко передвинуть туда, где им удобнее работать в рамках очередного проекта. Подумайте о ротации обязанностей – это позволит людям лучше понимать специфику работы друг друга. Вы также можете практиковать обмен сотрудниками между различными командами, чтобы люди научились работать с разными коллегами. Или вместо того, чтобы двигать сотрудников, вы можете предпочесть передавать проекты от одной команды другой, чтобы они научились приспосабливать свои практики под различные проекты. Сделав изменение рабочей среды систематическим, вы создадите культуру, в которой сотрудникам будет комфортно, несмотря на возникающую неопределенность. В результате они научатся видеть в изменениях не только угрозы, но и возможности.

Мы постепенно подошли к теме коммуникации относительно организационных изменений. Вам следует прилагать усилия, чтобы люди поняли: непрерывное изменение – это нормальное для организации поведение по умолчанию. Исключением будет как раз отсутствие изменений. Возможно, поэтому стоит избегать термина «реорганизация», который посылает сигнал, что изменения становятся нарушением существующего «организованного состояния». И не давайте своим инициативам названия вроде «Качество-2012» или «Переход к гибким методологиям». Это, опять же, подчеркивает, что организационные изменения – какое-то «экстраординарное» явление, имеющее начало и конец [Cohn 2009: 34]. Если вы будете относиться к изменениям как к «исключению из правил» или отходу от нормы, то дадите людям убедительный повод для снижения мотивации в тот момент, когда они поймут: этот процесс на самом деле никогда не заканчивается.

Часто эксперименты с изменениями имеют форму пилотных проектов. Но, если их проводить в специально созданных тепличных условиях, пилотные проекты бесполезны. Сложность проблем, с которыми приходится иметь дело в реальности, часто превосходит возможности «рабочих групп», специальных «комиссий» и других специально созданных для решения конкретной проблемы объединений, функционирующих в искусственных условиях [Dent 1999: 14]. Сама по себе идея проведения эксперимента вполне продуктивна. Эксперимент – это как отправка разведчика в адаптивный ландшафт, с целью удостовериться, не подстерегают ли основную массу войск какие-то опасности. Но тепличные условия, в которых такие эксперименты часто проводятся, сильно отличаются от реальных. Реакции искусственно созданной среды будут не похожи на реакции реальной. Например, не имеет особого смысла тестировать методики канбана в рамках какого-то побочного проекта, не важного и не приоритетного для компании. Приобретенный таким способом опыт будет неприменим в реальных условиях и не поможет предсказать, какими будут результаты внедрения в ходе реальных проектов.

В общем, обучение в песочнице осуществляется в искусственных условиях, где опасностей не может быть по определению. А вот цель отправки разведчика в реальную среду – выяснить, не ожидают ли нас какие-нибудь неприятные сюрпризы. Но в чем тогда смысл отправки разведчиков в песочницу? Пилотные проекты должны осуществляться на реальном материале, иначе вы ничему стóящему в итоге не научитесь.

Сделайте изменения желанными

Мне нравится меняться, когда в результате улучшается мое самоощущение. Так, я изменил стиль своих презентаций, перейдя от использования фотографий к рисункам, потому что простые рисунки как раз входили в моду. Я попытался изменить стиль своего общения в Twitter и Facebook, поскольку доверял мнению экспертов, что это поможет улучшить мой бизнес. Я купил смартфон Google Nexus One, поскольку это дало мне статус первого (и практически единственного) владельца такого устройства в нашей компании. И я вступил в политическую партию как раз в тот момент, когда у нее дела шли особенно хорошо – нас же учат ассоциировать себя с победителями.

Люди готовы изменять свое поведение, если это престижно. Есть разные способы воспользоваться данным принципом, чтобы помочь командам изменить привычные способы работы:

• Продемонстрировать, что новая модель поведения сейчас на пике моды и что отказ меняться заставит людей воспринимать вас как зануду-консерватора с причудами.

• Дать возможность экспертам, к которым сотрудники испытывают доверие, поделиться своим энтузиазмом и опытом, потому что энтузиазм заразителен.

• Праздновать даже небольшие успехи, потому что в результате люди начнут ассоциировать изменения в нужном направлении с победой, счастьем и бесплатной выпивкой.

• Сделать так, чтобы изменения удовлетворяли внутренние потребности людей: любознательность, идеализм, независимость, потребность в общении или стремление повысить свой статус (см. главу 5).

• Создать ассоциацию между изменениями и еще чем-то, что нравится людям. Лекарство должно иметь вкус, перед которым невозможно устоять, – например, темного шоколада.

В этом контексте интересно вернуться к главе 12, в которой мы говорили о различных типах коммуникации среди сотрудников. Некоторые эксперты по управлению изменениями рекомендуют проанализировать социально-сетевую структуру организации и идентифицировать в ней людей, которые являются концентраторами, барометрами, объединителями и продавцами, чтобы с их помощью распространить желательную модель поведения по всей компании [Manns, Rising 2005]. Вы также можете воспользоваться кривой восприятия инноваций Эверетта Роджерса (рис. 15.4) и начать с инноваторов, которым нравится пробовать что-то новое. Затем вы постепенно можете охватить ранних последователей, раннее большинство и позднее большинство. При этом не стоит обращать внимание на отстающих, которые в любом случае сопротивляются нововведениям до тех пор, пока их не примут все остальные.

В контексте сложных систем уместно сделать одно предупреждение: менеджерам не следует стремиться к полной организационной гармонии. Часто они считают, что изменения будут успешными, если удалось обратить в свою веру всех сотрудников. Однако на практике это может выливаться в искоренение или подавление расхождений во взглядах, которые на самом деле необходимы для спонтанных креативных изменений [Stacey 2000a: 105].

Внутренний конфликт – это нормальное состояние сложных систем, включая разногласия относительно того, каким именно способом изменения должны быть реализованы. Вы не должны ставить перед собой цель добиться полного единомыслия. Ваша настоящая задача состоит в том, чтобы команды нашли для себя лучшую точку в адаптивном ландшафте, а для этого разрешите им использовать имеющиеся у них конкурирующие идеи и разногласия, чтобы они могли продвинуться в нужном направлении все вместе. В команде, с которой я работал над последним проектом, ежедневно разворачивались дебаты по поводу использования в работе мобильных телефонов и социальных сетей. Это помогло нам стать более мобильными и эффективнее использовать социальные сети для решения профессиональных задач.

Сделайте застой болезненным

Однажды со мной случилась небольшая личная катастрофа, в результате которой пропали более 100 гигабайт информации с основного жесткого диска и одновременно с устройства для резервного копирования. К счастью, мне удалось восстановить самую важную часть данных, включая первые заметки для этой книги. Но вынужден констатировать, что, несмотря на охватившую меня поначалу панику, в конечном итоге после катастрофы ситуация существенно улучшилась.

При восстановлении директорий я переосмыслил их иерархию, вычистил ненужные старые данные, которыми все равно не пользовался, и улучшил систему названий папок и отдельных файлов, отделив жизненно важные данные от просто интересных. До катастрофы на диске был изрядный беспорядок. Сама катастрофа мотивировала меня на то, чтобы потратить достаточно времени и значительно улучшить ситуацию по сравнению с тем, что было ранее. Но почему я не проделал все это еще раньше? Это сэкономило бы мне массу усилий.

Вот к какому выводу в результате я пришел: воспринимаемая ценность изменений пропорциональна масштабу проблем, которые наступят, если данные изменения не реализовать.

Ну почему здания начинают укреплять после того, как произошло очередное землетрясение? Почему я начал тщательнее ухаживать за своими зубами только после того, как пришлось один вырвать? Почему я решил сделать рефакторинг кода только после того, как столкнулся с серьезными проблемами в дизайне продукта? Почему коммуникация между членами команды улучшается только после того, как на них наорет клиент?

Потому что восприятие ценности субъективно. Ценность, которую мы придаем изменениям, существенно повышается после того, как мы столкнулись с серьезными проблемами. И чем серьезнее проблемы, тем выше мы ценим изменения, которые помогут предотвратить наступление подобных проблем в будущем. Это нелогично, но по-человечески очень понятно. Ценность, которую мы ассоциируем с определенной трансформацией, не коррелирует с бизнес-ценностью результатов, которые обещает данная трансформация. Она коррелирует с серьезностью проблем, которые наступят, если данная трансформация не будет предпринята.

Именно поэтому люди вроде меня меняются, когда сталкиваются с проблемами. По этой причине менеджеры (тоже вроде меня) иногда стараются найти неочевидные способы создать сотрудникам «проблемы», чтобы мотивировать сотрудников на изменения. Это просто способ заставить людей воспринимать изменения как нечто желательное. Поэтому, если ни один из перечисленных в предыдущем разделе способов сделать изменения привлекательными не срабатывает, увеличивайте давление на сотрудников, чтобы они ощутили на себе необходимость изменить свои модели поведения.

О пользе ошибок

Ошибки – это неотъемлемая часть биологических процессов. ДНК подвергается постоянному воздействию химических веществ, радиации и ошибок копирования. В каждом человеческом эмбрионе присутствует около 100 мутаций, большинство из которых не будут ни полезными, ни вредными [Le Page 2008: 33]. Но даже в тех случаях, когда ошибки не важны и не вызывают немедленного эффекта, они расширяют набор возможных реакций системы в случае, если в будущем возникает неожиданная ситуация.

В прошлом году мы с моим партнером отправились навестить наших друзей Девику и Руди, которые живут на противоположном конце нашей маленькой страны. Мы собирались у них переночевать. На половине пути я свернул не туда и заметил это только через пятнадцать минут. Мне не хотелось выслушивать обвинения в том, что я, как всегда, заблудился, поэтому ничего не сказал. Я просто молился, чтобы впереди был еще один поворот, который позволит нам вернуться на основную дорогу, и разворачиваться в итоге не пришлось. К счастью, так и случилось, и я успокоился. Вся дорога заняла два часа, из них на этот небольшой объезд ушло около десяти минут. Мой партнер, который ориентируется еще хуже, чем я, так ничего и не заметил, а наши друзья сказали, что мы добрались достаточно быстро. Поскольку все были довольны, я не видел смысла рассказывать о том, что мы могли приехать еще раньше.

На следующий день по пути домой мы услышали по радио, что впереди огромная пробка именно в том месте дороги, которое мы, заблудившись, случайно объехали накануне. Поэтому я сказал своему партнеру, что беспокоиться не о чем, поскольку мне известен небольшой объезд, который займет не более десяти минут и позволит избежать пробки. В общем, мне удалось с пользой применить информацию, полученную в результате совершенной накануне ошибки. Поскольку у моего партнера плохо с ориентацией в пространстве, я был уверен, что он не узнает участок дороги, по которому мы по ошибке проехали накануне. Пусть временно, но моя репутация опытного водителя была спасена.

Ошибки в проектах по разработке ПО нельзя назвать безусловным злом. Хотя они могут привести к дополнительным затратам, часто в результате возникают некие плюсы, иногда даже способные перевесить минусы. Поэтому не слишком переживайте, если в ходе проекта вы свернули немного не туда. Исправьте ошибку и учтите приобретенный опыт на будущее.

Стратегия шума

Мутации в сложных системах, независимо от того, преднамеренные они или нет, представляют собой «случайный процесс». Сначала возникает сама мутация, и лишь затем внешняя среда решает, будет ли данное изменение полезным. Таким образом, полезность мутаций можно назвать случайным результатом [Gell-Mann 1994: 67]. Они позволяют выяснить, что работает, а что нет. Следовательно, к ошибкам нужно относиться не как к безусловно нежелательному явлению, а как к механизму обучения [Weinberg 1992: 181].

В книге «Управление фабрикой дизайна» (Managing the Design Factory) Дональд Райнертсен убедительно показал, что невозможно максимизировать доступную нам информацию, если целиком ориентироваться на максимизацию успеха [Reinertsen 1997: 71–79]. Многие специалисты по теории сложности разделяют представление, что, если вы стараетесь не совершать ошибок вообще, многому вы не научитесь.

Преднамеренные или случайные ошибки должны стать неотъемлемой частью любого творческого процесса. Эволюцию можно воспринимать как систематическое управление ошибками[98].

Опираясь на эту идею, некоторые эксперты в области разработки ПО проповедуют отказ от поиска идеальных процессов, полагая, что каждая мутация и каждая неудача дают команде возможность получить дополнительные данные об адаптивном ландшафте и его изменениях в качестве реакции на действия команды. Чем большей информацией об адаптивном ландшафте располагает команда, тем легче ей по нему передвигаться.

В рамках подхода, противоположного стандартизированным процессам, каждый новый проект рассматривается в качестве пилотного. Если существует привычный способ выполнить данную работу, то именно его использовать не разрешается. То есть стандартной будет ситуация, когда как минимум какая-то часть работы выполняется нестандартно[99].

Еще 6000 лет назад люди выяснили, что нагревание металлов с последующим охлаждением меняет их свойства, в частности повышает прочность и твердость (металлов, не металлургов!). Это процесс называется закалкой. При нагревании атомы металла приходят в движение, а когда металл быстро охлаждают, атомы образуют более регулярную структуру. Это своеобразная форма «снятия стресса», при которой намеренное воздействие помогает системе легче обрести новое равновесие, чем она могла бы сделать без вмешательства извне.

Исследователи полагают, что подобные явления происходят и в сложных системах. Ошибки и шум в системе, привносимые внешней средой, приводят систему в движение, позволяя ей отойти от субоптимальных результатов и относительно более легко перейти в лучшее состояние. Ученые называют этот процесс модельной закалкой; в нем случайность помогает системе найти глобальный оптимум [Miller, Page 2007: 24, Lissack 1999: 115–116].

Это выглядит как будто бы систему во время прогулки по адаптивному ландшафту подталкивают в том или ином направлении, заставляя скатиться с холма, на котором она могла застрять (рис. 15.5). После такого толчка система может внезапно оказаться в долине, а оттуда добраться до более высокого пика. Модельная закалка демонстрирует, как случайные процессы оказываются полезны при движении по адаптивному ландшафту [Miller, Page 2007: 108].

А разве все не наоборот?

Я рисую адаптивные ландшафты, как это обычно делают биологи – точкам максимальной приспособленности соответствуют пики. Это интуитивно понятнее, поскольку с совершенством обычно ассоциируются вершины.

Однако физики рисуют адаптивные ландшафты ровно наоборот: у них позициям наибольшей приспособленности соответствуют самые низкие положения. И действительно, для иллюстрации понятия модельной закалки их способ подходит лучше, поскольку в результате «встряски» система благодаря гравитации скатывается вниз, к более оптимальному положению.

Но не забывайте, что, как бы вы их ни рисовали, адаптивные ландшафты – это метафора. В действительности нет никаких горных цепей, встрясок или гравитации. Есть только чрезвычайно сложная математика.

При разработке ПО аналогичный подход позволяет командам не застрять в точке локального оптимума и найти способы повышения своей эффективности. Демарко и Листер призывают использовать политику «конструктивного привнесения дозированного беспорядка» [DeMarco, Lister 1999: 160]. Я иногда называю это «повышение эффективности через несовершенство».

Стратегия секса

Мутации – это эксперименты по замене отдельных частей или компонентов проекта с целью увидеть, какие результаты будут получены в результате такой замены – хорошие или плохие. Но это не единственный метод в нашем распоряжении. Еще одной стратегией будет секс. Или, лучше сказать, кроссинговер, что звучит более научно.

Кроссинговер – способ, к которому прибегает природа, чтобы биологические виды могли достигать пиков в адаптивном ландшафте за один прыжок, а не в результате серии мелких шагов. Ребенок наследует половину своих генов от матери, а другую половину – от отца. Мать и отец – вполне приспособленные особи, каждая из которых располагается в своем адаптивном ландшафте на пике или где-то рядом с ним. (Если бы это было не так, они были бы больны или мертвы – в том и другом случае размножение было бы затруднено.) Случайным образом перемешанные гены, унаследованные ребенком, помещают его в адаптивном ландшафте где-то посередине между отцом и матерью. Если в этой точке долина, то ребенок будет хуже приспособлен к данной среде, чем его родители. Но существует достаточно высокая вероятность, что в этой точке может оказаться даже более высокий пик, чем те, на которых находятся его родители. С точки зрения сложных систем две системы произвели на свет третью, которой за один прыжок удалось достичь более высокой точки в адаптивном ландшафте (см. рис. 15.6)!

Данная стратегия работает, потому что в сильно пересеченных адаптивных ландшафтах пики часто группируются. Поэтому при выведении улучшенных сортов растений или при разведении скаковых лошадей люди применяют кроссбридинг [Holland 1995: 66]. В качестве родителей берут две особи, показавшие лучшие результаты, их гены перемешивают и в итоге получают потомство, которое часто превосходит своих родителей.

Мутации – это способ, при помощи которого природа ставит эксперименты. Это осторожные шаги в новых направлениях с помощью произвольного изменения маленьких составляющих системы. Кроссинговер позволяет природе объединять хорошо зарекомендовавшие себя практики. Это способ относительно безопасно совершить прыжок в адаптивном ландшафте и таким образом провести дополнительное исследование территории, о которой в общих чертах уже известно достаточно много [Miller, Page 2007: 184].

Вы спросите, в чем здесь практический урок для команд разработчиков? Я бы рекомендовал проводить скрещивание команд и проектных подходов. Когда вы начинаете новый проект, попробуйте сочетать метод, оказавшийся эффективным в предыдущем проекте, с процессом, оказавшимся эффективным в каком-то другом проекте. Или попробуйте создать из существующих команд новую, особенно если команды существуют достаточно давно и темпы взаимного обучения сотрудников в них замедлились. Такое перекрестное опыление может дать «потомство», эффективность которого будет превышать эффективность даже очень сильных исходных команд.

Стратегия горизонтального переноса опыта

Мутации и секс далеко не единственные существующие в природе способы, позволяющие биологическим видам передвигаться по адаптивным ландшафтам. В частности, существует третья стратегия, чья роль в эволюции многоклеточных организмов до последнего времени недооценивалась, хотя, по-видимому, в мире бактерий она всегда играла существенную роль. Имеется в виду горизонтальный перенос генов (ГПГ).

Микробы обмениваются друг с другом генной информацией, выбрасывая геномный материал. Исследования показывают, что 10 % геномов бактерий заимствованы у других видов бактерий, и это типичный показатель. Известный микробиолог Карл Вёзе даже полагает, что горизонтальная генная передача была доминирующей формой эволюции до тех пор, пока у многоклеточных организмов не закрепилось половое размножение [Buchanan 2010: 34–37]. Считается, что беспорядочное распространение генетического кода среди разных видов позволило создать «объединенный генетический механизм», что в свою очередь позволило с большей легкостью видам делиться друг с другом инновациями.

Бактерии крайне расточительны и неразборчивы в том, что касается обмена генами – они практикуют истинный генетический коммунизм. ‹…› Иногда бактерии занимаются «сексом», обмениваясь генетическим материалом через межклеточные «мостики». В других случаях просто происходит выброс содержащих генный материал плазмид и вирусоподобных фрагментов, адресованных «всем и никому конкретно». В том и другом случае результатом становится свободный обмен генной информацией. Одно из следствий такого обмена генами – гораздо бóльшая коллективная адаптивность[100].

Существует ли способ распространить эту идею на команды разработчиков? Да, и, судя по всему, мы постоянно им пользуемся. Команды делятся друг с другом лучшими практиками, обмениваются сотрудниками, копируют и обсуждают свой опыт работы с теми или иными инструментами. Иногда это происходит в личных беседах, в других случаях информация распространяется в виде статей, блогов, презентаций или подкастов, «адресованных всем и никому конкретно». (Судя по всему, и эта книга – пример горизонтального переноса информации в действии!)

Недавние исследования показывают, что наиболее успешная стратегия – копирование идей. В ходе различных экспериментов выяснилось, что наиболее успешные агенты проводят почти все имеющееся у них время, наблюдая за другими агентами, а не занимаясь инновациями [McLeod 2010]. По-видимому, это означает, что командам следует инвестировать максимум времени, отводимого на обучение, копированию идей из разных источников. И лишь немного времени должно уделяться изобретению своих собственных идей.

Мне представляется очевидным, что организации должны применять все три стратегии для постоянного улучшения: мутации, кроссинговер и горизонтальную передачу. Мутации необходимы при осуществлении постепенных улучшений в неизвестных и потенциально опасных ландшафтах. Кроссинговер нужен для осуществления более радикальных изменений путем комбинирования методов и команд, которые уже достаточно эффективны. А горизонтальный перенос требуется для копирования практик между командами, что позволит им сдвигаться в «новых» направлениях, которые уже знакомы остальным (рис. 15.7).

Применение этих трех стратегий на практике означает, что вы должны разрешить командам использовать ретроспективы (или другие форматы) для исследования соответствующих адаптивных ландшафтов путем внесения изменений в функциональность, применяемые практики, инструменты, графики и бизнес-ценность. На другом уровне вы используете «постоянную реорганизацию» и комбинируете лучшие команды и проектные практики, пытаясь понять, можно ли этим путем создать «потомство», которое будет более эффективно. В рамках третьей стратегии для достижения более высокой глобальной эффективности происходит интенсивное копирование и обмен идеями, людьми и инструментами.

Вы хотите сказать, что состав команд должен постоянно меняться?

Вообще-то нет, я несколько преувеличил. Первый год может быть посвящен оптимизации структуры команд, следующий – стандартным процессам, а затем оптимизации уровней управления или бизнес-единиц. В здоровой организации какие-то из ее частей всегда находятся в стадии (ре)формирования.

Я не хочу сказать, что состав команд должен постоянно меняться. Это противоречит требованию, что команды должны оставаться стабильными достаточно протяженный промежуток времени, о чем более подробно сказано в главе 13.

Компьютерные симуляции показывают, что комбинация мутаций, кроссинговера и горизонтального переноса – прекрасный способ достичь глобального оптимума эффективности [Buchanan 2010: 36]. Мы имеем право предположить, что то же самое применимо к командам и организациям. Используйте метод мутаций, чтобы создавать инновации. Пользуйтесь горизонтальным переносом, чтобы копировать инновации у других команд. И применяйте метод кроссинговера для создания новых практик путем комбинирования уже известных.

Но биологические виды далеко не то же самое, что бизнес!

Это правда. Биологические изменения – ненаправляемые, в то время как оптимизация в бизнесе – направляемая (см. конец главы 14 «Ландшафт изменений»).

Биологические виды производят потомство с большим запасом, чтобы из него одна или две особи в конце концов пошли в нужном направлении. В бизнесе для достижения аналогичных результатов мы можем воспользоваться прогнозированием. При этом как биологические виды, так и бизнес могут процветать, а могут и потерпеть неудачу. С точки зрения практических результатов я не вижу разницы между ненаправляемыми и направляемыми изменениями.

Не копируйте улучшения

В предыдущей главе я предупреждал вас, что нельзя слепо копировать «лучшие» практики или следовать советам консультантов без учета конкретного контекста. Адаптивный ландшафт других команд может отличаться от вашего. Горизонтальный перенос – отличная стратегия, но он требует, чтобы вы удостоверились, что в вашей ситуации данные инновации имеют смысл.

Меня беспокоит, когда люди заимствуют мнения и аргументы других, не адаптируя их к своему локальному контексту. Некоторые забывают провести анализ ситуации, прежде чем применять скопированные идеи. А некоторые обвиняют других в том, что подход первых к разработке ПО неверен, не удосужившись проверить, смогут ли их собственные идеи выжить в контексте, в котором функционирует обвиняемый. Можно назвать это копипастом улучшений.

Примеры?

«Не надо заключать контракты с фиксированной ценой и фиксированным объемом разработки, потому что…»

Звучит разумно, но мне от этого не легче, поскольку мои клиенты заключают только такие контракты. Вы рекомендуете мне прикрыть свой бизнес?

«Не нужно начинать с объемных и детализированных требований к продукту, поскольку…»

Возможно, но клиент только что вручил мне технические требования на 500 страниц и готов платить за то, чтобы я их реализовал. Советуете мне отказаться от этого проекта?

«Команды должны быть кросс-функциональными и располагаться в одном помещении, при этом в них должны быть собраны специалисты всех необходимых профилей, потому что…»

Это было бы здорово, но, помимо меня, клиент для концептуального проектирования только что нанял еще одну компанию, а их офис находится на другом конце страны. Я должен попросить их переехать к нам?

«Продолжительность итераций должна составлять две недели, потому что…»

Да, но в чем польза от этого совета, если у меня краткосрочный проект, который продлится как раз две недели?

Я ценю любые советы из любого источника, включая такие, которые не очень легко переносятся в мой контекст. Это всегда возможность чему-то научиться и понять, как моя ситуация соотносится с другими похожими и чем она от них отличается.

Несмотря на то, что часто приходится слышать о «плохих» или «хороших» генах, я не думаю, что гены бывают плохими или хорошими. Воздействие, которое они оказывают на судьбу конкретного организма, сильно зависит от контекста. В определенной внешней среде даже наиболее вредные гены могут вдруг оказаться полезными. Моя покойная персидская кошка Поэзи (фото 15.1), скорее всего, не могла бы выжить вообще ни в какой иной среде, кроме как у любящего владельца, у которого есть большая расческа.

Точно так же зависят от контекста и практики, применяемые в менеджменте и при разработке ПО. Не надо приказывать людям, что им делать, полностью не разобравшись в их ситуации. И даже если в 95 % случаев вы окажетесь правы, люди все равно будут сопротивляться, если вы не признаете с самого начала, что их ситуация хотя бы немного отличается от стандартной.

Обычно я готов поддержать принятие новых практик «из учебника» только при условии, что сразу после будет процесс привязки этих стандартных практик к локальному контексту. Однако иногда не срабатывает и этот подход. Могут потребоваться чрезвычайные усилия на адаптацию прежде, чем вы сможете воспользоваться той или иной практикой из учебника.

Поэтому я бы рекомендовал отказаться от оптимизации по принципу «копировать – вставить». Пользуйтесь функциями «копировать – специальная вставка»… и тщательно выбирайте, что именно вы хотите вставить. (И не забывайте о пользе тех практик, которые вы уже применяете. Очень часто отличные новые подходы в процессе «адаптации» к потребностям конкретной организации в результате оказываются настолько разбавленными, что полностью теряют способность оказать какое-либо позитивное воздействие.)

Несколько завершающих практических советов по теме непрерывного улучшения

Трудно предложить более конкретные рекомендации по непрерывной оптимизации. Как отмечалось в главе 14 «Ландшафт изменений», природа сложности такова, что практически невозможно предложить универсальные подходы, которые подошли бы большинству организаций. И тем не менее я постараюсь дать вам несколько простых советов, которые вы сможете использовать, приспособив их к своей ситуации.

• Регулярно проводите ретроспективы, на которых обсуждайте текущее положение дел и способы внесения в него улучшений. Ретроспективы могут проводиться на разных уровнях в организации, а не только на уровне команд. Вы должны позаботиться о том, чтобы речь на них шла не только об адаптации (реагировании на возникающий в процессе разработки опыт), но и об исследовании (экспериментировании) и прогнозировании (подготовке к возможному развитию событий). Этим вы сможете обеспечить, чтобы двойные циклы обучения учитывали как уже состоявшиеся, так и возможные будущие события. Огромное количество полезных советов об организации ретроспектив можно найти в книге «Ретроспективы в гибких методологиях» (Agile Retrospectives) [Derby, Larsen 2006].

• Ведите журнал улучшений для каждой команды и на разных уровнях в организации, при этом журналы должны быть доступны всем. Это помогает людям отслеживать идеи, которые пока еще не внедрены. Как и в случае с любыми другими журналами, в любое время старые идеи, которые так и не были внедрены, могут быть заменены в них на новые [Cohn 2009: 62–63]. Может потребоваться ежемесячно резервировать для непрерывной оптимизации какое-то время в графиках загрузки, иначе есть риск, что идеи, перечисленные в журнале оптимизации, будут лишь обсуждаться, но до внедрения дело так и не дойдет.

• Создайте в очевидном виде цикл улучшений, состоящий из отдельных этапов. При этом вы можете использовать как те восемь этапов, которые я перечислил при описании обобщенного процесса оптимизации SLIP, так и любую другую серию этапов, которую находите полезной. Как и задачи, представленные на любой доске задач, применяемых в Scrum и канбане, позиции в журнале оптимизации должны пройти определенные стадии проработки, что поможет не пропустить ни одного из важных шагов (например, этапы измерения и проверки).

• Создайте переходную группу сотрудников (их еще иногда называют сообществами лидеров изменений), задачей которой будет продвигать и поддерживать изменения на уровне организации в целом. В эту группу должны входить старшие менеджеры и представители всех подразделений организации, которым предстоит переход на новые методы работы. Задачей «чемпионов изменений» будет не навязывать данные изменения, а помогать людям в их осуществлении [Cohn 2009: 63–70]. Как мы обсуждали ранее, поскольку изменения никогда не заканчиваются, такие группы могут создаваться на полупостоянной основе.

• Изучайте методы канбана, которые представляют собой отличный инструмент для управления непрерывным улучшениям. Канбан – управление изменениями, где в качестве механизма используются ограничения на объем незавершенного производства, а также широко применяется визуализация потоков ценности (или сетей создания ценности) как способ предъявления командам необходимости изменений [Anderson 2010].

• Рекомендуйте сотрудникам своей организации инициировать создание собственных сообществ по оптимизации вокруг тем, которые выходят за рамки отдельных проектов. Примерами таких тем могут быть тестирование, разработка архитектуры или пользовательских интерфейсов [Cohn 2009: 70–78]. Если вы менеджер, то лучше не создавать такие сообщества самому, поскольку это должны делать сами команды в результате самоорганизации и в зависимости от своих потребностей. В случае необходимости вы всегда сможете им помочь. (Такие сообщества будут результатом самоотбора, который мы обсуждали в главе 13.)

Уверен, что другие могут предложить гораздо больше советов по организации непрерывного улучшения. Но и тех, что приведены здесь, достаточно, чтобы вы смогли начать движение в нужном направлении.

Продолжайте движение

Изменяющаяся внешняя среда – а в случае коэволюционирующих систем и Гонка Черной Королевы – оказывает огромное воздействие на адаптивные ландшафты. В результате эти ландшафты как будто бы сделаны из резины (по ним было бы удобно передвигаться на роликах). Пики и долины постоянно сдвигаются, растут или понижаются. Система, которая еще вчера была отлично приспособленной, завтра может оказаться совершенно неприспособленной к изменившейся внешней среде. Сегодняшние лучшие практики завтра могут превратиться в худшие. Биологические виды, компании и команды должны постоянно изменять себя, поскольку требуется бежать изо всех сил, чтобы не сорваться с постоянно движущегося пика. А если гора вдруг превращается в долину, нужно уметь перепрыгнуть на соседнюю вершину.

В стабильной внешней среде адаптивный ландшафт меняется незначительно. После того как организация нашла для себя комфортный пик, она может некоторое время провести на нем, чтобы извлечь из этой ситуации максимум выгод. Но в стабильной внешней среде системы часто утрачивают способность изменяться. Привыкнув к ней, люди забывают, как изменяться. Опасность в том, что в этом случае они могут не заметить, что их комфортабельная вершина медленно превращается в долину. Удовлетворенность текущим состоянием бизнеса может оказаться вашим худшим врагом. Внезапно выясняется, что ваши даже наиболее талантливые сотрудники отстали от времени. Инструменты, которыми вы всегда пользовались, перестают давать оптимальные результаты. Любимый метод разработки, никогда раньше не подводивший, постепенно начинает тормозить ваше движение. А роликовые коньки заржавели, или вы их вообще потеряли.

Гарантия выживания заключается в гибкости.

В Agile-манифесте ничего не говорится о том, что нужно в обязательном порядке применять Экстремальное программирование, Scrum или какую-либо другую стандартную методологию. Там сказано, что вы должны принимать неизбежность изменений и приветствовать их. Процесс оптимизации функциональных возможностей, качества, компетентности сотрудников и команд, инструментов, графиков и процессов бесконечен. Он должен стать вашим образом жизни. Не довольствуйтесь достигнутым! Продолжайте движение! Лишь иногда останавливайтесь, чтобы взглянуть на адаптивный ландшафт и проверить, как поживают те самые пики. А затем опять становитесь на ролики и продолжайте гонку.

На этом мы заканчиваем беседу об улучшении всего и подходим к концу книги. Мы поговорили о людях, компетентности, расширении прав и полномочий, настройке ограничений, структуре и улучшении. Нам остается поговорить о модели Менеджмента 3.0 в целом.

Резюме

Большинство моделей непрерывного улучшения имеет линейный характер, однако команды разработчиков ПО – это нелинейные сложные системы. Поэтому процесс улучшения может выглядеть как шаг назад и два шага вперед. Команды разработчиков должны быть готовы как к постепенным, так и к радикальным изменениям; как к плавному движению, так и к прыжкам по пересеченным адаптивным ландшафтам.

Одним из способов движения будет внесение изменений в сам ландшафт. Это подразумевает целенаправленное изменение внешней среды (включая клиентов, топ-менеджмент и различные подразделения внутри компании), чтобы создать условия, позволяющие командам найти точку своей максимальной эффективности. Еще одна стратегия, которой могут воспользоваться менеджеры, – сделать изменения желательными с точки зрения сотрудников, а стагнацию – болезненной.

Для достижения оптимальной эффективности имеются три стратегии: эксперименты с применением различных практик, комбинирование практик, применяемых наиболее эффективными командами или сотрудниками, и обучение у тех, кто готов делиться своими знаниями.

Независимо от того, какими стратегиями вы воспользуетесь, важно понимать, что непрерывное улучшение непрерывно в буквальном смысле. Оно никогда не заканчивается.

Подумать и сделать

Посмотрим, как применить некоторые идеи из данной главы в вашей компании:

• Создайте журнал улучшения и разработайте процесс внедрения улучшений. Чтобы сформулировать, в чем заключаются желательные результаты, и быть в состоянии их отслеживать, вы можете использовать предложенное мною схематическое описание процесса улучшения или любую другую модель. (Не удивляйтесь, если реализованные вами изменения не приведут к немедленным улучшениям или поначалу эффективность даже снизится.)

• Обсудите со своей командой, каких именно изменений вам необходимо добиться. Эти изменения достаточно привлекательны для сотрудников? Их отсутствие воспринимается как болезненное?

• Проанализируйте проблемы, которые ваша команда никак не может решить, несмотря на все принимаемые меры. Попробуйте сосредоточиться на изменении внешней среды, а не на поведении команды, чтобы ликвидировать аттрактор, к которому они постоянно притягиваются.

• Возьмите себе за правило обсуждать с командой допущенные ошибки и то, какие уроки из этих ошибок можно вынести.

• Попробуйте поэкспериментировать с изменениями просто потому, что вы можете себе это позволить (без давления со стороны внешней среды и не зная заранее, в правильном направлении вы движетесь или нет). Обсудите с командой, чему вам удалось в результате научиться.

• Попробуйте скомбинировать подходы к разработке, применяемые разными командами. Удалось ли вам в результате получить более эффективный процесс, чем исходные?

• Обсудите с командой, как у них происходит заимствование интересных практик из различных источников. Удостоверьтесь, что процесс заимствования и «публикации» идей идет на постоянной основе.

• Удостоверьтесь, что все команды регулярно проводят ретроспективы.

• Создайте переходную группу, в задачу которой будет входить поддержка изменений в организации.

• Порекомендуйте своим сотрудникам создавать «сообщества улучшений» вокруг тем, выходящих за рамки отдельных проектов и касающихся сразу многих команд.

Глава 16 Все модели неверны, но некоторые из них полезны

Правда редко бывает чистой и никогда не бывает простой.

Оскар Уайльд, писатель, поэт (1854–1900)

Я чувствую, что не в состоянии завершить эту книгу должным образом. Такое впечатление, что любое описание гибкого менеджмента все равно неполно и каждый мой вывод можно поставить под сомнение.

Начать мыслить в категориях сложности – все равно что жениться на черной дыре. Чтобы сохранить рассудок, лучше с такими вещами вообще не связываться. И все же это очень привлекательный способ смотреть на окружающий мир. А кроме того, вас все равно затянет, и в результате все, во что вы верили, либо окажется опровергнутым, либо превратится в ничто. А я верю во множество вещей.

Шесть компонентов Менеджмента 3.0

Я считаю, что линейное мышление часто приводит нас к неверным выводам (см. главу 1) и что у гибких методологий разработки ПО и теории сложности имеется общий фундамент в виде нелинейного мышления (главы 2 и 3). Я полагаю, что люди – это самый важный элемент организаций и менеджерам необходимо прилагать максимум усилий, чтобы поддерживать в них активность, креативность и мотивацию (главы 4 и 5). Я уверен, что команды способны на самоорганизацию и для этого необходимо предоставлять им широкие права и полномочия, а также распространять на них доверие со стороны менеджмента (главы 6 и 7). В главах 8 и 9 показано, что самоорганизация может приводить к нежелательным последствиям и поэтому необходимо защищать людей и находящиеся в общедоступном пользовании ресурсы, а также ставить перед командами четкие цели. Я также считаю, что некомпетентные команды не смогут достичь поставленных целей и по этой причине в фокусе внимания менеджеров должно находиться развитие компетенций сотрудников (главы 10 и 11). Многие команды функционируют внутри сложных компаний, и поэтому я убежден, что важно уделять внимание созданию организационных структур, в которых коммуникация происходит без затруднений (главы 12 и 13). Я также думаю, что люди, команды и организации нуждаются в постоянном совершенствовании, чтобы в результате момент неудачи наступал как можно позже (главы 14 и 15). И наконец, мне иногда кажется, что поскольку мои выводы в этой книге достаточно просты для понимания, то это может быть симптомом, что они неверны.

На рис. 16.1 еще раз показана модель Менеджмента 3.0. В нее входит шесть компонентов, или точек зрения:

• Добавьте людям энергии.

• Расширяйте полномочия команд.

• Настройте ограничения.

• Развивайте компетенции.

• Выращивайте структуру.

• Улучшайте всё.

Я осознанно использую термин «точки зрения», а не «принципы» или «основы», чтобы подчеркнуть, что речь идет об одной и той же системе, рассматриваемой под разными углами зрения. Например, понятие «сообщество практикующих» (глава 13) хорошо вписывается по крайней мере в три компонента модели (компетенции, структура и улучшение). Рекомендация командам создавать свои ценности (глава 5) хорошо встраивается в такие компоненты модели, как добавление энергии, расширение полномочий команд и настройка ограничений. Мы действительно рассматриваем один и тот же объект с шести разных углов зрения.

Но как бы точно ни резюмировать содержание книги и как бы хороши ни были иллюстрации, теория сложности подсказывает мне, что любое простое описание менеджмента в гибких организациях будет незавершенным. Любое утверждение может быть опровергнуто мышлением в категориях сложности или вообще превратиться в ничто.

Это очень расстроило бы меня, если бы не тот факт, что вы дочитали книгу до этого места, – он все же несколько смягчает мои переживания по данному поводу.

Да, моя модель «неверна»

Причина моих переживаний – тот самый принцип несжимаемости:

Не существует точного (вернее, идеального) способа представить систему, кроме как предъявить саму эту систему. Создавая модели открытых систем, мы вынуждены исключать из рассмотрения какие-то их характеристики, а поскольку возникающие в результате такого исключения эффекты имеют нелинейный характер, мы не можем заранее сказать, насколько они впоследствии окажутся важными[101].

Разрешите мне немного перефразировать это утверждение…

В главе 3 я упоминал, что в основе теории сложности лежит теория хаоса. Эффект бабочки (глава 14) позволяет продемонстрировать, какие далекоидущие последствия могут иметь даже самые небольшие отклонения в первоначальных параметрах сложной системы. Когда мы пытаемся моделировать и описывать сложные системы, то вынуждены опускать какие-либо элементы; в противном случае мы будем погребены под огромным количеством деталей. Проблема в том, что в сложных системах любые детали имеют значение, поэтому если их опустить, то результат может оказаться весьма неожиданным!

Принцип несжимаемости утверждает, что единственным точным представлением сложной системы будет она сама. Любые упрощенные модели неполны, потому что в них могут быть упущены существенные детали. В соответствии с той же логикой моя модель Менеджмента 3.0 также неполна. Сожалею, если вы разочарованы – но если вы искали простые решения, то явно выбрали не ту книгу. К счастью для нас, на помощь приходит Джеральд Вайнберг, один из отцов системного мышления, со своим законом дополнительности:

Любые две точки зрения дополняют друг друга[102].

Несколько неполных моделей сложных систем могут оказаться достаточно точными и полезными, поскольку часто представляют собой дополняющие друг друга (а возможно, и противоречащие друг другу) способы смотреть на вещи [Richardson 2004a].

Не существует единой теории эволюции. Есть множество дополняющих друг друга, конкурирующих друг с другом и иногда противоречащих друг другу моделей. И тем не менее эта коллекция моделей обладает огромными описательными и прогнозирующими возможностями [McKelvey 1999: 19]. Нечто подобное наблюдается и в физике: принимаются обе модели – волновая и корпускулярная, – поскольку они обе дают точные описания происходящих процессов и позволяют надежно предсказывать их результаты. Судя по всему, физики не считают это доказательством того, что физика как наука потерпела фиаско.

Я думаю, что то же самое можно сказать и о различных моделях процесса разработки ПО. Scrum, канбан и Экстремальное программирование дополняют друг друга, конкурируют друг с другом и в чем-то даже противоречат друг другу. Но это не значит, что мы имеем дело с неудачными методологиями. Просто при пользовании ими и порождаемой ими информацией следует проявлять критичность и некоторую осторожность.

Что касается сложных систем, то наши знания всегда ограничены историей и контекстом. Никто не утверждает, что сама идея моделирования сложных систем порочна… Однако мы должны проявлять осторожность и не полагаться чрезмерно на «знание», которое обретаем в результате использования моделей. ‹…› Полученное таким образом «знание» нуждается в интерпретации, а интерпретации всегда приводят к упрощению. Значит, наш основной аргумент состоит не в том, что сложным системам присуща некая метафизическая непознаваемость, а в том, что это мы не в состоянии «познать» систему во всей ее сложности[103].

Более или менее совместимые или конфликтующие модели менеджмента вместе со своими сильными и слабыми сторонами будут существовать всегда, поскольку организации (и команды разработчиков) представляют собой сложные системы. Это напрямую следует из принципа несжимаемости. Никогда не будет создана единая теория управления организациями или разработкой ПО (от этой идеи мы отказались еще в главе 1). Нам неизбежно придется иметь дело с лоскутным одеялом из различных теорий, методов и стандартизированных подходов [Richardson 2008: 17]. Вполне очевидно, что доступный нам массив знаний о разработке ПО столь же уродлив, как и массив знаний о сложных системах (см. главу 3). Хотя юбочка, возможно, и другого цвета (см. рис. 16.2).

Другие модели точно так же «неверны»

Если случается, что я проваливаю какой-либо тест, то обычно утешаю себя тем, что я далеко не единственный, с кем это случилось. Также у меня вызывает чувство удовлетворения тот факт, что существуют другие модели управления организациями и что они в такой же степени «неверны», как и моя. Иногда этот общий для авторов моделей дискомфорт даже доставляет мне удовольствие. Вайнберг же говорит нам, что сумма нескольких моделей будет менее неполной, чем отдельно взятая модель. В общем, не исключено, что в этом случае два минуса в итоге дают плюс…

Дао Toyota

Дао Toyota было опубликовано в 2001 году. Оно описывает модели поведения, лежащие в основе управленческой и производственной системы компании Toyota. Дао состоит из двух главных принципов: уважение к людям и непрерывное улучшение, точно совпадающих с двумя компонентами моей модели (добавление энергии и улучшение всего).

Профессор Джеффри Лайкер проанализировал управленческую философию компании Toyota, детально описав четырнадцать управленческих принципов [Liker 2004]. Некоторые из них, например долгосрочные цели, воспитание лидеров, обучение сотрудников и постоянная рефлексия, вполне адекватно отражены в модели Менеджмента 3.0. Другие принципы, такие как представление производственного процесса в виде потока, система вытягивания и медленное принятие решения / быстрое внедрение, безусловно, полезны для многих организаций, но я предпочитаю рассматривать их просто в качестве полезных приемов, поскольку вряд ли они могут стать основополагающими принципами, которых во всех случаях следует придерживаться менеджерам.

Между моей моделью и Дао Toyota есть одно интересное отличие, а именно: в Дао отсутствует компонент, связанный с выращиванием структуры. Я не утверждаю, что это делает Дао Toyota непригодным, но остаюсь при своем мнении, что структура сложных систем является слишком важным элементом, чтобы его можно было проигнорировать – именно структура будет одним из основных факторов, обуславливающих эффективность гибких методологий.

Четырнадцать принципов Деминга

В книге «Выход из кризиса»[104] профессор менеджмента Уильям Эдвардс Деминг предложил четырнадцать принципов управления и трансформирования организаций [Deming 1986]. Принципы Деминга бессчетное число раз цитировались в литературе по менеджменту и вдохновили многих, кто развивает гибкие и бережливые методологии по всему миру.

Шесть компонентов моей модели вместе с соответствующими примерами и практическими приемами пересекаются практически со всеми из четырнадцати принципов Деминга. В тех или иных главах этой книги говорится о постоянстве цели, стремлении к изменениям, отказе от инспекций как инструмента обеспечения качества, постоянном улучшении всех производственных процессов, организации обучения без отрыва от производства, менеджерах как лидерах, а не надзирателях, искоренении страха, устранении барьеров между подразделениями, отказе от пустых лозунгов и призывов, создании возможностей для сотрудников испытывать гордость за свою работу, внедрении программ развития компетенций и ответственности всех работников за улучшение производственных процессов. Единственный из принципов Деминга, о котором в моей книге ничего не сказано, – это отказ от практики закупок по самой низкой цене; здесь я могу только выразить надежду, что, когда вы покупали мою книгу, она не показалась вам неоправданно дорогой.

Я также испытываю определенное беспокойство по поводу упоминаемого Демингом принципа, заключающегося в отказе от управления по целям, который, по-видимому, противоречит некоторым идеям, изложенным в главах, посвященных настройке ограничений и развитию компетенций. Однако поскольку у Деминга под этим принципом в основном подразумевается отказ от использования внешних стимулов и констатация, что у менеджеров зачастую отсутствует системный взгляд на вещи, то можно утверждать, что мы и так уделили достаточно времени и тому и другому.

Шестиуровневая модель Минцберга

Профессор Генри Минцберг – один из лучших мировых мыслителей и авторов, пишущих на темы менеджмента в бизнесе. В своей книге «Менеджмент»[105] он представил новую модель, разработкой которой занимался много лет [Mintzberg 2009: 48]. В рамках этой модели менеджмент осуществляется на трех «уровнях», при этом на каждом выполняются функции двух типов: уровень действий (делание и распределение ресурсов), уровень людей (функции лидера и связного) и уровень информации (коммуникация и контроль).

При сравнении модели Менеджмента 3.0 с моделью Минцберга создается впечатление, что они наполовину перекрывают друг друга. Мне представляется, что в этой книге мы достаточно детально обсудили темы лидерства, коммуникации и производственных процессов и не имеет смысла дополнительно говорить об этом. В моей модели практически не упоминается о второй половине действий из модели Минцберга (функции связного, контроля и распределения ресурсов), которые, с моей точки зрения, необязательно будут обязанностями менеджера и могут легко делегироваться командам. В то же время в модели Минцберга не упоминается добрая половина из того, о чем идет речь в модели Менеджмента 3.0: вопросы управления ростом организационных структур, развитием компетенций и улучшений, хотя я убежден, что для гибких организаций эти аспекты очень важны.

Данные расхождения объясняются тем, что модель Минцберга создавалась на основе эмпирических данных о том, чем менеджеры вынуждены заниматься на практике. В свою очередь, моя модель создана на основе научной теории. Она показывает, чем менеджерам следует заниматься на самом деле.

Пять принципов Хэмела

Гэри Хэмел, также один из известнейших бизнес-мыслителей и авторов, в своей книге «Будущее менеджмента»[106] описал пять принципов «управления компаниями в XXI веке» [Hamel 2007]. Эти принципы таковы: жизнь (порождение разнообразия), рынки (гибкость при распределении ресурсов), демократия (поощрение активности), вера (понимание смысла) и существование крупных городов (создание предпосылок для возникновения случайных удачных открытий).

Хотя предложенные Хэмелом названия принципов менеджмента достаточно расплывчаты, мне представляется, я смог разглядеть основные идеи, лежащие в их основе, (экспериментирование, мутации, естественный отбор, сети вместо иерархий, распределенное лидерство, вдохновляющие цели, неравнодушные люди, разнообразие, креативность, инновации и так далее) – и все они обсуждаются в моей книге. По-видимому, единственное измерение, отсутствующее в модели Хэмела, это развитие компетенций. Как и в первоначальной версии Agile-манифеста, в модели Хэмела подразумевается, что компетентные сотрудники падают с неба на парашютах и ничего не стóят. К сожалению, мой опыт говорит об обратном.

Есть и еще множество других моделей…

Существуют еще десятки, если не сотни, моделей менеджмента. Я решил включить в свой обзор и сравнить лишь несколько, которые были предложены наиболее уважаемыми и знающими авторами. (Я не хочу причинять вам страдания, заставляя читать от корки до корки источники с названиями вроде «Сто сорок два закона лидерства, применяемых жрецами, священниками и военными».) Моя цель – подчеркнуть, что ни одна из моделей не может быть идеальной и каждая может оказаться весьма полезной.

Типичные заблуждения практиков гибких методологий

Но не только менеджерам приходится иметь дело с обилием конкурирующих моделей, аналогичная ситуация существует и в области разработки ПО. Эксперты по Agile без конца повторяют, что для того, чтобы правильно использовать Scrum или XP, «разработчики должны перепроектировать код». Кто-то утверждает, что «всем нужны юнит-тесты» или что «Scrum все ухудшает из-за того, что игнорирует инженерные практики» и что «ты не гибкий, если не используешь непрерывную интеграцию каждый день». Для этих экспертов Agile не про адаптацию и выполнение всего возможного для того, чтобы проект был долгое время успешным. Если верить этим Agile-экспертам, гибкость – это следование практикам X, Y и Z. Но это очередное заблуждение.

Гибкость – это способность оставаться успешным в постоянно меняющейся внешней среде.

Я

Вот и все, к этому нечего добавить.

С моей точки зрения, существует лишь одна универсальная практика, которая в равной степени подходит всем организациям, – гнать с порога любых «экспертов», которые осмеливаются утверждать, что практика X оптимальна для любой организации. Скорее всего, имеется в виду та практика, в которой данный эксперт особенно силен и которую он за хороший гонорар готов помочь вам внедрить. (Если вам интересно, мне никто не приплачивает за усилия, которые я прилагаю, выгоняя таких экспертов из нашего офиса.)

Некоторые практики гибких методологий предлагают вообще отказаться от бренда «гибкие» или «Agile-методологии». В конце концов, поскольку данный термин так и не получил ясного определения, гибкими иногда называют даже дисфункциональные проекты. Это возможно только потому, что гибкие методологии не предписывают выбор конкретных методов и инструментов. Но это естественно, поскольку универсальных практик просто не существует! Если бы они имелись, мы могли бы прописывать любой сложной системе одну и ту же стратегию выживания, а это напрямую противоречит природе сложности (и более конкретно – теории игр). В задачу гибких методологий никогда не входило рекомендовать определенный набор практик. В Agile-манифесте нигде не сказано, что вы должны непременно применять автоматизированное тестирование, парное программирование или рефакторинг. (Я был бы не в состоянии написать книгу по гибким методологиям, если бы какие-либо из практик были обязательными.) Как только люди начинают считать ту или иную практику обязательной, само словосочетание «гибкая практика» становится логически противоречивым.

Казалось бы, естественно ожидать, что эксперты по гибким методологиям должны понимать основы теории сложности. В конце концов, гибкие методологии выросли именно из нее. Но если бы они по-настоящему разбирались в теории сложности, то не давали бы глупых рекомендаций вроде «Если вы не пользуетесь практикой X, то вашу методологию нельзя признать гибкой» или «У вас не настоящий Scrum, поскольку вы не делаете Y». К сожалению, это до сих пор случается очень часто. Последователи спорят о преимуществах гибких методологий над бережливыми, превосходстве Экстремального программирования над Scrum, плюсах канбана по сравнению со Scrum и так далее и тому подобное. (На момент написания этой книги Scrum все еще считается нормой, поэтому если вы усматриваете в нем недостатки, то вполне сможете произвести впечатление на непосвященных.) Но ведь любая модель неполна, и найти в каждой недостатки достаточно легко – только пользы от этого немного.

В мире полно специалистов по гибким методологиям, выучивших слова эмерджентность и самоорганизация, которые в настоящий момент не использует только ленивый. Но они не до конца понимают, что означают эти термины в контексте гибких методологий и в практике разработки ПО. Не пора ли и мне выступить с программным документом?

Инструкция по управлению сложностью

Мне кажется, нам всем пора признать, что, предпочитая простые решения, мы игнорируем сложность окружающего нас мира. Поэтому я предлагаю следующий набор рекомендаций…

У каждой проблемы есть много решений

Кубик Рубика можно собрать несколькими способами. Не существует единственного верного способа управлять бизнесом. Не существует единой оптимальной стратегии, позволяющей всегда выигрывать в настольной игре «Риск». И нет единого оптимального метода управления проектами. По-человечески понятно, что нам бы хотелось, чтобы только предлагаемые нами решения оказывались эффективными. Но следует все же допускать, что и решения, предложенные другими, могут также быть эффективными.

Выбор решения зависит от контекста

Форма биологического вида зависит от окружающей его среды. При выборе оптимальной стратегии необходимо учитывать характеристики данной команды и ее противников. Выбор маркетинговых решений зависит от того, с какими клиентами вы имеете дело. А выбор наиболее эффективных практик зависит от внешней среды, в которой реализуется конкретный проект. При разработке ПО многие факторы важны, но главным из них будет именно контекст.

Изменяющиеся контексты диктуют изменяющиеся решения

Когда изменяется среда обитания, изменяются и населяющие ее биологические виды. Лучшие стратегии продвижения аккаунта в социальных сетях в этом году отличаются от прошлогодних. (Подпишитесь на меня в Twitter, и мы вместе понаблюдаем, какие стратегии будут применяться в следующем году.) Стоит измениться контексту, как приходится изменять и способы управления соответствующими проектами.

Любое странное решение где-то будет лучшим

Антарктический криль – самый успешный вид на планете. Стратегия «око за око» – одна из доминирующих стратегий выживания в теории игр. Но даже рыбе-капле с ее специфической внешностью удалось найти свою нишу в этом мире. Ни одна стратегия в теории игр не будет универсальной. Как бы ни были популярны некоторые методологии разработки ПО, они не заменят другие методы, подходящие именно в нестандартных ситуациях – а такие ситуации будут всегда.

Выбранное решение в свою очередь влияет на контекст

Некоторые новые фильмы оказывают трансформирующее воздействие на всю киноиндустрию, и всем выходящим впоследствии фильмам волей-неволей приходится учитывать новые веяния. Оказавшиеся у нас в головах мемы изменяют наш образ мыслей и облегчают усвоение связанных с ними новых мемов. Аналогичным образом выбранные нами практики разработки ПО изменяют среду, в которой мы функционируем, и влияют на нашу способность применять другие практики.

Простота требует понимания сложности

Биологи, компании и правительства успели причинить много вреда, в свое время не разобравшись в сложности окружающего мира. Тем, кто не понимает, как устроен мир, трудно спрогнозировать, какие именно простые решения могут оказаться эффективными при решении сложных проблем.

Невозможно заранее предсказать, какое решение окажется лучшим

Прогнозирование, безусловно, это ценный инструмент, но тем не менее невозможно точно знать заранее, какие из предлагающихся решений сработают, а какие нет. Только располагая эмпирическими данными о реальной ситуации, мы можем делать заявления об ожидаемом успехе того или иного решения. Но надо научиться признавать, что часто мы просто не в состоянии вынести об этом какое-либо суждение и сначала предстоит испробовать различные методы, прежде чем выяснится, какой из них оказался эффективным в конкретной ситуации.

Предлагаемая ниже инструкция по управлению сложными проектами (рис. 16.3) не призвана опровергнуть никакие из существующих ценностей, принципов, ориентиров и практик (она также не противоречит никаким манифестам). Напротив, в ней подчеркивается, что все методологии полезны, если рассматривать их в соответствующем им контексте. При разработке ПО мы должны обсуждать не то, кто из нас прав, а кто нет. Единственное, что нас должно интересовать, – какой из методов эффективен в конкретной ситуации. Мы не должны слишком увлекаться противопоставлением пользовательских историй вариантам использования, гибких технологий – методам CMMI, Scrum – канбану или гибких технологий – бережливым. Вопрос лишь в том, когда и какой метод уместно использовать. Просто спор о том, кто прав, а кто нет, только служит росту популярности, а не пониманию.

Из-за простоты своих высказываний люди необразованные в глазах толпы кажутся более убедительными, чем образованные.

Аристотель

Я надеюсь, что разработчики ПО и менеджеры по всему миру поймут, что не стоит подвергать друг друга уничтожающей критике при обсуждении методологий, стандартизированных подходов, принципов и практик. В сложном мире найдется время и место для любой идеи. Нет смысла обсуждать, какая из имеющихся идей неверна, потому что они все неверны. Настоящий вызов в том, чтобы выяснить, какая из них может оказаться полезной в конкретном контексте.

Все модели неверны, но некоторые из них полезны [Box, Draper 1969].

Я осознаю, что в моей книге «неверно» все, но очень надеюсь, что она тем не менее будет вам полезна.

Резюме

В модели Менеджмента 3.0 шесть компонентов: настройка ограничений, развитие компетенций, расширение полномочий команд, выращивание структуры, добавление энергии и улучшение всего. Каждая из практик, применяемых менеджерами в рамках гибких методологий, должна вносить положительный вклад по крайней мере в один из этих шести компонентов.

В конечном итоге все модели терпят неудачу, включая и предлагаемую в этой книге. Ни одна модель не в состоянии дать полное описание сложных систем, примером которых являются, в частности, проекты по разработке программных продуктов. Поэтому все модели неверны; впрочем, некоторые из них могут оказаться полезными. Вот почему есть смысл для разных случаев иметь наготове разные дополняющие и противоречащие друг другу модели.

То же самое относится к методологиям разработки ПО. Любая из них может быть полезной, но только в определенном контексте. В сложном мире сложно все. И в конечном итоге истина всего одна: все и всегда зависит от ситуации.

Подумать и сделать

Давайте посмотрим, как применить некоторые идеи из данной главы в вашей компании:

• Пользуетесь ли вы при управлении своими задачами и проектами всеми шестью компонентами Менеджмента 3.0? Возможно, вы также делаете что-то, что отсутствует в данной модели?

• Сформулируйте свое отношение к этой книге. Понравилась ли она вам? Если да, посоветуйте ее тем, для кого она также будет полезной.

Библиография

Аллен Д. Как привести дела в порядок. Искусство продуктивности без стресса. – М.: МИФ, 2018.

Андерсон К. Длинный хвост. Эффективная модель бизнеса в Интернете. – М.: МИФ, 2012.

Андерсон Д. Канбан Альтернативный путь в Agile. – М.: МИФ, 2017.

Бек К. Экстремальное программирование. – СПб.: Питер, 2002.

Беркун С. Искусство управления IT-проектами. – СПб.: Питер, 2011.

Бланшар К., Джонсон С. Одноминутный менеджер. Самые практичные техники менеджмента. – Мн.: Попурри, 2013.

Чапел Х., Брукс Ф. Мифический человеко-месяц, или Как создаются программные системы. – М.: Символ-Плюс, 2010.

Бэкингем М., Коффман К. Сначала нарушьте все правила! Что лучшие в мире менеджеры делают по-другому? – М.: Альпина Паблишер, 2014.

Клег Б., Берч П. Идея на 1 000 000 евро. Так рождаются креативные идеи. Интенсив-тренинг по развитию суперспособностей. – М.: АСТ, Астрель, 2009.

Кон М. Scrum. Гибкая разработка. – М.: Вильямс, 2016.

Коберн А. Быстрая разработка программного обеспечения. – М.: Лори, 2016.

Коллинз Дж. От хорошего к великому. Почему одни компании совершают прорыв, а другие нет… – М.: МИФ, 2017.

Кови С. Семь навыков высокоэффективных людей. Мощные инструменты развития личности. – М.: Альпина Паблишер, 2018.

Кросс Р., Паркер Э. Невидимая сила социальных связей. Как на самом деле работают организации. – Киев: Калидос Паблишинг, 2006.

Давила Т., Эпштейн М. Дж., Шелтон Р. Работающая инновация. – Киев: Баланс Бизнес Букс, 2007.

Докинз Р. Слепой часовщик. Как эволюция доказывает отсутствие замысла во Вселенной. – М.: Corpus, 2014.

Докинз Р. Эгоистичный ген. – М.: Corpus, 2017.

Гиус де А. Живая компания. Рост, научение и долгожительство в деловой среде. – СПб.: Стокгольмская школа экономики в Санкт-Петербурге, 2004.

ДеМарко Т., Листер Т. Человеческий фактор. Успешные проекты и команды. – М.: Символ-Плюс, 2014.

Деминг У. Э. Выход из кризиса. Новая парадигма управления людьми, системами и процессами. – М.: Альпина Паблишер, 2017.

Дерби Э., Ларсен Д. Agile-ретроспектива. Как превратить хорошую команду в великую. – М.: Издательство Дмитрия Лазарева, 2017.

Гладуэлл М. Гении и аутсайдеры. – М.: МИФ, 2016.

Гладуэлл М. Переломный момент. Как незначительные изменения приводят к глобальным переменам. – М.: Альпина Паблишер, 2018.

Гласс Р. Факты и заблуждения профессионального программирования. – М.: Символ-Плюс, 2007.

Годин С. Лидер есть в каждом. Племена в эпоху социальных сетей. – М.: Альпина Бизнес Букс, 2012.

Хэмел Г., Брин Б. Будущее менеджмента. – BestBusinessBooks, 2013.

Хант Э., Томас Д. Программист-прагматик. Путь от подмастерья к мастеру. – М.: Лори, 2009.

Каплан Р. С., Нортон Д. П. Стратегическое единство. Создание синергии организации с помощью сбалансированной системы показателей. – М.: Вильямс, 2006.

Джордан-Эванс Ш., Кай Б. Любите их, или вы их потеряете. Как удержать ценных сотрудников. – М.: Добрая книга, 2011.

Ленсиони П. Пять пороков команды. – М.: МИФ, 2018.

Лайкер Дж. К. Дао Toyota. 14 принципов менеджмента ведущей компании мира. – М.: Издательская группа «Точка», 2018.

Мандельброт Б. Б., Хадсон Дж. К. (Не)послушные рынки. Фрактальная революция в финансах. – М.: Вильямс, 2006.

Максвелл Дж. К. 21 неопровержимый закон лидерства. – Мн.: Попурри, 2007.

Макконнелл С. Профессиональная разработка программного обеспечения. – М.: Символ-Плюс, 2007.

Минцберг Г. Требуются управленцы, а не выпускники МВА. Жесткий взгляд на мягкую практику управления и систему подготовки менеджеров. – М.: Олимп-Бизнес, 2010.

Нонака И., Такеучи Х. Компания – создатель знания. Зарождение и развитие инноваций в японских фирмах. – М.: Олимп-Бизнес, 2003.

Пинк Д. Драйв: Что на самом деле нас мотивирует. – М.: Альпина Паблишер, 2017.

Попендик М., Попендик Т. Бережливое производство программного обеспечения. От идеи до прибыли. – М.: Вильямс, 2010.

Рэнд А. Добродетель эгоизма. – М.: Альпина Паблишер, 2018.

Роэм Д. Визуальное мышление. Как «продавать» свои идеи при помощи визуальных образов. – М.: МИФ, 2012.

Сенге П. Пятая дисциплина. Искусство и практика самообучающейся организации. – М.: Олимп-Бизнес, 2003.

Судзуки С. Сознание дзен, сознание начинающего. – М.: Альпина Паблишер, 2016.

Тапскотт Д., Уильямс Э. Д. Викиномика. Как массовое сотрудничество изменяет все. – BestBusinessBooks, 2009.

Йордон Э. Путь камикадзе. – М.: Лори, 2008.

Abilla, Pete, “Zero Defects Is Wrong Approach” <-defects-is-wrong-approach> Shmula. April 3, 2007.

Abran, Alain and James Moore. Guide to the Software Engineering Body of Knowledge. Oxford Oxfordshire: Oxford University Press, 2004.

Adams, Cecil. “Why do we nod our heads for ‘yes’ and shake them for ‘no’?” The Straight Dope. March 14, 1986.

Adkins, Lyssa. Coaching Agile Teams. Reading: Addison-Wesley Professional, 2010.

Alleman, Glen B. “Self Organized Does Not Mean Self Directed” <-organized-does-notmean-self-directed.html>. Herding Cats December 24, 2008.

Ambler, Scott “The Discipline of Agile” <;. Dr. Dobb’s. September 5, 2007.

Ambler, Scott “Generalizing Specialists: Improving Your IT Career Skills” <;. Agile Modeling. 2010.

Anderson, Carl and Elizabeth McMillan. “Of Ants and Men: Self-Organized Teams in Human and Insect Organizations” Emergence Vol. 5 Iss. 2 2003.

Anderson, David. Agile Management for Software Engineering. Upper Saddle River: Prentice Hall Professional Technical Reference, 2004.

Arrow, Holly et.al. Small Groups as Complex Systems. Thousand Oaks: Sage, 2000.

Augustine, Sanjiv. Managing Agile Projects. Upper Saddle River: Prentice Hall Professional Technical Reference, 2005.

Austin, Robert. Measuring and Managing Performance in Organizations. New York: Dorset House, 1996.

Austin, Robert and Lee Devin. Artful Making. New York: Financial Times/Prentice Hall, 2003.

Avery, Christopher et.al. Teamwork Is an Individual Skill. San Francisco: Berrett-Koehler Publishers, 2001.

Bennet, Alex and David Bennet. Organizational Survival in the New World. Amsterdam: Elsevier, 2004.

Bobinski, Dan. “Gardening and Management: What They Have in Common” Hodu.com <;. 2009.

Bobinski, Dan. “Performance appraisals don’t work” Management-Issues. <-issues.com/2010/7/8/opinion/performance-appraisals-dont-work.asp>. 8 July 2010.

Bond, Michael. “Critical Mass.” New Scientist 18 July 2009 (b). <-why-cops-should-trustthe-wisdom-of-the-crowds.html>.

Bond, Michael. “Three degrees of separation.” New Scientist. 3 January 2009 (a) <-how-yourfriends-friends-can-affect-your-mood.html>.

Bowen, D.E. and Lawler, E.E. “Empowering service employees.” Sloan Management Review, Summer 1995.

Box, George and Norman Draper. Evolutionary Operation. New York: Wiley, 1969.

Brahic, Catherine. “All at sea over mystery currents.” New Scientist. 19 April 2008.

Brooks, Michael. “Born believers: How your brain creates God.” New Scientist, Feb 4, 2009. <-born-believers-how-your-brain-creates-god.html>.

Brown, Tim. “Strategy by Design” <-strategy.html>. Fast Company. June 1, 2005.

Buchanan, Mark. “Another kind of evolution” New Scientist. 23 January 2010.

Buchanan, Mark. “The curse of the committee” New Scientist. 10 January 2009.

Business Week. “Jack Welch Elaborates: Shareholder Value” Business Week. 16 March 2009.

Caudron, S. “Create an empowering environment.” Personnel Journal, 1995 74-9.

Chrissis, Beth, Mary et.al. CMMI. Boston: Addison-Wesley, 2007.

Chui, Glennda. “Unified Theory is Getting Closer, Hawking Predicts.” San Jose Mercury News, January 23, 2000.

Cilliers, Paul. Complexity and Postmodernism. New York: Routledge, 1998.

Cilliers, Paul. “Knowing Complex Systems” Richardson, K.A. Managing Organizational Complexity: Philosophy, Theory and Application. Greenwich: Information Age Publishing, 2005.

Cilliers, Paul. “Why We Cannot Know Complex Things Completely” Emergence. Vol. 4, Issue 1/2, 2002.

Cockburn, Alistair. “Process: the 4th dimension” <: _the_fourth_dimension>. 2003.

Coplien, James and Neil Harrison. Organizational Patterns of Agile Software Development. Upper Saddle River: Pearson Prentice Hall, 2005.

Corning, Peter A. “The Emergence of “Emergence”: Now What?” Emergence, Vol. 4, Issue 3, 2002.

Corning, Peter. Nature’s Magic. Cambridge: Cambridge University Press, 2003.

Cropley, Arthur J. “Definitions of Creativity” Encyclopedia of Creativity. Boston: Elsevier/Academic Press, 1999.

Culbert, Samuel and Lawrence Rout. Get Rid of the Performance Review! City: Business Plus, 2010.

Curry, Andrew “Monopoly Killer: Perfect German Board Game Redefines Genre” <-04/mf_settlers>. Wired. March 23, 2009.

Curtis, Bill et.al. People Capability Maturity Model. Boston: Addison-Wesley, 2001.

Davis, Mark. “Living with aliens.” New Scientist. 26 September 2009.

Dawkins, Richard “The Purpose of Purpose” <;. June 18, 2009.

De Wolf, Tom, and Tom Holvoet. “Emergence Versus Self-Organisation: Different Concepts but Promising When Combined.” Engineering Self Organising Systems: Methodologies and Applications, Lecture Notes in Computer Science, volume 3464, pp 1-15, 2005.

Deci, Edward L. and Richard M. Ryan. The Handbook of Self-Determination Research. Rochester: University of Rochester Press, 2004.

Dennett, Daniel. Consciousness Explained. Boston: Back Bay Books, 1992.

Dennett, Daniel. Darwin’s Dangerous Idea. New York: Simon & Schuster, 1995.

Dent, Eric B. “Complexity Science: a Worldview Shift” Emergence. Vol. 1, Issue 4, 1999.

Derby, Esther. “Performance Without Appraisal: Addressing the Most Common Concerns” 12 July 2010 <-without-appraisal-addressing-the-most-common-concerns.html>.

Eliot, Lise. “We are all from Alpha Centauri” NewScientist. 17 July 2010.

Eoyang, Glenda and Doris Jane Conway “Conditions That Support Self-Organization in a Complex Adaptive System” <-international.com/iaf99/Thread1/conway.html>. IAF January 14–17, 1999.

Falconer, James. “Emergence Happens! Misguided Paradigms Regarding Organizational Change and the Role of Complexity and Patterns in the Change Landscape” Emergence. Vol. 4, Issue 1/2, 2002.

Fonseca, José. Complexity and Innovation in Organizations. New York: Routledge, 2002.

Forrester, Jay W. “System Dynamics, Systems Thinking, and Soft OR” Massachusetts Institute of Technology, August 18, 1992.

Fox, John. “Employee Empowerment: An Apprentice Model” 22 June 1998. <;.

Friedman, Milton “The Social Responsibility of Business is to Increase Its Profits” New York Times Magazine September 13, 1970.

Gall, John. The Systems Bible. Ann Arbor: General Systemantics Press, 2002.

Gat, Israel. “A Social Contract for Agile” </a-social-contract-for-agile/>. The Agile Executive. February 3, 2009.

Gell-Mann, Murray. The Quark and the Jaguar. Clearwater: Owl Books, 1994.

Gilb, Tom et.al. Software Inspection. Boston: Addison-Wesley, 1993.

Gleick, James. Chaos. Harmondsworth Eng.: Penguin, 1987.

Gould, Stephen Jay. “Full House: The Spread of Excellence from Plato to Darwin.” Three Rivers Press, 1997.

Gould, Stephen Jay. The Structure of Evolutionary Theory. Cambridge: Belknap Harvard, 2002.

Granovetter, Mark. “The Strength of Weak Ties” American Journal of Sociology 78 (6): 1360–1380, May 1973.

Hackman, J. Leading Teams. Boston: Harvard Business School Press, 2002.

Hartzog, Paul B. “Panarchy: Governance in the Network Age” <%20-%20Governance%20in%20the%20Network%20Age.pdf>. 2009.

Heath, Chip and Dan Heath. Made to Stick. New York: Random House, 2007.

Heathfield, Susan M. “Team Building and Delegation: How and When to Empower People” Michigan State University M.E.N.T.O.R.S. Manual: Monthly Conversation Guide #9 2003-2004.

Heathfield, Susan M. “The Darker Side of Goal Setting: Why Goal Setting Fails….” <;. About.com. 2010 (a).

Heathfield, Susan M. “360 Degree Feedback: The Good, the Bad, and the Ugly.” <;. About.com. 2010 (b).

Heathfield, Susan M. “Performance Appraisals Don’t Work.” <;. About.com. 2010 (c).

Herzberg, Frederick. One More Time: How Do You Motivate Employees?. Boston: Harvard Business Press, 2008.

Highsmith, Jim. Adaptive Software Development. New York: Dorset House Pub, 1999.

Highsmith, Jim. Agile Project Management, Second Edition. Boston: Addison-Wesley, 2009.

Highsmith, Jim. “Does Agility Work?” Dr. Dobbs. June 1, 2002. <;.

Hofstadter, Douglas. Gцdel, Escher, Bach. New York: Basic Books, 1979.

Holland, John. Hidden Order. Boston: Addison-Wesley, 1995.

Hunt, Andrew. Pragmatic Thinking and Learning. City: Pragmatic Bookshelf, 2008.

Jacobson, Ivar “Enough of Processes: Let’s Do Practices.” <;. Dr. Dobb’s. March 12, 2007.

Jaques, Elliott “In Praise of Hierarchy” Harvard Business Review. January-February 1990.

Jaques, Elliott. Requisite Organization. Oxford Oxfordshire: Oxford University Press, 1998.

Jensen, Eric. Enriching the Brain. San Francisco: Jossey-Bass, A John Wiley & Sons Imprint, 2006.

Jones, Capers. Software Assessments, Benchmarks, and Best Practices. Harlow: Addison-Wesley, 2001.

Kao, John. Innovation Nation. New York: Free Press, 2007.

Kauffman, Stuart. At Home in the Universe. Oxford Oxfordshire: Oxford University Press, 1995.

Keizer, Kees, et.al. “The Spreading of Disorder” <;. Science. December 12, 2008.

Kelly, Kevin. Out of Control. Boston: Addison-Wesley, 1994.

Kruchten, Philippe. “Voyage in the Agile Memeplex” ACM Queue. August 16, 2007.

Lane, David et.al. Complexity Perspectives in Innovation and Social Change. Berlin: Springer, 2009.

Larman, Craig. Agile and Iterative Development. Boston: Addison-Wesley, 2004.

Larman, Craig and Bas Vodde. Scaling Lean & Agile Development. Boston: Addison-Wesley, 2009.

Leffingwell, Dean. Scaling Software Agility. Oxford Oxfordshire: Oxford University Press, 2007.

Le Page, Michael. “Evolution: A guide for the not-yet perplexed” New Scientist. 19 April 2008.

Levitt, Ted. Ted Levitt on Marketing. Boston: Harvard Business School Press, 2006.

Lewin, Roger. Complexity. Chicago: University of Chicago Press, 1999.

Lewin, Roger and Birute Regine. Weaving Complexity and Business. Mason: Texere, 2001.

Lissack, Michael R. “Complexity: the Science, its Vocabulary, and its Relation to Organizations” Emergence. Vol. 1, Issue 1, 1999.

Lundin, Stephen et.al. Fish!. New York: Hyperion, 2000.

Maguire, Steve. and Bill McKelvey. “Complexity and Management: Moving from Fad to Firm Foundations”. Emergence. Vol. 1, Issue 2, 1999.

Macleod, Mairi. “You are what you copy” New Scientist. 1 May 2010.

Manns, Lynn, Mary and Linda Rising. Fearless Change. Boston: Twayne Publishers, 2005.

Marick, Brian “Six years later: What the Agile Manifesto left out” <-years-later-whatthe-agile-manifesto-left-out/>.

Marion, Russ and Mary Uhl-Bien. “Paradigmatic Influence and Leadership: The Perspectives of Complexity Theory and Bureaucratic Theory” in Hazy, K., James et.al. Complex Systems Leadership Theory. Goodyear: ISCE Pub, 2007.

McConnell, Steve. Rapid Development. New York: McGraw-Hill, 1996.

McGregor, Douglas and Joel Cutcher-Gershenfeld. The Human Side of Enterprise. New York: McGraw-Hill, 2006.

McKelvey, Bill. “Complexity Theory in Organization Science: Seizing the Promise or Becoming a Fad?” Emergence. Volume 1 Issue 1, 1999.

Middleton, Peter and James Sutton. Lean Software Strategies. Portland: Productivity Press, 2005.

Miller, John H. and Scott E. Page. Complex Adaptive Systems. Princeton: Princeton University Press, 2007.

Minsky, Marvin. The Society of Mind. New York: Simon and Schuster, 1986.

Mintzberg, Henry. Managing. San Francisco: Ignatius Press, 2009.

Mitchell, Melanie. Complexity. City: Oxford U Pr, N Y, 2009.

Norberg, Johan. Financial Fiasco. Washington D.C.: Cato Institute, 2009.

Norman, Don. “Simplicity Is Highly Overrated.” <;. Jnd.org. 2007.

O’Donogue, James. “Look at the SIZE of those things!” NewScientist. 21 March 2009.

Pettit, Ross <-made-us-better-butwe-signed-up.html>. The Agile Manager. June 29, 2008.

Phillips, Jeffrey. Make Us More Innovative. United States: iUniverse, Inc., 2008.

Pmi, Pmi. Guide to the Project Management Body of Knowledge. Drexel Hill: Project Management Institute, 2008.

Poppendieck, Mary. “Unjust Deserts” Better Software. July/August 2004.

Poppendieck, Mary et.al. Implementing Lean Software Development. Boston: Addison-Wesley, 2007.

Prigogine, I. and Isabelle Stengers. The End of Certainty. New York: Free Press, 1997.

Pulford, Kevin et.al. A Quantitative Approach to Software Management. San Francisco: Ignatius Press, 1996.

Pundir, Ashok K, et.al. “Towards a Complexity Framework for Managing Projects” E: CO. Vol. 9, Issue 4, 2007.

Quinn, R.E. & Spreitzer, “G.M. The road to empowerment: Seven questions every leader should consider.” Organizational Dynamics, 26-2, 1997

Reinertsen, Donald. Managing the Design Factory. New York: Free Press, 1997.

Reiss, Steven. Who Am I? The 16 Basic Desires That Motivate Our Actions and Define Our Personalities. City: Berkley Trade, 2002.

Reynolds, Craig (1987), “Flocks, herds and schools: A distributed behavioral model.”, SIGGRAPH ‘87: Proceedings of the 14th annual conference on Computer graphics and interactive techniques (Association for Computing Machinery): 25-34, doi:10.1145/37401.37406, ISBN 0-89791-227-6.

Richardson, K.A. “Managing Complex Organizations” E: CO Vol. 10 No. 22008.

Richardson, K.A. “Systems theory and complexity: Part 1” E: CO Vol. 6 No. 32004 (a).

Richardson, K.A. “Systems theory and complexity: Part 2” E: CO Vol. 6 No. 42004 (b).

Rico, F., David et.al. The Business Value of Agile Software Methods. New York: McGraw-Hill, 2009.

Rothman, Johanna and Esther Derby. Behind Closed Doors. Raleigh: Pragmatic Bookshelf, 2005.

Runco, Mark and Steven Pritzker. Encyclopedia of Creativity. Boston: Academic Press, 1999.

Satir, Virginia et.al. The Satir Model. Palo Alto: Science and Behavior Books, 1991.

Saviano, Roberto and Virginia Jewiss. Gomorrah: a Personal Journey into the Violent International Empire of Naples’ Organized Crime System. New York: Picador, 2008.

Schwaber, Ken. “Agile Processes and Self-Organization” <-articles/selforg.pdf>. 2001.

Schwaber, Ken. Agile Project Management with Scrum. Redmond: Microsoft Press, 2004.

Schwaber, Ken and Mike Beedle. Agile Software Development with Scrum. Englewood Cliffs: Prentice Hall, 2002.

Sheedy, Tim. “People Management is Fundamental to the Success of Large Systems Integration Projects.” Forrester, June 11, 2008. <;.

Shore, James. “Why I Don’t Provide Agile Certification.” The Art of Agile, March 31, 2009. <-I-Dont-Provide-Agile-Certification.html>.

Sivers, Derek. “Shut up! Announcing your plans makes you less motivated to accomplish them” <; 16 June 2009.

Skyttner, L. General systems theory: Ideas and applications, River Edge, NJ: World Scientific. 2001.

Snowden, David. “Knowledge sharing across silos: Part II” Cognitive Edge <-edge.com/blogs/dave/2010/01/knowledge_sharing_across_silos.php> 2010 (a).

Snowden, David. “Multi-ontology sense making: a new simplicity in decision making” Management Today. Yearbook 2005, Vol 20.

Snowden, David. “The origin of Cynefin (part 1)…(part 7)” Cognitive Edge <-edge.com/blogs/dave/2010/07/origins_of_cynefin_part_7.php> 2010 (b).

Sokal, Alan and Jean Bricmont. Intellectual Impostures: Postmodern Philosophers’ Abuse of Science. Economist Books, 1998.

Solé, Ricard et.al. Signs of Life. New York: Basic Books, 2000.

Spagnuolo, Chris. “Discipline versus Motivation.” <-versus-motivation/> EdgeHopper. 9 October 2008.

Spanyi, Andrew. “Beyond Process Maturity to Process Competence.” BPTrends, June, 2004. <%20Process%20Competence.pdf>.

Spolsky, Joel. “In Defense of Not-Invented-Here Syndrome.” Joel on Software, 14 Oct. 2001. <;.

Spolsky, Joel. “The Law of Leaky Abstractions.” Joel on Software, 11 Nov. 2002. <;.

Sprangers, Chris “Verkeer zonder regels is veiliger” <;. January 11, 2007 Intermediair.

Stacey, Ralph D. Strategic Management and Organisational Dynamics: The Challenge of Complexity, First Edition. Upper Saddle River: Prentice Hall, 2000 (b).

Stacey, Ralph D. et.al. Complexity and Management. New York: Routledge, 2000 (a).

Stack, Jack. The Great Game of Business. Oxford Oxfordshire: Oxford University Press, 1994.

Stallard, Michael L. Fired Up or Burned Out. Nashville: Thomas Nelson, 2007.

Starcevich, Matt M. “Coach, Mentor: Is there a difference.” <;. Center for Coaching & Mentoring. 2009. “The State of Agile Development Survey 2009” Version One, August, 2009. <;.

Stephenson, Karen. Quantum Theory of Trust. Harlow: Pearson Education Ltd, 2005.

Sterling, Chris. “Focus on Value: How to create value-driven user stories.” <;.

Strogatz, Steven. Sync. New York: Theia, 2003.

Testa, Louis. Growing Software. San Francisco: No Starch Press, 2009.

Thomas, Kenneth. Intrinsic Motivation at Work. San Francisco: Berrett-Koehler Publishers, 2000.

Van Vugt, Mark. “Triumph of the Commons” New Scientist. 22 August 2009.

Wailgum, Thomas “The Best Way to Implement Agile Development Processes: Your Own Way” </> CIO.com. May 21, 2007.

Waldrop, M. Complexity. New York: Simon & Schuster, 1992.

Wallis, Steven E. “The Complexity of Complexity Theory: An Innovative Analysis” E: CO Vol. 11, Issue 4, 2009.

Webb, Richard. “I want what she wants” New Scientist. 20/27. December 2007.

Weinberg, Gerald. An Introduction to General Systems Thinking: Silver Anniversary Edition. New York: Dorset House, 2001.

Weinberg, Gerald. Quality Software Management. New York: Dorset House Pub, 1992.

Wilson, James Q. and George L. Kelling “Broken Windows.” <-institute.org/pdf/_atlantic_monthly-broken_windows.pdf>. The Atlantic Monthly. March 1982.

Wolfram, Stephen. “Universality and Complexity in Cellular Automata” Physica D, January 10, 1984, 1–35.

Сноски

1

Michael Brooks, “Born believers: How your brain creates God,” New Scientist, February 4, 2009 [Brooks 2009: 32].

(обратно)

2

Журнал E: CO. Emergence: Complexity & Organization выходит в издательстве Emergency Publications.

(обратно)

3

Далее в книге в качестве синонимов будут использоваться термины «гибкие методологии», «Agile-методологии» и производные от них.

(обратно)

4

У этой организации есть свой сайт .

(обратно)

5

Сайт был создан основателем Scrum Кеном Швабером.

(обратно)

6

На данный момент The Lean Software & Systems Consortium реорганизован в The Lean Systems Society, сайт организации . – Прим. ред.

(обратно)

7

Steve Maguire and Bill McKelvey, “Complexity and Management: Moving from Fad to Firm Foundations”. Emergence, vol. 1, issue 2, 1999 [Maguire, McKelvey 1999: 23].

(обратно)

8

Steven E. Wallis, “The Complexity of Complexity Theory: An Innovative Analysis,” E: CO, vol. 11, issue 4, 2009 [Wallis 2009: 26].

(обратно)

9

Роэм Д. Визуальное мышление. Как «продавать» свои идеи при помощи визуальных образов. – М.: Манн, Иванов и Фербер, 2012.

(обратно)

10

Jim Highsmith, Adaptive Software Development. New York: Dorset House Pub, 1999 [Highsmith 1999].

(обратно)

11

Ken Schwaber and Mike Beedle, Agile Software development with Scrum. Englewood Cliffs: Prentice Hall, 2002 [Schwaber, Beedle 2002].

(обратно)

12

Из блога Тома Хьюма (пост о презентации Джеффа Сазерленда).

(обратно)

13

Steve Maguire and Bill McKelvey, “Complexity and Management: Moving from Fad to Firm Foundations,” Emergence,vol. 1, issue 2, 1999 [Maguire, McKelvey 1999: 55].

(обратно)

14

Сенге П. Пятая дисциплина. Искусство и практика обучающейся организации. – М.: Олимп-Бизнес, 2009.

(обратно)

15

Тапскотт Д., Уильямс Э. Викиномика. Как массовое сотрудничество изменяет все. – М.: BestBusinessBooks, 2009.

(обратно)

16

Кросс Р., Паркер Э. Невидимая сила социальных связей. Как на самом деле работают организации. – Киев: Калидос Паблишинг, 2006.

(обратно)

17

Гласс Р. Факты и заблуждения профессионального программирования. – СПб.: Символ-Плюс, 2007.

(обратно)

18

Бланшар К., Джонсон С. Одноминутный менеджер. Самые практичные техники менеджмента. – Мн.: Попурри, 2013.

(обратно)

19

Бакингем М., Коффман К. Сначала нарушьте все правила. Что лучшие в мире менеджеры делают по-другому. – М.: Альпина Паблишер, 2014.

(обратно)

20

Arthur Cropley, Encyclopedia of Creativity. Boston: Elsevier/Academic Press, [Cropley 1999: 251].

(обратно)

21

Демарко Т., Листер Т. Человеческий фактор. Успешные проекты и команды. – СПб.: Символ-Плюс, 2014.

(обратно)

22

Воспроизводится по лицензии Creative Commons. Посетите сайт /.

(обратно)

23

Ted Levitt, Ted Levitt on Marketing. Boston: Harvard Business School Press, 2006. [Levitt 2006: 172.]

(обратно)

24

Судзуки С. Сознание дзен, сознание начинающего. – М.: Альпина Паблишер, 2016.

(обратно)

25

Robert Austin and Lee Devin, Artful Making. New York: Financial Times/Prentice Hall, 2003 [Austin, Devin 2003: 123].

(обратно)

26

Tom DeMarco and Timothy Lister Peopleware: Second Edition. New York: Dorset House Pub, 1999 [DeMarco, Lister 1999: 178].

(обратно)

27

Mary Poppendieck, “Unjust Deserts,” Better Software, July/August, 2004 [Poppendieck 2004: 34].

(обратно)

28

Steven Reiss, Who Am I? The 16 Basic Desires That Motivate Our Actions and Define Our Personalities. City: Berkley Trade, 2002 [Reiss 2002].

(обратно)

29

Scott Berkun, Making Things Happen: Mastering Project Management. Sebastopol: O’Reilly Media, Inc., 2008 [Berkun 2008: 186].

(обратно)

30

Мой рецензент Майк Кон посоветовал мне использовать термин «рост команды», а не «построение команды», поскольку он лучше отражает мой взгляд на организационную динамику. Увы, привычка говорить «построение команды» так укоренилась, что время от времени приходится себя одергивать.

(обратно)

31

Ken Schwaber, “Agile Processes and Self-Organization,” 2001 [Schwaber 2001].

(обратно)

32

Цитата из выступления Дэвида Сноудена на Скандинавской конференции по гибким методологиям – 2009.

(обратно)

33

Взято из статьи «Википедии» Distributed and Complex Systems.

(обратно)

34

Frederick Brooks, The Mythical Man-Month. Reading: Addison-Wesley Pub. Co, 1975/1995 [Brooks 1995: 201].

(обратно)

35

Tom DeMarco and Timothy Lister, Peopleware: Second Edition. New York: Dorset House Pub, 1999 [DeMarco, Lister 1999].

(обратно)

36

Johanna Rothman and Esther Derby, Behind Closed Doors. Raleigh: Pragmatic Bookshelf, 2005 [Rothman, Derby 2005: 124].

(обратно)

37

Kenneth Thomas, Intrinsic Motivation at Work. San Francisco: Berrett-Koehler Publishers, 2000 [Thomas 2000: 66].

(обратно)

38

Беркун С. Искусство управления IT-проектами. – СПб.: Питер, 2014.

(обратно)

39

Beverly Kaye and Sharon Jordan-Evans, Love ’Em or Lose ’Em: Getting Good People to Stay. San Francisco: Berrett-Koehler Publishers, 2008 [Kaye, Jordan-Evans 2008: 96].

(обратно)

40

Glen B. Alleman, “Self Organized Does Not Mean Self Directed,” Herding Cats, December 24, 2008 [Alleman 2008].

(обратно)

41

Коллинз Дж. От хорошего к великому. Почему одни компании совершают прорыв, а другие нет… – М.: Манн, Иванов и Фербер, 2011.

(обратно)

42

Kevin Kelly, Out of Control. Boston: Addison-Wesley, 1994 [Kelly 1994: 411].

(обратно)

43

Peter Corning, Nature’s Magic. Cambridge: Cambridge University Press, 2003 [Corning 2003: 172].

(обратно)

44

Kenneth Thomas, Intrinsic Motivation at Work. San Francisco: Berrett-Koehler Publishers, 2000 [Thomas 2000: 22].

(обратно)

45

Richard Dawkins, “The Purpose of Purpose,” June 18, 2009 [Dawkins 2009].

(обратно)

46

Henry Mintzberg, Managers Not Mbas. San Francisco: Berrett-Koehler Publishers, 2005 [Mintzberg 2005].

(обратно)

47

Chip Heath and Dan Heath, Made to Stick. New York: Random House, 2007 [Heath 2007].

(обратно)

48

Воспроизводится по лицензии Creative Commons. Зайдите на сайт .

(обратно)

49

Воспроизводится по лицензии Creative Commons. Зайдите на сайт .

(обратно)

50

С корпоративного сайта Google /.

(обратно)

51

Israel Gat. “A Social Contract for Agile,” The Agile Executive, February 3, 2009 [Gat 2009].

(обратно)

52

Arthur Cropley, Encyclopedia of Creativity. Boston: Elsevier/Academic Press, 1999 [Cropley 1999: 518].

(обратно)

53

Peter Corning, Nature’s Magic. Cambridge: Cambridge University Press, 2003 [Corning 2003: 180].

(обратно)

54

Gerald Weinberg, Quality Software Management. New York: Dorset House Pub, 1992 [Weinberg 1992: 23].

(обратно)

55

Ross Pettit, “Agile Made us Better, But We Signed Up for Great,” The Agile Manager, June 29, 2008 [Pettit 2008].

(обратно)

56

Гладуэлл М. Переломный момент: Как незначительные изменения приводят к глобальным переменам. – М.: Альпина Паблишер, 2017.

(обратно)

57

Andrew Spanyi, “Beyond Process Maturity to Process Competence,” BPTrends, June, 2004. [Spanyi 2004].

(обратно)

58

Andrew Spanyi, “Beyond Process Maturity to Process Competence,” BPTrends, June, 2004. [Spanyi 2004].

(обратно)

59

С сайта Principia Cybernetica Web.

(обратно)

60

L. Skyttner, General systems theory: Ideas and applications. River Edge, NJ: World Scientific, 2001 [Skyttner 2001: 93].

(обратно)

61

Аллен Д. Как привести дела в порядок. Искусство продуктивности без стресса. – М.: Манн, Иванов и Фербер, 2017.

(обратно)

62

Johanna Rothman and Esther Derby, Behind Closed Doors. Raleigh: Pragmatic Bookshelf, 2005 [Rothman, Derby 2005: 124].

(обратно)

63

Mary Poppendieck et al., Leading Lean Software Development. Boston: Addison-Wesley, 2009 [Poppendieck 2009: 96–97].

(обратно)

64

James Shore, “Why I Don’t Provide Agile Certification,” The Art of Agile, March 31, 2009 [Shore 2009]

(обратно)

65

Joel Spolsky, “In Defense of Not-Invented-Here Syndrome,” Joel on Software, Oct. 14, 2001 [Spolsky 2001].

(обратно)

66

Pete Abilla, “Zero Defects Is Wrong Approach.” shmula, April 3, 2007 [Abilla 2007].

(обратно)

67

Eric B. Dent, “Complexity Science: a Worldview Shift,” Emergence, vol. 1, issue 4, 1999 [Dent 1999: 15].

(обратно)

68

Michael Bond, “Three degrees of separation,” New Scientist, January 3, 2009. [Bond 2009a: 24–27].

(обратно)

69

Jim Highsmith, Adaptive Software Development. New York: Dorset House Pub, 1999 [Highsmith 1999: 286].

(обратно)

70

John H. Miller and Scott E. Page, Complex Adaptive Systems. Princeton: Princeton University Press, 2007 [Miller, Page 2007: 94].

(обратно)

71

J. Hackman, Leading Teams. Boston: Harvard Business School Press, 2002 [Hackman 2002: 153].

(обратно)

72

James Gleick, Chaos. Harmondsworth Eng.: Penguin, 1987 [Gleick 1987: 309–311].

(обратно)

73

Мандельброт Б., Хадсон Р. (Не)послушные рынки. Фрактальная революция в финансах. – М.: Вильямс, 2006.

(обратно)

74

John Gall, The Systems Bible. Ann Arbor: General Systemantics Press, 2002 [Gall 2002].

(обратно)

75

Bennet, Alex and David Bennet, Organizational Survival in the New World. Amsterdam: Elsevier, 2004 [Bennet 2004: 9].

(обратно)

76

Воспроизводится по лицензии Creative Commons. Зайдите на сайт .

(обратно)

77

Louis Testa, Growing Software. San Francisco: No Starch Press, 2009 [Testa 2009: 54].

(обратно)

78

Scott Ambler, “Generalizing Specialists: Improving Your IT Career Skills,”. Agile Modeling, 2010 [Ambler 2010].

(обратно)

79

Douglas Hofstadter, Gödel, Escher, Bach. New York: Basic Books, 1979 [Hofstadter 1979: 288].

(обратно)

80

Michael R. Lissack, “Complexity: the Science, its Vocabulary, and its Relation to Organizations,” Emergence, vol. 1, issue 1, 1999 [Lissack 1999: 114].

(обратно)

81

Гладуэлл М. Гении и аутсайдеры. Почему одним все, а другим ничего? – М.: Манн, Иванов и Фербер, 2016.

(обратно)

82

L. Skyttner, General systems theory: Ideas and applications. River Edge, NJ: World Scientific, 2001 [Skyttner 2001: 93].

(обратно)

83

Frederick Brooks, The Mythical Man-Month. Reading: Addison-Wesley Pub. Co., 1975/1995 [Brooks 1995: 78–79].

(обратно)

84

J. Hackman, Leading Teams. Boston: Harvard Business School Press, 2002 [Hackman 2002: 130].

(обратно)

85

Paul B. Hartzog, “Panarchy: Governance in the Network Age,” 2009 [Hartzog 2009].

(обратно)

86

Paul B. Hartzog, “Panarchy: Governance in the Network Age,” 2009 [Hartzog 2009].

(обратно)

87

Стэк Дж., Берлингем Б. Большая игра в бизнес. Единственный разумный способ управления компанией. – М.: Манн, Иванов и Фербер, 2016.

(обратно)

88

Sanjiv Augustine, Managing Agile Projects. Upper Saddle River: Prentice Hall Professional Technical Reference, 2005 [Augustine 2005: 58].

(обратно)

89

ЭEric Dent, “Complexity Science: a Worldview Shift,” Emergence, vol. 1, issue 4, 1999 [Dent 1999: 13].

(обратно)

90

Ashok K Pundir et al., “Towards a Complexity Framework for Managing Projects,” E: CO, vol. 9, issue 4, 2007 [Pundir 2007: 22].

(обратно)

91

Я считаю, что большинство продуктовых и процессных параметров регулируются степенным законом, а не нормальным распределением.

(обратно)

92

Ken Schwaber, Agile Project Management with Scrum. Redmond: Microsoft Press, 2004 [Schwaber 2004: 2].

(обратно)

93

Gary Hamel, The Future of Management. Boston: Harvard Business School Press, 2007. [Hamel 2007: 42].

(обратно)

94

Murray Gell-Mann, The Quark and the Jaguar. Clearwater: Owl Books, 1994 [Gell-Mann 1994: 237].

(обратно)

95

James Falconer, “Emergence Happens! Misguided Paradigms Regarding Organizational Change and the Role of Complexity and Patterns in the Change Landscape,” Emergence, vol. 4, issue 1/2, 2002 [Falconer 2002: 122].

(обратно)

96

Давила Т., Эпштейн М. Дж., Шелтон Р. Работающая инновация. Как управлять ею, измерять ее и извлекать из нее выгоду. – М.: Баланс Бизнес Букс, 2007.

(обратно)

97

Взято из бесплатного «Викисловаря».

(обратно)

98

Kevin Kelly, Out of Control. Boston: Addison-Wesley, 1994 [Kelly 1994: 470].

(обратно)

99

Tom DeMarco and Timothy Lister, Peopleware: Second Edition. New York: Dorset House Pub, 1999 [DeMarco, Lister 1999: 119].

(обратно)

100

Peter Corning, Nature’s Magic. Cambridge: Cambridge University Press, 2003 [Corning 2003: 52].

(обратно)

101

Paul Cilliers, “Knowing Complex Systems” K.A. Richardson, Managing Organizational Complexity: Philosophy, Theory and Application. Greenwich: Information Age Publishing, 2005 [Cilliers 2005: 13].

(обратно)

102

Gerald Weinberg, An Introduction to General Systems Thinking: Silver Anniversary Edition. New York: Dorset House, 2001 [Weinberg 2001: 120].

(обратно)

103

Paul Cilliers, “Why We Cannot Know Complex Things Completely,” Emergence, vol. 4, issue 1/2, 2002 [Cilliers 2002: 78].

(обратно)

104

Деминг У.Э. Выход из кризиса. Новая парадигма управления людьми, системами и процессами. – М.: Альпина Паблишер, 2017.

(обратно)

105

Минцберг Г. Менеджмент. Природа и структура организаций глазами гуру. – М.: Эксмо, 2009.

(обратно)

106

Хэмел Г. Будущее менеджмента. – М.: BestBusinessBooks, 2013.

(обратно)

Оглавление

Предисловие

Благодарности

Об авторе

Предисловие автора

  История этой книги

  Структура книги

  Содержание книги

  О названии модели

  О подзаголовке книги

Глава 1 Почему все не так просто

  Причинно-следственные связи

  Сложность

  Наше линейное мышление

  Редукционизм

  Идея целостности

  Иерархический менеджмент

  Гибкий менеджмент

  Моя теория всего

  Модель, предлагаемая в этой книге

  Резюме

  Подумать и сделать

Глава 2 Гибкие методологии разработки ПО

  Прелюдия к гибким методологиям

  Евангелие от Agile

  Фундаментальные принципы Agile-методологий

  Методологии, конкурирующие с Agile

  Препятствие на пути Agile-методологий

  Линейный и проектный менеджмент

  Резюме

  Подумать и сделать

Глава 3 Теория сложности

  Важность междисциплинарного подхода

  Общая теория систем

  Кибернетика

  Теория динамических систем

  Теория игр

  Эволюционная теория

  Теория хаоса

  Общая картина наших знаний о поведении систем

  Простота: новая модель

  Еще раз об упрощении

  Адаптивные и неадаптивные системы

  Не злоупотребляем ли мы научным подходом?

  Новая эра: мышление в категориях теории сложности

  Резюме

  Подумать и сделать

Глава 4 Информационно-инновационная система

  Инновации – ключ к выживанию

  Знания

  Креативность

  Мотивация

  Разнообразие

  Личность

  Почему только люди способны управлять сложными системами

  От создания идей к их реализации на практике

  Резюме

  Подумать и сделать

Глава 5 Как добавить людям энергии

  Фазы креативности

  Как создать рабочую среду, способствующую креативности

  Креативные методики

  Внешняя мотивация

  Внутренняя мотивация

  Демотивация

  Десять базовых потребностей членов команды

  Что мотивирует людей: найдите баланс

  Сделайте ваши награды внутренними

  Разнообразие? Вы имеете в виду связи!

  Оценка личности сотрудника

  Четыре этапа при оценке личности членов команды

  Создание командных ценностей: набор инструментов

  Определитесь со своими личными ценностями

  Политика отсутствия дверей

  Резюме

  Подумать и сделать

Глава 6 Базовые принципы самоорганизации

  Самоорганизация в контексте

  Самоорганизация с целью создания ценности

  Самоорганизация в сравнении с анархией

  Самоорганизация и эмерджентность

  Эмерджентность в командах

  Самоорганизация, самонаправление и самоотбор

  Принцип темноты

  Теорема Конанта – Эшби

  Распределенный контроль

  Делегирование прав и полномочий как концепция

  Передача прав и полномочий как необходимость

  Менеджеров можно сравнить с садовниками

  Резюме

  Подумать и сделать

Глава 7 Расширение прав и полномочий команд

  Не создавайте мотивационные долги

  Попробуйте стать волшебником

  Выбирайте волшебников, а не политиков

  Расширение полномочий в сравнении с делегированием

  Уменьшайте свой страх, повышайте свой статус

  Выбирайте правильный уровень зрелости

  Выбирайте правильный уровень полномочий

  Кому передавать полномочия – командам или отдельным сотрудникам

  Чек-лист для делегирования

  Если хотите, чтобы что-то было сделано, наберитесь терпения

  Сопротивляйтесь своему менеджерскому сопротивлению

  Не забывайте про десять внутренних потребностей людей

  Мягко влияйте на рабочую среду

  Доверие

  Уважение

  Резюме

  Подумать и сделать

Глава 8 Осмысленное лидерство и управление

  Игра «Жизнь»

  Классы клеточных автоматов

  Ложная метафора

  Вы не дизайнер игр

  Но… одной самоорганизации недостаточно

  Управляйте системой, а не людьми

  Менеджеры или лидеры?

  Правильнее сравнивать лидеров с правителями

  Смысл жизни

  Предназначение команды

  Постановка внешних целей

  Резюме

  Подумать и сделать

Глава 9 Настройка ограничений

  У людей должна быть общая цель

  Чек-лист для Agile-целей

  Рассказывайте о своей цели

  Видение против миссии

  Примеры организационных целей

  Разрешите своей команде иметь автономную цель

  Достигайте компромисса между вашей целью и целью вашей команды

  Создайте список границ передаваемых полномочий

  Выберите правильный менеджерский угол зрения

  Защищайте людей

  Защищайте ресурсы, находящиеся в общем пользовании

  Требования к качеству

  Заключите общественный договор

  Резюме

  Подумать и сделать

Глава 10 Искусство создавать правила

  Самообучающиеся системы

  Правила в сравнении с ограничениями

  Слепая зона гибких методологий

  Важная тема: профессиональное мастерство

  Положительная обратная связь

  Отрицательная обратная связь

  Дисциплина × умения = компетентность

  Разнообразие правил

  Принцип субсидиарности

  Восприятие рисков и иллюзия безопасности

  Меметика

  Разбитые окна

  Резюме

  Подумать и сделать

Глава 11 Как вырастить компетентность

  Семь методов развития компетенций

  Оптимизируйте систему в целом – на разных уровнях

  Оптимизируйте систему в целом – в разных измерениях

  Советы при выборе операционных показателей

  Четыре ингредиента саморазвития

  Менеджмент, коучинг, менторинг

  Подумайте о сертификации сотрудников

  Используйте силу социального давления

  Используйте адаптируемые инструменты

  Подумайте о супервайзере

  Проводите встречи с глазу на глаз

  Встречи для обсуждения оценок 360°

  Повышайте стандарты

  Управляйте системой, а не правилами или людьми

  Резюме

  Подумать и сделать

Глава 12 Коммуникация в организационных структурах

  Это баг или фича?

  Коммуникация и обратная связь

  Передача искаженной информации – это норма

  Возможности коммуникаторов

  Сетевые эффекты

  Настройка соединения

  Конкуренция и сотрудничество

  Группы и границы

  Гиперпродуктивность, или Автокатализ

  Формирование паттернов

  Симметрия в масштабе: большие и маленькие паттерны

  Как расти: вертикально или горизонтально?

  Резюме

  Подумать и сделать

Глава 13 Как выращивать структуру

  О внешней среде, продуктах, размерах организаций и людях

  Сначала подумайте о специализации…

  … И только потом о генерализации

  Расширьте названия должностей

  Культивируйте неформальное лидерство

  Поддерживайте границы между командами

  Оптимальный размер команды – пять человек (скорее всего)

  Функциональные и кросс-функциональные команды

  Два принципа организационного дизайна

  Выберите свой организационный стиль

  Превратите каждую команду в небольшую бизнес-единицу, создающую ценность

  Создавайте отдельные команды для решения однотипных задач

  Каждый иерархический уровень должен создавать дополнительную ценность

  Сколько нужно менеджеров, чтобы изменить организацию?

  Создавайте гибридные организации

  Анархия мертва, да здравствует панархия

  Не имейте секретов

  Сделайте все заметным

  Связывайте людей

  Стремитесь к адаптивности

  Резюме

  Подумать и сделать

Глава 14 Ландшафт изменений

  Внешняя среда находится вовсе не «где-то там»

  Страх неопределенности

  Законы изменений

  Каждый продукт успешен… пока не потерпит неудачу

  Успех и степень приспособленности: все относительно

  Как адаптироваться к изменениям

  Адаптация, исследование, прогнозирование

  Гонка Черной Королевы

  Можно ли измерить сложность?

  Становятся ли программные продукты более сложными?

  Форма вещей: фазовое пространство

  Аттракторы и конвергенция

  Устойчивость и возмущения

  Адаптивный ландшафт

  Формируем ландшафт

  Направленная и ненаправленная адаптация

  Резюме

  Подумать и сделать

Глава 15 Как улучшить всё

  Линейные улучшения в сравнении с нелинейными

  Определите свое местоположение

  Советы путешествующим по зыбкому ландшафту

  Измените внешнюю среду: пусть гора придет к вам

  Сделайте изменения желанными

  Сделайте застой болезненным

  О пользе ошибок

  Стратегия шума

  Стратегия секса

  Стратегия горизонтального переноса опыта

  Не копируйте улучшения

  Несколько завершающих практических советов по теме непрерывного улучшения

  Продолжайте движение

  Резюме

  Подумать и сделать

Глава 16 Все модели неверны, но некоторые из них полезны

  Шесть компонентов Менеджмента 3.0

  Да, моя модель «неверна»

  Другие модели точно так же «неверны»

  Типичные заблуждения практиков гибких методологий

  Инструкция по управлению сложностью

  Резюме

  Подумать и сделать

Библиография Fueled by Johannes Gensfleisch zur Laden zum Gutenberg