Проще говоря, задача состоит не в том, чтобы повсюду заменить бюрократию на Agile, а в том, чтобы найти баланс между этими подходами. Организации должны руководить процессами, хорошо ведя операционную деятельность. Им необходимо менять бизнес, постоянно внедряя не только новые продукты и услуги или инновации, но и новые методы и процедуры работы. Хотя подобные задачи требуют различных навыков, они не противоречат друг другу. Скорее представляют собой взаимодополняющие, взаимозависимые, взаимовыгодные возможности, которые нуждаются друг в друге, чтобы выжить. Недостаточное внимание к инновациям формирует статичное предприятие, не способное адаптироваться к изменяющимся условиям. Подобное отношение к операционной деятельности создает хаос низкое качество, высокие затраты и опасные риски для клиентов и бизнеса.
Большинство крупных компаний сегодня сделали выбор в пользу бюрократии и нуждаются в инновациях. Они создали неподвижные организации, нацеленные на достижение предсказуемых результатов. Вот почему Agile так популярен. Но решение не в том, чтобы до упора склонить чашу весов в другую сторону. Скорее, оно заключается в том, чтобы следовать бюрократическим правилам и соблюдать иерархию там, где это уместно. Например, делая старые инструменты управления более удобными для людей и в то же время используя гибкие методы там, где это необходимо. Подобная схема может показаться простой, но это не так. Agile и бюрократия подобны маслу и уксусу: они хороши в смеси, но их нелегко смешать. Быстрее получится смесь азотной кислоты и глицерина, что может привести к взрыву.
Agile-команды добиваются успеха, быстро выполняя работу. Они претворяют в жизнь новые идеи, часто еще до того, как те полностью сформулированы, и тестируют их с потенциальными клиентами. Они не уважают бюрократию и не следуют детализированным планам. Чтобы такие команды добились успеха в организации, им нужно много свободы и поддержки. Бюрократия им, разумеется, прямо противоположна: она успешно существует только при жестком контроле. Бюрократы хотят точно знать, что уже сделала группа, что она планирует сделать в течение следующих двенадцати месяцев и сколько все это будет стоить. Для традиционной бюрократии Agile-команды могут казаться инородными телами, заражающими организм. Формалисты часто видят свою работу в том, чтобы, подобно Т-клеткам в иммунной системе, устранить инфекцию или, по крайней мере, ограничить наносимый ею вред.
На настоящем Agile-предприятии бюрократия и инновации становятся партнерами. Они создают систему, в которой улучшаются оба компонента и в которой представители того и другого лагеря сотрудничают, чтобы добиться превосходных результатов. Чуть позже мы покажем, как гармонизировать эти два компонента.
А сейчас займемся Agile
Фредерик Уинслоу Тейлор утверждал, что смог превратить бюрократическое управление из искусства в науку. Его исследования с секундомером считаются классикой в летописях бизнеса. В своей книге «Принципы научного менеджмента» 1911 года он изложил четыре фундаментальных принципа:
1. Менеджеры планируют работу, а рабочие ее выполняют;
2. Менеджеры проводят научный анализ наиболее эффективных способов выполнения работы;
3. Менеджеры проводят научный отбор и обучение правильных работников правильным видам работ;
4. Менеджеры строго контролируют выполнение работниками поставленных задач.
[4]
В то время методы Тейлора подвергались жесткой критике за то, что он относился к людям, как к машинам. Но его подход прижился и пережил своего создателя. Даже сегодня во многих компаниях есть менеджеры и руководители, которые в душе являются тейлористами. А когда тейлористы пытаются внедрить Agile, это беда.
Часто получается так: высшее руководство планирует Agile-трансформацию своих подчиненных, а не самих себя. Компания создает проектный офис для управления программой с высокими полномочиями по принятию решений. Этот отдел составляет подробные бюджеты, определяет вехи и дорожные карты по выполнению проекта, дополненные диаграммами Ганта и строгими системами отчетности, чтобы обеспечить выполнение планов. Департамент создает массу Agile-команд, обычно возглавляемых тейлористами, только что прошедшими двухдневную подготовку по Agile. Если какая-то из команд добивается успеха, пусть и незначительного, проектный офис громко оповещает об этом в надежде убедить как внутреннюю, так и внешнюю аудиторию, что программа работает по плану. Тем временем само руководство продолжает действовать как раньше, контролируя все процессы и занимаясь микроменеджментом своих подчиненных, в число которых теперь входят члены Agile-команд. Эти управленцы часто указывают командам не только что делать, но и как это делать. В конце концов, разве не в этом заключается работа начальника?
Однако Agile погибает, если им управляют сверху, применяя микроменеджмент. Все его положения о самоуправлении, тестировании, обучении и т. д. начинают звучать фальшиво. Так или иначе, инструменты директивного управления по принципу «сверху вниз» не работают в среде Agile. Сравнительные анализы оказываются бесполезными вне их уникального контекста. Прогнозы людей все чаще становятся ошибочными, потому что руководители неспособны распознать или приспособиться к непредсказуемой динамике системы. Для диагностики здоровой среды Agile-программ в организации мы используем инструмент, называемый коэффициентом гибкости Бейна. При тейлористском подходе руководители и члены команды по-разному воспринимают ситуацию. Топ-менеджеры описывают Agile-инициативы компании как успешные и удовлетворительные. Члены Agile-команд, которые ближе к фронту работ, считают результаты программы разочаровывающими и обескураживающими. Они мало чем отличаются от результатов традиционных целевых рабочих групп. Сначала мы предполагали, что руководители лгут, но вскоре поняли, что они просто не в курсе. Они настолько далеки от использования Agile, что знают только то, что им говорят подчиненные. А те, в свою очередь, говорят только то, что руководители хотят услышать.
Справедливости ради надо признать, что некоторые Agile-команды добиваются успеха даже на тейлористских предприятиях. Они скрывают свои действия от начальства и преуспевают скорее вопреки руководству, чем благодаря ему. Но настоящее Agile-изменение требует активного участия и поддержки главных лиц компании. Топ-менеджеры, которые действительно хотят масштабной Agile-трансформации, добиваются лучших результатов, если сами показывают, что надо делать, а не отправляют подчиненных на обучающие семинары. Они должны понимать Agile, любить его и использовать его методы в собственных командах. Есть известное высказывание Ганди: «Если хочешь изменить мир, изменись сам». Это справедливо и в отношении Agile.
Agile в качестве быстрого решения
Некоторые организации, столкнувшись с серьезными стратегическими угрозами и нуждаясь в радикальных переменах, проводят в некоторых подразделениях масштабные Agile-преобразования одним махом. Например, в 2015 году компания ING Netherlands[6] ожидала роста потребительского спроса на программное обеспечение и активное вторжение новых цифровых конкурентов в область цифровых технологий. Руководство решило действовать агрессивно. Были распущены организационные структуры, в том числе занимающиеся развитием IT, управлением продуктами, каналами распространения и маркетингом. По сути, их работа была упразднена. Затем создали небольшие «Agile-отряды» и от 3,5 тысяч сотрудников потребовали заявки на 2,5 тысячи измененных должностей. Около 40 % людей, вступающих в эти должности, были обязаны освоить новую работу. Всем требовалось серьезно преобразовать свое мышление.
[5]
Опыт показывает, что с таким подходом связано множество проблем. Он сбивает с толку и травмирует организацию. Люди не знают, куда двигаться и что делать. Этот подход предполагает, что тысячи людей, большинство из которых не имеют знаний об Agile, внезапно его поймут и будут работать в соответствии с новыми принципами. Хотя радикально настроенные «новообращенные» демонстрировали успехи, общие результаты часто не соответствовали нереалистичным обещаниям. Цены на акции, включая акции ING, часто падали, иногда на 30 % и больше. За закрытыми дверями директора и их подчиненные дают более взвешенные оценки, которые обычно звучат примерно так: «Наши руководители и наша культура не были готовы к таким радикальным изменениям. Чем больше мы повторяли общепринятые клише «сорвать пластырь» и «сжечь корабли», тем больше мы в них верили. Но ни один из наших старших руководителей никогда не работал в Agile-среде. Мы не готовились к непредвиденным последствиям. Хуже того, мы потеряли нескольких прекрасных людей, которых заклеймили как препятствующих инновациям за попытку указать на эти последствия. Наш подход к гибкости был не очень гибким».
Более распространенный «инновационный» инструмент бюрократа это копирование других. Конечно, для такого явления существуют и привлекательные названия: бенчмаркинг, конкурентная разведка или быстрый последователь. Но в конечном счете все сводится к повторению. Любимый объект подражания компания Spotify, хорошо известная своим оригинальным Agile-лексиконом: отрядами, племенами, гильдиями и т. п. Иногда оказывается, что компании имитируют друг друга.
Такая практика соблазнительна. Пионеры, как Spotify, потратили годы на изучение и применение принципов Agile. Почему бы не повторить этот успех за шесть месяцев? Особенно заманчиво звучит идея, что все, что вам нужно сделать, это скопировать организационную структуру и дизайн офиса первопроходца Agile. Если вы поменяете местами прямоугольники и их положение в организационной структуре, вы наверняка измените подход людей к работе. Постепенно подобные шаги приведут к новым итогам и результатам. Но что может пойти не так?
Что ж, давайте посмотрим. Во-первых, группы людей, как и человеческий организм, это сложные системы, а значит, в разных средах переменные взаимодействуют по-разному. Лекарства, которые помогают одним пациентам, могут оказаться вредными для людей с другой генетикой, полом, возрастом или рационом. Менеджеры, пытающиеся внедрить структуры инновационных отделов одной компании в рамках совершенно другой организации, неизбежно получают плачевные результаты. Компания Spotify обладает достаточным опытом, чтобы на ее примере это понять. Она разработала инженерную модель в соответствии со своей уникальной культурой, извлекая выгоду из доверия и сотрудничества двух ее главных ценностей. Технологические группы Spotify из-за их модульных продуктов и технологической архитектуры имеют меньше взаимозависимостей, чем подобные команды в большинстве организаций. Так что потенциальные подражатели, имеющие линейки продуктов, требующие тесной координации взаимозависимостей, часто получают «племенные» структуры, создающие хаос. Сотрудники Spotify постоянно предупреждают, что технологическая модель их компании непрерывно развивается и ее не следует копировать другим организациям или даже другим подразделениям внутри Spotify. Тем не менее, подражание продолжается.
Во-вторых, существует проблема, связанная с копированием организационных диаграмм. Слишком часто компании непреднамеренно уничтожают ответственность за свои действия в подразделениях. Они создают новые разрозненные Agile-команды, которые так же сложно интегрировать, как и обособленные структурные подразделения. Управляющие, которые когда-то чувствовали себя действительно высшими руководителями подразделений, внезапно лишаются возможности достигать компромиссов. Например, финансовые показатели бизнеса некой компании по выпуску кредитных карт значительно ухудшились, когда ключевые рычаги влияния на доходы и расходы были распределены между несколькими различными «племенами» вне влияния руководителя бизнес-единицы. Agile-команды должны поддерживать правильно сформированные бизнес-единицы подразделения, отвечающие за значимые прибыли и убытки. Они не могут обходить или игнорировать эти отделы, не ставя под удар подотчетность.
В-третьих, матричное управление создает неожиданные сложности. Agile-команды это кросс-функциональные команды. Они по определению требуют матричных организаций. На бумаге матрицы могут выглядеть просто. Мы часто обнаруживаем, что занимаемся приведением в порядок компаний, создавших сотни Agile-групп, которые борются за место под солнцем. Кто отвечает за команды и кто может создавать дополнительные? Должны ли существовать отдельные подразделения организации для технологических Agile-команд (иногда называемые продуктовыми командами) и всех других инновационных отделов? Кто их финансирует, как будут приниматься решения, как будут оцениваться и вознаграждаться команды и так далее. Эти детали не видны на организационных схемах. Их легко проглядеть и невозможно скопировать у других.
Но самая серьезная проблема заключается в том, что подражатели не понимают главного принципа успешного применения Agile: готовности постоянно учиться, развиваться, совершенствоваться и расти. Пытаясь пойти напрямик, подражатели не развивают навыки адаптации, настройки и гармонизации всех элементов действующей системы. Agile-переходы это бесконечные путешествия, а не сплошное копирование. Людям нужно время, чтобы создать новую операционную модель и привыкнуть к ней. Трудно точно предсказать, как то или иное изменение повлияет на организацию, поэтому необходимо тестирование, обучение и пошаговое масштабирование.
Методы Agile, как и все другие инструменты управления, имеют свои сильные и слабые стороны. Они не устраняют проблемы. При правильном использовании в соответствующих ситуациях они заменяют потенциально катастрофические проблемы на предпочтительные. Небольшие автономные Agile-команды счастливее, быстрее и успешнее, но они также требуют большей координации и более частых циклов планирования и финансирования. Agile-группы сокращают число иерархических уровней, но меньшее число уровней означает также и меньшее количество изменений в должностях и менее частые повышения. Неспособность предвидеть и решать такие проблемы приводит к путанице и разочарованию членов команды. Лучший подход это не выбирать Agile из всех других подходов к управлению, а научиться, когда, где и как использовать его в сочетании с другими инструментами. Это согласуется с тем, что Аристотель более 2300 лет назад назвал «нахождением золотой середины». Это практический путь к достижению того, что другие называют организациями-амбидекстрами, использующими философию и теорию обстоятельств, а также Теорию Y.
Agile, который работает: дорожная карта книги
В далеком 2001 году, после того как разработчики программного обеспечения в течение примерно десяти лет практиковали так называемые легкие методы разработки, группа из семнадцати человек решила создать более эффективную модель. Они переименовали легкие методы в Agile и вывели простой набор принципов, определяющих этот процесс. Их манифест о разработке программного обеспечения помог сотням тысяч команд принять методы Agile и применить их на практике. Сегодня, когда компании уже около десяти лет имеют дело с Agile в том или ином виде, мы находимся в аналогичной ситуации: теперь у нас достаточно опыта для анализа новых успехов и неудач. Поэтому нам нужно избавиться от пагубных заблуждений и неправильного масштабирования Agile, прежде чем плохой метод вытеснит хороший. Нельзя допустить, чтобы эта мощная философия попала на свалку управленческих маний, как реинжиниринг бизнес-процессов и круги контроля качества. Пришло время внести больше здравомыслия, практичности и равновесия в движение Agile. В этом и заключается цель книги. Мы хотим, чтобы Agile стал ценным и практичным инструментом, а не еще одним разочаровывающим решением высшего руководства. Философия и методы Agile могут сделать людей в организации счастливее и успешнее. Мы хотим, чтобы читатели через пять-десять лет могли оглянуться на свои Agile-переходы с чувством гордости и удовлетворения, а не разочарования и сожаления.