ием проектами для предоставления заранее определенных функций. Последнее перекликается с определениями других Agile-подходов. Однако следует отметить два существенных отличия. Во-первых, в то время как Agile использует один и тот же подход во всех видах инновационной деятельности, управление продуктами концентрируется на товарах, основанных на технологиях. Во-вторых, сторонники управления продуктами утверждают, и довольно убедительно, что владельцы продуктов многих Agile-команд просто управляют бэклогами и не действуют, как настоящие руководители. Они не несут полной ответственности за результаты разрабатываемых ими продуктов. Они не понимают всего контекста рынка, истинных потребностей клиентов, позиций конкурентов или финансовых последствий сложных компромиссов. Они не создают постоянные команды для разработки и развития прибыльных решений.[8]
Эти различия кажутся довольно незначительными, но на деле могут оказаться полезны для Agile. Но они также могут породить огромное количество недоразумений, конфликтов и неэффективности. Некоторые активисты утверждают, что все команды управления продуктами должны быть постоянными и что группа никогда не должна создавать временные ячейки для решения срочных проблем. Некоторые организации добавляют новый уровень стратегических менеджеров для надзора за владельцами продуктов, вместо того чтобы разъяснить и усовершенствовать работу последних. Фанатики иногда утверждают, что команды по управлению продуктами предназначены только для инициатив, связанных с технологиями, навязывая названия должностей, словари и учебные программы для технологических инноваций. Как показывает наш опыт, гармонизация гибких методов и методов управления продуктами для разработки единых подходов, которые могут быть адаптированы к культуре компании и приняты по всему предприятию, дает лучшие результаты, чем поощрение состязательных споров.
В основе создания экономически эффективных решений, которые оценят клиенты, лежат хорошо отлаженные процессы и технологии. Более того, инновации, доступные для автоматизации и улучшения процессов, например, роботизированная автоматизация процессов и машинное обучение развиваются ускоренными темпами. Но внедрение этих технологий во многих организациях идет медленно. Методы, описанные в этой главе, должны помочь компаниям преодолеть эти барьеры.
1. Agile предназначен для инноваций, это нечто большее, чем создание новых продуктов и услуг для клиентов. Эти методы одинаково хорошо зарекомендовали себя как для улучшения бизнес-процессов, производящих товары и услуги, так и для совершенствования технологий, обеспечивающих эти бизнес-процессы.
2. Поскольку надежность и эффективность так важны для бизнес-процессов и технологий, бюрократия делает все возможное, чтобы свести к минимуму восприимчивость и изменения. Agile-подходы также поддерживают строгое соблюдение стандартных операционных процедур, но регулярно внедряют инновации для их улучшения. Они помогают следить за тем, чтобы новые процедуры были приняты, включены в обучение и должным образом выполнялись.
3. Постоянные, кросс-функциональные Agile-команды – это лучший способ совершенствовать бизнес-процессы и технологии. По мере того как группы приобретают опыт и доверие операционных подразделений, их возможности в области разработки увеличиваются, а темпы внедрения растут.
4. Agile-команды, работающие над бизнес-процессами и технологиями, так же одержимы удовлетворением потребностей клиентов, как и те, кто разрабатывает продукты и услуги для потребителей. Иногда их инновации напрямую улучшают покупательский опыт. В других случаях их клиентами становятся внутренние сотрудники, чья производительность критически важна для улучшения клиентского опыта.
5. Во многих компаниях есть большое количество технологических Agile-команд, но мало где есть технологические Agile-организации. Одна из причин – отклонения от лучших практик, мешающие любой Agile-команде, а также другие, специфичные для программного обеспечения проблемы. Их преодоление предполагает создание более модульной архитектуры, помогающей инженерам стать многосторонними, и разрушение функциональных барьеров внутри и за пределами IT-отделов.
Глава 8Agile, который работает
Когда мы решили написать эту книгу, мы спросили себя, что, по нашему мнению, читатели будут делать после ее прочтения. Какую проблему клиентов мы пытались решить? В конце концов, в открытом доступе есть бесчисленное множество книг, статей и блогов по Agile. Зачем миру может понадобиться еще одна?
Ответ был простым. Мы действительно хотим, чтобы Agile стал ценным и практичным инструментом, а не очередным разочаровывающим увлечением. Мы считаем, что новое мышление и новые методы могут сделать людей в организации счастливее и успешнее. Мы хотим, чтобы читатели через пять-десять лет могли оглянуться на свои Agile-переходы с чувством гордости и удовлетворения, а не разочарования и сожаления. Мы обеспокоены тем, что неправильное использование Agile бросит тень на всю идею целиком. Если фанатики будут пытаться исправить один вид дисбаланса, полностью перейдя к его противоположности, или если авторитарные руководители будут использовать гибкость как еще одну дубинку, чтобы заставить людей подчиняться приказам быстрее, чем раньше, Agile вскоре присоединится к кружкам контроля качества и реинжинирингу бизнес-процессов на упомянутой выше свалке управленческих маний.
А это действительно свалка. За последние двадцать семь лет наша фирма собрала откровенные отзывы почти пятнадцати тысяч руководителей в более чем семидесяти странах. Мы пытались узнать правду о всевозможных инструментах управления. Это самая большая в мире собранная за самый продолжительный период база данных по этому вопросу. Она позволила нам отследить популярность и эффективность множества этих инструментов с течением времени. Мы наблюдали, как такие методы, как управление знаниями, контроль качества, реинжиниринг бизнес-процессов и Lean Six Sigma, внезапно стали популярными, а затем вышли из моды. Чаще всего это происходило, когда они были разрекламированы и ошибочно применялись к проблемам, для решения которых никогда не предназначались. Потребление растет быстрее, чем удовлетворенность, как в той старой рекламе сигарет, когда людей спрашивали: «Правда ли, что вы курите больше, но получаете от этого меньше удовольствия?» В конце концов, менеджеры понимают, что новое увлечение – это не панацея, ведь оно фактически заставило их пренебречь другими аспектами бизнеса. Аналитики начинают высмеивать тех, кто наивно поддался тренду. И тогда популярность инструмента быстро идет на спад.
Стремление компании Bain[14] узнавать правду об инструментах оказалось полезным для Agile. Результаты исследований, перечисленные в Приложении С, подтверждают, что Agile – это не причуда. Наш собственный опыт работы с клиентами тоже это доказывает. Мы и наши коллеги основали Agile Enterprise Exchange, чтобы делиться с руководителями высшего звена правдивой информацией о своем опыте. Действуя в соответствии с правилом Chatham House[15], группа из более чем сорока руководителей высшего звена из широкого спектра отраслей, регионов и бизнес-функций согласилась регулярно встречаться, общаться друг с другом и открыто делиться информацией о своих успехах и проблемах. Это помогает Agile стать ценным и устойчивым инструментом. Эта глава в значительной степени основана на коллективном опыте, и мы благодарны членам группы, которые щедро помогают друг другу и всем желающим правильно использовать Agile.
Некоторые из рекомендаций, как, например, отказ от следования моде – для правильного использования Agile – просты и очевидны, и мы их неоднократно упоминали. Применение Agile не должно вызывать страха. Вопреки распространенному мнению, люди боятся не перемен. Большинство из нас любят отпуска, качественные косметические средства, новые фильмы и т. д. Мы боимся потерь. По словам психолога Дэниела Канемана, страх потери в два раза сильнее надежды на выигрыш. Agile-переход не должен провоцировать страх потерять контроль над операциями, растерять функциональный опыт или отказаться от существующих способов работы, прежде чем люди узнают, что новые методы лучше. Вы можете победить страх с помощью подлинного сотрудничества и итеративного прототипирования, тестирования и адаптации предлагаемых изменений в реальных условиях.
Помните также, что Agile – это инструмент, а не стратегия. Бензопила – замечательный инструмент для удаления упавших деревьев с линий электропередач или заготовки пиломатериалов для строительства дома. Но ни одной компании не нужна стратегия бензопилы или директор по бензопилению. И бензопила не лучший инструмент для нарезки помидоров или выполнения операции на сердце. Правильное использование Agile означает его точечное внедрение как инструмента для реализации стратегии повышения эффективности бизнеса, то есть только там, где это уместно. Майкл Портер был прав, когда говорил, что суть стратегии заключается в выборе того, чего не следует делать. Мы также склоны думать, что правильное использование Agile означает выбирать те места, где его не стоит использовать.
Гибкие методы предназначены для разработки инновационных решений, когда то, «что» и «как» надо получить, априори не определено и непредсказуемо. Помните, это не лучший способ выполнения рутинных операций, которые требуют строгого соблюдения стандартизированных операционных процедур.
Хочется еще раз повторить, что Agile не предназначен для резкого сокращения затрат. Инновационные бизнес-процессы в конечном итоге позволяют людям выполнять больше работы с меньшим количеством ресурсов. Но Agile не лучший метод, чтобы быстро избавиться от 30 % сотрудников. Иногда его так преподносят, потому что фанатики узнали, что бюрократы благосклонно относятся к инструментам снижения затрат, особенно если они обещают обеспечить рост и скрыть предыдущие ошибки менеджмента. Но мы надеемся, что никогда не услышим подобных заявлений: «Мы превращаемся из компании по производству гравия в технологическую компанию, и теперь, когда мы ускоряем рост, применяя Agile-методы, у нас нет другого выбора, кроме как уволить 30 % наших замечательных сотрудников».