Айтишники плохого не посоветуют

Два года назад, когда начал работать в 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 -мастеров я определил сам из отдела менеджеров. Они были вне команд, фасилитировали процессы и помогали разруливать критические моменты с клиентами.

Спорной ролью оказался «владелец продукта» – специалист, который, с одной стороны, общается с клиентом и определяет ценность задач, а с другой, – объясняет командам, что нужно сделать и принимает работу –инкремент.

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

Достижения

  1. Оборот компании вырос в 3 раза. Scrum – напрямую не влияет на оборот, но благодаря этому мы смогли удерживать клиентов и попадать в их ожидания.
  2. Удовлетворенность клиентов улучшилась на 30%.

Недостатки

  1. Не все готовы меняться. Звучали фразы: «Зачем мне идти на планирование? Я и так знаю, что мне надо делать». Таких сотрудников пришлось потерять, мы не увольняли никого, сами ушли. И, как правило, это были специалисты выше среднего уровня, те, которые знают себе цену.
  2. Долго. Весь процесс занял больше года.
  3. Удорожание процесса за счет выведения новой должности «владелец продукта».
  4. Сложно распределять по командам клиентский портфель. Например, пришел клиент, который требует 40 часов команды в месяц, а у меня есть 4 команды по 10 часов свободных в каждой. Без перетасовок – никак, а это всегда болезненно для сработанной команды. В то время как в вертикальной структуре с отделами – это элементарная задача.

Преимущества

  1. Прозрачные процессы: для клиента и руководства.
  2. Удобный расчет рентабельности проектов и команд.
  3. Сплоченные команды. Мы многих потеряли, но это лишь укрепило команды – «выпустили» яд.
  4. Снижение риска срыва сроков и проектов. Уменьшилось количество задач «на вчера».
  5. Довольные клиенты.
  6. Позитивно влияет на имидж агентства. Клиентам интересно слушать наши Agile-рассказы на встречах.
  7. Нет дорогостоящих вложений, кроме времени топов.

Полгода назад я покинул Promo. Но, чем бы я теперь ни занимался, уже не представляю, как можно работать без Agile-подходов. Удачи!

Виталий Цимбалюк, экс-директор по клиентскому сервису интернет-маркетингового агентства Promo

 

 

Добавить комментарий