Как увеличить производительность команды за счет сотрудничества
Казалось бы, все знают, что сотрудничество необходимо для продуктивной работы коллектива. Все знают — но лишь единицы готовы сотрудничать сами в полном смысле этого слова.
Казалось бы, все знают, что сотрудничество необходимо для продуктивной работы коллектива. Все знают — но лишь единицы готовы сотрудничать сами в полном смысле этого слова. Я решил еще раз напомнить о том, почему взаимодействие внутри и за пределами команды так важно; рассказать, как отличить подлинное сотрудничество от имитации, и привести несколько примеров из практики, когда внедрение принципов сотрудничества приводило к кратному росту эффективности.
Почему важно сотрудничать
Ответ прост: это повышает производительность труда и снижает издержки. В условиях, когда рынок тех же IT-специалистов перегрет, дешевле и проще настроить внутри компании правильное взаимодействие и следить за тем, как команды учатся, растут, перенимают опыт и с энтузиазмом ищут пути решения задач, — нежели перекупать «звездных» специалистов, мотивировать их высокой зарплатой и ждать, когда их перекупит кто-то с более выгодным предложением.
Зачем сотрудничать, когда есть регламент?
Неудивительно, что кризис сотрудничества часто наблюдается в компаниях с большими бюджетами и зарплатными фондами: крупных ретейлерах, банках. Там полагаются на регламент, и часто вся работа построена вокруг постановки и приемки задач. Схема, при которой ставится задача, затем в пяти письмах уточняется ее исполнение, и в результате простое решение вместо получаса занимает день-два, крайне затратна по времени. Кажется, что если отлажены все бизнес-процессы, это уже ключ к продуктивности, но на деле нужна активная вовлеченность самих участников процесса. И даже если есть команда, работающая по agile, с активным сотрудничеством внутри, — при общении с другими отделами и заказчиками она вынуждена сталкиваться с отсутствием культуры кооперации и всякого желания сотрудничать.
Что важнее команда или личный KPI?
Есть второй проблемный тип команд и компаний: когда коллеги убеждены, что они сотрудничают, а на самом деле это не так. Этих гораздо больше, чем первых. Например, может быть ситуация, когда у нескольких человек в команде в KPI поставлены индивидуальные задачи, а не командные. А от KPI зависит бонусное вознаграждение. Логично, что при таком раскладе человек берет в приоритет свои персональные задачи, а командные выполняет по остаточному принципу. Если таких человек в команде несколько, то сотрудничество уже невозможно.
Подлинное сотрудничество построено на четырех основных элементах:
- Достижение согласия.
- Общая цель.
- Обмен знаниями.
- Обучение.
О том, как «перезапустить» команду и наладить взаимодействие, я расскажу на конкретных примерах из своей практики построения команд.
Достижение согласия
В одной команде первая же ретроспектива выявила ряд сложностей:
- команда использовала голосование консенсусом, но многие голосования проваливались из-за 1-2 голосов «против»;
- в команде были «нытики» — они пытались каждое обсуждение свести в область «у нас это не получится, потому что я так чувствую»;
- в команде были «тролли» — они саботировали каждую новую идею в духе «это не получится, как и всегда».
Мы начали с того, что обсудили механизм консенсуса, где согласие возникает при отсутствии существенных возражений. Следом мы уточнили формулировку слова «возражение» следующим образом:
Возражение — конкретный измеримый факт, который можно доказать экспериментом, данными или статистикой, неоспоримо доказывающий несостоятельность текущего предложения.
Типичные возражения «нытиков» и «троллей» под это определение не подходят, так что их поле деятельности переместилось в курилки и на кухню, а со временем и вовсе эта деятельность сошла на нет: они сами стали обращать внимание других на подобные разговоры и вносить вклад в трансформацию культуры.
Для обоснованных возражений мы договорились предлагать альтернативу. Например:
«Мне кажется, что данная инициатива снизит продажи на 20% и принесет нам миллионные потери — это доказывают предварительные опросы. Можем ли мы опробовать эту инициативу только на клиентах мобильного приложения, ограничить её сплит-тестированием и настроить период работы, чтобы потом проверить результаты?»
Чувствуете, в чем отличие такого подхода?
Общая цель
Для слаженной работы команда должна разделять общее стремление. Основные проблемы при постановке и выполнении целей могут быть следующими:
- цели поставлены руководством сверху, и не все члены команды их знают и разделяют;
- цели поставлены нечетко, размыто и вызывают споры при обсуждениях;
- цели поставлены и понятны, но часть команды их не разделяет и даже саботирует;
- цели не поставлены, каждый в команде ставит собственную цель, командная работа отсутствует;
- цель поставлена, но у каждого члена команды есть своя цель.
Опять же, пример из опыта: команда уверена, что сотрудничает, у нее есть общая цель, однако при ближайшем рассмотрении выясняется, что некоторые члены команды тратят большую часть времени не на общую цель, а на свои отдельные задачи. У системного архитектора была индивидуальная задача поддерживать архитектуру, и за неполадки в ней ему грозил штраф. У другого разработчика были KPI на разработку фич — при выполнении он получал бонус, при невыполнении — штраф. Логично, что замотивированные таким образом, 80% времени они посвящали задачам, от которых зависит их вознаграждение или наказание.
Важно понимать: если у тебя есть KPI, завязанные не на задачи команды, то ты не можешь быть частью команды.
Мы подняли этот вопрос на следующей ретроспективе и обсудили его всей командой. Те, кто не имел бонусов, были благодарны: вторая половина команды пообещала помочь и отказаться от своих KPI на благо общим результатам. После ретроспективы, мы смогли это согласовать с руководством, чтобы зарплата конкретных людей не пострадала и учитывался командный результат. Теперь если команда работала хорошо, то бонусы получали все, пропорционально своему вкладу.
Обмен знаниями
Выше я уже писал о неэффективной трате времени, когда на получасовое обсуждение задачи тратится день-два в переписке. Так, в одной команде при анализе коммуникаций выяснилось, что на уточнения, поиск писем и обновление договоренностей уходило 40% рабочего времени. Все общение при этом происходило в почте, скайпе и вотсапе, вживую сотрудники общались крайне редко.
Для решения этой проблемы мы взяли за правило больше общаться вживую и стараться визуализировать наше общение: делать зарисовки на листочках, доске или флип-чартах. Команда полностью повторила эксперимент, в котором доказала, что наиболее эффективный формат передачи информации — это общение лицом к лицу и вспомогательная визуализация в виде графиков, рисунков и текстов с последующей отправкой их на почту для истории.
Впоследствии в команде прижилась также практика парной разработки, что еще больше повысило уровень взаимодействия.
Обучение
Каждый человек имеет свои сильные стороны и способен в чем-то разобраться лучше остальных. Мы уже прошли стадию с эффективным обменом знаниями — осталось только передать свои уникальные знания тем, кому они нужны.
На ретроспективе с командой мы подняли вопросы:
- Как часто мы помогаем коллегам узнать что-то новое?
- Какие знания нужно приобретать?
Команда договорилась, что в разрезе сотрудничества нужно приобретать знания, которые приблизят нас к достижению цели. Мы начали мыслить не абстрактными категориями развития, а в рамках конкретных компетенций и знаний.
Заключение
Возможно, скептикам эти практики покажутся танцами с бубном, однако цифры доказывают обратное. С командой, в которой мы постепенно внедряли все четыре элемента сотрудничества, на старте скорость была 40 сторипойнтов* в итерацию**; после упразднения системы персональных KPI и ориентации на общую цель скорость выросла до 80 сторипойнтов; внедрили обучение — и ребята стали делать 160 сторипойнтов в спринт. Сейчас они постепенно выходят на скорость в 200 сторипойнтов.
Помните: командный результат всегда намного сильнее, чем результат одного конкретного человека.
Успехов вам!
* сторипоинт (story point) — это относительные оценки объёма работы, трудоёмкость, оцениваемая командой.
** итерация — цикл разработки, состоящий из планирования набора задач, их реализации, релиза, проверки и оценки.

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

Личный опыт человека, который прошел путь от менеджера по продажам мобильных телефонов Nokia до партнёра СкрамТрек. Егор Ткачев рассказывает, как начать работать тренером, какие навыки надо развивать прежде всего, почему важно работать с ментором и где его найти. И, естественно, отвечает на вопрос: Agile — это Скрам или Канбан?

Личный опыт и советы начинающим свой путь в Agile-коучинг, а также скрам-мастерам, находящимся в середине этого пути. Вы узнаете:
— с каких тренингов начать свой путь в Scrum-мастера и Agile-коучи, на что стоит обратить внимание;
— какие мягкие навыки (soft skills) важно прокачивать — наравне с твёрдыми (hard skills) — особенно если вы были проектным менеджером.