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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теперь осталось обучить команду.

Основное в подготовке к проведению аудита:

1.Решите, что лучше – взяться за проведение аудита коммерческой службы самостоятельно, либо пригласить профессиональных консультантов? Оба решения имеют свои плюсы и минусы.

2.Если решили проводить аудит своими силами, то соберите проектную команду аудита.

3.Команда аудита включает в себя:

   a.руководителя;

   b.администратора;

   c.специалистов-предметников;

   d.представителя заказчика.

4.При подборе команды следует принять во внимание:

   a.уровень компетенций членов команды;

   b.уровень формального интеллекта;

   c.уровень ответственности;

   d.уровень эмоционального интеллекта;

   e.распределение функциональных ролей (PAEI);

   f.потенциал высокоранговости.

5.Члены команды должны договориться о ролях и порядке работы;

6.Команду следует представить заказчику и договориться о порядке ее взаимодействия с руководством, самостоятельности, сроках и результатах. Команде аудита нужен «зеленый свет», никто не должен противодействовать ей сокрытием информации или каким-то иным путем;

7.Команде следует внедрить методы и инструменты Scrum, а именно:

   a.создать доску задач;

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

   c.проговорить между собой правила командной работы и договориться следовать им (в книге я привел лишь основные рекомендации, правила могут быть и иные, но не следует покушаться на самостоятельность команды. Правила должны работать на эффективность работы команды, а не против нее);

   d.договориться о сценариях работы:

      i.определить порядок проведения ежедневных брифингов;

      ii.договориться о проведении совещаний по результатам спринта;

      iii.раз в две недели проводить ретроспективные совещания;

      iv.если нужно, то ввести ритуалы.

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