Айтишники плохого не посоветуют
Два года назад, когда начал работать в Promo, я понятия не имел, что такое Agile, Scrum и Kanban. Меня волновали огромное количество недовольных клиентов и бесконечный поток «пожаров», которые нужно было тушить.
Агентство было молодое, росло, как на дрожжах, выигрывая тендеры один за другим. Мы боролись за крупные корпорации с хорошими бюджетами и выгодно отличались от конкурентов красивыми презентациями и проработанным подходом. Наша техническая экспертиза опережала менеджерские навыки. Поэтому для меня как ответственного за удовлетворенность клиентов эти победы превращались в бесконечные войны. Проблемы с выполнением обязательств начинались практически сразу. В таком положении не хотели оставаться ни клиенты, ни сотрудники, ни я. Поэтому нужно было что-то менять.
Разгадать ребус
К Agile мы пришли не сразу. Поначалу хотелось найти толковую программу по управлению проектами, тогда ошибочно казалось, что в этом дело. Но, по мере изучения софта, все больше натыкался на статьи про Scrum. Я подумал, что айтишники плохого не посоветуют, и команда руководителей Promo отправилась на курсы.
На учебе было здорово и интересно, играли в игры, клеили стикеры. Затем вернулись в офис, начали думать, как эти айтишные штучки применить в нашем бизнесе. Все кейсы, обучающие видео и книги об Agile написаны про IТ и для IТ. Кто наши стейкхолдеры? Что такое работающий продукт в маркетинге? Этот ребус мы разгадывали полгода на затяжных вечерних мозговых штурмах, а днями налаживали работу тестовой команды одного из наших ключевых клиентов.
Два наиболее сложных барьера на пути к Scrum-командам – создать:
— новую парадигму задач;
— новую структуру организации, разрушив вертикальную структуру.
С этими проблемами столкнулись многие адепты Scrum в non-IT, а без этого полноценная трансформация невозможна.
Новые парадигмы задач
Слово «инкремент» в Scrum-гиде встречается 36 раз. Это – конечный продукт команды разработки, работающая добавочная ценность к продукту. Мы не пишем программный код, у нас нет тестировщиков. Наш продукт – это позиции в поисковой выдаче. Как быть?
Начали с определения стейкхолдеров. В SEO это – поисковый алгоритм Google, именно он принимает решение поднимать позиции данной страницы сайта или нет; интернет-пользователь, поведение которого оценивает Google для принятия решения; и, конечно же, заказчик, у которого могут быть особые пожелания.
Инкремент – это задачи, которые влияют на конечного стейкхолдера. Например, мы написали уникальные тексты для страницы сайта, согласовали их с клиентом, получили за них деньги. В данном случае это не будет является инкрементом, поскольку тексты будут работать на рост сайта, только когда их разместят на нем и откроют для поискового робота.
Определение стейкхолдеров и инкремента помогло изменить парадигмы задач, сделав их ориентированными на результат. Это позволило ставить правильные цели на спринт и выполнять обязательства по контрактам. Мы избавились от бесполезных задач и обрели осмысленный подход в работе.
Новая структура компании
Scrum подразумевает работу с кроссфункциональными командами, которые производят инкремент и работающий продукт. Самая распространенная ошибка – это взять отдел и назвать его командой, ничего при этом не меняя. Мы сразу поняли, что команды нужно объединять вокруг целей стейкхолдеров, и сделали из 5 отделов – 10 команд. Но ошибок избежать не удалось.
Мы собрали команды вокруг клиентов и под продукты, которые купил клиент, наполнили их техническими специалистами. Ошибка была в том, что команда постоянно раскалывалась на продуктовые направления, а мы видели в этом лишь нежелание команды взаимодействовать, недоработки Scrum-мастера, саботаж членов команды. Затянутое планирование спринта, скучные стендапы – это были проблемы, которые мы регулярно поднимали на ретроспективе. Все заработало только тогда, когда мы пересобрали команды под продукты, а не под клиентов. Если клиент покупал несколько продуктов, например, контекстную рекламу и SEO, то у него были две команды и два аккаунт-менеджера. Команды стали более продуктивными, теперь ими стало возможно управлять всеми инструментами Scrum.
Когда разобрались с составами команд, встал вопрос о Scrum-мастере и владельце продукта. Поскольку я был локомотивом реорганизации и руководителем аккаунт-менеджеров, Scrum -мастеров я определил сам из отдела менеджеров. Они были вне команд, фасилитировали процессы и помогали разруливать критические моменты с клиентами.
Спорной ролью оказался «владелец продукта» – специалист, который, с одной стороны, общается с клиентом и определяет ценность задач, а с другой, – объясняет командам, что нужно сделать и принимает работу –инкремент.
На первый взгляд, это – аккаунт-менеджер, но у него недостаточно технической базы, чтобы определять ценность задач, а, зачастую, и определять сами задачи. Но технический специалист не должен тратить время на общение с клиентом, это – обязанности аккаунт-менеджера. Крутые технические решения – это наш конек, поэтому владельцами продукта стали выходцы из технических отделов. Это – лучшие технари агентства, которые готовили стратегии для клиентов, придумывали тот самый работающий продукт.
Достижения
- Оборот компании вырос в 3 раза. Scrum – напрямую не влияет на оборот, но благодаря этому мы смогли удерживать клиентов и попадать в их ожидания.
- Удовлетворенность клиентов улучшилась на 30%.
Недостатки
- Не все готовы меняться. Звучали фразы: «Зачем мне идти на планирование? Я и так знаю, что мне надо делать». Таких сотрудников пришлось потерять, мы не увольняли никого, сами ушли. И, как правило, это были специалисты выше среднего уровня, те, которые знают себе цену.
- Долго. Весь процесс занял больше года.
- Удорожание процесса за счет выведения новой должности «владелец продукта».
- Сложно распределять по командам клиентский портфель. Например, пришел клиент, который требует 40 часов команды в месяц, а у меня есть 4 команды по 10 часов свободных в каждой. Без перетасовок – никак, а это всегда болезненно для сработанной команды. В то время как в вертикальной структуре с отделами – это элементарная задача.
Преимущества
- Прозрачные процессы: для клиента и руководства.
- Удобный расчет рентабельности проектов и команд.
- Сплоченные команды. Мы многих потеряли, но это лишь укрепило команды – «выпустили» яд.
- Снижение риска срыва сроков и проектов. Уменьшилось количество задач «на вчера».
- Довольные клиенты.
- Позитивно влияет на имидж агентства. Клиентам интересно слушать наши Agile-рассказы на встречах.
- Нет дорогостоящих вложений, кроме времени топов.
Полгода назад я покинул Promo. Но, чем бы я теперь ни занимался, уже не представляю, как можно работать без Agile-подходов. Удачи!
Виталий Цимбалюк, экс-директор по клиентскому сервису интернет-маркетингового агентства Promo