Ева Беляева, Руководитель отдела разработки продуктов Security Vision
Введение
В этой статье хотелось бы рассказать о неочевидном лайфхаке для поддержания работоспособности команды вдолгую на примерно одинаковом уровне. В своей работе я столкнулась с тем, что команда, которую мне доверили, как-то незаметно очень сильно выросла в количестве и встал вопрос с тем, как наладить коммуникации внутри нее. Задача была в том, чтобы органично вписать в процесс работы взаимодействие инженеров и выстроить сеть поддержки без того, чтобы вынуждать людей общаться.
Неудачная практика: дружи, чтобы работать
Был в моей работе много лет назад довольно неприятный период, из которого можно было вынести выводы только о том, как делать не надо. Этот антипример или антипаттерн заключается в том, что компания или команда ставит человека в тупик, фактически не давая выполнять свою работу по процессу. Например, от человека ожидается использование в своей задаче результата работы его коллег, но никаких рычагов давления на этих коллег у него нет, более того, у тех коллег есть свои, более приоритетные задачи, от которых их с трудом можно отвлечь.
В таком случае человек просто-напросто не может выполнить свою работу – только ждать, или, что еще хуже, постоянно эскалировать вопрос. Проблему решил бы выстроенный процесс, при котором вторая сторона воспринимала бы эти задачи с нужным приоритетом и могла выделить на это время, но в данном случае вопрос решали иначе – мы заводили полезные знакомства с коллегами по ту сторону проблем и для нас начинали делать исключения, идти навстречу и помогать в работе.
Очевидно, что-то в процессах идет не так, если для того, чтобы люди просто делали свою работу, приходится выстраивать хорошие отношения. Проблема не в том, чтобы в принципе это делать, беда начинается тогда, когда без этого условия ничего не работает
Почему это плохо и не работает вдолгую, тоже очевидно: нельзя просто работать свою работу, если с кем-то был конфликт, работа гарантированно не будет выполнена и зависит от личных отношений – вы могли кому-то не понравиться, вам кто-то не понравился – и вот уже это почему-то влияет на то, насколько качественно вы справляетесь со своими задачами. Даже с теми, кто по какой-то причине неприятен, все равно должно быть возможным выстраивание рабочих отношений, которые не потребуют влезания в жизнь другого человека.
Однако, проблема коммуникаций больше и глубже.
Проблема коммуникации
Несмотря на негативную сторону прошлого подхода, проблема остается: люди боятся и стесняются коммуницировать, особенно по работе. Иногда простейшие рабочие задачи растягиваются на несколько дней, если не недель только потому, что кто-то постеснялся задать вопрос другому человеку и копается во всем в одиночку.
Даже хорошие или нейтральные отношения не гарантируют эффективной коммуникации – иногда страх или стеснение останавливают человека от того, что, по его мнению, он может продемонстрировать другому: свою некомпетентность и неумение разобраться в вопросе, хотя на самом деле это не так. Такие проблемы грозят и срывом сроков, и работой не по стандартам и в целом свидетельствуют о том, что у сотрудников отсутствует один из важных навыков для их работы – умение принимать помощь.
Даже если сам сотрудник открыт к тому, чтобы поделиться своим опытом и знаниями, даже если процесс выстроен так, что цепочка эскалаций приводит к этому сотруднику и помощь входит в ряд его рабочих обязанностей – все равно нужно учить людей по ту сторону задачи грамотно использовать этот «рабочий инструмент».
Софтскиллы – это тоже работа
Любое взаимодействие, внутри или вне команды – это навык, который нужно прокачивать. Более того, со временем мы начали понимать, что сотруднику будет гораздо проще воспринимать такое взаимодействие как свою работу, если мы со своей стороны по-честному будем это маркировать как настоящую рабочую задачу.
Чтобы это работало, ни в коем случае нельзя требовать от сотрудника хорошего отношения, выходящего за рамки рабочего – приятельства или дружбы. Наша цель не в том, чтобы сблизить людей, она в том, чтобы убрать между ними барьеры и помешать взращиванию предрассудков.
Люди должны уметь договариваться и тратить на это время. Без того, чтобы наладить контакт заранее, пусть это и требует вовлеченности и рабочего времени, дальнейшие задачи не ускорятся и не упростятся. В этом случае всегда стоит мыслить стратегически, планируя эффективность от введенных действий не прямо здесь и сейчас, а в обозримом будущем. Мы выявили некоторые закономерности, характерные для наших процессов, у вас цифры могут отличаться: для того, чтобы наладить общение между 10 людьми в одной команде ушел квартал, 20 – полгода.
Налаживание взаимодействия внутри команды должно идти сверху, от компании и руководства, это должно стать ее политикой. У нас политика открытости и вовлеченности была с самого начала, но все равно процессы пришлось модернизировать: мы сильно приросли в количестве, и несмотря на то, что сидели мы по-прежнему в одном пространстве, пришлось приложить усилие для того, чтобы не потерять контакт.
Если мы говорим об одной команде, то взаимодействие внутри нее будет вырастать органично при грамотной постановке задач и смене ролей для задействованных сотрудников. С другой стороны, кросс-командное взаимодействие должно регулироваться процессами, отсюда нужно убрать личный фактор нравится/не нравится и упор нужно сделать именно на рабочие моменты.
Где это применимо
В целом, налаживать отношения и убирать барьеры нужно везде. Но вот где наш подход с внутренним нетворкингом приносит или может принести пользу:
· SOC и команды внутри каждой из линий (если они есть) – помогает заранее решить рабочие вопросы и конфликты, до того, как возникнет проблема в ходе эскалации.
· Команды разработки – при разграничении областей разработки нередко сотрудник хорошо знает только свою область, но для того, чтобы выполнять задачи качественно, требуется знание о том, как твой код повлияет на весь остальной функционал.
· Администрирующие команды, вспомогательные для SOC – для того, чтобы знать друг друга «в лицо» и понимать, к кому обращаться по возникшим вопросам.
Главная цель – люди не должны бояться и стесняться обращаться к коллегам с вопросами и давать советы в ответ на просьбу; должны представлять, с кем работают, и кто какими знаниями обладает.
Как сделать это внутренней политикой компании
Мы для себя вывели несколько сценариев внедрения такого подхода в повседневную рабочую жизнь – от встреч до задач, от серьезных подходов до геймификации.
1. Общение и мини-тимбилдинги.
Раз в какое-то время, обязательно рабочее, мы собираем всю команду на маленький тимбилдинг. Смысл в том, чтобы узнать дополнительную информацию друг о друге в комфортном формате и научиться взаимодействовать с разными людьми из команды, подготовить тот самый фундамент, который позволит не постесняться и подойти за помощью в дальнейшем. Прежде чем вводить такую же деятельность, нужно понимать, что это процесс.
Итоговая цель этих встреч – обсуждение текущих проблем и ограничений по остальным, «легальным» задачам, но прийти к этому можно далеко не сразу. Зависит и от размера команды, и от состава, и от задач. Про нас скажу, что команде из 10 человек потребовалось где-то 3 месяца, а команде из 20 – полгода, чтобы перейти от неконструктивного разговора к конструктивному.
Это нормально, если встреча будет использоваться для того, чтобы выговориться, пожаловаться на что-то или похвастаться. Какое-то время уйдет на то, чтобы выплеснуть все яркие эмоции, необязательно негативные, и поделиться с другими чем-то о себе. Здесь главное не отступить назад, когда начинает казаться, что люди просто отдыхают лишние полчаса или час – на самом деле это далеко не так, и как минимум смена действия на социализацию и внутренний нетворкинг помогают перезагрузиться.
Когда разговоры неизбежно перейдут в сугубо рабочую плоскость, чтобы не терять неформальность встреч, можно перейти к смене обстановки и контекста – перенести встречу в парк или разбавить легкой разминкой.
Если у вас тоже бывают моменты авралов (с другой стороны, у кого их нет?), такие встречи полезны еще и тем, что они являются гарантированным островком спокойствия внутри любых дедлайнов – каждому сотруднику нужна передышка время от времени, даже если всё горит. Более того, когда встречи начнут восприниматься чем-то вроде тихой гавани, это отношение перенесется и на остальных коллег, которые при этом присутствуют. Поэтому при прочих равных приоритет будет отдан своей команде и мнению своей команды, что для некоторых ситуаций важно.
2. Общие рабочие активности в игровой форме.
В одной из статей про деловые игры это описано несколько подробнее. Но если коротко – мы воспроизводим сценарии работы с нашими продуктами как от лица заказчиков, так и от лица партнеров. Это часто помогает при брейнстормах фичей для продукта, а также в тестировании итоговых результатов.
Кроме того, это позволяет, во-первых, лучше понять то, что мы делаем и как оно должно работать – что ожидается от продукта. Во-вторых, дает понимание, для чего и для кого мы это делаем – сценарии использования, особенно опробированные после на «живых» заказчиках, дают необходимую для развития обратную связь.
3. Совместные задачи для обмена опытом.
Несмотря на то, что наша большая команда разбита на подгруппы, фундамент, с которым мы работаем, у нас обычно общий. Таланты у ребят тоже различаются, кто-то хорош в аналитике, кому-то легко дается написание сложных запросов. Чтобы в команде не было больших перекосов очень помогает мотивировать людей к обмену опытом. Не ставить таску в стиле «научи А делать Б», а именно ставить людей в пару или в группу, где один человек обладает максимальными знаниями по задаче, а второму нужно научиться.
Мы практикуем разные варианты парного программирования, насколько это возможно при программировании в ноукод-формате, внедряем кросс-ревью не для того, чтобы кого-то отчитать или потыкать носом в ошибки, а наоборот: проводящий ревью как раз может узнать для себя что-то новое, новый способ решения классической задачи или иной подход к процессу в целом.
Иными словами, если люди вынуждены проводить время вместе ради общего дела, со временем КПД всей команды неизбежно возрастет.
Построение отношений – настоящая цель помимо очевидных «выполнить задачу» и «успеть в срок», фокус здесь переходит от качества и эффективности работы к качеству и эффективности взаимоотношений, что в любом случае неизбежно приводит к улучшению первого.
Смена парадигмы при взаимодействии
Наша цель – перейти от парадигмы «там есть кто-то злой и странный, лучше я сам, а к нему не пойду» к парадигме «вот есть там один инженер с прикольным котом, кажется, он умеет писать запросы к SIEM, подойду поспрашиваю».
Иными словами, превращаем это:
В это:
В итоге вместо обезличенных имен перед сотрудником выстроена целая система, «сеть поддержки» из знакомых и понятных ему коллег, которые мало того, что должны помогать ему в его работе (как и он им), так теперь еще и не кажутся недосягаемыми и странными.
Для этого мы как раз и используем все вышеупомянутые способы коллаборации и проводим встречи, неизбежно сближая людей.
Результаты внедрения практики
Коротко о результатах. Некоторые из этих бонусов появились почти сразу после внедрения, некоторых пришлось подождать.
Перераспределение нагрузки и задач – стало возможно более гибко управлять временем каждого сотрудника, а нагрузка стала более прозрачной – люди перестали бояться сказать о том, что чего-то не успевают или что-то не получилось. Спойлер, обманывать тоже не стали, потому что смысла в этом особого не было – кто-то придет на помощь и начнет активно вникать в задачу, она все равно сдвинется с места и станет видно, какой у кого был вклад.
Командная работа внутри отдела – сотрудникам стало еще больше не все равно, что происходит у коллег по цеху. Мы делаем продукты, и делаем их вместе – это значит, что наша задача сделать хорошо всё нашими силами, а не сделать очень хорошо пару вещей, а на остальные закрыть глаза.
Снизился общий уровень тревоги – та самая тихая гавань дала свои плоды в моменты авралов и вала задач, теперь почти любая необходимость «взять и все переделать» или «сделать срочно к показу за два дня» не воспринимается так остро – человек знает, что будет как время прийти в себя, так и время отдохнуть после. Да и, честно говоря, после обмена опытом мы пришли к тому, что у нас стало гораздо меньше переработок там, где это было не нужно – если раньше человек сидел со своим затыком два дня и грустил, теперь ему могли помочь в течение часа.
Понимание взаимодействий – более прозрачная схема команды. А еще приятный бонус – если иногда меняться ролями, становится лучше понятно, чем занимаются коллеги по цеху. В основном, понятно, что работа коллеги – не чепуха и такая же сложная, как и твоя собственная, если не больше. Практика обмена задачами помогает не обесценивать друг друга и адекватно оценивать свой вклад в общее дело.
Как изменилась работа
Раньше запросы помощи и вникание в то, что происходит у соседа, возникало несколько хаотично – люди шли или к бывшим коллегам, которых они знали раньше, или к тем, с кем когда-то учились – в общем, находили тех, с кем было что-то общее до прихода в нашу команду. Но безопасный и знакомый – не значит самый компетентный в этом вопросе. Да, две головы лучше, чем одна, да и подтягивание сотрудников к одному уровню компетенций выручает, но все-таки лучше спросить того, кто разбирается в вопросе больше. Неожиданно, но у нас многие скорее боялись попросить о помощи, чем ее предоставить, хотя все внутри себя были готовы подойти, вникнуть и показать, на что способны. Этой энергии буквально не хватало выхода.
Благодаря сериям встреч и обмену задачами мы получили четкую схему запросов и эскалаций внутри отдела на горизонтальном уровне – мы знаем, кто в чем хорош, знаем, кто насколько загружен и какие у кого проблемы. Можно как четко задать вопрос нужному человеку и получить консультацию и помощь, так и в свободную минутку посмотреть пул запросов в ветке помощи и пойти объяснить или настроить.
Ожидаемый плюс – всё меньше вопросов было эскалировано на лидов, а также ушел вал одинаковых вопросов от разных людей. Теперь все были заинтересованы в том, что происходит в разных продуктовых командах и начали запоминать сначала проблемы, с которыми мы сталкивались, а потом еще и пути решения.
Скрывать не буду, в первую очередь это сильно разгрузило меня, но в конечном итоге от этого выиграла вся команда.
Больше проблем у нас было решено совместно, благодаря этому мы получили более эффективный результат и возросшее качество работы. Когда думаешь над задачей один, а еще и если не очень в ней компетентен, зачастую рад уже тому, что оно хоть как-то начало работать и не всегда можешь вернуться к ней для рефактора. Здесь же, когда мы разбирали все последующие шаги отдельно и делились экспертизой, получилось часть задач сделать с первого раза «на чистовик» – хорошо и качественно.
Кроме того, благодаря общению и обсуждениям для каждой задачи находилось множество решений вместо одного-двух, и мы еще и протестировать их успели, чтобы понять, какое эффективно в каком случае.
Выводы
Софтскиллы – это работа.
Нетворкинг – такая же задача, как и остальные, не менее значимая, чем любая другая инженерная или аналитическая задача.
Суть внедрения в рабочий процесс неформального общения в рабочее время в том, чтобы перестать заставлять людей налаживать связи в их свободное время, не давая для этого никаких инструментов и рычагов воздействия.
Попытка сменить формат работы требует относительно долгого ожидания до тех пор, пока она не начнет приносить первые плоды, но конечный результат того стоит.
.jpg)
