Как мы наладили рабочую атмосферу в команде

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

Привет! Меня зовут Вячеслав, я возглавляю отдел системного анализа в банке «Ренессанс Кредит». В этой статье расскажу, как нам удалось построить крутую CRM-команду. Утренние стендапы на 50 человек, сотни задач от десятка смежных команд и совместные тусовки — будет интересно. Поехали, коллеги! ?

Вячеслав Ушаков

Начальник отдела аналитики приложений по взаимодействию с клиентами

Выстроили процесс поиска и найма крутых людей

Чтобы было проще разобраться в том, как мы наладили работу в команде, я разобью процесс на этапы. Первый — поиск и отбор сотрудников на собеседованиях.

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

Кто мы: мы банк, а это значит, что у нас

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

Откуда мы взялись:

Добрая половина команды — выходцы из консалтинга (колыбель, которая взращивает такого рода специалистов, за что ей, конечно, большое спасибо), вторая половина — те, кто выросли внутри компаний-заказчиков. Такое сочетание усиливает наш общий опыт.

Что и как делаем — это проще объяснить метафорой:

• большой и уютный дом мы уже построили (коробка платформы);
• у него отличный фундамент (команда);
• провели в нём газ и воду (различные pipeline в механизме CI/CD);
• время от времени строим целые этажи и террасы (новый функционал) и с удовольствием их обустраиваем (кастомизируем)
• и даже приглашаем соседей на тусовку! ? (смежные системы)

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

А потом узнаю человека, деля собеседование на три части:

Hard skills

• всё про коробку, БД, интеграцию, инфраструктуру;
• ранее приобретённый технический бэкграунд (если таковой есть).

Soft skills — ценности, подход к решению задач и так далее:

• Умение писать документацию (и даже в некоторой степени, любовь к ней). Нужно писать качественные ТЗ и ФТ, которые будут понятны и коллегам, и ребятам из смежных отделов, и заказчикам. Сплошное перечисление технических подробностей или бизнес-терминов — плохой вариант, часть читателей обязательно запутается. Мы стараемся соблюдать баланс в подаче материала.
• Умение доносить информацию. Все вводные, которые поступают в процессе работы: новые требования заказчика, подробности о продукте и так далее — нужно быстро «переваривать» и облекать в понятную форму. Так, чтобы люди не возвращались с бесконечными вопросами и уточнениями по тексту.
• Стрессоустойчивость. В банке работает очень много людей, со своим бэкграундом, характером и манерой общения. Для эффективной работы с ними важно уметь держать свои эмоции под контролем. Допустим, вы задали вопрос, но не получили на него ответ. Что делать? Не доводя до скандала, переспросить человека столько раз, сколько будет нужно, чтобы получить полный ответ. Или привлечь других людей — вплоть до руководителя.
• Пунктуальность. Мы поддерживаем четыре релиза (4, Карл!):проекты, которые только начали прорабатывать аналитикизадачи в разработкето, что успели отдать в тестированиеи, наконец, работающий функционал в Продакшн среде.
• Человек, которого мы берём в команду, должен понимать, что внезапная задержка на его стороне стопорит все последующие процессы. А ещё это подставляет руководителя.
• Работа с возражениями: «разговорный жанр» — это про нас и это обязательно. То, насколько вы умеете защищать свою точку зрения, например, перед заказчиком, насколько вы аргументированы и насколько «подвешен ваш язык» — напрямую сыграет вам на руку (или наоборот).

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

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

Ну а в конце, в открытую без обиняков, я обязательно даю обратную связь (если соискатель, конечно, сам этого хочет):

• что и насколько хорошо знает человек
• что ему надо подтянуть
• соответствует ли его самооценка результатам собеса или нет (если нет, то конечно, это повод серьёзно задуматься, — как нам, так и ему)

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

Допилили онбординг

Итак, мы прособеседовали человека и взяли его в команду. Как помочь ему влиться в процессы?

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

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

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

• «Сходи к Денису, у него есть кое-что интересненькое для твоей виртуалки…»
• «Сходил?» — «Да!»
• «Отлично, что ж, сегодня ты уже сделал полдела! Ещё чуть-чуть и ты будешь в строю», — а в это время у человека прибавились дополнительные гигабайты к жёсткому диску, где «внезапно» обнаружились все необходимые дистрибутивы под рукой ?

Во время онбординга мы, хоть и на удалёнке, находимся рядом с новым сотрудником (считай, дышим в один микрофон :)), помогаем влиться в группу — чтобы ему в дальнейшем было комфортно работать, и в итоге он стал максимально самостоятельным.

Настроили рабочие инструменты

Аналитики — это люди, которые реализуют функционал. Работают с требованиями заказчика, формируют документацию, пишут и согласуют её, и взаимодействуют с разработчиком — чтобы проект вышел в продакшен.

Чтобы все процессы работали, мы, как и большинство аналитиков, используем несколько инструментов:

• в Word пишем документацию и функциональные требования — по большей части для заказчиков;
• в Jira ставим и подробно описываем задачи для разработки, следим за их статусом и временем выполнения;язык запросов JQL — наше всё. Люди, умеющие работать с простейшей выборкой, сортировкой и фильтрацией на SQL (эти два диалекта схожи) здесь однозначно выигрывают и сами себе помогают в работе, создавая многочисленные дашборды:а что у меня в работе “в таком-то статусе”;а дай-ка я найду задачи, над которыми работал пару лет назад;а нет ли у меня входящих консультаций «от такой-то смежной команды по такому-то проекту»;плагины к Jira — мой большой рекомендасьён. И к Confluence тоже, как правило, эта пара платформ всегда живёт вместе:Structure — позволяет построить иерархию задач (эпиков и т.д.) посредством группировки по нужному признаку, работая одновременно с сортировкой и фильтрацией (must have!);Timesheet Reports — инструмент для формирования отчёта по проекту или человеку, таймшиты (кто, что и сколько потратил на задачу).Calendar — название говорит само за себя: в нём можно вести персональный и общий календарь, есть функции шаринга и экспорта.Balsamiq Wireframes for Confluence — инструмент прототипирования.

