Мнения об Agile до сих пор разнятся: одни считают эти методики «серебряной пулей», другие же заявляют о полной их бесполезности. В рамках конференции «Ночь на Ивана Купалу», организованной клубом ИТ-директоров «я-ИТ-ы», Михаил Кудашев, руководитель компании «Реалайз» (выделившееся ИТ-подразделение производителя ювелирных изделий SOKOLOV), рассказал о своем опыте использования гибких методик. Он полагает, что каждая команда должна идти своим путем — эффективный Agile у каждого свой и зависит от мировоззрения человека. В штате «Реалайз» 80 сотрудников, объединенных в семь команд: шесть команд работают по Scrum и одна — по Kanban. Кудашев рассказал о становлении в компании гибких методик, поиске взаимопонимания с бизнесом и пользе открытых зарплат.
— Зачем потребовался переход к Agile, какие были проблемы?
Проблем было несколько. Мы работаем с компаниями, которые производят и продают ювелирные изделия SOKOLOV, сейчас выделились в отдельную ИТ-компанию и пробуем автоматизировать все направления: производственный блок, оптовую дистрибуцию, партнерские продажи, маркетинг и трейд-маркетинг — получается несколько крупных областей.
.jpg) |
| Источник: sokolov.ru/sokolov-life/production/ |
В какой-то момент мы поняли, что нам не хватает сплоченности. Компания быстро разрасталась. Когда мы оценили свое состояние по кривой Адизеса (рождение — юность — расцвет — стабильность — бюрократия — смерть), то увидели, что многие наши процессы сильно забюрократизированы. Последствия очевидны: штат растет, не очень понятно, кто чем занимается. Мы постарались до бизнеса донести идею о том, что Agile — объединение бизнеса с ИТ в команды и их разделение по разным областям — поможет компании оздоровиться и вернуть былую скорость.
Найти правильный ориентир нам очень помог визит в Сбербанк. Мы посетили их Agile Home, посмотрели на него своими глазами. И хотя нас не везде пустили, многое нам действительно понравилось. И тогда было принято решение идти тем же путем.
Роль Сбербанка в этой истории действительно велика. В 2015 году я начал говорить о необходимости перемен, но меня не слышали. И вот годом позже, когда Герман Греф дважды громко произнес слово Agile, ситуация изменилась. В 2017 году мы уже запустили первый пилот. Наша команда по автоматизации производственных процессов работает уже больше года, остальные появились чуть позже. То, что Греф на широкой публике употребил слово Agile, не только вывело его из разряда чуть ли не ругательных, но и повлияло на восприятие этих идей бизнесом.
Раньше на все рассказы о преимуществах гибких методик бизнес отвечал что-то вроде: сделай нам CRM и живи сам по Agile. Однако со временем люди поняли, что дело не в системе, которая им нужна, а в подходе — тесном взаимодействии и коммуникациях между ИТ и бизнесом, в изменении мышления. Многое должно измениться: всегда должна быть обратная связь, не должны замалчиваться проблемы. Собрать кросс-функциональную команду тоже непросто, учитывая то, что мы находимся в регионе.
— Вероятно, на практике все оказалось сложнее.
Старт проекта внутри ИТ был сделан «по книжкам». Мы наступали на грабли в течение полугода, внедряя различные гибкие механики — стендапы, планерки и т. п., и наконец поняли, что самостоятельно нам это не осилить. Пришлось привлекать консультантов ScrumTrek. Они согласились провести у нас аудит и предложили пилот по запуску. После бесед с бизнес-руководителями, плотного общения с ИТ-специалистами, а также оценки того, что уже было сделано, они указали направления, которые стоит подтянуть.
Мы собрались вместе с первыми лицами компании и попытались выстроить карту создания ценности всего цикла разработки. Просидели полдня, жутко переругались, толком ничего не добились. Тем не менее это взаимодействие показалось руководству перспективным и позволило принять решение о реализации пилотного проекта.
В качестве пилотного направления выступил производственный блок. В течение трех дней для ключевых заказчиков разработок была организована сессия с отрывом от основной деятельности. В ее ходе была проведена просветительская работа: теория, а также игры, позволяющие участникам понять, почему сложно делать прогнозные оценки, почему не работают технические задания, почему заказчик никогда не знает, чего он хочет. Попробовали разработать видение продукта — нашей внутренней ERP, пытались расставить по приоритетам огромный список накопившихся задач. Мы объясняли людям, почему часто приходится говорить «нет», зачем нужны приоритеты, как определять ценность для бизнеса.
Поскольку у нас появились все необходимые инструменты, уже буквально на следующий день стартовала новая Agile-команда, на сегодняшний день она отработала 40 двухнедельных спринтов. Это до сих пор одна из лучших наших команд.
Мы поняли, что пилот «выстрелил», стали выделять другие области и формировать команды для них. Так, следом возникла команда автоматизации продаж, обслуживающая процессы от поступления готовой продукции на склад до отгрузки оптовому партнеру. Другая команда обслуживает обучающий портал для продавцов. Команды также сформированы для маркетинга, интернет-продаж, поддержки B2B-каталога и личного кабинета партнеров.
Позже выделилась сервисная команда, которая работает чисто по Kanban. Она охватывает все вспомогательные подразделения: общепит, автосервис, строительство, управление персоналом.
— Очень часто идеи в процессе реализации трансформируются. Насколько сильно отличалась первая идея от того, что в итоге было внедрено?
Не скажу, чтобы отличалась сильно. Все-таки, когда берется тот или иной фреймворк (например, Scrum), у него есть обязательные процессы. Однако он не ограничивает вас в дополнительных. У нас даже есть команды, которые по-разному ведут оценку: кто-то работает в пользовательских историях, кто-то дробит их на технические составляющие. В командах разные скрам-мастера, и они организуют работу по-разному. Причесать всех под одну гребенку не получается, да это и не нужно. Некоторые наиболее важные ИТ-показатели мы стараемся транслировать на все команды (например, время вывода продукта на рынок), а бизнес-метрики везде свои в зависимости от обслуживаемого направления. Очень многое зависит и от владельца продукта. Кстати, их поиск и воспитание — отдельная история.
— Эти различия в работе — вынужденная мера или осознанный шаг?
Вы же знаете: строительные инструменты стандартные, а вот то, что сделано с их помощью, может быть очень разным — всё зависит от того, в чьи руки эти инструменты попадают.
Команды включают от 5 до 10 человек. Это живые люди, они неодинаковые. Мы не можем всех заставить ходить строем. Есть особенности и в людях, и в продуктах, и в аудитории, на которую мы работаем.
— Как изначально воспринимался проект внутри ИТ и как он воспринимался бизнесом? Ведь любые изменения порождают сопротивление…
В ИТ он был принят «на ура», и еще на стадии пилота мы постарались зацепиться за людей, близких нам по духу. Проект на производстве показал, что используемые практики вполне жизнеспособны, а дальше все зависит от людей. Не все команды выжили — были и такие, которые приходилось расформировывать и переформировывать. И мы, естественно, натыкались на сопротивление со стороны бизнеса. Учим, объясняем, проводим внутренние тренинги, показываем достигнутые результаты — доказываем, что это работает. Таким образом, обращаем все больше людей в нашу веру. Инициативные, небезразличные люди начинают активно участвовать в нашей жизни, вливаются в ряды самых близких заказчиков.
Надо не подавлять сопротивление, а демонстрировать успешность продвигаемого подхода.
— Что требовалось изменить, где были самые серьезные барьеры?
Первоначально ИТ-команда была территориально оторвана от бизнеса, поэтому требовалось всех людей собрать в одном месте и обеспечить их непрерывное взаимодействие. Распределенная команда — не наша история, в такой команде очень сложно выстроить взаимодействие. Мы были ограничены в площадях. Пришлось переехать, разделиться на команды, посадив ИТ-специалистов вместе с теми бизнес-пользователями, с которыми необходимо непосредственное взаимодействие. Так убирается множество проволочек, писем, совещаний.
Вторая сложность — поиск владельцев продукта. Даже когда удавалось найти грамотного человека, требовалось освободить его от всех остальных задач и сделать так, чтобы он именно «владел продуктом», чтобы 80% своего времени он мог посвятить разбору задач, общению с заинтересованными лицами, осознанию потребностей бизнес-заказчиков и переводу языка бизнеса в понятные программистам термины.
Следующая сложность — максимальное вовлечение заинтересованных лиц. У людей свои графики, многим совершенно неинтересно посещать раз в две недели собрания и смотреть, что для них сделали. Из-за этого команда не получает своевременную обратную связь, не знает о проблемах, которые можно устранить на ранней стадии. Мы чуть ли не насильно приводили людей на такие собрания, уверяя, что это нужно в первую очередь им. И постепенно они вовлекались.
Наконец, большая проблема — внешние бюрократические проволочки. Если в команде есть кросс-функциональные специалисты и мы наделяем их достаточной властью, чтобы они самостоятельно принимали решения, то весь «остальной мир», который работает не так быстро, становится большой помехой.
— Как Agile стыкуется с другими популярными подходами — гибким графиком и удаленной работой? Складывается впечатление, что это противонаправленные тенденции.
Не всегда людей можно физически усадить в один офис. Однако именно от их совместной работы получается максимальная отдача. Если люди распределены, то нельзя сказать, что Agile неприменим вовсе. У меня есть удаленные сотрудники, находящиеся в разных странах. В этом случае как минимум необходим ежедневный стендап по видеосвязи, к которому подключаются все удаленные сотрудники. У нас на стенах висят скрам- и канбан-доски в аналоговом исполнении, а для удаленных специалистов приходится использовать систему управления, позволяющую всем видеть, что происходит с задачами. Это может быть Jira или Trello. Мы, например, используем Kaiten.
Кроме того, удаленных сотрудников все равно иногда приходится собирать вместе. У нас есть ежеквартальное мероприятие под названием «Большая кросс-командная ретроспектива». В его ходе мы смотрим на кросс-командные задачи, формулируем договоренности и даем обещания на последующие шесть спринтов. Кроме того, мы собираемся вместе, чтобы управлять своими проблемами. Наконец, такие встречи приносят удовольствие и повышают командный дух — мы общаемся, понимаем, что работаем на общую цель.
— Agile требует высочайшего профессионализма сотрудников, их мотивированности и ориентированности на результат. Где взять столько героев и что делать с остальными сотрудниками?
Учить. Мы столкнулись с проблемой мотивации и решили сделать информацию о зарплате сотрудников открытой для всех. Выяснилось, что эти зарплаты не всегда справедливы.
Мы посмотрели на модель Spotify и адаптировали ее для наших целей, назвав «чаптеры» гильдиями и введя в них разряды («грейды»). Сейчас у нас четыре гильдии: разработка фронт-энд, PHP-разработка, 1С-разработка и тестирование. В каждом блоке до 14 разрядов, от которых, в числе прочего, зависит зарплата. На каждом из них необходимо владеть определенными навыками, и не только техническими. Начиная с определенного разряда, играют роль и личные качества (soft skills): насколько человек помогает другим командам, сколько занятий проводит.
Внутри гильдий проводится обучение, благодаря чему подтягивается уровень недавно пришедших сотрудников. Мы принимаем много молодых сотрудников практически с нулевым профильным образованием, предлагая базовый оклад и давая возможность за несколько месяцев схватить азы в ИТ. Если он «взлетает», то становится членом команды.
— Чего реально удалось достичь, каковы результаты?
Результаты есть, но перевести их в цифровые показатели довольно сложно. Два главных показателя — сокращение времени выполнения задач (lead time) и сокращение времени вывода продукции на рынок (time to market). Это очень важно, поскольку раньше у нас задачи могли находиться в очереди и по 500 дней. Еще один значимый показатель — производительность. У каждой команды он свой, но мы смотрим, растет он или нет. Наконец, есть бизнес-метрики, привязанные к каждой команде, — выручка, количество пользователей, количество заказов, конверсия.
Мы видим, что у наших сотрудников хороший уровень владения декомпозицией. Если раньше команда выполняла отдельные задания за 9–12 дней, то сейчас этот срок сократился до 3–4 дней. Задача каждого спринта — отдать заказчику «подарочек», тот функционал, с которым можно работать. Таким образом мы смотрим, эффективна команда или нет.
— В целом ожидания оправдались?
Да, оправдались, хотя большой объем работы еще предстоит проделать. Не все направления запущены — мы собираем новичков, кого-то выделяем из других команд и формируем новые продуктовые команды. Таким образом мы масштабируемся.
Не разнятся ли оценки такой «аджайлизации» со стороны ИТ и бизнеса? Подобные ситуации нередки…
Абсолютно верно. Вы же знаете: можно показать, что компания одновременно и рентабельна, и убыточна — все зависит от личности аналитика. Здесь имеют значение субъективные впечатления: доволен ли бизнес произошедшими изменениями или нет. Если бизнес недоволен, значит, зря все это затеяли или что-то идет не так. Если бизнес доволен, надо искать пути дальнейших улучшений. К счастью, в нашем случае бизнес доволен.
— Были ли неожиданные результаты, на которые не рассчитывали изначально?
Были примеры неожиданного роста людей. Например, один из рядовых сотрудников очень быстро стал сначала скрам-мастером, а затем через полгода — владельцем продукта. Будучи очень грамотным аналитически, он боялся общаться с людьми. Преодолев боязнь общения с бизнесом, он сделал скачок вверх.
Однако случалось и так, что нам приходилось расформировывать команды. Основная причина заключалась в том, что показатели эффективности руководителей бизнеса шли вразрез с тем, что делала команда. Возможно, в этом была моя вина как руководителя. Когда проблема обнаружилась, было уже поздно: производительность упала, а на ретроспективе выяснилось, что народ «убит».
— Каким вам видится будущее?
Будем масштабироваться и расширяться в теме Agile, у нас есть еще непокрытые с этой точки зрения области. Сейчас мы всерьез занялись обучением своих сотрудников. Кроме того, у нас имеются собственные проекты, которые мы пытаемся продвигать.
