24.11.2016 09:00   27024   

Евгений Устинов: «Agile — это история о творчестве и доверии»

Руководитель проектов McKinsey Евгений Устинов перевел на agile-рельсы уже не одну крупную компанию по всему миру. Поэтому кто, как не он, может в красках рассказать об особенностях этого модного направления, его плюсах и подводных камнях.

— Тема agile сейчас мегапопулярна, но ведь этому направлению, как я понимаю, не один десяток лет?

— Не секрет, что в ведущих российских банках локальные применения agile-подхода к работе практиковались достаточно давно и довольно успешно. Само движение к agile началось не сверху, на уровне топ-менеджмента, а снизу, на уровне отдельных команд.

— Расскажите об истории этой методики. 

— Термин agile (дословно: гибкий, динамичный) появился в 2001 году с манифеста, в котором люди, продукт и готовность к изменениям ставились выше согласований, бумажек и первоначального плана. Но организации, работавшие по этому принципу, возникли еще в 60-х годах XX века, причем даже не подозревая, что они agile. Просто люди делали так, как чувствовали, и все. Сейчас agile ассоциируется прежде всего с разработкой программного обеспечения, с передовыми технологиями. На самом деле agile-организации можно встретить в разных областях, и пионеры этого подхода встречались в совершенно неожиданных сферах.

Мой любимый пример: в 60-х годах в США был такой летчик, военный стратег Джон Бойд. Он придумал теорию OODA, по которой воздушный бой выигрывает не самый лучший самолет с точки зрения техники, а пилот, который принимает максимальное количество решений за определенный отрезок времени и моментально реагирует на изменяющиеся обстоятельства. В общем, побеждает наиболее быстрый и гибко мыслящий. Теория Бойда активно применялась в те времена в военной сфере. Но это лишь один из многих эпизодов, показывающих, где agile был востребован.

— Что он представляет собой в современной интерпретации? 

— Надо сказать, что agile — это зонтичное понятие, а не конкретная технология или какое-то одно решение. Это понятие объединяет множество различных методов и подходов, которые в совокупности делают организацию другой. Ядро agile, главный его компонент, — это небольшая команда. Причем есть четкое научное обоснование ее оптимального размера — от шести до двенадцати человек. Команда должна быть кросс-функциональной, то есть включать людей разных специализаций: продуктовиков, маркетологов, юристов, дизайнеров, IT-специалистов и так далее. Все они образуют единый организм и в идеале должны работать в одном помещении. 

— То есть удаленка в agile не приветствуется?

— Во многих случаях без нее не получается, но эта проблема решается при помощи тех же видеоконференций, мессенджеров, которые позволяют ощущать чувство локтя, даже если человек находится на другом конце планеты. В идеале вся команда сидит в одном помещении и работает над понятной бизнес-задачей, которую способна реализовать самостоятельно от начала до конца.

Работают люди небольшими отрезками. Они сознательно себя ограничивают, договариваются между собой, что продвигаются дистанциями спринта, а не марафона. Эти отрезки так и называют — спринтами. Каждый может длиться от недели до месяца, но наиболее часто используемый стандарт сейчас — две недели. То есть команда свою работу планирует только на этот срок. Почему так? Очень просто: человек плохо умеет прогнозировать, все исследования это подтверждают. Составить реалистичные планы на годы вперед невозможно. Можно ставить долгосрочные цели, это правильно. Но просчитать, что конкретно и когда ты будешь делать, получается максимум на месяц. Команда строит работу так, чтобы произвести в этот отрезок времени целостный и жизнеспособный продукт, который можно отдать клиенту или вывести на рынок.

— Давайте разберем ситуацию на простом примере — создании сайта.

— Давайте. Как он создается при классическом поэтапном подходе, который получил название waterfall? Приходит в компанию заказчик и рассказывает о своих желаниях: хочу красивый дизайн, все виды оплаты, каталог товаров на четыре тысячи наименований, чат… «Ну хорошо, — говорят разработчики, — давайте все детализируем и задокументируем». Пишется толстенная кипа бумаг, делается множество презентаций. Все это несется дизайнерам, потом переходит к разработчикам, потом к тестировщикам… В итоге что получается: пока все детально расписывали — прошел месяц, пока рисовали — еще месяц, в разработке у девелоперов сайт с огромным количеством товаров застрянет еще на полгода точно. Тестировщики забрали недели четыре. В итоге длительность производства сайта составила восемь месяцев. За это время случилось что? 

