В технологических компаниях Agile показывает впечатляющие результаты: 59% отмечают рост показателей удовлетворенности клиентов, 48% — качества, 41% — продуктивности (данные 15th State of Agile Report за 2021 год). Поэтому бизнесы вне IT — от банков до нефтедобычи — тоже все активнее экспериментируют с гибкими подходами.
Антон Немчинов более 10 лет внедряет Agile в разных компаниях — Raiffeisen Bank, Bank of Business Partners, ДомКлик, X5 Group и других. Например, в сервисе жилой и коммерческой недвижимости Антон участвовал в трансформации направления «Безопасные платежи», в результате которой оборот за полгода увеличился почти в 7 раз (до 2 млрд рублей).
Нам Антон рассказал, как собрать «пилотную» Agile-команду, пересмотреть привычные роли, систему мотивации и коммуникаций.
#1. Используйте Agile в изменчивой среде
Классический проектный подход эффективен в устойчивой среде, когда цели понятны, задачи повторяются, команда способна строить прогнозы, планировать сроки и ресурсы. В таких условиях Agile может не подойти: например, если на долгий срок есть четкое видение, что делать, — людям непонятно, зачем каждый день тратить 15 минут на стендапы.
В условиях быстрых изменений Agile помогает адаптироваться и реагировать на внешние перемены. Например, появление новых продуктов. Иначе мало шансов выжить на рынке — так компания Apple «выбила» телефоны Nokia и Blackberry, а цифровая фотография — Polaroid.
Agile можно использовать во всех индустриях — от IT до тяжелой промышленности. Например, в моем опыте есть кейс нефтегазовой компании — применение гибких практик в геологических исследованиях. Этот этап состоит из множества видов работ — определение места добычи нефти, пробы, расчеты. Организации удалось «схлопнуть» операции — проводить не последовательно, а параллельно, повысить эффективность работы и ускорить сроки.
Я применяю Agile даже в планировании отпуска. Сейчас сложно прогнозировать закрытие границ, поэтому покупаю билеты и бронирую гостиницы не за несколько месяцев, а прямо перед поездкой — когда убедился, что она все-таки состоится. Это дороже, но снижает риски еще больших финансовых потерь в случае нового локдауна.
#2. Запустите «пилот»
Некоторые компании проводят Agile-трансформации сразу во всей организации. Но это требует огромных ресурсов, есть риск потерять контроль и превратить гибкий подход в карго-культ.
Выберите и обучите первую «пилотную» группу. Привлекайте только добровольцев.
В «пробную» Agile-команду нужно собрать сотрудников разных функций и всех уровней — от специалистов до топ-менеджеров. Команда должна быть независимой и выделенной под проект на 100% занятости.
Чтобы отследить успешность эксперимента, Agile-команде необходимы:
- Продукт/цель. Вне IT конкретного продукта может не быть, но есть понятные задачи. Например, ритейл-компания внедрила динамическое изменение цен с использованием ИИ — и торговые сети увеличили прибыльность.
- Клиент. Желательно выбирать внешнего — он более объективен, и результат проще отследить (например, по прибыльности). Внутренние клиенты иногда просто вынуждены принимать изменения и не дают честный фидбек.
- Высококонкурентная среда. Это стимулирует проведение экспериментов.
Если в течение 6–8 месяцев все хорошо — можно постепенно масштабировать Agile во всей организации.
#3. Дайте команде время адаптироваться
Если гибкий подход для людей в новинку, трансформация не произойдет быстро. Нежелание меняться — нормальная человеческая реакция (мозг воспринимает новое как угрозу).
Поддерживать сотрудников можно по специальным методикам — например, применять подход Джона Коттера:
- показать необходимость и неизбежность преобразований (что не работает и почему это нужно улучшить)
- создать команду изменений из людей, имеющих полномочия и доверие
- составить видение и стратегию трансформации — как именно коллектив дойдет из точки А в точку Б
- убедиться, что команда понимает необходимость перемен и согласна с этим
- использовать тактику быстрых побед — поставить и достичь краткосрочных целей: это мотивирует
Agile-команда — единый организм. Например, если часть сотрудников не успевает выполнить собственные задачи для достижения цели спринта — остальные переключаются со своих дел, чтобы помочь. Людям, привыкшим работать по старинке — когда каждый играет сам за себя, — нужно время на перенастройку.
Часто инициатива внедрить Agile зарождается на уровне одной из IT-команд — люди хотят найти способ приносить больше пользы бизнесу. Но чтобы гибкие подходы прижились, их должны поддерживать первые лица организации и бизнес (иначе трансформация «потухнет»).
#4. Трансформируйте роль руководителя
В классической команде есть менеджер, который отвечает за весь проект и коллектив — сроки, ресурсы, качество. При внедрении гибкого подхода роль руководителя кардинально меняется — он становится лидером компетенций: люди сами выбирают путь достижения целей и планируют свое развитие. А задача лидера — поддерживать их.
Меняется стиль коммуникации: сотрудники уважают лидера, а он доверяет команде и создает для нее условия (люди не должны отвлекаться на закупки, HR-процессы, финансирование, бытовые вопросы и т. д.). В Agile, если кто-то выше по статусу в организационной иерархии — он не имеет права использовать это как аргумент в коммуникации.
В Agile-подходе загрузка людей планируется по принципу пожарной части. Нет цели загрузить каждого на 100% (зачастую — примерно на 75%). Нормально, если люди «простаивают» — тогда в случае «пожара» у них есть ресурс, чтобы бросить все силы на его «тушение».
#5. Следите за численностью и структурой
Во фреймворке Scrum оптимальная численность команды, чтобы не превращать ее в бюрократическую машину, — от 3 до 9 человек плюс Scrum-мастер и владелец продукта. В других фреймворках такой регламентации нет.
По данным исследований, в социальной среде число Данбара — то есть количество контактов, которые может одновременно поддерживать один человек, — около 25. Если сотрудников много — используйте техники масштабирования: разделяйте на команды до 9 человек («строительные блоки») и настраивайте синхронизацию между ними.
Например, в одной компании из сферы торговли (с IT-составляющей) коллектив вырос до 25 сотрудников. Это слишком много, начались проблемы: усложнились коммуникации, удлинились встречи, информация стала «теряться». Команду нужно было разделить на несколько — причем так, чтобы каждая включала не более 9 человек и была кросс-функциональной (могла самостоятельно выполнить любую задачу).
Мы провели фасилитацию: повесили три флипчарта и попросили людей разделиться по командам самостоятельно. И приступили к эксперименту. Работать в новом формате получилась не сразу, но с 3–4 попытки команды выполнили цели спринтов. При этом длительность встреч сократилась с 40 до 10 минут, каждый участник стал тратить на коммуникации 30 минут в день (вместо 3 часов).
#6. Укрепляйте социальные связи
Традиционные проектные команды разделены на функции, информация передается между звеньями, но люди мало соприкасаются между собой на личностном уровне. Каждый отвечает за свой узкий участок работы.
Гибкие команды сохраняют культуру «гаража» — стартапа (даже внутри большой организации). Agile-подход подразумевает, что коллектив физически находится в одном помещении, общение — не только профессиональное, но и личностное, «человеческое». В гибких командах более тесные связи, люди дружат, знают о личной жизни, семьях, хобби друг друга.
В классическом варианте каждый отвечает за свой участок работы, а руководитель — за общий результат. В Agile-команде все несут ответственность за проект в целом. Это повышает качество коммуникаций: каждый лично заинтересован в продуктивности и развитии коллег.
Проводите синхронизационные встречи ежедневно — выделите 15 минут, чтобы команда обменялась информацией и спланировала работу на 24 часа. Внедрите правило «Просто говори» — если узнал что-то важное для проекта, нужно громко об этом сказать (так действительно легче оставаться в общем контексте).
#7. Поменяйте схему мотивации
В традиционном подходе есть система целеполагания — бизнес-цели каскадируются на подразделения, у команд и каждого сотрудника есть ключевые показатели эффективности, компания вознаграждает их выполнение. Иногда люди даже не понимают ценности своих действий. Часто бывает и так: если есть квартальные премии за достижение показателей — первые два месяца сотрудники работают на клиента, а третий — на выполнение планов, которые не создают ценности для покупателя, но гарантируют бонусы.
В гибком подходе другой фокус. Он опирается на исследования мотивации в интеллектуальной работе. Например, Дэниел Пинк в своей книге «Драйв. Что на самом деле нас мотивирует» описал ряд экспериментов, которые доказали: прежде всего — не деньги, а автономия, совершенствование и предназначение.
Например, в IT популярная практика — давать людям 1–2 дня в месяц заниматься своими личными проектами. Многие успешные продукты компании получили именно так — например, сотрудник Google Пол Бакхайт создал Gmail в рамках самостоятельного проекта.
Гибкие команды сильнее вовлечены отчасти потому, что регулярно и часто получают обратную связь от клиентов и могут быстро корректировать действия. В отличие от проектных команд, которые получают фидбек уже после запуска, максимум — еще в нескольких контрольных точках.
В Agile финансовая мотивация строится по принципу «платим столько, сколько нужно». В среднем — рыночное вознаграждение плюс 10–15%. Расходы компании при этом не растут — просто меняется структура, переменная часть изначально закладывается в гарантированное вознаграждение.
Но могут быть дополнительные поощрения — например, если команда превысила ожидания, привлекла больше пользователей или повысила продажи. В таком коллективе обычно есть роль владельца бюджета — и он может выдать дополнительную сумму, но как ее делить и на что тратить (хоть переехать на месяц на Кипр) — команда решает сама.
#8. Используйте только актуальные практики
Применяя гибкие подходы, можно брать за основу существующие процессные модели и методики. Scrum практиковался 25 лет. Нет смысла тратить столько же времени, чтобы придумать еще один «велосипед». При этом экспериментируйте осознанно. Например, Scrum «заточен» под IT-продуктовые команды — для промышленных компаний и рекламных агентств актуальны не все его элементы.
Коллектив может выбирать фреймворки и практики, которые помогают решать именно его задачи. Например, само по себе создание кросс-функциональной команды — объединение экспертов из разных департаментов, позволяет убрать бюрократию и иерархию. Неизменны только 4 принципа Agile-манифеста:
#1. Люди и взаимодействие важнее процессов и инструментов
#2. Работающий продукт важнее исчерпывающей документации
Весь бизнес-контент в удобном формате. Интервью, кейсы, лайфхаки корп. мира — в нашем телеграм-канале. Присоединяйтесь!
#3. Сотрудничество с заказчиком важнее согласования условий контракта
#4. Готовность к изменениям важнее следования первоначальному плану
Пробуйте разные подходы и смотрите на результат — что приживется, а что «отвалится».
Например, в IT, согласно Scrum, есть Product Owner (отвечает за видение и успешность продукта, формирует бэклог) и Scrum-мастер (отвечает за эффективность работы команды). Вне IT не всегда есть задача разработать продукт, чаще нужно оптимизировать процессы. Роли Product Owner и Scrum-мастера выполняет один человек: например, эксперт в предметной области создает бэклог, коммуницирует со стейкхолдерами, управляет процессами и экспериментами в команде.
В то же время не всегда нужно выделять для этой роли ведущего специалиста. Например, невозможно «выдернуть» с производства руководителя цеха — скорее всего, больше подойдет менеджер отдела оптимизации процессов.
#9. Не пытайтесь оцифровать все
Желательно, чтобы сотрудники находились в одном пространстве и даже за одним столом. В идеале для работы Agile-команде нужна только физическая доска на видном месте, где фиксируется ход проекта. Или как альтернатива для удаленки — онлайн-доска с общим доступом.
Конечно, гибкие команды используют софты для управления проектами (Microsoft Project, Trello, Jira, Miro). Но не нужно оцифровывать живое общение — в Agile это один из ключевых факторов успеха.
Хотите получать дайджест статей?
