Читать книгу Agile, который работает. Как правильно трансформировать бизнес во времена радикальных перемен - Даррелл Ригби - Страница 7

Некоторые организации, столкнувшись с серьезными стратегическими угрозами и нуждаясь в радикальных переменах, проводят в некоторых подразделениях масштабные 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.