Отрывок из книги А. Кожемяко «Эра умных продаж — аудит своими силами.»

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

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

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

Правила Scrum

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

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

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

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

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

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

© 2016, Ассоциация экспертов системного менеджмента «МихиКо». Все права защищены.

Rating: 5.0. From 1 vote.
Please wait...