История о том, как я внедрял Scrum в отделе продаж и почему для этого стоило использовать Kanban
Несколько лет назад я руководил отделом В2В продаж в компании Vodafone Украина. Отдел состоял из 2 групп менеджеров: одни работали с действующей базой, другие занимались привлечением новых клиентов. Все шло довольно неплохо, но руководство требовало новых побед, а “голова” — новых экспериментов. В этот момент ко мне в руки попала “Красная книжка”.
Как-то так исторически сложилось, что на постсоветском пространстве Scrum считается чуть ли не единственным методом для внедрения Agile подходов. Ну а стать гибче хотят, конечно же, все. Не исключением был и я. Вот только одна беда: Scrum — это фреймворк для создания сложных продуктов, а в моем управлении был процесс оказания услуг…
“Скрам — это фреймворк, предназначенный для разработки, поставки и поддержки сложных продуктов.” — Scrum Guide, 2017
Ходил я с этой дилеммой какое-то время, пока более опытные товарищи мне не подбросили мысль о том, что продуктом или проектом по доставке определенной ценности может быть назван любой процесс, ограниченный во времени и с конкретным итоговым результатом. А для управления им, соответственно, можно уже применить и Scrum.
Вот я и решил попробовать.
Взял группу менеджеров, которая занималась привлечением новых клиентов, в качестве экспериментальной “Команды разработки”. Их квартальный план по доходам назвал итоговым продуктом, который мы хотим получить. Себя “назначил” Product Owner и Scrum Master данного проекта в одном лице.
Далее совместно с командой мы создали стандартную доску с “To Do”, “In Progress”, “Done”, наполнили Backlog задачами и стартовали первый Sprint.
И получилось, в общем-то, неплохо. Backlog был составлен из задач, необходимых для привлечения конкретных клиентов. Цели на недельные Спринты мы брали в виде сумм нового дохода, который планировали привлечь. Ежедневно собирались у Стены на утренние Стендапы и обсуждали планы на день. Подводили итоги Спринтов и обсуждали возможные улучшения на Ретроспективах.
На тот момент я был вполне доволен результатами.
Менеджеры начали брать на себя больше ответственности. Появились разговоры о необходимых улучшениях, которые инициировал уже не я, а они сами. Процесс работы, в целом, стал более прозрачен и прогнозируем и я, как руководитель, начал понимать, где нужна моя помощь в режиме “реального времени”, а не тогда, когда уже надо было тушить пожары.
Я считал, что получил максимум из того, что мог предложить Scrum в моей ситуации. И, скорее всего, это было действительно так. Но сейчас я вижу, что можно было сделать значительно больше с помощью Kanban.
Kanban был создан для управления и совершенствования сервисов и процессов. Весь его инструментарий заточен именно под это.
Так, используя практики Kanban вместо стандартной Scrum доски с тремя колонками, я бы расписал процесс привлечения клиентов значительно более подробно.
Отдельной колонкой стоило описать каждый шаг в работе с потенциальным клиентом. Например, выход на лицо принимающее решение, прояснение потребности, формирование коммерческого предложения и т.д. Это бы дало мне, как руководителю, значительно больше информации о состоянии дел по каждому лиду и не приходилось бы тратить время на дополнительные расспросы во время ежедневных встреч.
Далее стоило бы установить ограничения на количество задач, которые находились в работе на каждой из стадий.
Это решение не очевидно на первых порах, но когда у менеджера 3 клиента в стадии “Рассмотрения КП” и он берется за 4-го вместо того, чтобы дожать уже имеющихся — это определенный сигнал для руководителя. Значительно проще это отслеживать введя правила на Kanban доску, чем в коммуникации с каждым менеджером в отдельности.
Также, применяя Kanban нет необходимости придумывать недельные цели. Абсолютно спокойно можно использовать привычные для всех месячные или квартальные KPI. При этом стоит вести детальную статистику по тому, как каждый лид проходит по вашей стене/системе и на каком из этапов менеджеры испытывают наибольшие сложности.
На основании этой информации можно делать значительно более точные выводы, чем это предполагается в Scrum.
Ну и финальное “неудобство”, которое заложено в Scrum, с позиции его применения в продажах — это командная работа над общей целью.
Какие могут быть общие цели у продажников-одиночек, да еще и с индивидуальными KPI и бонусами? Чтобы их придумать мне приходилось всячески изгаляться и толкать призывные речи о важности общего результата и т.д. и тп. Но получалось так-себе. Настоящий продажник всегда, в первую очередь, мотивирован своим собственным результатом, а не командным.
Kanban этого не требует.
“Управляйте работой, дайте людям организоваться вокруг нее” — Essential Kanban Condensed
Одним из основных постулатом Kanban является утверждение о том, что нужно управлять работой, а не людьми. Нет выделенной роли Scrum-мастера, который должен “коучить Команду быть самоорганизующейся”. При этом есть роль Сервис деливери менеджера, который отвечает за управление всем процессом. Эта роль отлично ложится на функционал начальника отдела продаж и соответствует его обязанностям.
А Kanban-доску можно спроектировать так, чтобы она показывала ход работы по каждому сотруднику в отдельности.
Итого, мои выводы из полученного опыта.
Scrum — это отличный инструмент под заложенные в него изначально цели и задачи. Он прекрасно работает при разработке новых продуктов и при запуске новых для компании проектов.
Но не стоит стараться втиснуть его в уже действующие процессы. Для этого есть другие, специально предназначенные инструменты.
Kanban — один из них. Не единственный, но лично мне нравящийся больше остальных. По какой-то причине он снискал славу очень сложного метода. На мой взгляд, это не так. Все зависит от языка подачи.
Поэтому в рамках этого блога я буду стараться раскрывать практики Канбана максимально доступным образом. Если вам интересно — обязательно подписывайтесь. Если возникли вопросы или замечания по материалу статьи — пишите. С радостью отвечу!
