По следам Teamlead Meetup’а от Binary District на тему оценки и мотивации разработчиков

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

Мой доклад назывался “Как мы нанимаем и мотивируем сотрудников в привлечении Tinkoff.ru”. В нем я хотел рассказать про:
- Сложности найма в крупную компанию со сложившимся брендом и как их обойти
- Как выстроить процесс оценки разработчиков и их вклада в общее дело
- Горизонтальные переходы внутри компании

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

Чем занимается техлид, особенно в связке с тимлмдом?

Если кратко, то тимлид отвечает за команду, а техлид часто за какой-то технический компонент, сервис или библиотеку. Подробнее схема коммуникации есть в моем выступлении на Teamlead Conf Spb 2018.

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

Зачем писали свою систему performance review, если для этого есть AirTable, typeform и Google Tables?

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

С какими сложностями при проведении собеседования или оценки сталкивались лично?

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

Если говорить про оценку работы сотрудников, то самым сложным часто бывает выровнять ожидания сотрудника и руководителя, особенно если они изначально сильно расходились. Например, Вася считал себя гуру программирования, а Петя (его тимлид) так не считал, т.к. Вася уже зафакапил ряд важных задач. Из-за факапов Петя может начать подбирать для Васи задачки попроще, а Вася все эти задачки будет легко щелкать. На performance review может выясниться, что Петя оценивает Васю как middle разработчика, а Вася считает себя архитектором:) Чтобы такого не происходило у ребят должны быть периодические one-to-one, которые позволяют вовремя выявить эти расхождения и решить их до того, как эту пропасть в восприятии невозможно будет преодолеть.

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

Вопрос очень context-specific. Если говорить лично про меня, то я “закончился” после перехода за десяток человек, но у меня помимо работы связанной с организацией процессов были вопросы, связанные с архитектурой решений и продуктовой составляющей:) Думаю, что опытный человек может тянуть до десяти-пятнадцати человек так, чтобы они чувствовали, что руководитель с ними и в курсе всех их чаяний, надежд и всегда готов прийти на помощь:)

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

Мне кажется, что не снижает. Ненулевая вероятность есть и она подтверждена собранной мной статистикой:) Тратить целый день не приходится, достаточно нескольких минут, чтобы написать о человеке то, что накипело:)

Помогали ли HR и в каких моментах?

С нашими hr’ами всегда можно проконсультироваться на любые темы, особенно связанные с hr-вопросами:)

Вы указали, что оцениваете разработчиков по направлениям хард и софт. Почему нет бизнес направления (предметная область, бизнес процессы)?

Когда я говорил про наш процесс performance review я сделал отдельный акцент, что мы оцениваем результаты. Причем вначале сотрудник делает self review, где он рассказывает что крутого было сделано за промежуток времени. Именно здесь мы можем понять насколько он в контексте бизнеса, процессов и полученных результатов. Есть ли у него mapping между его решением технических вопросов и получением business value.
В конце 2018 года у нас к процессу performance review добавился инструмент сбора отзывов. Вот именно в нем есть 2 оценки и текстовое поле. Оцениваются технические компетенции и работа в команде. Эта система отзывов дополняет наш процесс, в котором уже учитывается погружение в бизнес составляющую.

Какие у вас метрики для Performance review?

Мы оцениваем результаты, что были доставлены на продакшен сотрудником и его рост в соответствии с планом развития, который был составлен на прошлом performance review

Какая зона ответственности у тимлидов?

В привлечении Tinkoff.ru достаточно много команд и они разные, поэтому сложно дать общий ответ для тимлидов всех команд. Зона ответственности тимлидов зависит от многих факторов, например:
1. Есть ли у команды релиз-менеджер или нет
2. Есть ли у команды единый product owner или нет
3. Есть ли у команды техлид или нет
4. Насколько сложный продукт разрабатывает команда
5. Насколько процессы разработки в команде автоматизированы (помогли ли уже с этим devops-инженеры или нет)
В общем и целом, вариантов слишком много поэтому для точного определения ответственности надо смотреть на каждый конкретный случай. Но если описывать общие черты для всех тимлидов, то он обычно отвечает за результаты работы команды, а не как линейный специалист только за себя и свои результаты работы.

Кто ставит задачи?

Источниками задач обычно являются следующие люди:
- product owner’ы
- бизнес-аналитики
- системные аналитики

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

Как они раскидываются по командам?

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

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

Я учился на прикладного математика и физика в МФТИ. Дальше изучал системный анализ и управление там же, а после этого еще числился в экономической аспирантуре. Как видно из вышеперечисленного, жизнь не готовила меня к качественному проведению собеседований. Но, как говорится, нужда заставит и не так раскорячишься:)
Мне кажется, что собеседование не сильно отличается от других задач. Важно понимать собственные ожидания от собеседования, понимать что ждет кандидат и попробовать поставить себя на его место. Если все вышеперечисленное получилось, то дальше сам процесс собеседования можно превратить в равную дискуссию нескольких человек, из который каждый может вынести что-то интересное для себя.

У тебя, допустим, 100 человек, на каждого написали по 3 отзыва. Ты сказал, что самое классное, это перечитать отзывы по человеку, нежели, смотреть оценки. А это 300+ отзывов. Как, когда и кем прочитать все эти отзывы? не получится ли что после 5–6 сотрудника и 20+ отзывов у тебя уже замылится взгляд? Как с этим бороться?

На самом деле я не зря упоминал в своем выступлении про иерархичность. Я не смотрю на все 300+ отзывов одновременно. У меня есть около 10–15 сотрудников, которых я лично должен оценить. Обычно на каждого есть 10–15 отзывов. Я могу растянуть общение со своими подчиненными на неделю, чтобы каждый день я должен был изучить отзывы на трех сотрудников и провести 3 встречи. Это довольно приемлемая для меня нагрзука.

Профессиональные тесты, опросники, которые используете, сами разрабатывали или покупали у поставщиков? Если покупали, то у какого поставщика ?

Разрабатывали самостоятельно.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.