Участники дискуссии об Agile — о «покусанных эджайлом» и как этот подход делает сотрудников счастливее

13 апреля в Минске состоялся организованный «Про бизнес.» Деловой форум 2017. В нем приняло более полутора тысяч человек, хедлайнером форума выступил Нассим Николас Талеб, один из самых ярких мыслителей современности, автор мировых бестселлеров «Черный лебедь» и «Антихрупкость». Генеральным партнером форума стал Альфа-Банк (Беларусь).

Официальный партнер — А-100 Девелопмент.

Партнер — мебельная компания Pro-Trade.

Одна из дискуссий форума — «Как перейти к Аgile и горизонтальной культуре в компании». Своим опытом во внедрении Agile, в частности Scrum, как одного из методов гибкого управления проектами поделились консультант, основатель сообщества Agile.by Юрий Шиляев, директор компании «АйТи уит», эксперт по управлению проектами Максим Якубович, председатель совета директоров ГК «Белагро» Андрей Милевич и сооснователь и директор ИТ-компании Vizor Games Сергей Бруй.

Мы приводим ключевые тезисы спикеров.

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

Как работает по Agile ИТ-компания — опыт Vizor Games

Сергей Бруй: Мы не решились на холакратию (управление без иерархии и менеджеров — прим. «Про бизнес.»), сохранив неглубокую иерархию. Горизонтальные формы управления мы используем в тех департаментах, где надо быстро принимать решения и адаптироваться под внешние изменения, где удачное решение, принятое быстро, окупает десятки ошибочных.

Но так ведь бывает далеко не всегда и нужно ответить себе на вопрос, где вы хотите гибкости, а где предсказуемости.

Сергей Бруй. Фото: Павел Поташников, probusiness.by

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

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

В ИТ обратная ситуация с рынком труда, нежели в реальном секторе: работодатели не диктуют условия, ведь спрос превышает предложение. Специалисты на рынке есть, но каждая компания начинает искать «под себя» определенный типаж. И тут большие проблемы. Мы, руководство, стали практически HR-ами — много времени уделяем набору сотрудников и определению их в команды.

Мы стараемся искать людей, которые помимо своих hard skills (профессиональных навыков — прим. «Про бизнес.») обладают набором soft skills (личные качества, которые помогают во взаимодействии с людьми — прим. «Про бизнес.») — это эмпатия, возможность коммуницировать, доводить свои идеи до логичного конца. У нас есть команды с абсолютно разным темпераментом, и их участники в других командах работать не смогли бы.

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

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

Как работает Agile не в ИТ — выводы «Белагро» и «ЮрСпектр»

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

Андрей Мелевич и Максим Якубович. Фото: Павел Поташников, probusiness.by — Андрей Милевич и Максим Якубович. Фото: Павел Поташников, probusiness.by

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

Тогда мы пригласили консультанта по внедрению проектного управления и пришли к Scrum-методу. Он подразумевает более частые итерации, и команды стали собираться для промежуточного контроля не раз в квартал, а каждую неделю. Как ни странно, это очень подстегивало. Если контроль был реже, то случалось, что айтишники приносили продукт, который заказчику уже не нужен.

Единственный проект, который я не завел изначально по методологии Scrum — разработка собственной CRM-системы, и я очень об этом жалею. Мы должны были закончить примерно в августе, но не успели, мне постоянно говорили «завтра». Тогда мы начали все заново по Scrum-методу и за три месяца сделали то, что не могли сделать за год.

Контроль касается всего персонала. Сейчас все наши продавцы как на ладони, каждый оцифрован: я вижу их активность, они занормированы. Делает каждый из них 30 звонков в день или 10 поездок в неделю или не делает. Продавец не может открыть свой компьютер, если не сделал то, что должен был сделать вчера. Мы контролируем их ежедневно. Если раньше цифра по исполнению активности в отчете отдела маркетинга, не поднималась выше 50%, то сейчас она приближается к 70%. Или, например, если менеджер по продажам уехал к клиенту, то я вижу, у кого он был и где он сейчас. Ранее у нас бывали случаи, когда продавец сидел на рыбалке в рабочее время — сейчас же мы можем это проследить.

