Гибкие технологии: могут ли корпорации использовать Agile и Scrum для развития инноваций
Вадим Чухлебов, эксперт компании O2Consulting, в соавторстве с Алексеем Никитченко, генеральным директором O2Consulting, написал для Firrma колонку о практике внедрения методов Agile и Scrum во внутренние процессы корпораций.
В последние годы на рынке все чаще говорят о гибких методиках развития проектов (прежде всего, Agile и Scrum), чьи преимущества оценили не только предприниматели, но и крупные корпорации. Однако в сфере работы с инновациями большинство крупных компаний в России по-прежнему предпочитают работать по стандартным схемам, предполагающим разработку ТЗ, детального плана с описанием ресурсов, продолжительности, бюджета, рисков, ключевых промежуточных точек и поступательную реализацию проекта с последующими корректировками. Где-то, как например, в строительстве, это продиктовано отраслевой спецификой, однако, в большинстве случаев мы имеем дело с обыкновенной инертностью и консерватизмом, препятствующими любому обновлению.
Традиционные подходы к развитию новых и инновационных проектов показывают низкую эффективность, так как в этом случае требуется двигаться быстро и максимально результативно. Поскольку речь идет о новых проектах, есть риск, что проект может «не взлететь» или не окупить затраты корпоративных ресурсов на него. В связи с этим корпорациям важно быстро оценивать, тестировать и запускать (либо хоронить) такие проекты. Любое промедление влечет за собой финансовые потери. Гибкие методики позволяют максимально оперативно и эффективно протестировать потенциал проекта и проектной команды. Agile и Scrum – отличный формат взаимодействия реализуемых проектов с корпорацией. Давайте разберемся, как это работает.
Особенности корпоративного Agile/Scrum управления проектами
Впервые об Agile-манифесте бизнес услышал в начале двухтысячных годов. Главные принципы этого нового для того времени подхода – максимальная клиентоориентированность (первоочередная цель – довольный заказчик), корректировки проекта в режиме реального времени, минимум документации, максимум оперативных неформальных коммуникаций, отсутствие иерархии. Разработчики напрямую общаются с конечным пользователем их продукта, фазы инициации и планирования упраздняются. В результате скорость работы повышается, а количество ошибок снижается за счет отсечения промежуточных звеньев.
Agile/Scrum быстро подхватили международные корпорации и начали применять для управления проектами. Со временем выяснилось, что Agile/Scrum-методология особенно ценна при работе с большими проектами, которые могут длиться годами и включать в себя несколько сотен и даже тысяч задач. Положительный эффект от Agile/Scrum заключается в том, что на выполнение каждой задачи или блока задач отводится около двух недель, после чего разбираются результаты и осуществляется планирование следующих действий. Дело в том, что для долгосрочных задач, особенно в российской действительности, часто работает студенческий синдром: желание отложить все на последний день. Если на задачу отведено две недели, то 95% исполнителей приступают к ее реализации за два дня до дедлайна. Поэтому все задачи нужно дробить на короткие интервалы, чтобы иметь возможность вовремя спросить: «Где результат?» Тогда люди начинают лучше планировать и равномерно распределять свою загрузку.
Еще одна область применения гибких методик – работа с корпоративными инновациями в рамках внутренней акселерации проектов, смысл которой заключается в том, чтобы за короткий период времени понять, есть ли у предлагаемой технологии и/или решения будущее и способна ли проектная команда, учитывая запросы корпорации, достигнуть намеченной цели.
Проектная команда обычно состоит из небольшого количества человек – до 10. В связи с этим, учитывая, что одно из условий эффективной работы по Scrum – производительная, позитивная, неформальная коммуникация внутри проектной команды, Agile/Scrum, как правило, хорошо ложится для решения задач проектных команд. В большем коллективе моментально наступают расслоения, появляются лидеры, ведомые и халявщики. Если же в Scrum-команде появился хотя бы один халявщик, он начинает отравлять весь коллектив, и его нужно сразу убирать. В идеале команда должна быть замотивирована не только материально, но и морально. Возможность создать свой успешный бизнес, используя ресурсы крупной корпорации – как раз подходящий стимул.
Еще одно важное условие – отсутствие внешних раздражителей и фокусировка только на текущем проекте. Scrum-мастер (фактически руководитель проекта) должен принять на себя все коммуникации с внешним миром: уточнить запросы заказчика (корпорации), организовать быт, подготовить встречи. Все остальные работают, не поднимая головы. Отсюда простое следствие: эффективная Scrum-команда работает только над одним проектом. Соблюсти это правило «в обычной жизни» сложно: в бизнесе и в госструктурах крайне популярен матричный подход, при котором один человек выдергивается сразу на несколько проектов, при этом его текущие операционные задачи с него не снимаются. Однако в процессе акселерации инновационных проектов компания должна позволить сотрудникам сосредоточиться только на своем проекте, который при правильном стечении обстоятельств может с лихвой окупить двух- или трехмесячный «простой» сотрудника.
Несмотря на возрастающую популярность внутри корпоративной акселерации проектов, единых методов работы по их сопровождению нет. Задача быстро разработать проект под конкретные запросы корпорации решается по-разному, в зависимости от подходов, которые приняты у специалистов, сопровождающих проекты. Однако в большинстве принятых на рынке «лучших практиках» есть элементы Agile и Scrum. Например, в части быстрого принятия решений.
В Scrum для облегчения этого процесса есть особая «фишка» – покерное планирование. Раздаются специальные карты, где стоят оценки задач, собирается команда. Вопрос: «К нам пришла новая задача, за сколько мы ее сделаем?» Не сговариваясь, каждый член команды кладет на стол свои карты, затем выводится средняя. Сравните с классической схемой планирования, где разрабатывается глобальный сетевой план-график в формате диаграммы Ганта, где устанавливаются связи между текущими, предшествующими и грядущими работами, рассчитываются критические пункты и т.д. и т.п. В Scrum ничего этого нет. Есть доска с системой координат: время и объем задач. Никакого графика на год вперед, никакого списка задач, только объем работы. План рисуется в виде прямой линии, которая ежедневно немного продлевается по прогрессу. Scrum–мастер отмечает: идем с опережением, по плану, с отставанием. Какое тут ограничение? Для команды из 30 и более человек такой график создать нереально.
Если посмотреть глубже на то, что такое покерное планирование, то это старый-добрый Delphi-метод работы с экспертными оценками, которые используются с незапамятных времен. Адепты Agile делают из давно известной всем вещи «конфетку». Если раньше эксперты на листе белой бумаги писали свои оценки из головы, то тут есть специальные карточки с четким набором ответов. Такой вот своеобразный ритуал, и в этом всегда есть азарт. Модная сегодня геймификация: вместо банального экспертного опроса интригующее собрание за круглым столом.
Еще один Scrum-ритуал – ежедневные короткие митинги «на ногах». Вместо долгих тягучих совещаний – летучка с ответами каждого члена команды на три коротких вопроса: «Что ты сделал сегодня? Чем займешься завтра? Есть ли проблемы?» Проблемы на таких митингах не решают, для этого есть отдельные рабочие встречи, где присутствуют только вовлеченные люди, время всей команды тратить на это не нужно. Примерно по этой же схеме работают большинство программ акселерации: короткий митинг – план на день и работа-работа-работа.
Кроме ежедневных Scrum предполагает еще и расширенные встречи, на которых обсуждается ретроспектива прошедшей недели. Весь объем проекта по Scrum делится на спринты (короткие промежутки в 1-2 недели), их легко спланировать, вспомнить и проанализировать. В конце каждого такого спринта проходит расширенный митинг. На них приглашаются представители заказчика (отдельных подразделений корпорации), им показывают, что уже сделано и «снимают» обратную связь. Результат этой ретроспективы фиксируется и ставится в блок задач на следующий период. Интервал планирования в Scrum – максимум две недели, затем начинается перепланирование «от достигнутого».
Успешные и не самые: примеры внедрения гибких методик
Герман Греф не раз заявлял о жизненно важной необходимости и о переводе всех процессов ПАО «Сбербанк» на «гибкие методики». Такие выступления понятны: в крупных компаниях на быстроразвивающихся рынках проект теряет актуальность уже во время разработки, потому что бизнес-процесс меняется быстрее, чем его могут реализовать. Однако в случае со Сбербанком, внедрение, а точнее эффективное применение Agile, затруднено по многим причинам. Когда Сбербанк в 2012 году пригласил Дмитрия Лобасева (Agile-коуч – прим. ред.) внедрять Agile, из пяти созданных им команд фактически заработала лишь одна. Методики гибкого проектирования вступили в конфликт с 14-уровневой иерархией банка.
Если более детально рассмотреть кейс Сбербанка, то:
Во-первых, внедрение методики идёт «сверху», а не «снизу». Именно Герман Греф, а не команды разработчиков или многочисленных отделов вводит и стимулирует использование новых методов. Вообще в крупных компаниях, особенно в России, где наиболее ярко выражены отношения «начальник-подчиненный», сложно представить внедрение новых методик «снизу»: одно осознание того, что её необходимо согласовать с десятком вышестоящих лиц становится непреодолимым барьером.
Во-вторых, у Сбербанка огромная команда с уже устоявшимися внутренними правилами и нормами, поэтому новый, полный энтузиазма сотрудник, зараженный идеями внедрения Scrum, понимания, скорее всего, не встретит: в чужой монастырь со своим уставом не ходят…
В-третьих, у Сбербанка нет ярко выраженного заказчика – он улучшает и оптимизирует собственные процессы. Поэтому промежуточные результаты приходится согласовывать со всеми заинтересованными управлениями, фактически возвращаясь к водопадной схеме.
Если говорить про успешные практики применения гибких методик, то они связаны, в первую очередь, с набором свежей команды и решением новых задач, а не изменением уже налаженных механизмов.
История успеха разработчика CRM-решений в области автоматизации продаж Salesforces началась именно с внедрения Agile-методик. Понимая, что команда не справляется с увеличивающимися объёмами заказов и требований, было принято решение разделить персонал на фактически независимые команды. Сегодня Salesforces обслуживает более 110 миллионов заказов в сутки.
Hewlett-Packard (HP) при разработке ПО для принтеров столкнулся с рядом проблем: постоянное увеличение бюджета проектов, увеличение сроков при интеграции и тестировании и ухудшение отзывов потребителей. Применение гибких методик решило перечисленные проблемы: расходы на разработку прекратили стремительный рост, количество обновлений увеличилось с 1 в неделю до 100 в неделю, а время интеграции уменьшилось с недели до 3х часов. Кейс HP – пример успешного внедрения Agile в крупную компанию. Это стало возможным благодаря осознанию необходимости изменений руководителями всех уровней и найму соответствующих специалистов: Scrum-мастеров, имеющих широкий опыт работы по гибким методикам.
В качестве саммари: возможности и ограничения гибких методик
Scrum и Agile стремительно проникают в рутину крупного бизнеса и подчас становятся даже устоявшимися корпоративными практиками. Однако есть несколько факторов, тормозящих их распространение и внедрение в сферу развития инноваций. Первый из них – ограничения на состав команды. Метод подходит только для небольших и относительно молодых коллективов. В принципе почти любой стартап проходит в своем зародыше фазу Scrum: небольшая «тусовка» единомышленников создает что-то на энтузиазме и вне формальной структуры. Дальше начинаются ограничения.
Второй – высокая мотивация и сплоченность команды. Если из команды уходит ключевой сотрудник: мастер или ведущий разработчик, проект можно начинать заново. У неформальной, гибкой, не бюрократизированной группы потеря любого элемента обычно обрушивает всю конструкцию.
Третье ограничение – максимальная концентрация, в идеале люди должны быть отрезаны от внешнего мира и погружены только в решение задач проекта.
Четвертый важный фактор (относится не только к Scrum, но и к другим итерационным моделям управления) – невозможность спрогнозировать точное количество итераций на доработку и выход продукта. Scrum-проект хорошо реализуется тогда, когда в приоритете находятся функциональность и качество продукта, а не бюджет. Проще говоря, если есть спонсор, готовый давать Scrum-команде столько денег, сколько потребуется.
Тем не менее, плюсы Scrum тоже очевидны: гибкость и чуткость к пожеланиям клиента, ориентация на качество продукта, короткое плечо планирования, моментальное исправление выявленных ошибок и рисков, поддержание постоянного драйва, энтузиазма и работоспособности команды, нацеленность на достижение целей, хорошо развитое управление приоритетами. Для высоко креативных проектов с хорошим бюджетом и большими амбициями –это отличная методика. Крупным компаниям удобнее от начала и до конца планировать по «тяжелой», водопадной методике, а вот развивать инновации в рамках программ корпоративных акселерационных программ – по Agile и Scrum.