Что значит быть тимлидом

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

На мой взгляд, главная и едва ли не единственная задача тимлида на проекте – сделать максимально возможное, чтобы поставить продукт вовремя. Звучит легко, однако за этой формулировкой стоит такой огромный спектр задач, что можно легко запутаться. Попробую раскрыть тему, что обычно я делаю для того, чтобы поставить продукт вовремя. Что можно включить в перечень задач, достигая которые выполняется главная?

Установить начальные процессы разработки

Процесс разработки – это протокол взаимодействия между людьми в тех или иных ситуациях. Стратегия ведения веток в гите, статусы тикетов в джире и логика перехода из одного в другой, разграничение ответственностей каждого из участников проекта и группы разработки в целом и т.д. Сделать процессы понятными для всех важно, чтобы каждый понимал, что делать в той или иной ситуации. Я руководствуюсь собственным набором best practice:

  • брэнч-стратегия – Gitflow
  • канбан либо scrum в качестве методики управления проектом
  • прописанный свод правил “что делать, если…”. В качестве примера можно взять этот документ
  • созданный репозиторий в GitLab/Github/Azure/<your repo system> с “фундаментом” проекта
  • настроенный Continious Integration, который проверяет сборку основных веток и мердж-реквесты
  • настроенные проверки синтаксиса и статический анализатор кода

Следить за установленными процессами разработки

Недостаточно только установить процессы, необходимо также понимать, работают они или нет. Необходимо отслеживать прогресс работы и анализировать, как влияют принятые процессы и правила на него. Баги в проекте отражают реальную картину. Баг не может возникнуть из ничего, и его причина может сказать многое: недопонимание, непрозрачные требования, неописанные правила взаимодействия между участниками. Главное – никогда не упускать из виду процессы.

Адаптировать и адаптироваться

Best practice – это рекомендации, а не жесткие правила. Если что-то для вашей команды не работает, то нужно либо адаптировать процессы, либо адптироваться самому. Адаптировать процессы важно, потому что рекомендации описаны слишком универсально, чтобы могли быть применены без изменений к любой команде. Важно понять, как именно поменять процесс, а для этого необходимы анализ и ретроспективы.

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

Если подытожить

На мой взгляд, основная задача тимлида - это не тикеты в Jira двигать, а делать так, чтобы его команда комфортно могла делать это вместо него и ничто ей не мешало. Часто тимлид берет задачи в разработку, но нужно помнить, что такое стиот делать только в том случае, когда в тот момент времени команда перформит на достаточно высоком уровне.