Автоматизировав многие процессы и наладив контроль, мы стали выходить из кризиса и подняли производительность. Не все приняли новый подход сразу, но все были поставлены на рельсы Scrum-управления очень быстро, потому что НЕ agile-команды быстро отстали по результатам от своих коллег.

Юрий Шиляев: Когда «ЮрСпектр» стал менять бизнес-модель и запустил новый онлайн-продукт, с помощью Agile мы стали решать две проблемы:

1. Скорость производства — подготовка материалов занимала до 3 месяцев.

2. Управление продуктом.

Компания создала собственный продукт в онлайне, и к этому времени не обладала компетенциями управления этим продуктом. Это и поиск бизнес-модели, и организационной структуры, и вывод его на рынок. У всего этого нет правильных ответов! Мы стали использовать Agile, чтобы отделить свои фантазии от реальных вещей, на которые можем опереться. И мы раз за разом проверяем наши гипотезы. В пилотный проект «ЮрСпектра» мы подбирали самых мотивированных, но потом стали распределять этих людей по командам и в эти команды набирать «середнячков». Первых членов команд мы называем «покусанные эджайлом» — и они начали «кусать» новых. Так из функциональных отделов и высокой иерархии мы фактически сделали 15 команд. Менеджерская структура очень сильно упростилась.

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

Комментарий Максима Якубовича: Манифест Agile был написан айтишниками, для ИТ-проектов, но ценности могут разделять команды из разных областей бизнеса.

В моей практике есть пример использования Scrum (самый популярный agile-подход) для проекта разработки и запуска новой программы лояльности в компании, занимающейся производством сантехники.

Есть ли проекты, для которых не стоит использовать Agile? Конечно, есть — это проекты, где стоимость внесения изменений в развивающийся продукт проекта очень велика, например, проекты строительства зданий.

Основное преимущество

Максим Якубович: Agile позволяет поднять вовлечение. Короткие итерации означают, что ты не можешь отсидеться — ты у всех на виду. И это делает сотрудника счастливее — когда ты становишься полезным в команде, это мотивирует подтягиваться. Для самого заказчика тоже более вдохновляюще видеть результаты каждую неделю.

Многие компании, которые ранее не были проектными, позже говорят: «До этого мы не понимали, насколько тяжело нам работать вместе, людям из разных подразделений. Работать совместно в команде многие компании не умеют. Agile дает умение работать в команде.

С чем сталкиваются компании, внедряя Agile

Максим Якубович: Я замечаю проблему с двумя ключевыми ролями:

1. Владельцы продуктов (роль одного из членов команды в Scrum, который отвечает за продукт, созданный всей командой — прим. «Про бизнес.»), которые боятся принимать решения. Им постоянно нужно согласовывать каждое решение наверху. Они иногда говорят «мы хотим, но боимся».

2. «Scrum-мастера». Они не принимают решение сами, а учат команду брать на себя ответственность. И вот таких в компаниях мало.

Юрий Шиляев: Главная проблема — культурная. Многие люди внутренне несвободны. Им надо разрешить, сказать, что у них есть возможность принимать решения, они сами отвечают за свое будущее и свое настоящее.

Чтобы решить проблему, сотрудники идут через руководителей до «белого Кремля» на самый верх — и все думают, что в «белом Кремле» есть ответы на все вопросы.

Две роли вызвали наибольшие изменения в кадровой политике. Это появление роли «владелец продукта», который должен принимать решения. По сути, это роль микропредпринимателя. Но традиционная функциональная структура всеми ресурсами выдавливала из себя сотрудников с мышлением предпринимателей, и тут внезапно они понадобились — и их нет.

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

А для роли Scrum-мастеров мы попробовали использовать отдел развития персонала, фактически HR-тренеров. Наше открытие в том, что они чудесно сработали.

Что следующее после Agile

Максим Якубович: Пока у меня нет ответа на этот вопрос, но есть пару мыслей. Должен появиться подход к разработке новых продуктов, который позволит использовать знания, как люди принимают решения (например, описанные в книгах Канемана), об иррациональности нашего выбора при принятии решений о покупках (книги Д. Ариэли).

Scrum впитал в себя все лучшее, что было придумано для командной работы над продуктами в 80−90-е годы. Подход, что придет на смену, должен использовать знания, полученные в 2000—2010 годы.