Disclaimer

  • У меня есть опыт руководства командой, которая находилась в одной локации. Советы актуальны и для распределенных команд, однако для них стоит учесть разные таймзоны.
  • Когда я пишу “разработчики”, я имею в виду не только программистов, но и тестировщиков, аналитиков, дизайнеров и всех, кто выполняет задачи бизнеса и помогает строить продукт.

1. Ты - не разработчик

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

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

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

2. Устанавливай правила

Правила нужны не для того, чтобы их нарушать, а чтобы каждый в команде знал, что он может делать и что делать не может и не должен. Тимлид составляет кодекс - что-то вроде свода правил работы над проектом. Кодекс должен быть опубликован там, где каждый участник команды и даже компании сможет его прочесть. Не бойся прописывать очевидные истины. Если кажется, что “это и так все знают”, то все равно пропиши, потому что может и не знают. Формулировки должны быть краткими и точными, нет лозунгам типа “работаем хорошо, а плохо - не работаем”. Здесь я опубликовал кодекс, которому призывал следовать ребят в своей команде.

Приведу здесь список принципов, которые я считаю первичными:

  • Принимаем реальность и работаем с ней.
  • Нет ничего страшного в том, что мы допускаем ошибки; страшно, когда мы не учимся на них.
  • Мы выявляем проблемы и не миримся с ними. Мы исправляем их и делаем выводы.
  • Мы используем инструменты и утвержденные процедуры, чтобы регламентировать выполнение работы.
  • Явное лучше неявного

Каждый тиммейт должен знать ответ на вопрос “а что делать в случае, если …?” Таким образом, отвлекать тимлида будут меньше. Если возникла ситуация, не озвученная в своде правил - дополняй список установок.

3. Автоматизируй по-максимуму

Чем меньше тебя будут отвлекать, тем лучше. Пользуйся инструментами автоматизации, чтобы минимизировать конфликты и ошибки:

  • Настрой CI/CD,
  • Добавь stylecop для проверки синтаксиса, пусть автоматика реджектит невалидный код,
  • Пиши сам и требуй автотесты, их много не бывает,
  • Не забывай о правилах проведения кодревью,
  • Сокращай время подготовки окружения: минимум действий от пулла репозитория до поднятия всей инфраструктуры на PC

Здесь я написал те действия, которые я делаю для проектов на .NET и Angular. Споры о том, что использовать - табы или пробелы - не иссякнут никогда, а энергию отнимают очень быстро, поэтому пусть автоматика расскажет новичкам в команде о том, какой синтаксис принят тут.

4. Позволь им ошибиться

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

Тимлидство - работа с людьми, а люди ошибаются. И пускай - будут учиться быстрее.

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

5. Адаптируй правила

Ошибки совершают не только твои ребята, но и ты сам. В том числе и при составлении правил. Кодекс должен работать на благо команды, но если некоторые пункты противоречат каким-то процессам в компании, то нужно трезво посмотреть на ситуацию: это процесс в компании неоптимален или это правило сделает только хуже? Важно рефлексировать и разобрать, изменение чего из двух сделает лучше команде и проекту.

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

6. Улучшай условия работы

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

  • Новичок мучается с настройкой окружения? Организуй скрипт, который установит нужные SDK и сервисы на компьютер.
  • Деплой требует кучу ручных действий? Удели внимание на Continious Delivery на проекте.
  • На ревью много споров о форматировании? Настрой stylecop, чтобы только один формат кода был дозволен, а все иное - реджектилось пайплайном билда.
  • Какая-то библиотека работает нестабильно - убирай ее из зависимостей проекта.

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

7. Успехи - команды, провалы - твои

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

Тимлид все настроил, организовал, проблемы выявил и устранил - он молодец

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

8. У тимлида другие метрики

Успех работы тимлида отражается в следующем:

  • Команда работает сама, ей не требуются ручные указания,
  • Рабочие конфликты возникают по архитектурным вопросам,
  • Каждый конфликт приводит к улучшению работы: новое правило, багрепорт, автотест, адаптированный процесс,
  • Каждый член команды знает, что делать в той или иной ситуации и без подсказки тимлида,
  • Команда собрана из людей с разными навыками, но эти навыки дополняют друг друга,
  • Bus factor минимизирован, в том числе и для тимлида. Если тимлид в отпуске, то работа не останавливается,
  • Сокращение времени адаптации новичков в команде,
  • Рост профессионального уровня разработчиков в команде,
  • Дэдлайны обсуждают с командой и не нарушают.

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