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

Предисловие

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

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, я могу с уверенностью сказать, что многие вещи в команде стали лучше. И процессы разработки, и качество кода, и взаимоотношения с командой. И стали они лучше благодаря одной простой вещи - признанию своих ошибок.

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

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