Что НЕ должен делать тимлид — или сага о задачках в таск-трекере
Привет! Меня зовут Виталий, я фронтенд-тимлид в KTS. Рассказываю, что входит в нашей компании в обязанности тимлида, а что — нет. Спойлер: это не расставление задач в таск-трекере.
Привет! Меня зовут Виталий, я фронтенд-тимлид в KTS. Рассказываю, что входит в нашей компании в обязанности тимлида, а что — нет. Спойлер: это не расставление задач в таск-трекере.
Поскольку архитектурные задачи требуют глубоких технических знаний, они не могут быть делегированы. Тимлид валидирует ключевые технические решения и предлагает более эффективные способы построения архитектуры.
А если этот тимлид / техлид уходит в отпуск, заболевает или уволняется, то команда ждет прихода нового волшебника, который не делегировал и не обсуждал с ними технические решения?
Например, недавно тимлид одной из наших команд предложил переставить разработчика на другой проект. Со стороны менеджеров не было заметно, что что-то идёт не так: сотрудник укладывался в сроки. Но тимлид заметил, что код разработчика получает много комментариев во время код-ревью
То есть, по словам этого тимлида, разработчик плохой и необучаемый и поэтому вместо увольнения решили перевести его в другую команду? Ну и я промолчу про причину "много комментариев во время код-ревью", когда человек делает задачи и укладывается в ожидаемые сроки.
Вы уверены, что правильно понимаете фразу "валидирует ключевые технические решения"?)
Валидирует значит проверяет и утверждает, а не придумывает за команду не советуясь
А по второму пункту — как "переставить на другой проект" превратилось в "плохой и необучаемый"?:))
Вроде очевидно, что переставить на другой проект значит что на другом проекте разработчик лучше будет справляться
Здравствуйте, отвечаю на ваши комментарии:
1. В любой момент времени в проекте есть кто-то, кто обладает наибольшей компетенцией. Этот человек чаще всего лид проекта, и на нем ответственность за конечный результат. В этом блоке речь идет о валидации решения. Проработку предложения по архитектуре и реализации, конечно, можно и нужно делегировать — так развивается команда и решается проблема bus-фактора. Но опять же, ответственность за финальное решение на лиде. Если лид идет в отпуск / заболевает / увольняется / etc., в экстренном порядке можно получать внешние консультации от других лидов их проектов, временно предложить им вести проект, с постепенной передачей роли лида другому сотруднику. В целом, текущий лид проекта должен выстраивать работу так, чтобы не быть незаменяемым и развивать других сотрудников на замену себе.
2. Проблемы сотрудника на одном проекте — не всегда следствие его необучаемости. Очень часто это признак выгорания, или, возможно, проект человеку субъективно не нравится. И практика показывает, что перевод сотрудника на другой проект позволяет сильно увеличить его вовлеченность, мотивированность и, следовательно, эффективность. Много комментов на код-ревью здесь тоже скорее пример низкой вовлеченности сотрудника.