Как я внедрял Scrum в отделе продаж и почему стоило использовать Kanban — колонка Антона Глазкова
Ранее мы публиковали материал о методах управления проектами Scrum и Kanban. Но теория сильно отличается от практики. Agile-коуч agiledrive Антон Глазков рассказал о собственном опыте внедрения Scrum в отделе продаж, а также объяснил, почему стоило выбрать Kanban.
Несколько лет назад я руководил отделом В2В-продаж в компании Vodafone Украина. Отдел состоял из 2 групп менеджеров: одни работали с действующей базой, другие занимались привлечением новых клиентов. Все шло довольно неплохо, но руководство требовало новых побед, а голова — новых экспериментов. В этот момент ко мне в руки попала «красная книжка» по Scrum.
Как-то так исторически сложилось, что на постсоветском пространстве Scrum считается чуть ли не единственным методом для внедрения Agile-подходов. Ну, а стать более гибкими хотят, конечно же, все.
Я не стал исключением. Вот только одна беда: Scrum — это фреймворк для создания сложных продуктов, а в моем управлении был процесс оказания услуг. Я проходил с этой дилеммой какое-то время, пока более опытные товарищи мне не подбросили мысль о том, что продуктом или проектом по доставке определенной ценности может быть назван любой процесс, ограниченный во времени и с конкретным итоговым результатом. А для управления им, соответственно, можно уже применить и Scrum. Вот я и решил попробовать.
Как внедрял Scrum
Я взял группу менеджеров, которая занималась привлечением новых клиентов, в качестве экспериментальной «Команды разработки». Их квартальный план по доходам назвал итоговым продуктом, который мы хотим получить. Себя «назначил» Product Owner и Scrum Master этого проекта в одном лице. Далее совместно с командой мы создали стандартную доску с «To Do», «In Progress», «Done», наполнили бэклог задачами и запустили первый спринт.
Получилось, в общем-то, неплохо. Бэклог был составлен из задач, необходимых для привлечения конкретных клиентов. Цели на недельные спринты мы брали в виде сумм нового дохода, который планировали привлечь. Ежедневно собирались у «стены» на утренние стендапы и обсуждали планы на день. Также подводили итоги спринтов и обговаривали возможные улучшения на ретроспективах.
На тот момент я был вполне доволен результатами. Менеджеры начали брать на себя больше ответственности. Появились разговоры о необходимых улучшениях, которые инициировал уже не я, а они сами. Процесс работы, в целом, стал более прозрачен и прогнозируем. Я, как руководитель, начал понимать, где нужна моя помощь в режиме «реального времени», а не тогда, когда уже надо было тушить пожары.
Я считал, что получил максимум из того, что мог предложить Scrum в моей ситуации. И, скорее всего, это было действительно так. Но сейчас я вижу, что можно было сделать значительно больше с помощью Kanban.
Почему стоило использовать Kanban
Kanban создан для управления и совершенствования сервисов и процессов. Весь его инструментарий заточен именно под это. Так, используя практики Kanban вместо стандартной Scrum-доски с тремя колонками, я бы расписал процесс привлечения клиентов значительно более подробно.
Отдельной колонкой стоило описать каждый шаг в работе с потенциальным клиентом. Например, выход на человека принимающего решения, прояснение потребности, формирование коммерческого предложения и другое. Это бы дало мне, как руководителю, значительно больше информации о состоянии дел по каждому лиду, а значит мне не приходилось бы тратить время на дополнительные расспросы во время ежедневных встреч.
Далее стоило бы установить ограничения на количество задач, которые находились в работе на каждой из стадий. Это решение не очевидно на первых порах, но когда у менеджера 3 клиента в стадии «Рассмотрения коммерческого предложения» и он берется за 4-го вместо того, чтобы дожать уже имеющихся — это определенный сигнал для руководителя. Значительно проще это отслеживать введя правила на Kanban-доску, чем в коммуникации с каждым менеджером в отдельности.
Также, применяя Kanban нет необходимости придумывать недельные цели. Абсолютно спокойно можно использовать привычные для всех месячные или квартальные KPI. При этом стоит вести детальную статистику по тому, как каждый лид проходит по вашей стене/системе и на каком из этапов менеджеры испытывают наибольшие сложности. На основании этой информации можно делать более точные выводы, чем это предполагается в Scrum.
Ну и финальное «неудобство», которое заложено в Scrum, с позиции его применения в продажах — это командная работа над общей целью. Какие могут быть общие цели у продажников-одиночек, да еще и с индивидуальными KPI и бонусами? Чтобы их придумать мне приходилось всячески изгаляться и толкать призывные речи о важности общего результата. Получалось так себе. Настоящий продажник всегда, в первую очередь, мотивирован своим собственным результатом, а не командным.
Kanban этого не требует. Его основной постулат: «Перестаньте управлять людьми, начните управлять работой». Нет выделенной роли Scrum-мастера, который должен «коучить команду быть самоорганизующейся». При этом есть роль Service Delivery Manager, который отвечает за управление всем процессом. Она отлично ложится на функциональные обязанности начальника отдела продаж и соответствует его обязанностям. А Kanban-доску можно спроектировать так, чтобы она показывала ход работы по каждому сотруднику в отдельности.
Scrum — отличный инструмент под заложенные в него изначально цели и задачи. Он прекрасно работает при разработке новых продуктов и при запуске новых для компании проектов. Но не стоит стараться втиснуть его в уже действующие процессы. Для этого есть другие, специально предназначенные инструменты.