Обучение команды основным принципам Scrum. Материал из книги «Эра умных продаж. Как провести аудит коммерческой службы своими силами и оторваться от конкурентов».

Как говорят командиры, отправлять в бой необученное подразделение – преступление. Вести аудит силами необученной команды – глупость.

Как говорят командиры, отправлять в бой необученное подразделение – преступление. Вести аудит силами необученной команды – глупость. Даже по беглому анализу запрашиваемых документов становится понятно, что аудит системы продаж – не самое простое занятие. Самое сложное в данной процедуре – сделать правильные выводы в ограниченный срок (вспомните про «мертвую» стратегию, за которую Джек Уэлч, получивший за свою склонность к оптимизации прозвище «нейтронный Джек», уволил команду аналитиков). Решить эту задачу необходимо также ограниченными ресурсами - силой одной команды. Не аудит, а настоящее реалити-шоу, только цели преследуются другие.

Так вот, команда должна быть как следует подготовлена и обучена. Члены команды должны обладать необходимым опытом и знаниями в области продаж, маркетинга, экономики предприятия и психологии, правда, есть хорошая новость – невероятно глубоких знаний не требуется, достаточно знаний на уровне хорошего опытного сотрудника. Знания, помноженные на командное взаимодействие, способны дать неплохой результат, что называется, с «первого прохода», и если все сделаете качественно, то ваша команда непременно справится! Конечно, если вы преследуете цель получить исключительно экспертные рекомендации и хотите, чтобы аудит проводила опытная команда профессионалов, то наймите консультантов, регулярно проводящих подобные аудиты и имеющих значительные наработки в данной области.

Итак, команда собрана, задачи аудита поставлены, трудоемкость задач известна, доска в trello.com создана (о сборе команды аудита и подготовке доски задач читайте в предыдущих разделах книги). Так что, определенные принципы Scrum команде уже известны. Доска задач – центральный инструмент технологии Scrum. Теперь о принципах и порядке работы с задачами.

Правила Scrum.

Технология проектного управления Scrumбыла создана Джеффом Сазерлендом в 90-х годах для разработки программного обеспечения. Джефф заметил, что актически все проекты, затеваемые крупными компаниями, схожи в одном: они никогда не укладываются в заявленную смету и сроки. На защите проектов рисуются разноцветные диаграммы Ганта, представляются всевозможные графики и обоснования, созданные отнюдь не глупыми людьми, но увы… ситуация повторяется снова и снова. Джефф сообразил, что работать с плохо формализованными задачами нужно совершенно по-другому, ведь любое отклонение от изначального плана рушит всю систему в тар-тарары.

А если задача плохо формализована? Тогда вместо того, чтобы детально планировать каждый шаг, не лучше ли разбить проект на задачи, каждая из которых дает видимый заказчику конечный результат и особенно не углубляться в то, что находится внутри этой задачи? Получаем эдакий набор черных ящиков с понятным результатом. Что там внутри каждого ящика – должна разобраться команда, планировать заранее не нужно, а точнее – бессмысленно, будут значительные корректировки в процессе. Поэтому, основным правилом Scrum является наделение команды полномочиями принимать решения и самим определять, что нужно сделать для решения данной задачи. При необходимости команда может запросить консультации, в том числе, у ТОР-менеджеров, но окончательное решение что конкретно нужно сделать для реализации проекта, команда определяет сама, и никто не должен ей навязывать свою волю. Это – важнейшее правило и отменить его – значит разрушить систему. Итак, команде дается свобода в рамках отведенного дедлайна. Обратной стороной свободы является ответственность, поэтому за результаты отвечает также команда, это – второе важнейшее правило Scrum.

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

