Предисловие

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

Как говорил дядя Бен, большая сила — это большая масса, умноженная на большое ускорение большая ответственность. Поэтому новоиспеченный тимлид (со всей этой растущей ответственностью и силой) может поддаться соблазну принимать как можно больше сильных и эффективных решений.  

Раньше бизнес ждал от него A = x полезной работы. Простота и логика подсказывают: теперь бизнес ждёт A = x * n, где n — число людей в команде. Значит, нужно приложить в n раз больше усилий, верно? 

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

Осторожно, «пятничный» контент! 

1. Бери самые важные задачи в спринте себе

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

2. Делай ревью вообще всего кода 

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

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

3. Ходи на все встречи только сам 

Не бери на встречи ребят из команды — помни, не стоит их отвлекать от работы. Если кто-то из команды хочет пойти с тобой на встречу — объясни, что все встречи глупые и бесполезные (не забудь при этом вздохнуть).  

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

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

4. Регулярно напоминай команде, где в компании есть враги (везде) 

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

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

5. Не пускай команду на митапы и конференции

Ещё раз, ребятам не надо лишний раз отвлекаться от работы. Очевидно же? 

К тому же, ни на одной конференции или митапе никогда не говорят ничего полезного, что можно было бы применить в вашей работе. Всякие DDD, BDD, TDD, DnD. Кто в здравом уме будет пытаться писать тесты до разработки кода? Или выстраивать потоки данных? 

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

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

6. Постоянно проверяй, чем ребята заняты и какие задачи делают

Проси ребят дробить задачи на минимальные сабтаски вида «написать класс», «добавить регистрацию в DI», «написать миграцию». Когда в задаче есть 10–15 сабтасков — сразу понятно, на каком этапе кто находится.  

На утренних стендапах проси называть номер сабтаска, над которым человек работает, какие еще остались и (самое главное!) срок, когда задача будет готова целиком. Так ты приучишь ребят к дисциплине и ответственности. 

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

7. На любые вопросы руководства отвечай контратакой

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

Чтобы усилить эффект, добавь, что во всё виноваты эйчары и рекрутеры. И весь отдел кадров. 

8. Переписывай код команды после ревью

Если в коде, который прошёл твоё ревью, нашлись ошибки, перепиши всё сам и объясни ребятам, что ты с самого начала видел проблемы, но сжалился над автором.  

Не лишним будет отправить автору кода сообщение с твоим коммитом, чтобы человек знал, как надо было сделать правильно. Всё это – часть обучения команды. 

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

Это всё придумали люди, которые не хотят и не умеют работать. Особенно 1-на-1 — тебе это точно не нужно, ведь ты постоянно тусуешься с ребятами на кухне и объясняешь им задачи. Зачем ещё отвлекать их от работы?  

Стандарты – познаются в бою, документация – всегда устаревает. Знание системы есть у тебя, ребята всегда могут подойти и спросить. 

10. Будь постоянно на связи, даже в отпуске

Особенно в отпуске! Да, это тяжело, но ведь без тебя всё сломается, работа встанет. Ребята не будут знать, какую следующую таску или баг им делать. Бизнес не будет получать фичи.  

Ты один можешь понять, почему прод не работает, как залить фикс, выгрузить отчёт для отдела продаж (который ты лично сделал три года назад и бережно хранишь на рабочей машине в файле new_text_document (27).txt). 

Ответственный vs «Ответственный» 

Хотел бы я сказать, что выдумал эти «советы» исключительно из художественных соображений, вдохновившись Григорием Остером. Увы, на часть этих граблей я наступал сам, когда только стал тимлидом и иногда встречаю подобные ошибки у других.

Я считаю, что ответственность – действительно важное качество для тимлида. Главное, чтобы оно не превращалась в «ответственность».  

Читайте книги, смотрите на других тимлидов, перенимайте опыт, рефлексируйте. Простота бывает крайне обманчивой.