— Запустилось еще пять подобных сайтов.

— Совершенно верно, а ваш еще и морально устарел. Потому что технологии меняются стремительно. Придерживаясь идеологии agile, мы за две недели, максимум за месяц, подготовим какую-то одну продуктовую линейку к размещению на сайте, сделаем доступными самые распространенные способы оплаты, создадим пробный дизайн и выпустим продукт на рынок. Потому что работа будет вестись не поэтапно, как в случае waterfall, а короткими спринтами, каждый из которых вмещает все этапы создания продукта. Группа из разных специалистов во главе с владельцем продукта, который видит общую картину и несет ответственность за конечный результат, садится вместе и начинает все обсуждать. Например, дизайнер предлагает идею внешнего вида сайта, а разработчик тут же обдумывает способ ее реализации. Или, наоборот, сразу говорит: «То, что ты предлагаешь, технически выполнить невозможно». В итоге в конце каждого спринта получается MVP (minimum viable product) — минимальный продукт, готовый к жизни и реальному тестированию на рынке.

— А как работает agile в крупных корпорациях?

— Здесь начинается самое интересное. В больших организациях есть много задач и продуктов, над которыми необходимо работать одновременно. Поэтому весь коллектив разбивается на множество небольших команд — иногда на десятки или даже сотни. Они, в свою очередь, объединяются в так называемые «племена». Количество команд, которые могут образовывать «племя», ограничено десятью, максимум двадцатью. В итоге в каждую из больших групп входит до ста-двухсот человек. Это тоже научно обоснованное число: при нем еще можно поддерживать социальные связи без ущерба для работы. При большем количестве участников «племени» эффективность падает.

— Как «племена» между собой взаимодействуют?

— Они начинают договариваться. Для этого придуманы определенные церемонии. Например, утренний 15-минутный стендап — летучка, на которой можно «сверить часы»: понять, кто что делает и нужна ли кому-то помощь. До начала проекта — спринта — осуществляется планирование, на которое отводится часа два. А на финише демонстрируются результаты работы. На эту презентацию может прийти кто угодно, даже внешние пользователи. И в самом конце делается ретроспектива, обсуждение работы: что получилось, что не получилось и как это исправить. 

— Заказчик вовлекается в проект?

— В идеале — да. Даже если это две разные организации, они все равно должны формировать единую команду. Также могут участвовать сторонние специалисты, если в них есть потребность. Допустим, я банк и у меня не хватает своих разработчиков или дизайнеров. Идеальное решение — я привожу привлеченных специалистов к себе в офис или сам иду к ним и мы работаем вместе.

Важно понять, что построение agile-команд практически нивелирует иерархию. В каждой группе есть лидер, и на этом, собственно говоря, начальники заканчиваются. Дальше идет генеральный директор, собственник. Обычно получается три-четыре уровня управления. Такой способ взаимодействия еще раз наглядно показывает, что люди прекрасно умеют между собой договариваться и самоорганизовываться.

Agile — это, конечно, история и о технологиях. Любая доработка IT-продукта моментально становится релизом, те же Amazon и Google выкатывают тысячи обновлений ежедневно. Но в первую очередь это история о людях, о культуре доверия. Причем как внутри организации, так и вне ее: под зонтиком agile умещается в том числе клиент, которого очень внимательно слушают, пытаются максимально понять его запросы, мысли и мечты. То есть в таких группах очень развита эмпатия.

— Это все красиво звучит, но насколько в нашей стране работает? Особенно в банках, где обычно очень сильна властная вертикаль и без бумажки мало что можно сделать, как мне кажется. Готовы ли наши компании меняться?

— За свою карьеру я сотрудничал со многими международными компаниями — южноафриканскими, европейскими, азиатскими, так что мне есть с чем сравнивать. Могу с уверенностью сказать, что в этом плане Россия не уникальна. Идеология «без бумажки ты никто» не чужда всем. В каждой стране эту проблему решают по-своему, но практически всегда успешно.