Есть еще один важный момент. В команду может попасть человек, который постоянно запускает неконструктивную групповую динамику, провоцируя личностные конфликты в группе, в результате чего, команда вместо сплоченной работы теряет мотивацию. Воздействует такой человек исключительно на эмоциональные струны, дергая за которые, стремится спровоцировать чувство вины, страх или злобу. Известно, что когда эмоции зашкаливают, логика отключается и команда моментально теряет работоспособность. Люди, которые занимаются подобной «раскачкой эмоций», как правило действуют бессознательно – они так привыкли. Раскачивая эмоции окружающих, они создают хаос вокруг себя и извлекают из этого состояния дивиденды, перехватывая на себя лидерство. Но подобное лидерство, может быть, и продуктивное для «манипулятора», вносит хаос в работу команды и демотивирует ее членов, поэтому, если такие люди в команде присутствуют, то лучше «вскрыть» свои опасения заранее и удалить этого человека из группы. Если нужно, группа может свое решение обосновать руководству, но терпеть подобных деятелей в своей среде команда позволить себе не может. Мне понравилось определение Джеффа, который называет таких лидеров «засранцами».  Отсюда четвертое правило – никаких засранцев!

Пятое правило – гибкое перераспределение ролей. Если в ходе работы команды выяснится, что изначально роли распределены не совсем верно, то есть, оказалось, что способности людей где-то были недооценены, а где-то переоценены, команда может оперативно перераспределить роли. Правило пятое – никакого стеснения, никаких «камешков за пазухой» (см. выше – про нежелательные явления группового взаимодействия). Все, что может принести пользу делу, должно быть немедленно внедрено. Группа, конечно, не должна соглашаться на перемены ради перемен (подобное поведение породит лишь хаос), но если предложение выдвинуто, то оно может быть отклонено группой лишь в случае предъявления аргументированной позиции других ее членов. Наличие аргументированной позиции в споре – шестое правило.

Седьмое правило, к стати, одно из важнейших в Scrum – это ритм. Ритм в команде задается инструментами, сценариями и ритуалами. Лишь, поймав ритм и разобравшись с другими шестью правилами, команда начнет продуктивно работать.

Инструменты Scrum.

Сначала об инструментах. Основным инструментом является доска задач. Как уже говорилось ранее, мы в своей практике пользуемся облачным сервисом www.trello.com. Он прост, удобен, бесплатен (на момент написания книги) и для присоединения к нему достаточно использовать google-аккаунт пользователя. На доске задач, как уже говорилось ранее, отображаются задачи в виде карточек и их ответственные (рис. 1). Изначально задачи помещаются в единый список (левую колонку доски), называемую бэк-лог – накопитель задач и назначаются ответственные. В процессе работы ответственные сотрудники могут оперативно переназначены по решению группы, основная идея Scrum– гибкость – не должна быть потеряна.

Доска задач содержит несколько колонок. Первая колонка «бэк-лог» - это общий список задач, куда погружаются карточки с задачами аудита единым списком. Вторая колонка носит название «спринт» (наименования «спринт» и «бэк-лог» предложены создателем метода, поэтому не вижу смысла их менять. Слово «спринт» подчеркивает стремительность выполнения задачи, и то, что группа должна на «спринте» изрядно выложиться. Изначально взято из спортивной практики). Обычная длина спринта – одна или две недели, наш опыт проведения аудита коммерческого блока показывает, что спринт удобно рассчитывать на одну неделю. Колонка «сегодня в работе» нужна для того, чтобы команда определила свою дневную фокусировку в этот день не обращала бы внимания на другие задачи из спринта и уж, тем более, из бэк-лога. В ходе работы команда быстро почувствует свои возможности, возьмет необходимый разгон и начиная со 2-3 спринта начнет планировать свою загрузку довольно точно.

Говоря об инструментах, мы затронули еще одно важное правило Scrum– исключение потерь. Одним из самых распространенных видов потерь является многозадачность. Конечно, нам всем бы хотелось ощущать себя Юлиями Цезарями, с его способностью делать несколько дел одновременно, но только боюсь, что вероятность рождения подобных индивидов существенно ниже  статистической погрешности. Так что, не обольщайтесь. Занимайтесь одной задачей необходимое время, и лишь затем переключайтесь на следующую – в фокусе сознания мы способны удерживать лишь одну задачу одновременно.

