Опрос 360: как работает этот метод и для чего он разработчикам

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

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

Сегодня поговорим об опросе 360 – разберемся, когда стоит использовать этот метод для сбора обратной связи в команде и как к этому подготовиться. Также я расскажу про наш опыт и подводные камни.

Что важно знать о сотруднике

Приходя в компанию, человек хочет расти, и мы должны показать ему пути развития. Чтобы их видеть и понимать, нам важно знать следующее:

какими хард-скиллами обладает сотрудник,
какие у него есть софт-скиллы,
что мотивирует его ходить на работу,
в чем он хорош и какие у него точки роста.

Есть разные способы это выяснить:

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

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Как мы запускали опрос 360

Сначала мы создали матрицу карьерного роста. У нас стандартная сетка должностей со ступенями junior, middle, senior. Далее два пути: ведущий разработчик (это про работу с людьми и менеджмент) и эксперт (про технологии и системную архитектуру). Матрица нужна, чтобы сделать процесс перехода между должностями прозрачным. Также она выступает некой эталонной структурой, которая помогает понять, относительно чего оценивать коллегу.

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

Рассмотрим пример софт-скиллов в матрице:

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

Харды в матрице карьерного роста мы описали в двух редакциях. Первая привязана к стеку: джун во фронтенде должен уметь делать селекты, знать HTML, CSS. Вторая – более общая: уметь ревьюить код, знать паттерны проектирования.

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

Как составить анкету в опросе 360

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

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

Для форм нужны анкетные вопросы и шкала с вариантами. Вот что мы учли при разработке:

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

Разберем на примере, кому отправлять опрос. Нам нужно оценить компетенции фронтендера. Проектной команде (проджект, продакт, тестировщики, аналитики) мы отправим опрос по софт-скиллам. А разработчикам того же функционала вышлем анкету и по софтам, и по хардам, так как они видят код фронтендера. Все ответы собираем анонимно. Фронтендер тоже оценит себя по софтам и хардам, затем мы сверим его ответы с оценками коллег.

Интерфейс для участников опроса

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

Интерфейс 360 для руководителя

Опрос 360 для руководителя Группа рассылки. Мы административно ограничили количество писем до 10. Пересечение выборок респондентов для каждого опроса становится все больше, поэтому человек может просто пропустить письмо или не успеть ответить. Чтобы собираемость была на уровне, мы выбираем респондентов осмысленно.

Респонденты. По разным артефактам мы ищем смежников. Из Jira добавляем исполнителей и постановщиков задач: чей проект получал сотрудник и кому поручал доработки. Из Bitbucket подтягиваем ревьюеров. Если в системе нигде не отражается соисполнитель, можно добавить его руками.

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

Результаты опроса 360

Что важно знать об индикаторах

Индикатор должен быть наблюдаемым со стороны. На старте в компетенциях эксперта был индикатор: «Выявляет узкие места в процессах и ускоряет разработку». Но не все коллеги могли понять, что имеется в виду. Мы заменили формулировку на «Помогает коллегам быстрее решать задачи». Так индикатор могут наблюдать участники команды. В компетенциях эксперта было также: «Мыслит масштабно в рамках технологического стека». Но как оценить чужие мысли? Мы изменили индикатор на исчисляемый: «Рассказывает о развитии стека и инновациях в компании».
Индикатор должен быть однозначным. «Разработчик энергично и упорно выполняет задачи». А если только энергично? Удачнее звучит так: «Выполняет задачи в озвученный срок». На стендапе сотрудник сказал, что фича будет за два дня, и уложился – это значит, что все идет хорошо.