Во-вторых, существует проблема, связанная с копированием организационных диаграмм. Слишком часто компании непреднамеренно уничтожают ответственность за свои действия в подразделениях. Они создают новые разрозненные Agile-команды, которые так же сложно интегрировать, как и обособленные структурные подразделения. Управляющие, которые когда-то чувствовали себя действительно высшими руководителями подразделений, внезапно лишаются возможности достигать компромиссов. Например, финансовые показатели бизнеса некой компании по выпуску кредитных карт значительно ухудшились, когда ключевые рычаги влияния на доходы и расходы были распределены между несколькими различными «племенами» вне влияния руководителя бизнес-единицы. Agile-команды должны поддерживать правильно сформированные бизнес-единицы подразделения, отвечающие за значимые прибыли и убытки. Они не могут обходить или игнорировать эти отделы, не ставя под удар подотчетность.
В-третьих, матричное управление создает неожиданные сложности. Agile-команды это кросс-функциональные команды. Они по определению требуют матричных организаций. На бумаге матрицы могут выглядеть просто. Мы часто обнаруживаем, что занимаемся приведением в порядок компаний, создавших сотни Agile-групп, которые борются за место под солнцем. Кто отвечает за команды и кто может создавать дополнительные? Должны ли существовать отдельные подразделения организации для технологических Agile-команд (иногда называемые продуктовыми командами) и всех других инновационных отделов? Кто их финансирует, как будут приниматься решения, как будут оцениваться и вознаграждаться команды и так далее. Эти детали не видны на организационных схемах. Их легко проглядеть и невозможно скопировать у других.
Но самая серьезная проблема заключается в том, что подражатели не понимают главного принципа успешного применения Agile: готовности постоянно учиться, развиваться, совершенствоваться и расти. Пытаясь пойти напрямик, подражатели не развивают навыки адаптации, настройки и гармонизации всех элементов действующей системы. Agile-переходы это бесконечные путешествия, а не сплошное копирование. Людям нужно время, чтобы создать новую операционную модель и привыкнуть к ней. Трудно точно предсказать, как то или иное изменение повлияет на организацию, поэтому необходимо тестирование, обучение и пошаговое масштабирование.
Методы Agile, как и все другие инструменты управления, имеют свои сильные и слабые стороны. Они не устраняют проблемы. При правильном использовании в соответствующих ситуациях они заменяют потенциально катастрофические проблемы на предпочтительные. Небольшие автономные Agile-команды счастливее, быстрее и успешнее, но они также требуют большей координации и более частых циклов планирования и финансирования. Agile-группы сокращают число иерархических уровней, но меньшее число уровней означает также и меньшее количество изменений в должностях и менее частые повышения. Неспособность предвидеть и решать такие проблемы приводит к путанице и разочарованию членов команды. Лучший подход это не выбирать Agile из всех других подходов к управлению, а научиться, когда, где и как использовать его в сочетании с другими инструментами. Это согласуется с тем, что Аристотель более 2300 лет назад назвал «нахождением золотой середины». Это практический путь к достижению того, что другие называют организациями-амбидекстрами, использующими философию и теорию обстоятельств, а также Теорию Y.
Agile, который работает: дорожная карта книги
В далеком 2001 году, после того как разработчики программного обеспечения в течение примерно десяти лет практиковали так называемые легкие методы разработки, группа из семнадцати человек решила создать более эффективную модель. Они переименовали легкие методы в Agile и вывели простой набор принципов, определяющих этот процесс. Их манифест о разработке программного обеспечения помог сотням тысяч команд принять методы Agile и применить их на практике. Сегодня, когда компании уже около десяти лет имеют дело с Agile в том или ином виде, мы находимся в аналогичной ситуации: теперь у нас достаточно опыта для анализа новых успехов и неудач. Поэтому нам нужно избавиться от пагубных заблуждений и неправильного масштабирования Agile, прежде чем плохой метод вытеснит хороший. Нельзя допустить, чтобы эта мощная философия попала на свалку управленческих маний, как реинжиниринг бизнес-процессов и круги контроля качества. Пришло время внести больше здравомыслия, практичности и равновесия в движение Agile. В этом и заключается цель книги. Мы хотим, чтобы Agile стал ценным и практичным инструментом, а не еще одним разочаровывающим решением высшего руководства. Философия и методы Agile могут сделать людей в организации счастливее и успешнее. Мы хотим, чтобы читатели через пять-десять лет могли оглянуться на свои Agile-переходы с чувством гордости и удовлетворения, а не разочарования и сожаления.
Кому будет полезна эта книга? Мы представляем себе несколько типов читателей. В первую очередь хотим помочь руководителям крупных компаний преодолеть пропасть между их бюрократическим недугом и стремлением к гибкому подходу. Мы подскажем тем, кто только начинает свой путь к Agile, как избежать ошибок и развить установки и привычное поведение Agile. Если компания уже начала внедрение гибких подходов, но терпит неудачи, надеемся помочь ей, пока не поздно, распознать ловушки и избежать их. Мы предполагаем, что члены Agile-команд и работники, сотрудничающие с этими командами, также будут использовать эту книгу для повышения своей эффективности. И, возможно, поделятся ею с некоторыми боссами, враждебно настроенными по отношению к Agile. Стартапы, уже практикующие гибкость, будут использовать эту книгу для создания сбалансированных Agile-предприятий по мере упрочения своего успеха. В каждом из этих случаев наша цель одна: помочь людям выработать Agile-приемы, которые улучшат их результаты и сделают их счастливее.
Для всех читателей мы попытались составить краткий путеводитель. Его смогут осилить даже бизнесмены, которым вечно не хватает времени. Мы составили главы как логичные и устойчивые шаги на пути к созданию Agile-предприятия.
Глава 1. Как работает Agile. Немногие руководители наблюдали Agile-команду в действии. Еще меньше людей активно участвовали в работе такой команды, и почти никто из них не руководил ею. Без практического опыта руководителям трудно понять, что такое Agile. В этой главе мы расскажем историю, демонстрирующую Agile в действии. Мы объясним, откуда взялась эта философия, и опишем элементы, которые делают ее особым и эффективным методом внедрения инноваций.
Глава 2. Масштабирование Agile. Чем больше используете Agile, тем сложнее его применять. Но его использование также может дать исключительные результаты. Некоторые организации масштабируются, просто увеличивая число команд. Другие хотят создать настоящее Agile-предприятие. Такая компания сочетает широкое использование Agile-команд с некоторыми бюрократическими функциями и гармонизирует работу тех и других. Эта глава знакомит читателя с замечательной трансформацией компании Bosch и описывает шаги, которые должна предпринять организация при создании Agile-предприятия.
Глава 3. Какой уровень Agile вам нужен? Больше не всегда лучше. Для каждого бизнеса и для каждого вида деятельности существует оптимальный диапазон Agile. Но как определить этот диапазон? Компаниям следует искать правильный баланс между статичностью и хаосом, и для этого придется идти на необходимые компромиссы. Понадобится новый набор показателей, которые помогут определить, насколько гибкой (Agile) компания хочет стать, движется ли она в правильном направлении и какие ограничения препятствуют дальнейшему прогрессу. В этой главе мы покажем, как решать подобные проблемы с помощью Agile-методов.
Глава 4. Agile лидерство. Как верно подметил член правления Bosch Power Tools Хэнк Беккер, руководить Agile-предприятием не то же самое, что управлять обычной компанией. Agile-руководители тратят меньше времени на анализ работы подчиненных. Они привносят свою ценность, адаптируя корпоративные стратегии, руководя критически важными Agile-подразделениями, проводя время с клиентами, наставляя отдельных людей и тренируя команды. Менять собственное поведение, перестраивать повседневную рутину и развивать новые навыки гораздо сложнее, чем учить этому других. Такая работа и ценится выше. В четвертой главе вы узнаете, как правильно ее выполнять.
Глава 5. Agile планирование, бюджетирование и анализ. Системы планирования, бюджетирования и анализа лежат в основе командно-административного управления. Dell и другие Agile-компании не отменяют эти процессы, они делают их гибкими. Организации проводят все три процесса в виде частых адаптивных циклов, которые в значительной степени зависят от данных, подаваемых по восходящему принципу снизу вверх. Они отдают приоритет стратегическим императивам, приветствуя при этом незапланированные инициативы. Они регулярно сравнивают фактические и ожидаемые результаты, чтобы определить, нуждаются ли планы и бюджеты в изменении.
Глава 6. Agile-организация, структуры и управление людьми. Компании часто поддаются искушению скопировать организационную схему Agile-предприятия, полагая, что новые отделы решат все их проблемы. Но это не работает: чтобы сломать барьеры и иерархии, нужно нечто большее, чем структурные изменения. Agile-предприятиям часто приходится перестраивать все элементы своей операционной модели роли и права на принятие решений, системы найма и управления кадровым потенциалом и т. д. Могут потребоваться и изменения в организационных схемах. Но решение, какие инструменты использовать, в какой последовательности и в какой степени, требует тестирования, обучения, балансировки и настройки, а не копирования.