Что НЕ должен делать тимлид — или сага о задачках в таск-трекере

Привет! Меня зовут Виталий, я фронтенд-тимлид в KTS. Рассказываю, что входит в нашей компании в обязанности тимлида, а что — нет. Спойлер: это не расставление задач в таск-трекере.

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

Мы выстроили свою схему разделения обязанностей между тимлидами, менеджерами и аналитиками. Она позволяет снять с тимлидов менеджерскую работу, для которой не нужно обладать глубокими техническими знаниями, но нужно часто переключаться между разными задачами и сотрудниками. Это даёт возможность тимлидам работать над теми задачами, которые и отличают их от менеджеров, — с технической частью проекта. Рассказываем, как мы реализовали эту схему для компании из 80 сотрудников.

Выясняют требования к конечному продукту и формализуют задачи у нас менеджеры. Если задача большая, то подключаются аналитики. Декомпозицией тоже занимаются аналитики и менеджеры. Например, в веб-разработке они могут сами разбить её до уровня вёрстки и прикрутки к API одного экрана или одного блока в рамках экрана, реализации определенного метода API.

Роль тимлида

Несмотря на то что тимлид не формализует и не декомпозирует задачи, на практике он валидирует предложенные постановки. Его цель — проконтролировать, что декомпозиция проведена эффективно, а описания задач годятся для разработки. Также в зону ответственности тимлида входит выявление сложных и нетиповых для декомпозиции задач. Он должен заранее предвидеть проблему и предложить, например, звонок, где он с менеджером прояснит детали задачи, или дополнительную декомпозицию.

Аналитики и менеджеры дообучаются с помощью своевременной помощи тимлида. В следующий раз, когда им встретится похожая задача, они уже будут знать оптимальный способ её декомпозировать. Тимлид здесь берёт на себя не просто операционные задачи, а развивает сотрудников. Команда, где задачи разработчикам ставятся без участия тимлида, может существовать, но менее эффективно.

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

Тимлид же делает следующее

Распределяет задачи для достижения краткосрочной и долгосрочной эффективности, развития команды. Он сильнее погружён в подробности разработки и особенности устройства модулей системы. Это позволяет тимлидy распределять задачи между сотрудниками так, чтобы плавно развивать их компетенции. Например, он может дать задачу разработчику без релевантного опыта, чтобы тот научился справляться с похожими задачами.

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

Мониторит, справляются ли сотрудники с задачами. Например, недавно тимлид одной из наших команд предложил переставить разработчика на другой проект. Со стороны менеджеров не было заметно, что что-то идёт не так: сотрудник укладывался в сроки. Но тимлид заметил, что код разработчика получает много комментариев во время код-ревью. Дальше задачи бы стали сложнее, поэтому возникла бы проблема, которая повлияет на работу всех сотрудников. Тимлид позвал другого разработчика, который в итоге отлично справился с задачей.

Код-ревью на проекте — обязательная часть нашего технического процесса, без него ни один коммит не уходит в продакшн. Это позволяет обеспечивать заменяемость сотрудников, единые архитектурные подходы и стиль кода, контролировать качество. Подробнее про код-ревью мы рассказали в этой статье.

Роль тимлида

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

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

Если в разработке возникают проблемы, менеджер не всегда в них разберётся. Например, третий спринт подряд команда не успевает выпустить релиз к концу спринта. На вопрос команде «почему так происходит», он услышит лишь общие слова про сложность задач или их объём. Единственное, что остаётся менеджеру, — попросить разработчиков быть внимательнее к своим оценкам. Тимлид видит все процесс разработки изнутри, понимает его и может повлиять. Он может увидеть глубинную причину срыва дедлайнов — например, какой-то костыль, который каждый раз приходится обходить при модификации одного модуля.

Также тимлид должен делать «чёрный ящик» разработки серым для менеджеров и аналитиков: пояснять, что может быть усложняющим фактором в создании продукта, предупреждать о возможных проблемах. Это позволяет менеджерам обучаться, распознавать эти сложности и точнее определять сроки выполнения проекта в дальнейшем. Например, тимлид может указать на связь с определёнными модулями, сложную архитектуру или причины использования той или иной технологии.

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

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

Не стоит забывать про объём внимания: редко человек может контролировать больше шести объектов одновременно. Здесь можно провести параллель и с управлением командой: чем больше команда, тем сложнее ей управлять. Когда в команде больше шести человек, управлять ей становится слишком сложно. Поэтому большие команды стоит дробить: в каждой из них нужен свой лид. Для текущего тимлида такое разбиение может стать хорошей точкой для перехода на следующий уровень управления. Он начинает руководить не просто разработчиками, а тимлидами.

Тимлид в нашей компании занимается стратегическими вопросами: развивает команду, улучшает процессы изнутри и контролирует техническую часть.

Менеджер, аналитик и тестировщик ответственны за операционную часть: выявление требований, формализацию и декомпозицию задач, проверку качества выполненной задачи.