При переключении между задачами наш мозг, если говорить упрощенно, совершает последовательно четыре операции: прерывает текущий процесс, обращается к памяти, выбирает там нужные ассоциации с новым процессом и лишь затем запускает его. Если задачи нетривиальные, то на полное переключение нам требуется около 15 минут драгоценного времени. Итак, восьмое правило – по возможности, исключите многозадачность. Конечно, есть вторая грань – усталость от выполнения задачи, что происходит, например, с людьми, работающими на конвейере. Например, наблюдая за своей эффективностью, я ввел для себя правило 1,5-2. Это время в часах, которое я отвожу на выполнение одной задачи без переключения на другую, если, конечно, задача не будет выполнена раньше. Дальше следует переключение, иначе возникает переутомление и, как следствие, потеря эффективности.

Но вернемся к доске задач. Как видите, на рис.1 существует еще пара колонок: «сделано» и «отказались». В колонку «сделано» перемещаются карточки с обозначением задач, которые, по мнению команды уже выполнены, в колонку «отказались» - задачи, которые в процессе проведения аудита потеряли свою актуальность (такое бывает). Тем не менее, карточки, потерявшие свою актуальность, не стоит удалять с доски задач – они могут понадобиться для анализа или вдруг «всплыть» в дальнейшем. Аудит системы продаж для команды, созданной из сотрудников компании – это всегда плохо формализованная задача.

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

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

Рис. 3. «Разворот» карточки задачи на доске аудита, созданной в www.trello.com.

На рис. 3 хорошо видно, что представляет из себя карточка задачи на доске команды аудита. Вверху находится название задачи, далее в графе “Members” добавляются ответственные члены команды, ниже в графе “Description” мы рекомендуем добавлять ссылки на документы, в которых проводится анализ по данной задаче и даны рекомендации. Помните один из главных принципов Scrum? Каждая задача должна приводить к появлению ценности для заказчика. Поэтому, любой анализ, который команда проводит в ходе аудита коммерческой службы, должен завершаться рекомендациями заказчику. Потом все эти рекомендации будут сведены командой в программу внедрения, но это уже другая история – синтез. О синтетической стадии поговорим в конце книги, пока что речь о подготовке к проведению аудита. Далее идет та самая детализация задачи, о которой речь шла чуть выше. Для этого на карточке предусмотрено поле “Checklist”, позволяющее создавать подзадачи. Программа возле каждой подзадачи ставит поле, в котором, при выполнении подзадачи ответственный может поставить галочку, сигнализирующую о том, что подзадача выполнена. Карточка, в которой не все подзадачи выполнены, не может перемещаться в колонку «Сделано». Удобным полем является “Addcomments”, где аудиторы могут указать важные для себя или для других членов команды комментарии.

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

Любое планирование команда аудита проводит с использованием доски задач.

Вторым инструментом, который мы используем в ходе проведения аудита, является единая среда для обработки информации, к которой любой член команды имеет доступ и права редактирования. Наиболее удобной средой для таких проектов, как аудит системы продаж, считаю google-диск по причине уникальной возможности в создании и редактировании документов, электронных таблиц и презентаций прямо в редакторе, находящимся в «облаке». Google-диск, подобно Windows, позволяет создавать структуру папок, доступную всем членам команды аудита в любой момент времени, кроме того, аудиторы могут предоставлять доступ к папкам или файлам другим сотрудникам компании, задействованном в ходе аудита. Удобство облачного хранилища с возможностью обработки файлов заключается в том, что компания может начать внедрять рекомендации аудита еще до его завершения!

Рис. 4. Структура папок проекта аудита в «облаке» Google-диск.

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

