Организация нетворкинга внутри команд для повышения эффективности

Введение

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

Неудачная практика: дружи, чтобы работать

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

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

Очевидно, что-то в процессах идет не так, если для того, чтобы люди просто делали свою работу, приходится выстраивать хорошие отношения. Проблема не в том, чтобы в принципе это делать, беда начинается тогда, когда без этого условия ничего не работает.

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

Однако, проблема коммуникаций больше и глубже.

Проблема коммуникации

Несмотря на негативную сторону прошлого подхода, проблема остается: люди боятся и стесняются коммуницировать, особенно по работе. Иногда простейшие рабочие задачи растягиваются на несколько дней, если не недель только потому, что кто-то постеснялся задать вопрос другому человеку и копается во всем в одиночку.

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

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

Софтскиллы – это тоже работа

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

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

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

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

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

Где это применимо

В целом, налаживать отношения и убирать барьеры нужно везде. Но вот где наш подход с внутренним нетворкингом приносит или может принести пользу:

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

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

• Администрирующие команды, вспомогательные для SOC – для того, чтобы знать друг друга «в лицо» и понимать, к кому обращаться по возникшим вопросам.

Главная цель – люди не должны бояться и стесняться обращаться к коллегам с вопросами и давать советы в ответ на просьбу; должны представлять, с кем работают, и кто какими знаниями обладает.

Как сделать это внутренней политикой компании

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

• Общение и мини-тимбилдинги.

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

Итоговая цель этих встреч – обсуждение текущих проблем и ограничений по остальным, «легальным» задачам, но прийти к этому можно далеко не сразу. Зависит и от размера команды, и от состава, и от задач. Про нас скажу, что команде из 10 человек потребовалось где-то 3 месяца, а команде из 20 – полгода, чтобы перейти от неконструктивного разговора к конструктивному.

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

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

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

• Общие рабочие активности в игровой форме.

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

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

• Совместные задачи для обмена опытом.

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

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

Иными словами, если люди вынуждены проводить время вместе ради общего дела, со временем КПД всей команды неизбежно возрастет.

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

Смена парадигмы при взаимодействии

Наша цель – перейти от парадигмы «там есть кто-то злой и странный, лучше я сам, а к нему не пойду» к парадигме «вот есть там один инженер с прикольным котом, кажется, он умеет писать запросы к SIEM, подойду поспрашиваю».

Иными словами, превращаем это:

В это:

В итоге вместо обезличенных имен перед сотрудником выстроена целая система, «сеть поддержки» из знакомых и понятных ему коллег, которые мало того, что должны помогать ему в его работе (как и он им), так теперь еще и не кажутся недосягаемыми и странными.

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

Результаты внедрения практики

Коротко о результатах. Некоторые из этих бонусов появились почти сразу после внедрения, некоторых пришлось подождать.

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

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

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

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

Как изменилась работа

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

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

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

Скрывать не буду, в первую очередь это сильно разгрузило меня, но в конечном итоге от этого выиграла вся команда.

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

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

Выводы

Софтскиллы – это работа.

Нетворкинг – такая же задача, как и остальные, не менее значимая, чем любая другая инженерная или аналитическая задача.

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

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