Agile-менеджмент. Лидерство и управление командами
Все права защищены. Данная электронная книга предназначена исключительно для частного использования в личных (некоммерческих) целях. Электронная книга, ее части, фрагменты и элементы, включая текст, изображения и иное, не подлежат копированию и любому другому использованию без разрешения правообладателя. В частности, запрещено такое использование, в результате которого электронная книга, ее часть, фрагмент или элемент станут доступными ограниченному или неопределенному кругу лиц, в том числе посредством сети интернет, независимо от того, будет предоставляться доступ за плату или безвозмездно.
Копирование, воспроизведение и иное использование электронной книги, ее частей, фрагментов и элементов, выходящее за пределы частного использования в личных (некоммерческих) целях, без согласия правообладателя является незаконным и влечет уголовную, административную и гражданскую ответственность.
Посвящается Раулю.
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, одном из крупнейших поставщиков решений для электронной коммерции в Нидерландах. В качестве менеджера Юрген возглавлял группы разработчиков программного обеспечения, проектных менеджеров, менеджеров по качеству и сервису, некоторых из которых он нанял случайно.
Среди его основных интересов — разработка программного обеспечения и теория сложности с точки зрения менеджера. В качестве автора он публиковал аналитические работы и статьи во многих журналах, а также ведет блог на сайте http://noop.nl. Его часто приглашают выступать на семинарах и конференциях.
И последнее (не по важности) его достижение: Юрген проводит обучающие семинары на основе модели Менеджмента 3.0, где рассматриваются темы развития инициативы, расширения полномочий и возможностей команд, оптимизации ограничений, развития компетенций, развития организационных структур и улучшения всего.
Тем не менее иногда он откладывает в сторону написание статей, выступления и проведение тренингов и сам занимается программированием; дома он проводит время, сортируя свою коллекцию книг по научной фантастике и фэнтези: он складывает их в шкаф высотой четыре метра, который сам и сконструировал.
Вместе со своим партнером Раулем Юрген живет в Роттердаме (Нидерланды) — и иногда в Брюсселе (Бельгия). У него двое детей, а также есть воображаемый хомяк, которого зовут Джордж.
Предисловие автора
Это книга о гибком, или Agile-менеджменте — управленческом аналоге гибких методологий разработки ПО. Я считаю, что гибкий менеджмент недостаточно представлен в мире, который требует гибких подходов. Существуют десятки книг по Agile-методологиям для разработчиков, тестировщиков, коучей и проектных менеджеров, но практически нет книг по этой тематике для Agile-менеджеров и лидеров команд. Но, если организации хотят внедрить Agile-практики, абсолютно необходимо, чтобы лидеры команд и другие руководители знали лучший подход для управления и лидерства в их командах.
Исследования показывают, что при переходе к гибким методам основным препятствием оказывается традиционный менеджмент [VersionOne 2009]. Командам разработчиков ПО тяжело внедрять такие процессы, как Scrum, XP или канбан, если их «лидеров» заклинило на устаревших управленческих подходах. Менеджерам необходимо понять, в чем заключается их новая роль в XXI веке и как добиваться от команд разработчиков максимальных результатов. Данная книга предназначена для менеджеров, которые хотят перейти на гибкие методы управления в своих компаниях, и на разработчиков, которые уже используют эти методы при создании ПО, но хотят больше узнать о менеджменте в целом.
Эта книга по менеджменту уникальна, поскольку целиком основана на научном подходе и теории сложности. В отличие от других книг по общему менеджменту, она не призывает вас открыть свое сердце, взяться за руки и повторять мантры. Многие менеджеры, особенно в высокотехнологичных компаниях, предпочитают пользоваться левым полушарием мозга, полагаясь на рациональное, аналитическое начало. Поэтому я написал книгу, апеллирующую к таким людям. Но и тем, кто предпочитает пользоваться правым полушарием, нечего опасаться. Научные идеи представлены достаточно неформально, с подробными объяснениями и обилием метафор и иллюстраций. Здесь даже можно найти как минимум пару действительно смешных шуток.
Одной из моих важнейших целей при написании этой книги было придерживаться описательного подхода, а ни в коем случае не нормативного. Цель — дать вам понять, как работают организация и Agile-команды для того, чтобы вы могли решить собственные проблемы. Мир слишком сложен, чтобы можно было отделаться списком практик, которым необходимо следовать. Что действительно необходимо менеджерам в XXI веке, так это понимание общих подходов, используя которые, они смогут создать свои собственные рецепты, соответствующие их конкретным потребностям [Mintzberg 2004: 252].
История этой книги
Мне потребовалось десять лет, чтобы написать эту книгу. В свое время я заинтересовался гибкими методологиями разработки ПО и теорией сложности (не помню, в какой последовательности), и в течение первых пяти лет авторы, пишущие об этих двух предметах, едва поспевали за моим интересом. При чтении разных книг у меня постепенно начала складываться общая картина. Я понял, что гибкие методы создания ПО — это практическое приложение теории сложности и команды разработчиков ПО и соответствующие проекты выступают в качестве примера таких систем. Также стало ясно, что практически никто не видит эту связь между теорией и практикой (заметными исключениями стали Джим Хайсмит и Кен Швабер). В результате примерно в 2005 году я попытался написать собственную книгу на эту тему. Но в тот момент ничего не получилось. У меня был в руках текст, но отсутствовали читатели. Были новые идеи, но не было обратной связи. Обилие теорий и минимум опыта. Я был преисполнен энтузиазма, но мне не хватило терпения.
Параллельно все эти десять лет я занимался управлением проектами по разработке ПО и приобрел обширный опыт, узнал о множестве способов неправильного управления проектами. Будучи руководителем и внедряя гибкие методологии разработки, я размышлял о роли менеджмента в этом процессе. Я был уверен, что менеджерам и лидерам команд должна отводиться важная роль. Но в книгах ничего не говорилось о том, в чем конкретно она должна состоять.
В январе 2008 года я запустил свой блог на http://noop.nl с целью получить обратную связь от читателей относительно моих идей в области разработки ПО, менеджмента и сложных систем, а также понять, интересна ли эта тематика вообще кому-нибудь. Через полтора года у меня было 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. Иногда в книге попадаются серые вставки с вопросами или замечаниями и ответами на них. Большинство этих вопросов задавались читателями моего блога и рецензентами первых версий книги. Я также использую много ссылок на сайт «Википедии». Некоторые считают, что ссылаться на «Википедию» — порочная практика, но я с этим не согласен. Я предпочитаю ссылки на живой ресурс, над которым постоянно ведется работа по улучшению, чем на ветки потенциально мертвого дерева.
Предвидя обвинения в излишнем теоретизировании, я сделал так, что в сумме объем практических глав превышает объем тех, что отданы теории. Более того, в конце каждой главы есть раздел «Подумать и сделать», что делает книгу еще более полезной с практической точки зрения.
Часто говорят, что применение метафор улучшает понимание абстрактных понятий — именно поэтому я так часто ими пользуюсь. В этой книге вы найдете сравнения менеджеров с садовниками, волшебниками, регулировщиками дорожного движения и другими интересными людьми. Вначале я подумывал назвать эту книгу «Абстрактный садовник». Но в конечном итоге решил использовать другое название, потому что любая метафора имеет свойство изнашиваться, если ей пользоваться часто и для описания разных явлений. Поэтому теперь при необходимости я стараюсь подобрать отдельную метафору для каждого случая.
У этой книги есть сопутствующий сайт https://www.management30.com. На нем вы найдете дополнительные материалы, не вошедшие в книгу, первоначальные версии иллюстраций (разрешается их похитить и использовать для своих целей), материалы, присланные читателями, и ссылки на другие ресурсы, посвященные гибким методологиям, разработке ПО и теории сложности.
О названии модели
«Менеджмент 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 и других замечательных достижениях социальных групп, которым удалось сформировать общую цель и в результате многого добиться. Они полагают, что «самоорганизующиеся» группы вообще не нуждаются в менеджерах, только в лидерах, обладающих видением.
К сожалению, данная точка зрения игнорирует тот факт, что ни в одном из таких примеров речь не идет о бизнесе. Если никто не будет владельцем активов организации, то никто и не нужен, чтобы управлять ими. Акционеры вряд ли оценят, если в результате самоорганизации их биотехнологическая компания будет трансформирована в кейтеринговый бизнес. Не стоит принимать во внимание и мнение сотрудников о том, нужны им менеджеры или нет. Менеджеры необходимы акционерам для того, чтобы управлять их бизнесом. Самоорганизация сама по себе лишена ценности. Требуется кто-то заинтересованный в результате, кто и будет решать, «хороши» или «плохи» результаты самоорганизации.
Увы, некоторые считают, что иерархия — это всегда «плохо», а самоорганизация — всегда «хорошо». Я называю их жрецами (и жрицами), потому что они проповедуют свою веру в то, что считают «хорошим», хотя (как показано в этой книге) никаких научных оснований для этой веры нет.
Прагматики
Когда речь идет о менеджменте и лидерстве, реальность требует от нас оставаться прагматиками. Любой бизнес нуждается в менеджменте от лица акционеров. Да, у менеджеров должны быть лидерские качества. Но многие лидерские роли могут исполняться самоорганизующимися людьми (не занимающими менеджерских должностей), находящимися на самых разных позициях в компании. Эти неформальные лидеры должны понимать, что направление, в котором происходит самоорганизация, необходимо немного корректировать и что делается это акционерами через распределение полномочий среди менеджеров.
Если вы похожи на меня, то вы не принц и не жрец, вы — один из простолюдинов. Я буду называть нас прагматиками. Мы понимаем, что управленческая иерархия — это базовая необходимость (и нечем тут хвастаться) и что основная часть работы совершается внутри социально-сетевой структуры, состоящей из равных: лидеров и последователей. Коммуникация осуществляется через сети, а полномочия — через иерархию.
Я написал эту книгу для прагматиков.
Почему все не так просто
Всякая сложная проблема имеет решение — простое, удобное и ошибочное.
Однажды мне удалось некоторое время побыть миллионером — по крайней мере на бумаге. Частные инвесторы оценили мой стартап в интернете в 10 миллионов евро, при этом мне принадлежало 70% финансовой фикции, которую им удалось создать вокруг моего проекта. Мне даже присудили титул предпринимателя года, поскольку я очень хорошо передал свое видение проекта. А созданные мной цветные графики, показывающие ожидаемые доходы и расходы, выглядели просто сказочно — опять же на бумаге.
Несмотря на все это, деньги, которые мы с инвесторами вложили в проект, не привели к росту прибыли. Создание дополнительного контента не привело к увеличению посещаемости нашего сайта. Мы наняли больше программистов, но это не сказалось каким-либо существенным образом на скорости разработки. Договоренности, которые у нас были с другими сайтами, не привели к росту доходов. Доходы оказались даже ниже, чем перед первым раундом инвестиций. Уверен, что вам незнакомо название нашего не слишком известного сайта. Все попытки раскрутить его позорно провалились. А когда лопнул пузырь доткомов, это вообще поставило жирный крест на всем проекте — так же, как и на множестве других, которыми были заняты все вокруг нас.
И тем не менее сам процесс был весьма увлекательным. Мы многому научились. О, как многому мы научились! Если правда, что лучше всего учишься на собственных ошибках, то к настоящему моменту я должен был быть просто всеведущим божеством. В качестве менеджера, руководившего процессом разработки, лидера команды, менеджера проекта и просто разработчика программного обеспечения я совершил столько ошибок, что мне до сих пор кажется странным, что вместе со своим проектом я не обрушил весь интернет. Но мы действительно в результате очень многому научились.
При написании этой книги меня поддерживала надежда, что и вы многому научитесь на моих ошибках и ошибках тех, кто совершал их до меня. За последние десять лет я понял, что при разработке программного обеспечения оптимальные результаты дают именно Agile-методологии (см. главу 2 «Гибкие методологии разработки ПО»). Я также убедился, что серьезнейшее препятствие на пути принятия Agile-методологий во всем мире — это традиционный менеджмент. Я исхожу из представления, что вы либо руководитель, либо просто интересуетесь менеджментом. Возможно, вы разработчик, технический директор, глава проектной группы или тестировщик. На данный момент это не имеет особого значения. Важно то, что вы хотите больше узнать о мен…