Всего за 399 руб. Купить полную версию
Во-вторых, существует проблема, связанная с копированием организационных диаграмм. Слишком часто компании непреднамеренно уничтожают ответственность за свои действия в подразделениях. Они создают новые разрозненные Agile-команды, которые так же сложно интегрировать, как и обособленные структурные подразделения. Управляющие, которые когда-то чувствовали себя действительно высшими руководителями подразделений, внезапно лишаются возможности достигать компромиссов. Например, финансовые показатели бизнеса некой компании по выпуску кредитных карт значительно ухудшились, когда ключевые рычаги влияния на доходы и расходы были распределены между несколькими различными «племенами» вне влияния руководителя бизнес-единицы. Agile-команды должны поддерживать правильно сформированные бизнес-единицы подразделения, отвечающие за значимые прибыли и убытки. Они не могут обходить или игнорировать эти отделы, не ставя под удар подотчетность.
В-третьих, матричное управление создает неожиданные сложности. Agile-команды это кросс-функциональные команды. Они по определению требуют матричных организаций. На бумаге матрицы могут выглядеть просто. Мы часто обнаруживаем, что занимаемся приведением в порядок компаний, создавших сотни Agile-групп, которые борются за место под солнцем. Кто отвечает за команды и кто может создавать дополнительные? Должны ли существовать отдельные подразделения организации для технологических Agile-команд (иногда называемые продуктовыми командами) и всех других инновационных отделов? Кто их финансирует, как будут приниматься решения, как будут оцениваться и вознаграждаться команды и так далее. Эти детали не видны на организационных схемах. Их легко проглядеть и невозможно скопировать у других.
Но самая серьезная проблема заключается в том, что подражатели не понимают главного принципа успешного применения Agile: готовности постоянно учиться, развиваться, совершенствоваться и расти. Пытаясь пойти напрямик, подражатели не развивают навыки адаптации, настройки и гармонизации всех элементов действующей системы. Agile-переходы это бесконечные путешествия, а не сплошное копирование. Людям нужно время, чтобы создать новую операционную модель и привыкнуть к ней. Трудно точно предсказать, как то или иное изменение повлияет на организацию, поэтому необходимо тестирование, обучение и пошаговое масштабирование.
Методы Agile, как и все другие инструменты управления, имеют свои сильные и слабые стороны. Они не устраняют проблемы. При правильном использовании в соответствующих ситуациях они заменяют потенциально катастрофические проблемы на предпочтительные. Небольшие автономные Agile-команды счастливее, быстрее и успешнее, но они также требуют большей координации и более частых циклов планирования и финансирования. Agile-группы сокращают число иерархических уровней, но меньшее число уровней означает также и меньшее количество изменений в должностях и менее частые повышения. Неспособность предвидеть и решать такие проблемы приводит к путанице и разочарованию членов команды. Лучший подход это не выбирать Agile из всех других подходов к управлению, а научиться, когда, где и как использовать его в сочетании с другими инструментами. Это согласуется с тем, что Аристотель более 2300 лет назад назвал «нахождением золотой середины». Это практический путь к достижению того, что другие называют организациями-амбидекстрами, использующими философию и теорию обстоятельств, а также Теорию Y.
Agile, который работает: дорожная карта книги
В далеком 2001 году, после того как разработчики программного обеспечения в течение примерно десяти лет практиковали так называемые легкие методы разработки, группа из семнадцати человек решила создать более эффективную модель. Они переименовали легкие методы в Agile и вывели простой набор принципов, определяющих этот процесс. Их манифест о разработке программного обеспечения помог сотням тысяч команд принять методы Agile и применить их на практике. Сегодня, когда компании уже около десяти лет имеют дело с Agile в том или ином виде, мы находимся в аналогичной ситуации: теперь у нас достаточно опыта для анализа новых успехов и неудач. Поэтому нам нужно избавиться от пагубных заблуждений и неправильного масштабирования Agile, прежде чем плохой метод вытеснит хороший. Нельзя допустить, чтобы эта мощная философия попала на свалку управленческих маний, как реинжиниринг бизнес-процессов и круги контроля качества. Пришло время внести больше здравомыслия, практичности и равновесия в движение Agile. В этом и заключается цель книги. Мы хотим, чтобы Agile стал ценным и практичным инструментом, а не еще одним разочаровывающим решением высшего руководства. Философия и методы Agile могут сделать людей в организации счастливее и успешнее. Мы хотим, чтобы читатели через пять-десять лет могли оглянуться на свои Agile-переходы с чувством гордости и удовлетворения, а не разочарования и сожаления.