Записки юного TeamLead: Ошибки, о которых не стыдно говорить

d375ba1ffe332f6efa29ff0310bccd30.jpeg

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

Предисловие

Буквально несколько дней назад был «субботник» у одной компании с красно-белым лого. В первом докладе спикер рассказывал про оси развития разработчика. Всего он выделил три оси:

  1. Технологии

  2. Продукт

  3. Люди

В целом, он не ошибся. Любой разработчик может уйти в сторону оси «Технологии» и делать свой стек технологий сильнее — становиться ведущим или старшим разработчиком. Можно попробовать прокачать себя в оси «Продукт» — уйти в PM и потом пойти дальше по матрице компетенций и расти по вертикали. Но есть еще одна ось, о которой можно много говорить, о которой много пишут, писали, и будут писать — «Люди». Управление людьми, работа с командой напрямую, выстраивание своих локальных процессов разработки — участь TeamLead (далее TL).

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

Ошибки

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

Вот и я будучи TL в компании в первые месяцы допустил несколько больших ошибок.

Доверие

Ошибка, которую допускают, я думаю, многие TL, в том числе и я — отсутствие доверия к своей команде или к людям из команды.

Мысли, а ля «Я могу сделать это лучше» первое время постоянно рядом, из-за этого получается, что вы перегружаете себя и, конечно же, не успеваете. Ведь помимо разработки у вас есть другие не менее важные задачи. Решение данного вопроса очень простое: нужно учиться доверять, оценивать людей не только по их личным, но и по их техническим характеристикам. Тогда будет намного легче. Возможно, вы перестанете быть звездой-гением-мысли-лучшим разработчиком среди всех разработчиков в компании, но вы будете хорошим TL, который умеет самое главное — доверять. От этого вам плюсик в карму от команды.

Оценка сроков

Другая не менее распространенная ошибка — Ошибка в оценке сроков

Иногда, на глобальном планировании на несколько спринтов вперед бизнес может сказать «Нам нужно это, это, и вот это — сможешь?».

Тут начинается игра «Кто хочет стать Багоделом», потому что чем больше вы возьмете на себя и свою команду, тем больше будет проблем потом. Проблемы будут появляться из-за:

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

  2. Сложности. То, что по заявлением должно делаться N часов — делается 2N часов — отсюда смещение по времени и нарушение дедлайнов.

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

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

Приоритеты

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

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

Отсутствие развития сотрудников в профессиональном плане

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

Общение с разработчиками

Или One-to-One. Лучший способ узнать что происходит у разработчика — прямо спросить. И не обязательно спрашивать «ну что, как там с задачами?». Нужно быть человеком и искренне проявлять интерес к жизни сотрудника. Спросить что-то отвлеченное от работы или обсудить, к примеру, вчерашний футбольный матч — прекрасное начало диалога, который поможет больше понять что беспокоит сотрудника. Если необходимо спросить про трудности с задачами — это стоит делать без претензией, а с искренним желанием помочь.

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

Конфликты

Самое страшное, что может случиться в команде — это конфликт между разработчиками. Что самое забавное, его причины достаточно прозаичны, например — pull request был предвзято оценен или чрезмерно раскритикован. И самое неприятное в конфликте то, что он может быть продолжительным и он может съесть день вашего времени. Решение конфликта кроется в общении:

  1. С каждым по-отдельности — разговор one-to-one для поиска причины и оценки ситуации

  2. Совместно с конфликтующими — разговор, который направит на нахождение компромисса

Это поможет быть:

  1. Ближе к команде

  2. Справедливее. Вы не занимаете стороны — вы стремитесь к общей идее сплоченной команды

Не занимайте стороны, не говорите эмоциями — говорите фактами.

Заключение статьи

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

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

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

© Habrahabr.ru