Меня зовут Екатерина, я тимлид в компании МойСклад.

В прошлом году я выступала на конференции Saint TeamLead Conf 2018 ^[1]. Главное из своего доклада собрала в эту статью, само же выступление можно посмотреть по ссылке ^[2].

Мой путь в компании как разработчика начался два с половиной года назад. Тогда в МоемСкладе не было налаженных процессов, а нашего тимлида назначили по принципу «Это самый опытный разработчик в команде? Ты и будешь тимлидом». Но хороший разработчик — не всегда хороший тимлид.

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

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

Самоменеджмент

Первым делом я начала контролировать собственное рабочее время и задачи. Приходящие ко мне в течение дня вопросы я делила на три типа:

• задачи, которые можно оценить по времени и приоритизировать. Это тикеты в Джире, организационные моменты;
• встречи с коллегами, которые нужно планировать на точное время;
• вопросы, с которыми подходят коллеги время от времени.

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

Еще одно правило самоменеджмента появилось из-за проблемы, которую мы называем «жадная Шурочка». Так мы говорим о коллегах, которые берут много тикетов и не успевают их сделать. Получается, задач у человека много, но мы не понимаем, что из них в работе и будет сделано в ближайшее время.

Чтобы не быть жадной Шурочкой, пять минут ежедневного времени я посвящаю планированию списка дел на день. За это время я:

• просматриваю календарь и записываю в него встречи;
• расписываю задачи, которые планирую выполнить сегодня; отмечаю, в какие часы буду ими заниматься;
• в качестве лоадфактора оставляю немного времени для решения минорных вопросов.

Это позволяет мне четко понимать, какие задачи я успею выполнить сегодня.

Больше ответственности

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

Например, вы можете:

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

Проблемы и решения

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

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

Еще полезно анализировать сильные и слабые стороны своей команды. Если вы будете их знать, станет проще распределять задачи, ведь не всегда в команде бывают только золотко-разработчики, которые работают качественно и в срок. Анализ hard-skills тиммейтов можно делать по результатам ревью кода, по тикетам в Джире. С soft-skills сложнее — оценить их можно только при постоянном взаимодействии с командой в рамках задач.

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

Поиск заместителя

Стать тимлидом — это очень круто. Но с этим к вам приходят новые проблемы, обязанности и бОльшая ответственность.

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

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

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

На балансе противоположных качеств и были выбраны эти ребята. Я спросила у них, не хотят ли они немного поруководить командой. Каждому объяснила их сильные и слабые стороны — чтобы они приглядывали друг за другом и сдерживали в неверных решениях. При этом вся команда знала, что нужно идти именно к ним. С таким подходом мы работаем и сегодня.

И еще немного новых проблем

Когда я стала тимлидом, ко мне начала обращаться вся команда разом. Еще появились всевозможные административные задачи, митинги и вопросы около этого. Нужно было разобраться, как с этим работать и не впадать в экзистенциальный кризис. Ответ оказался прост: терпи или делегируй.

Но делегировать можно по-разному. Самое простое — раздавать задачи участникам команды. Так мы делаем редко. Чаще стараемся, чтобы ребята сами разбирали задачи по интересам.

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

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

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

Этот способ помогает мне не загнать себя в административную рутину, сидя на десятом митинге.

Эксперименты в команде

На тимлида-новичка сваливаются вопросы и задачи, которые не всегда можно решить быстро. Чтобы разобраться, полезно читать статьи и книги по вопросам управления. А еще лучше — советоваться со старшими товарищами.

Но чужой опыт не всегда подходит тебе и команде, а универсальных способов вообще не существует. Чтобы разобраться, надо пробовать, поэтому я стараюсь внедрять новые практики с помощью цикла Деминга, адаптированного под команду. Вот как это работает:

• plan — во время спринта каждый участник команды может внести предложение по улучшению процесса. На ретроспективе мы обсуждаем предложенные идеи и их реализацию, договариваемся, какие из них мы возьмем в качестве эксперимента на следующий спринт;
• do — во время спринта команда следует выбранным на ретроспективе практикам;
• check — на ретроспективе мы обсуждаем результаты эксперимента. Каждый участник команды дает фидбэк, мы анализируем, помогло ли внедрение практики улучшить процессы и добиться результатов. После договариваемся, как поступим дальше: оставим практику на постоянку, внесем в нее коррективы и повторим, откажется совсем;
• act — все избранные практики вносятся в ретроспективы, а по итогу входят в список наших best practices.

Все эти эксперименты помогли нам внедрить практики контрольных точек, маленьких тимлидов и еще много полезных вещей.

Для себя же я поняла основное: если хотите организовать команду, начните с себя; не бойтесь нарабатывать опыт и набивать шишки. А еще не забывайте советоваться с коллегами и делегировать задачи.

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

Автор: drmwks

Источник ^[3]