Третьим инструментом является чат команды аудита. Он нужен для проведения ежедневных «летучек» команды аудита, а также для оперативной связи членов команды в ходе работы над проектом. Чат должен иметь возможность поддерживать видео- и аудио-конференции команды, а также текстовые сообщения, которые видят все члены команды. По желанию можно организовать чаты и между двумя сотрудниками, решающими частные задачи, общение по которым нет смысла выносить на обсуждение команды – это будет лишь информационный мусор, «белый шум». Не стоит засорять командный эфир потоками лишней информации. В качестве командного чата мы «облюбовали» сервис компании Google “Hangouts”, он также предоставляется бесплатно и поддерживает все необходимые нам функции.

Итак, мы имеем: правила Scrum, которые нужно донести до команды и неукоснительно соблюдать, набор инструментов – сформированная доска задач в www.trello.com, среда для создания документов google-диск и чат Hangouts, которые нужно активировать и удостовериться, что команда научилась ими пользоваться. Осталась последняя вершина нашей триады успеха – это сценарии и ритуалы.

Сценарии Scrum.

Основных сценариев в Scrum, которые могли пригодиться для проведения аудита – три:

- ежедневные брифинги;

- еженедельные совещания;

- ретроспектива.

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

- что он сделал по проекту вчера (результат);

- что планирует сделать сегодня (при этом карточки «сегодня в работе к моменту брифинга должны находиться  на своих местах);

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

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

Администратор проекта строго следит за тем, чтобы брифинг не перерастал в подобное совещание, иначе есть риск потери динамики группой. Если совещание требуется, то на доске задач аудита появляется соответствующая карточка с указанием дед лайна (duedate), до которого совещание должно быть проведено и необходимые решения вынесены. В совещании не обязательно принимает участие вся группа, там должны присутствовать только те сотрудники, которые участвуют в решении данного вопроса.

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

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

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

Далее по очереди раскрываются карточки из колонок «сегодня в работе» и «спринт», ответственный при необходимости корректирует срок выполнения задачи и обозначает помехи, если таковые есть. Группа штурмует способы преодоления помех, в карточки вносятся соответствующие комментарии.

Затем настает очередь «бэк-лога», из которого команда переносит карточки в спринт, назначает ответственного, который ставит срок выполнения задачи по данной карточке.

После того, как команда сформировала следующий спринт и разрешила все вопросы, совещание можно считать закрытым.

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

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

В своих работах Деминг придал своим наблюдениям форму, представив деятельность команд в виде цикла PDCA (англ. «Plan-Do-Check-Act» - планирование-действие-проверка-корректировка). Идеи Деминга лучше всего прижились в послевоенной Японии, став основой японского «промышленного чуда», в японских компаниях этим принципом компании пронизаны сверху донизу, философия постоянных улучшений на всех этажах иерархии японских компаний – основа философии бережливого производства. Так вот, если вы обратили внимание, сценарии Scrum, которые я рекомендую применить к работе команды аудита, полностью соответствуют циклу PDCA:

Рlan: планирование (ежедневные брифинги и еженедельное планирование спринтов);

Do: действия по осуществлению задуманного;

Check: оценка командой колонки «готово» в ходе еженедельного планирования;

Act: ретроспектива и улучшение процессов после ее проведения.

И, наконец, ритуалы. Ритуалы могут быть… самые разные. Очень интересными можно считать ритуалы, практикующиеся в компании «Менло парк», описанные в книге Р. Шеридана «Работа мечты» - его компания одна из первых стала применять принципы Scrumв своей деятельности. У нас как-то ритуалы особо не прижились. Наверное, это можно списать на суровый нрав челябинских мужиков :-) что, конечно, не соответствует действительности, это не более чем штамп телевизионщиков – в Челябинске живут очень приветливые люди, умеющие радоваться жизни. Но надо же как-то объяснить то, что внедрить удалось не все, что планировали. Ох уж эти ментальные ловушки… сам в них иногда попадаюсь. Наверное, просто мы не уделили этому аспекту должного внимания, думаю зря. Ведь человек намного умнее своей головы, а ритуалы позволяют подключить к решению задачи еще и мудрость тела. Так что, делайте выводы.

 

© Антон Кожемяко.

 

 

 


Комментарии

Читайте также

Показать больше записей