Записки юного TeamLead: Ошибки, о которых не стыдно говорить
Честно сделанные ошибки следует считать не неудачами, а семенами для основной деятельности по их исправлению
Предисловие
Буквально несколько дней назад был «субботник» у одной компании с красно-белым лого. В первом докладе спикер рассказывал про оси развития разработчика. Всего он выделил три оси:
Технологии
Продукт
Люди
В целом, он не ошибся. Любой разработчик может уйти в сторону оси «Технологии» и делать свой стек технологий сильнее — становиться ведущим или старшим разработчиком. Можно попробовать прокачать себя в оси «Продукт» — уйти в PM и потом пойти дальше по матрице компетенций и расти по вертикали. Но есть еще одна ось, о которой можно много говорить, о которой много пишут, писали, и будут писать — «Люди». Управление людьми, работа с командой напрямую, выстраивание своих локальных процессов разработки — участь TeamLead (далее TL).
Я осмелился написать этот пост на основе своих же ошибок. Мне не стыдно их признать, не стыдно рассказать о них, показать, что некоторые тактики не всегда помогают.
Ошибки
Все их допускают, без них никуда. На основе ошибок можно понять слабые места, понять, что и где нужно исправить или убрать. Ошибки толкают нас к движению, к прогрессу.
Вот и я будучи TL в компании в первые месяцы допустил несколько больших ошибок.
Доверие
Ошибка, которую допускают, я думаю, многие TL, в том числе и я — отсутствие доверия к своей команде или к людям из команды.
Мысли, а ля «Я могу сделать это лучше» первое время постоянно рядом, из-за этого получается, что вы перегружаете себя и, конечно же, не успеваете. Ведь помимо разработки у вас есть другие не менее важные задачи. Решение данного вопроса очень простое: нужно учиться доверять, оценивать людей не только по их личным, но и по их техническим характеристикам. Тогда будет намного легче. Возможно, вы перестанете быть звездой-гением-мысли-лучшим разработчиком среди всех разработчиков в компании, но вы будете хорошим TL, который умеет самое главное — доверять. От этого вам плюсик в карму от команды.
Оценка сроков
Другая не менее распространенная ошибка — Ошибка в оценке сроков
Иногда, на глобальном планировании на несколько спринтов вперед бизнес может сказать «Нам нужно это, это, и вот это — сможешь?».
Тут начинается игра «Кто хочет стать Багоделом», потому что чем больше вы возьмете на себя и свою команду, тем больше будет проблем потом. Проблемы будут появляться из-за:
Непредвиденных обстоятельств, блокирующих задач других людей или команд.
Сложности. То, что по заявлением должно делаться N часов — делается 2N часов — отсюда смещение по времени и нарушение дедлайнов.
Перегруженности команды: в высоком темпе разработчик работать может, но недолго — дальше выгорание и потеря сотрудника.
В итоге, получается ситуация, где все можно успеть, но или очень с очень плохим качеством (т.е. техническим долгом), или с убитой командой, или (самый благоприятный исход) — просто не успеть.
Приоритеты
Это особенно важная история в рамках команд, которые работают над несколькими большими задачами в спринте.
Принцип прост: сильному разработчику — более сложная и приоритетная задача. Разработчику послабее — задача его уровня. Но тут нужно понимать одну вещь, связанную с развитием каждого разработчика отдельно — нельзя вечно держать разработчика на задачах его уровня. Нужно вкидывать хотя бы иногда что-то сложнее и интереснее, ведь разработчик заинтересован в своем развитии. Отсюда появляется следующая ошибка
Отсутствие развития сотрудников в профессиональном плане
Вы как TL должны думать не только о том, какие фичи поставляет ваша команда, но и том, как развивать каждого члена команды в отдельности. Ведь все абсолютно разные, у всех свой опыт и свой бэкграунд, а значит каждому нужна своя траектория развития.
Вряд ли разработчик будет сидеть на одних и тех же задачах — он потребует больше, интереснее, сложнее. Учитывая это, TL может построить правильную траекторию развития каждого разработчика.
Общение с разработчиками
Или One-to-One. Лучший способ узнать что происходит у разработчика — прямо спросить. И не обязательно спрашивать «ну что, как там с задачами?». Нужно быть человеком и искренне проявлять интерес к жизни сотрудника. Спросить что-то отвлеченное от работы или обсудить, к примеру, вчерашний футбольный матч — прекрасное начало диалога, который поможет больше понять что беспокоит сотрудника. Если необходимо спросить про трудности с задачами — это стоит делать без претензией, а с искренним желанием помочь.
Ошибок, которых я допустил — тысяча. Но скажу одно — даже у ошибок есть польза. Нужно просто уметь получать эту пользу.
Конфликты
Самое страшное, что может случиться в команде — это конфликт между разработчиками. Что самое забавное, его причины достаточно прозаичны, например — pull request был предвзято оценен или чрезмерно раскритикован. И самое неприятное в конфликте то, что он может быть продолжительным и он может съесть день вашего времени. Решение конфликта кроется в общении:
С каждым по-отдельности — разговор one-to-one для поиска причины и оценки ситуации
Совместно с конфликтующими — разговор, который направит на нахождение компромисса
Это поможет быть:
Ближе к команде
Справедливее. Вы не занимаете стороны — вы стремитесь к общей идее сплоченной команды
Не занимайте стороны, не говорите эмоциями — говорите фактами.
Заключение статьи
Сейчас, спустя несколько месяцев работы TL, я могу с уверенностью сказать, что многие вещи в команде стали лучше. И процессы разработки, и качество кода, и взаимоотношения с командой. И стали они лучше благодаря одной простой вещи — признанию своих ошибок.
Проблема производительности команды не кроется в отдельных разработчиках — она кроется в грамотной постановке не только дедлайна и задачи, но и в условиях, в которых разработчики каждый день находятся, в правильной «постановке атмосферы» разработки — надеюсь не перемудрил и вы меня поняли. Если кратко: сделать комфортные условия и увеличить КПД — вот задача тимлида.
В следующей статье я расскажу о других наблюдениях, или «очевидных открытиях». А пока спасибо за внимание и до скорых встреч. Жду ваши отзывы и предложения.
