Фреймворк для бизнес-команды: Канбан-Scrum-OKR

Бизнес хочет зарабатывать деньги, желательно вкладывая меньше ресурсов. При этом у бизнеса есть накопленный опыт, который зафиксирован в ряде методологий. В зависимости от типа проекта подбирают те практики, которые ему подходят и позволяют сэкономить ценные ресурсы. Однако, большая часть существующих фреймворков заточена под IT-разработку.

А вот у операционной части IT-бизнеса (маркетинга и продаж в широком смысле) есть большой соблазн взять лучшие практики себе. Что из этого иногда получается — выжимка из нашего опыта в UIS.

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

Почему он появился у нас и вообще почему это, по моему мнению, тренд.

Говоря менее метафорично, имеющихся средств автоматизации в виде CRM не хватает для организации рабочего процесса команды вокруг четкого достижения поставленной цели (условно, плана квартала или года, как это бывает в продажах). Забегая вперед, для декомпозиции этой цели на пошаговые задачи в привязке к точным срокам и времени исполнения. То есть для всего того, что в имеющихся фреймворках (как видится завистливым взглядом операционного директора со стороны) так четко выстроено в IT-команде — разве что с иными терминами.

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

Итак, с чего мы начинали. Для более осязаемой зарисовки «боли» оставлю тут табличку в Excel, которую рядовой сотрудник отдела маркетинга ежедневно отправлял своему руководителю, частично дублируя тот же процесс в CRM Битрикс24 (и факт дубляжа помечался в таблице плюсами — это на практике означало, что в задаче несколько исполнителей).

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

Табличка из примера изменялась по формату со сменой руководителей отдела маркетинга, но сути это не меняло.

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

Мы долго прожили с физической Канбан-доской и стикерами, привязав строки доски к сотрудникам, а столбцы к этапам выполнения ими их задач. В какой-то момент времени команда стала распределенной и Канбан-доска переехала в Jira.

По факту, для нас это был апгрейд таск-менеджера, который позволял, во-первых, добиться прозрачности работы именно как команды (когда сотрудники в буквальном смысле видят задачи друг друга) и серьезно улучшить эффективность выполнения задач, потому что теперь мы давали коммитмент реализовать их, опять же, на глазах у всей команды. А еще мы еженедельно и все вместе контролировали то, насколько актуальными были задачи друг друга с точки зрения их соответствия поставленным целям по каждой из зон ответственности отдельных сотрудников (их мы к тому времени научились формулировать по SMART и пересматривали раз в квартал на общекомандном планировании).

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

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

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

Для того, чтобы применить в операционке IT-фреймворк и стать крутыми реализаторами целей, нам следовало перевернуть логику работы и приблизиться к формату процессов разработки. Веховые цели бизнеса умозрительно превратить в своеобразные «релизы», а работу операционной команды декомпозировать на проекты, которые им соответствуют.

К примеру, для моей текущей команды — команды развития проекта по интеграции UIS с Битрикс24 — релизами (эпиками) становились такие задачи, как увеличение числа лидов от партнеров или, скажем, увеличение числа включений клиентов на интеграцию.

При этом задачи в рамках эпиков раскидываются на разных сотрудников бизнес-команды и Канбан-доска строится в разрезе именно ключевых проектов. Личная эффективность уходит на второй план, уступая место фокусу на реализации общих целей команды.

Еще одна сильная сторона Scrum — подстегивание сроков реализации задач. Для этого вводится система планирования по спринтам, которые, как правило, длятся от 1 до 4 недель (у нас 2).

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

С учетом того, что в UIS в Scrum живет несколько бизнес-команд из операционного юнита, а также — классически — команды разработки, то наше спринт-ревью происходит в 2 этапа. Первый — общее собрание всех этих проектов вместе и поочередная презентация результатов. Второй — разделение на отдельные «комнаты», куда могут приходить все желающие (в том числе клиенты), чтобы задать вопросы и оставить обратную связь.

Еще один ритуал Scrum — проводящаяся в конце каждого спринта встреча-ретроспектива. На ней члены команды осмысливают прошедшие две недели с точки зрения того, что им мешало в выполнении задач и могло бы быть улучшено. А также выплескивают эмоции и разбирают конфликтные ситуации, если таковые случались. Подобная штука полезна для того, чтобы в зачатке погасить и убрать моменты, которые могли бы снизить эффективность команды в будущем.

При этом в Scrum зафиксировано несколько базовых ролей, которые могут отражать, а могут и не отражать штатную структуру бизнес-команды (так, скрам-мастера может отыгрывать кто-то из команды или же внешний специалист):

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

Product owner является связующим звеном между командой и заказчиком (в случае с операционным бизнесом это клиенты, партнеры и другие покупатели ваших услуг или продукта). Его задача — максимальное увеличение ценности работы команды. Он же отвечает за бэклог команды — по сути, список задач, необходимых для достижения целей команды и бизнеса, отсортированный по приоритету.

Scrum master — тот человек, который должен помогать команде максимизировать ее эффективность посредством устранения препятствий, мотивирования, помощи продакт-оунеру. Можно считать его этаким менеджером бизнес-команды.

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

В целом, Scrum является одной из наиболее популярных методологий разработки ПО. Но все же это не священный грааль и не волшебная таблетка, которая дает указания к действию во всех ситуациях (к примеру, в официальном описании Scrum лишь указана необходимость оценки времени, необходимого на выполнение работы, но не уточняется вид оценки. Т.е. это может быть и planning poker и другой способ оценки).

Исходя из всей этой гибкости и, по факту, отсутствия формального лидера и руководителя, важно не наступить на некоторые грабли, если надумаете внедрять фреймворк. Мы наступили.

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

Недооценка важности мотивации сотрудников. Лишь небольшая часть сотрудников способна эффективно работать в Scrum без существенных изменений поведения по этому вопросу в ролях Scrum master и Product оwner, если они совпадают с штатными должностями в компании. При том, что команда должна быть самоорганизующейся, это потенциально приводит к неверному использованию Scrum.

Не та команда. Scrum не подойдет для команды, где большая часть действий является рутинными и прибита гвоздями регламентов. Последних вполне хватит для организации процессов. А мероприятия фреймворка лишь требуют лишних затрат времени и не соотносятся с добавленной ценностью Scrum. У нас это касалось части бизнес-команды, которая состоит из аккаунтов интеграторов Битрикс24. В итоге, блок аккаунтинга мы из Scrum вывели и оставили в фреймворке ту часть команды, которая отвечает за лидогенерацию — то есть подразумевает постоянное развитие и изменения.

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

Поэтому с начала этого года мы присматриваемся к методологии OKR (Objectives and Key Results). Это система постановки целей, которая позволяет синхронизировать команду с помощью дерева целей. При этом команда сама ставит себе цели, выстраивая их снизу вверх, и таким образом глубже погружается в то, что ей предстоит делать. Одновременно с этим фиксируются ключевые метрики, которые позволяют оценить вклад сотрудников и прогресс в достижении цели.

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

И пытаемся примерить на себя, например, историю о том, что по OKR цель, выполненная на 70%, считается отличным показателем. И вообще невыполнение цели на 100% совершенно не считается недоработкой и поводом срочно демотивироваться. Лично меня, как перфекциониста по натуре, это все еще психологически триггерит :)