Что касается банковской сферы, то она действительно особенная. Здесь речь идет о деньгах людей, что накладывает на финансовые организации огромную ответственность и порождает массу регулирующих документов. Банки не могут соглашаться на компромиссы по надежности, по вопросам защиты клиентов, поэтому нужно внимательно смотреть на те области, где планируется внедрять agile-подход, и понимать, какие типы контроля необходимо в него встроить. 

— Назовите самые распространенные заблуждения, связанные с agile.

— Одно из самых популярных: agile не предполагает «архитектуры», генплана, каждый делает что хочет. Это, конечно, не так. Люди немного по-другому работают с «архитектурой», но общую картинку обязательно получают. Другое заблуждение — вообще нет документации. Она есть, но только самая необходимая, и вводится по мере надобности, а не вся сразу на старте проекта. На самом деле при правильном применении agile дает большую прозрачность, чем традиционные методы работы. 

— Мне кажется, львиная часть документов в современных компаниях создается для снятия ответственности. «Я две недели назад написал служебку, Вася на нее не отреагировал, его вина». Или: «Я это не обязан делать, у меня и документ имеется»… 

— Вот именно. Избыточная документация обеспечивает не реальный контроль над ситуацией, а скорее его имитацию. Правильно выстроенный agile позволяет всем вовлеченным сторонам видеть картину в целом и реально участвовать в том, что происходит.

Еще один важный момент: agile обязательно включает в себя элемент доверия, дает людям возможность безопасно экспериментировать. Потому что работа движется «перебежками», и если кто-то напортачит, то несильно. При этом во время экспериментов рождаются те самые инновационные идеи, которые могут вылиться во что-то более глобальное. Также свобода творчества делает людей счастливее. Когда я задаю себе вопрос, чем именно занимаюсь, то отвечаю на него так: я стараюсь делать гигантские корпорации более человечными, а сотрудников — счастливыми. В компаниях, перешедших на agile, людям становится приятнее работать.

— Вот приходите вы в организацию и с чего начинаете делать ее agile-ориентированной? 

— Есть два магистральных направления: сверху вниз и снизу вверх. В чем заключается первый подход. Руководители организации решают жить по-новому. Они садятся — с консультантом или без — и планируют заново всю структуру. Делят людей на команды, объединяют их в «племена», обучают сразу всех сотрудников новому подходу к работе, подкручивают корпоративные процессы во всех областях — от HR до финансирования. Этот подход хорош тем, что предполагает масштабные изменения, которые дают быстрый результат. Вся организация делает большой скачок, не возникает проблем с тем, что кто-то уже перешел на agile-рельсы, кто-то еще нет. 

Другой подход — снизу вверх. В организации создается одна команда, которая проходит обучение и начинает работать по-новому. Остальные сотрудники, видя довольных жизнью коллег с горящими глазами, говорят: «Мы тоже так хотим!» И постепенно, по цепочке, вся организация становится agile. Этот путь более органичный, но долгий.  

— С плюсами все понятно, а есть ли какие-то минусы, подводные камни?

— Agile — это во многом вещь из области культуры, и бывают люди, которые просто не готовы к переменам. Самое интересное, что в крупных организациях ими оказываются менеджеры среднего звена. Они держат ключевые контрольные точки, которые в новой реальности не нужны, из-за чего такие сотрудники чувствуют себя некомфортно.

Переход на agile требует изменения мотивации людей. При этом подходе не применяются, например, индивидуальные KPI, потому что результат работы — командный. Для кого-то это отличная новость, для кого-то не очень. 

Еще одна сложность возникает при попытках «воткнуть» agile в каждую нишу, в каждую сферу деятельности. От этого возникают неправильные трактования, непонимание того, что может дать применение этой методики, а что нет. 

— В каких сферах лучше не применять agile?

— Так как это зонтичная система, отдельные ее компоненты можно интегрировать в любую отрасль. А целиком agile неприменим, например, в тех сферах, где сделать конечный продукт за две недели просто невозможно. К примеру, нельзя построить за это время ракету или возвести крупное инженерное сооружение. Но сама идея работы в кросс-функциональных командах, нарезки рабочего процесса на спринты и проведения agile-церемоний подойдет для любой отрасли.

Фото: Надя Дьякова

Мы на facebook

2017 © Finparty
Использование материалов Finparty.ru разрешено только при наличии активной ссылки на источник.
ООО «Информационное агентство Банки.ру».
Карта сайта
Карта тегов
Дизайн — «Липка и друзья», 2015