Agile не только набирает популярность в IT-компаниях, но активно проникает в другие сферы: банкинг, производство, маркетинг и даже образование. Если вы интересовались этой темой, то, конечно, встречали и даже, возможно, читали книгу Джеффа Сазерленда «Scrum: революционный метод управления проектами». И если компания решила переходить «на Scrum», то это влечет за собой серьезную перестройку всей организационной структуры. Изменяются привычные процессы, вводятся новые правила работы, новые артефакты, новые термины. Сотрудникам становятся непонятны перспективы карьерного роста в компании, состоящей из самоорганизующихся команд с тремя ролями, не связанными иерархией. И то, что является спасением для инновационных команд, живущих в «запутанных системах» (по модели Кеневин), то становится пугающим и возможно даже губительным для традиционных производств и сферы услуг.
При этом, реалии времени требуют от всех быть Agile, причем, не формально прикрываясь модным ярлыком, а фактически – проявляя проворность, гибкость в стремительно и непредсказуемо меняющихся условиях. Где же выход?
Возможно, вам понравится путь, который с первого года основания вслед за Intel избрала Google. Секрет Google раскрыл Рик Клау на уже историческом выступлении в 2013 году. Эта система называется OKR (Objective and Key Results – цели и ключевые результаты, ЦКР). Сегодня ее применяют как мировые гиганты, вроде Amazon, Microsoft, Panasonic, Deloitte, так и представители среднего и малого бизнеса. В России этот подход незаслуженно малоизвестен, и цель этой статьи – дать читателям первое представление о том, что это, в чем преимущества, и как применять в российских условиях.
Важно отметить, что это мета-система, внутри которой допускаются различные подходы к управлению проектами и процессами. Например, в Google система ЦКР принята на уровне всей компании, и согласовывает деятельность всех ее команд, а уже внутри каждая команда сама решает, работать по Scrum, или использовать что-то другое. То есть, чтобы начать применять систему и уже с первого месяца видеть результативность, не надо ломать сложившуюся организационную структуру и привычные методы работы! Основное преимущество системы ЦКР в том, что ее можно внедрять эволюционно.
Почему важно чаще корректировать цели
Так за счет чего без революционных изменений компания вдруг станет Agile? Обратимся к определению, что такое business agility. Это способность бизнес-системы быстро реагировать на изменения, адаптируя свою первоначальную стабильную конфигурацию. (Evan Leybourn, Directing the Agile Organisation: A Lean Approach to Business Management. IT Governance Publishing. 2013). Таким образом, если мы даем компании инструмент, который позволит держать руку на пульсе изменений, происходящих во внешней и внутренней среде, и оперативно и слаженно реагировать – то мы взращиваем ее business agility.
И такая оперативность, проворность обратной связи тесно связана с горизонтом планирования. Если раньше стратегические цели ставили на двадцать и более лет, еще недавно – на три-пять лет, то сегодня стратегической уже считается цель на год! Потому что время настолько сжимается, что становится очень важным как можно чаще пересматривать ориентиры: что сейчас происходит и туда ли двигается компания.
Да, для компании важнее создавать видение – куда в принципе развиваться. Роберт Дилтс, исследуя факторы бизнес-успеха, отмечает, что осознанные лидеры при принятии важных решений всегда рассматривают большую перспективу, чем текущий момент. Этот принцип был описан еще в Великом законе ирокезов, согласно которому, принимая решения сегодня, важно подумать о семи будущих поколениях, смотреть вперед на 150 лет. И только тогда можно быть уверенным, что эти решения принесут пользу потомкам (Р. Дилтс, «Моделирование факторов успеха»).
Но четко в цифрах поставить долгосрочную цель и зафиксировать ее нельзя, потому что внешняя среда меняется гораздо быстрее и, главное, непредсказуемо. Как признался Роберт Перлштейн, вице-президент Стенфордского международного исследовательского института, мы сейчас не можем с уверенностью прогнозировать, каким будет мир через пять лет. И может оказаться так, что цель поставили на пять лет, зафиксировали, а через пять лет мир вообще стал другим.
Поэтому, например, Google, ориентируясь на свое видение и миссию, конкретные бизнес-цели в масштабах компании ставит на год, а в масштабах подразделений – на каждый квартал. Перед началом каждого квартала в Google происходит сверка: что изменилось в мире, в технологиях, в компании, что сейчас более приоритетно. И на основании свежей информации подразделения выбирают три самые приоритетные цели, на достижении которых все сотрудники фокусируются и согласованно действуют в течение следующего квартала.
Как должна быть сформулирована цель
В нашей пока еще начальной практике с российскими производственными предприятиями мы описываем стратегическую цель на год и затем ставим ЦРК на месяц – как компании, так и ее подразделениям. Это связано как с сезонностью бизнеса, так и с тем, что система находится в компании на стадии начальной адаптации, и поэтому частая ревизия целей позволяет менеджменту научиться более четко их ставить. И мы рекомендуем такой подход для компаний, начинающих внедрение ЦКР.
Какой эффект это дает? Видя годовую перспективу, вы ставите цели на маленький промежуток времени и сверяете, придя в эту точку, насколько корректно были поставлены цели, насколько они соотносятся с реальностью. Если ситуация не изменилась – то на следующий промежуток времени остаются эти же цели, возможно, со скорректированными числовыми показателями. А если что-то поменялось, то можно достаточно быстро изменить курс, реализуя ту самую проворность, бизнес-agility. Таким образом, реализуется ценность agile-манифеста – «готовность к изменениям важнее следования первоначальному плану».
В таком сжатом по срокам движении становится особенно важной согласованность приоритетов. Все понимают, что в этом месяце фокус внимания такой, а в следующем месяце сезон поменялся, ситуация поменялась, и фокус внимания другой. То есть остальные виды деятельности продолжают реализовываться, но особенный фокус внимания уделяется именно приоритетным целям и ключевым результатам. И чтобы удерживать сфокусированность, рекомендуется выбирать не более трех приоритетных целей на каждый промежуток времени.
Чтобы у всех сотрудников была максимальная ясность (на чем всем надо фокусироваться на этот промежуток времени), цели должны быть сформулированы, с одной стороны, вдохновляюще и амбициозно, с другой – предельно конкретно. Кроме представления о том, что мы хотим сделать, важно понимать, как мы узнаем, что этой цели достигли. И поэтому каждая цель описывается еще тремя-четырьмя ключевыми результатами – измеримыми, количественными, выраженными или в цифрах, или дихотомически (да/нет). И уже достижение результатов измеряется по шкале выполнения. Таким образом, на квартал (или месяц, или другой выбранный компанией промежуток времени) ставят по три ЦКР – три цели, каждая из которых описана тремя-четырьмя ключевыми результатами.
Как двигаться к цели
Поставить цель, даже идеально сформулировав, совершенно недостаточно. Если вспоминать о цели только на сессиях планирования раз в квартал (или месяц) – значимых изменений в деятельности сотрудников не произойдет. Поэтому, на наш взгляд, ключевой элемент этой системы – формирование корпоративной привычки регулярно и согласованно сверять действия с выбранным ориентиром. Это достигается за счет четырех видов регулярных собраний.
Два собрания (иногда их объединяют в одно) проводятся перед каждым циклом – очередным кварталом или месяцем. Это ретроспектива, подведение итогов прошедшего периода, анализ эффективности действий и поиск путей улучшения. Сценарии ретроспективы аналогичны тем, что проводятся в scrum-командах и могут включать различные наборы фасилитационных инструментов. На следующем этапе проводятся командные сессии, где ставятся цели и ключевые результаты – вначале на уровне компании, и затем на уровне подразделений.
И дальше каждую неделю проходят два собрания в обязательном порядке. Дни недели можно выбрать любые, но в лучшей практике это понедельник и пятница.
В понедельник все члены команды собираются на короткое прогресс-собрание (похожее на scrum-митинг) и сверяют текущий уровень результатов с запланированным. Цель собрания – запланировать на неделю и согласовать действия членов команды, направленные на достижение выбранных целей. Важно еще раз отметить, что выделение приоритетных ЦКР означает не отказ от остальных видов деятельности, а выделение особого фокуса внимания именно на важном. Поэтому собрания в понедельник посвящены именно ЦКР и задают этот фокус всей команде, таким образом, удерживая сотрудников на выбранном пути. В то же время, имея возможность гибко маневрировать, регулярно сверяясь с курсом, и согласовывая действия друг с другом. А каждую пятницу проходят неформальные собрания, на которых команды празднуют достижения недели, что усиливает внутреннюю мотивацию.
Такие четыре вида собраний можно проводить при любой организационной структуре компании – как плоской, так и иерархической, как с кросс-функциональными командами, работающими по Scrum (где эти собрания уже есть), так и с коллективами функциональных подразделений.
Почему руководитель должен начать с себя
Внедрение ЦКР не ломает существующие структуры и процессы, а создает гибкость планирования и согласованность сфокусированного движения. Поэтому возможно начинать применение ЦКР эволюционно, частями, добавляя постепенно новые элементы и вовлекая больше подразделений и сотрудников. Возможно применение ЦКР даже в рамках отдельной команды и отдельного сотрудника. Но, конечно, чтобы всю компанию перевести на ЦКР, важно начинать с руководителя и управленческой команды.
Для мягкого, эволюционного перехода рекомендуем не вовлекать в него сразу весь коллектив: пусть сначала пожить в этом ритме попробует руководитель компании. Сформулируйте по ЦКР свои приоритетные цели, например, на месяц, и каждую неделю организуйте самому себе короткие сессии по измерению прогресса и планированию. Это можно делать самостоятельно или с коучем. Втянитесь в эту привычку, почувствуйте усиление энергии, направленной на выбранные приоритеты, потренируйтесь в выборе самих приоритетов, четкости формулировки целей и ключевых результатов. И затем можно расширять круг руководителей, участвующих в ЦКР, начиная с тех, кто внутренне готов.
И так, в несколько этапов, можно вовлекать в процесс все больше и больше сотрудников, согласованно двигаясь к достижению приоритетных целей и ключевых результатов – до тех пор, пока компания естественным образом не сформирует новую систему корпоративных привычек.
И когда все сотрудники будут понимать и работать по ЦКР, тогда появится возможность вовлекать их в постановку ЦКР компании, как это делается в прогрессивных компаниях.
В этой короткой статье рассмотрены только некоторые аспекты ЦКР, обеспечивающие бизнес-agility, и показан путь их эволюционного применения. Будем рады видеть комментарии. Какие возникли мысли, идеи, чувства? О каких из упомянутых, но не расписанных подробно аспектах вы хотели бы узнать подробней? Какие вопросы возникли? Что посчитали для себя самым полезным и хотели бы попробовать в работе? И конечно, будем рады, если откликнутся те, в чьих компаниях уже применяется ЦКР, или те, кто уже стоит на пороге внедрения.
Почему-то авторы статей на тему передовых agile-компаний упорно не обозначают область применения этой зонтичной технологии - под зонтиком Agile собрано достаточно много известных достаточно давно технологий. Если Google использует в своей работе различные Сервисы, то ему тысячу раз удобно использовать Scrum и scrum-команды под каждый Сервис. Не придираюсь, но не каждый найдёт в тексте эти области применения и пропустит мимо себя такую ценную информацию :), что такой объём Agile внедрения - это не для всех.
Ну, тогда российские компании давно всех опередили в горизонтах планирования на год вперёд, а то и меньше ... :) Ну, а то что называют ЦКР - цели и ключевые результаты - Кто ещё не использует в нашей стране? Вот уж эти передовые иностранцы со своими санкциями такое пропустили ...:)
Наталья Гульчевская пишет: "...Agile не только набирает популярность в IT-компаниях, но активно проникает в другие сферы: банкинг, производство, маркетинг и даже образование... При этом, реалии времени требуют от всех быть Agile, причем, не формально прикрываясь модным ярлыком, а фактически..."
Наталья, нельзя вводить в заблуждение читателей:
1. Сфера применения подхода Agile - разработка программного обеспечения: уже само название (agilesoftware development) об этом говорит - это серия подходов к разработке программного обеспечения.
2. Применять Agile в других сферах (производство, банкинг, маркетинг), как это предлагает автор статьи, нельзя - последствия будут катастрофическими.
Нужно понимать, что наряду с положительными результатами применения Agileпри при разработке программного обеспечения (гибкость), есть и существенные недостатки: - "Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути, управления требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» и переделками практически на каждой очередной итерации" (привел цитату из интернета, хотя есть уже отзывы тех, кто пытался применить Agile не по назначению).
Любой производственник откажется от такого подхода - такие "переделки" в сфере материального производства будут катастрофичны. А при разработке программного обеспечения допустимы.
А горизонты планирования и управление по целям и показателям, которые описаны в статье, никакого отношения к Agile не имеет, да и не содержит элементов новизны - обсуждать нечего.
Поддержу Юрия Петрова. Неоднократно задавал сторонникам Agile вопрос, как они планируют внедрение данных принципов в системной интеграции, строительстве, производстве сложной аппаратуры. В ответ, к сожалению, внятных предложений не поступало.
В ПО, да, всё просто. Есть спринт, постановка задачи на него, через 3 недели демонстрация продукта.
В производстве аппаратуры спринт полгода. Или 24 недели. Потом демонстрация продукта в виде опытного устройства. Все изменения, произошедшие за этот период сдвигают сроки пропорционально. Т.е. если заказчик решил через 3 месяца, что ему нужен ещё один разъём на плату - 3 месяца в корзину. Agile? Готовность к изменениям?
Исключительно интересны варианты Agile при строительстве ЦОД для банков и в части строительства и в части создания серверных мощностей. Или при подготовке бакалавра по 4 летней программе.
Посему, при всей модности подхода, применимость его, как мне кажется, весьма ограничена.
совершенно в другом понимании - Гибкие Производственные Технологии - очевидно, что это название потом позаимствовали у производственников :).
И согласен с Вами, что ошибки в понимании приведут к катастрофе во многих других областях применения Agile, и тем более особенно осторожно стоит относиться к тому, что пишут о гибких методах управления на производстве. Это новая волна :), которая подняла большое количество дилетантов и просто авантюристов. Что-то очень похожее было с Реинжинирингом бизнес-процессов в начале 90-х, когда всё вокруг стало Реинжинирингом. Наступила очередь Agile :)
В IT используется намного больше различных Agile методологий, чем в других областях применения Agile. Это и понятно, за почти тридцать лет прогресс ушёл очень далеко. Автор ошибается, когда пишет: "набирает популярность в IT-компаниях" - На практике это используется многими командами разработчиков с момента появления RAD (быстрая разработка приложений) средств разработки ПО - насколько помню, в нашей стране в начале 80-х годов - и это позволило максимально приблизить разработку к Заказчику, и привлечь его к участию в проекте.
Но по своей сути то, что подразумевается в более широком смысле под Agile сейчас - это Маркетинговый проект с максимальным непосредственным участием Клиента. В результате может появиться прототип какого-то нового изделия и новой услуги. В таком понимании Agile, в самом экстремальном случае цели проекта могут меняться даже после каждого этапа. А для Google, Сбербанка и т.п. возможно использовать Мультипроект для всех Сервисов, которые они собираются включить в своё ПО.
Но если для IT компаний меньше препятствий в изменении стратегии, то для других областей применения Agile методологий их может оказаться намного больше. Да и похоже, что у многих авторов в т.ч. зарубежных явная путаница в понимании что такое Стратегия и Тактика. Но они так осторожны в своей неконкретности изложения, что их сложно поймать на этом ... :)И чего спорить на ровном месте? :-) Есть интересный опыт с картинками. Прочтите и скажите спасибо, а то добросовестным руководителям пришлось бы все это слушать долго и больно за большие деньги в какой-нибудь МВА. А где и как этот опыт применять или не применять - зависит от конкретного руководителя и той среды, где он работает. Особенно это касается глубины понимания специфики этой среды в каждый конкретный момент этим руководителем, т.е., если хотите, уровня зрелости этого руководителя. Поэтому хочется заметить некоторым коллегам, что В УПРАВЛЕНИИ нет таких понятий как "всегда", "никогда", "много", "мало", "хорошо", "плохо", "нельзя" и т.п. Эта лирика - для обсуждения "в курилке". И вообще: декларативный стиль в управлении - вот это - реальный нонсенс. Есть только одна сущность, которой позволено говорить про абсолютное "нельзя", даже конституции меняются. И переваливать собственное незнание ситуации в управлении в разных странах, в том числе по использованию гибких подходов и методологий в управлении, на автора статьи - ну грустно же...
Господа, в эпоху цифровой экономики все не-аджайл компании вымрут как динозавры
Так что можете дальше рассуждать о невозможности аджайла и продолжать тянуть компанию на кладбище
Платон, внедрять Agile принципы - это уже само по себе утопия. Agile нельзя внедрить, к нему можно прийти. Это определенный подход к работе, а не процессы, которые можно взять и внедрить.
Вы в своем комментарии рассмотрели некий вариант "аля Scrum" в узком понимании. Конечно же, если производство делает электронное устройство, а заказчик говорит о смене разъемов, когда уже идет технологический процесс, то это не Agile в этом смысле с точки зрения производства этой платы. Не надо Agile натягивать на что попало и смотреть на него через замочную скважину. Поднимитесь на уровень выше, посмотрите шире. На это же производство этой же электроники из вашего примера. Если конкуренты уже добавили новый разъем, а ваше производство нет, т.к. млин 3 месяца еще плюсом, то где такая компания будет через некоторое время?
Автор об этом и говорит, что нужно быть гибким на внешние изменения, и если потребители хотят новый разъем на плате, то надо взять и сделать как можно раньше, чтобы как можно раньше предоставить рабочий экземпляр, который бы удовлетворял потребителя. Вот это про Agility, именно про это и говорит автор, а не про спринты при производстве плат.
Повторюсь ещё раз. Изменения в технологии устройства требует соблюдения технологического процесса. В том числе разработки и согласования проектной документации. Принципы Agile в виде отказа от артефактов при создании таких фундаментальных вещей просто не могут быть исполнены при реализации проекта.
И никаких "как можно раньше" не получится. Определённые процессы уже отработаны и измерены. Ребёнка вы раньше чем за 9 месяцев не родите, хоть по проектной методологии, хоть по Agile.
Так и техническое задание по ГОСТ 34 писать 1 месяц, согласовывать с участниками 1 месяц. Это аксиома. Реальность мира. Как и создание АПК даже объектного значения без технического задания по ГОСТ 34 будет провалено. Тоже, кстати, реальность мира, которую регулярно пытаются подвергнуть сомнению различные герои. Если они не пишут его в таком виде, значит пишут в другом, но пишут. А потом рассказывают сказки, что не писали.
Это, простите, не экранные формы переделывать. И не "новую фичу" в личный кабинет добавить. Когда владелец продукта сказал, мастер в спринт внёс, дизайнер нарисовал, программист поправил.
Это когда вы поправили в документе PIN разъёма и у вас запустился процесс с количеством участников - несколько тысяч человек и сроком в несколько месяцев.
Как уже говорил выше, чётких действий по подобным проектам в рамках Agile мне услышать не удавалось.
Андрей Роговский