Как увеличить производительность команды за счет сотрудничества

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

Почему важно сотрудничать

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

Зачем сотрудничать, когда есть регламент?

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

Что важнее команда или личный KPI?

Есть второй проблемный тип команд и компаний: когда коллеги убеждены, что они сотрудничают, а на самом деле это не так. Этих гораздо больше, чем первых. Например, может быть ситуация, когда у нескольких человек в команде в KPI поставлены индивидуальные задачи, а не командные. А от KPI зависит бонусное вознаграждение. Логично, что при таком раскладе человек берет в приоритет свои персональные задачи, а командные выполняет по остаточному принципу. Если таких человек в команде несколько, то сотрудничество уже невозможно.

Подлинное сотрудничество построено на четырех основных элементах:

1. Достижение согласия.
2. Общая цель.
3. Обмен знаниями.
4. Обучение.

О том, как «перезапустить» команду и наладить взаимодействие, я расскажу на конкретных примерах из своей практики построения команд.

Достижение согласия

В одной команде первая же ретроспектива выявила ряд сложностей:

• команда использовала голосование консенсусом, но многие голосования проваливались из-за 1-2 голосов «против»;
• в команде были «нытики» — они пытались каждое обсуждение свести в область «у нас это не получится, потому что я так чувствую»;
• в команде были «тролли» — они саботировали каждую новую идею в духе «это не получится, как и всегда».

Мы начали с того, что обсудили механизм консенсуса, где согласие возникает при отсутствии существенных возражений. Следом мы уточнили формулировку слова «возражение» следующим образом:

Возражение — конкретный измеримый факт, который можно доказать экспериментом, данными или статистикой, неоспоримо доказывающий несостоятельность текущего предложения.

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

Для обоснованных возражений мы договорились предлагать альтернативу. Например:
«Мне кажется, что данная инициатива снизит продажи на 20% и принесет нам миллионные потери — это доказывают предварительные опросы. Можем ли мы опробовать эту инициативу только на клиентах мобильного приложения, ограничить её сплит-тестированием и настроить период работы, чтобы потом проверить результаты?»

Чувствуете, в чем отличие такого подхода?

Общая цель

Для слаженной работы команда должна разделять общее стремление. Основные проблемы при постановке и выполнении целей могут быть следующими:

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

Опять же, пример из опыта: команда уверена, что сотрудничает, у нее есть общая цель, однако при ближайшем рассмотрении выясняется, что некоторые члены команды тратят большую часть времени не на общую цель, а на свои отдельные задачи. У системного архитектора была индивидуальная задача поддерживать архитектуру, и за неполадки в ней ему грозил штраф. У другого разработчика были KPI на разработку фич — при выполнении он получал бонус, при невыполнении — штраф. Логично, что замотивированные таким образом, 80% времени они посвящали задачам, от которых зависит их вознаграждение или наказание.

Важно понимать: если у тебя есть KPI, завязанные не на задачи команды, то ты не можешь быть частью команды.

Мы подняли этот вопрос на следующей ретроспективе и обсудили его всей командой. Те, кто не имел бонусов, были благодарны: вторая половина команды пообещала помочь и отказаться от своих KPI на благо общим результатам. После ретроспективы, мы смогли это согласовать с руководством, чтобы зарплата конкретных людей не пострадала и учитывался командный результат. Теперь если команда работала хорошо, то бонусы получали все, пропорционально своему вкладу.

Обмен знаниями

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

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

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

Обучение

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

На ретроспективе с командой мы подняли вопросы:

• Как часто мы помогаем коллегам узнать что-то новое?
• Какие знания нужно приобретать?

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

Заключение

Возможно, скептикам эти практики покажутся танцами с бубном, однако цифры доказывают обратное. С командой, в которой мы постепенно внедряли все четыре элемента сотрудничества, на старте скорость была 40 сторипойнтов* в итерацию**; после упразднения системы персональных KPI и ориентации на общую цель скорость выросла до 80 сторипойнтов; внедрили обучение — и ребята стали делать 160 сторипойнтов в спринт. Сейчас они постепенно выходят на скорость в 200 сторипойнтов.

Помните: командный результат всегда намного сильнее, чем результат одного конкретного человека.

Успехов вам!

* сторипоинт (story point) — это относительные оценки объёма работы, трудоёмкость, оцениваемая командой.

** итерация — цикл разработки, состоящий из планирования набора задач, их реализации, релиза, проверки и оценки.