Интерфейс инструмента прототипирования Balsamiq Wireframes for Confluence

• в Confluence пишем разного рода руководства: как надо и не надо делать, частые кейсы, штуки, которые могут помочь в повседневной работе, даты релизов, отпусков и так далее.
• GitLab — репозиторий git (и его многочисленные клиенты, от монументальной Visual Studio до цветастой SourceTree и минималистичной TortoiseGit). Да, в наше время требуется масса навыков и универсальность. Аналитики не погружающиеся в код «в репе» и не делающие branch ветки, commit и merge — это прошлый век. Поэтому «репа» — наше всё!

SourceTree — клиент для Git-репозитория, которым мы пользуемся

Выглядит просто. Но мы потратили несколько месяцев на то, чтобы настроить все процессы — учитывая размер команды (в какой-то момент нас было 50 человек, сейчас чуть меньше) и количество задач, которое поступает ежедневно.

Настроили процессы так, чтобы рутина напрягала минимально

Чтобы отслеживать работу команды, мы проводим встречи.

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

На этих же встречах мы делимся новостями: что случилось по конкретной задаче или в смежной команде, как это влияет на работу команды и так далее. Я называю это «оперативкой».

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

Упомянутый выше плагин к Jira «Structure»: посмотрев глазами представителей разных команд на консолидированную информацию — сразу понимаешь, что у тебя «поехало» по срокам или зависло в ожидании ответа от кого-либо

Последнее — ретроспективные встречи. На них мы обсуждаем прошлые релизы: что было сделано хорошо, что плохо, что сто́ит поменять. А ещё слушаем отзывы о работе друг друга — и стараемся учитывать их в будущем.

Retro Tool — инструмент для ретроспектив, который мы начали использовать недавно. Он помогает упорядочивать мысли и голосовать за идеи

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

Поэтому тайминг, тайминг и ещё раз тайминг.

Наконец, есть чаты. Банк использует Skype for Business, где есть отдельные группы, ещё есть пара корпоративных мессенджеров, которые работают на уровне банка, ну и, конечно, Telegram, который позволяет решать срочные вопросы.

Что пришлось достроить

Перестроили утренние стендапы. Когда нас было 15–20 человек, 15–20 минут уходило на то, чтобы обсудить задачи на день. И ещё полчаса мы рассказывали друг другу анекдоты и делились историями, узнавали, у кого ремонт, а кого и сосед затопил.

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

• доносить мысли чётко и лаконично;
• говорить только о работе: поход в кино и котики — не тема встречи;
• придерживаться формата: что ты сделал значимого, над чем будешь работать сегодня, есть ли проблемы.

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

Ввели «дежурства»: выделили ключевых сотрудников на повторяющиеся и очень нужные для всей команды, активности. Например:

• Нужен свежий код (поставка) на Тесте?  — Ок, на этой неделе это Коля.
• Нужно смёржить ветки перед началом работы над новым релизом? — Запросто, только маякни Серёге.
• Нужно поддержать выход в Прод? — Ок, Артём и Женя уже знают про это.

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

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

Стараемся отдыхать

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

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

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

Это же помогает наладить атмосферу в группе. Мы ко всему подходим с юмором (насколько это возможно). Потому что задач бывает так много, что без шуток и перерывов ты превращаешься в мясорубку, которая просто перемалывает всё, что в неё закидывают.

Находим подход к сложным людям

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

Это снижает эффективность всей группы. Кроме того, один токсичный сотрудник может «заразить» остальных — и отлаженные за много лет процессы рухнут. Наконец, мы можем не заметить, что что-то сделано не так. И спустя месяцы — или даже пару лет, — когда человек уйдёт из команды, это вскроется. Придётся переписывать плохой документ или переделывать нелепую реализацию, а потом объяснять заказчику, почему мы не уследили.

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

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

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

Если сотрудник не исправляется, у меня просто не остаётся выбора, и мы прощаемся. Банками пользуются все — даже те самые «сложные сотрудники», причём очень часто — и проблемы в продакшене могут сказаться на очень большой аудитории и принести большие убытки.

Советы, как не выгореть самому и не поломать настроенную систему

1. Следить за своим здоровьем. Кроме банальных истин про сон и питание, могу сказать, что мне очень помогает просто подышать свежим воздухом. Ну и конечно делать небольшие перерывы каждый час. Если заставлять себя работать без перерыва, когда явно чувствуешь, что подустал, на работу не останется ни сил, ни желания.
2. Доверять людям, не держать всё в себе (или на своих плечах). Просить помощи — это нормально. Если вы попали в сплочённый коллектив, вам обязательно помогут.
3. По возможности переключаться на другие задачи, когда мозг начинает закипать. Когда бьёшься третьи сутки над проектом для четырёх смежных команд, иногда очень помогает поделать что-то максимально простое.
4. Под конец каждого рабочего дня составлять план своей работы на завтрашний день. Окинуть мысленным взглядом всё, над чем работали сегодня, выявить, что сделано и что осталось. Записать это в виде чек-листа — пусть это будет ваш личный DoD (Definition of Done).

Для всех вообще «записулек» на свете я использую OneNote. (В этом месте «старички»-консалтеры, наверное, улыбнутся «ламповым», но до сих пор отлично работающим вещам)

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

Так команда понимает, что я тоже «работу работаю» наравне с каждым, а не просто раздаю ценные указания.