Всем привет!
Эволюция специалиста из простого разработчика в тимлида в рамках небольшой компании зачастую является событием как желанным, так и немного тревожным. Новоиспеченный тимлид обычно знает про роли и обязанности вскользь, от коллег и из статей в интернете. В таких статьях тимлида могут описывать и как штатного психолога, и как переросшего себя ведущего разработчика, и как человека, который умеет всё и должен делать всё.
Поэтому здесь изложено видение роли тимлида, характерное для нашей компании - не слишком подробно, но с охватом самых важных моментов. Погнали!
Роль тимлида
Как можно понять из названия роли, тимлид лидит тиму, то есть ведет команду разработки. Причем ведет он команду не просто в светлое будущее, а к успешно выполненному проекту. Но что это значит для всех участников процесса?
Для клиента эта роль заключается главным образом в точке контакта с командой разработки по техническим вопросам. Заказчик обычно не так часто ныряет на инфраструктурный уровень, но если ему потребуются уточнения по реализации интеграций, консультации по пределам нагрузки на приложение или у него возникнут другие технические вопросы, то тимлид сможет на них ответить точнее других.
Для проект-менеджера тимлид это тот, кто точно знает как и с чего стоит начать разрабатывать проект, что должно быть фундаментом приложения, его строительными блоками. К тимлиду можно обратиться с просьбой крупноблочной оценки проекта или новых пожеланий клиента.
Для разработчика же тимлид является главной опорой в решении сложных технических вопросов. Тимлид поможет с формулировкой задач, чтобы они описывали именно то, что нужно клиенту. Тимлид может дать свежий взгляд на план реализации фичи, подсветить подводные камни того или иного решения. При непреодолимом баге тимлид подскажет возможные его причины, посоветует лучшие способы для исследования или направит к коллегам, которые уже могли столкнуться с подобной проблемой.
Ответственность
На первый взгляд может показаться что задачи тимлида очень похожи на то, что делает опытный разработчик. Но ключевым отличием между этими ролями является разница в областях ответственности.
Если разработчик в первую очередь ответственен за качественное выполнение задач, то от тимлида зависят более широкие аспекты разработки, такие как:
общая скорость разработки проекта;
выбор последовательности шагов разработки, обеспечивающий постепенное и видимое приближение к конечному результату;
соответствие конечному результату целям и потребностям заказчика;
продуманность архитектуры, позволяющая без лишних трудностей вносить изменения;
стабильность и надежность приложения под нагрузкой.
Обязанности
От проекта к проекту, от команды к команде конкретные обязанности и задачи тимлида могут отличаться довольно сильно. Кроме того, обязанности зачастую могут поменяться по ходу ведения проекта.
К примеру, на сложном проекте, при нехватке рабочих рук, от тимлида может потребоваться помощь в аналитике предметной области. В командах, где часть разработчиков это новые члены компании или просто джуны, скорее всего потребуется повышенное внимание к коду разработчиков на этапе code review и описания задач. А при старте проектов от тимлида будут ждать в первую очередь проработку архитектуры и выстраивания оптимального порядка этапов разработки.
По причинам, перечисленным выше, сложно сформировать единый список обязанностей. Вместо этого хочется обозначить важные для тимлида моменты, которые могут быть полезны в виде напутственных слов для тех, кто только взялся за эту роль.
Наши рекомендации
Принять изменчивость ТЗ
В очень редких случаях проект пройдет без единой правки все стадии создания, от архитектурного планирования до успешной сдачи клиенту. Почти всегда по ходу разработки будут появляться новые требования, меняться старые, сдвигаться сроки, тасоваться задачи — в общем, проект будет жить своей жизнью.
Известная пословица говорит «не можешь остановить — возглавь». Поэтому тимлиду первому нужно научиться принимать изменчивость проектов, учитывая ее при проектировании, реализации фич, при оценке проделанной работы.
Во время составления порядка реализации той или иной функциональности, нужно выяснить УТП клиента — соответствующая ему бизнес-логика практически наверняка поменяется меньше всего, в то время как сопутствующие фичи могут сильно видоизменяться, появляясь и исчезая в процессе разработки. Например, при разработке условного интернет-магазина имеет смысл опираться на то, что функциональность витрина товаров и их покупки останется с проектом до конца (соответственно, их архитектура будет незыблемой на всем периоде разработки), а вот онлайн-помощник или рекомендательная система могут измениться до неузнаваемости по сравнению с изначально описанными в ТЗ правилами, или же вообще пропасть из роадмапа из-за сжатых сроков или урезанного бюджета.
Кроме проектирования, изменчивость ТЗ не должна девальвировать ценность разработки компонентов приложения, которые по итогу пришлось переделывать. Если заказчик трижды менял планы, и приходилось трижды проектировать, ставить задачи, вносить изменения в код и тестировать их — это все равно означает, что вашей командой трижды была выполнена ответственная и тщательная работа, которой можно и нужно гордиться, пусть до прода добрался в итоге только один вариант. Отмечайте фичи, которые пришлось переделать или пустить под нож, как полноценные части работы и избегайте отношения «нет в итоговом приложении — значит ничего не делалось». Подчеркивание трудозатрат на внесение изменений в уже созданные компоненты может не только дать клиенту понимание стоимости таких внезапных разворотов, но и добавить морали команде, которая не видит результат всех своих трудов на проде.
Прокачивать софт-скиллы
Общение для тимлида это не то, что отвлекает от работы, а едва ли не основной его инструмент. Поэтому и относиться к общению следует соответствующе, учась правильно им пользоваться, прокачивая софт-скиллы.
Так, для тимлида в куда большей мере чем для разработчиков полезно держать все общение открытым, избегая обсуждения производственных моментов в личных сообщениях. Удобная организация всей информации о проекте в определенных каналах, возможность в любой момент обсуждения обратиться к другим членам команды, открытость процессов для всех заинтересованных сотрудников – всех этих плюсов с лихвой должно хватить, чтобы оставить личные сообщения для действительно личных тем, не касающихся проекта.
Вдвойне важной открытая коммуникация становится при общении с клиентом. Некоторые из заказчиков могут попробовать через личные сообщения уговорить на сроки поменьше, пообещать что требования не будут меняться или же просто высказывать претензии в неформальном виде. Ни к чему из этого нельзя будет обратиться в будущем, когда окажется, например, что требования все же поменялись. Поэтому лучше мягко, но настойчиво отклонятьвсе попытки клиента перевести разговор в приватное русло и предлагать продолжить общение в предназначенных для этого каналах или группах.
Еще один важный софт-скилл, который для тимлида является одним из ключевых, это своевременное информирование обо всех рисках. Если разработка фичи затянулась, например, интеграция со сторонним сервисом подвисла из-за того, что со стороны сервиса нет необходимых доступов, то не нужно ждать, когда про это вспомнят на внутреннем мите или на встрече с заказчиком. Стоит в тот же момент, когда появилось понимание что сроки придется двигать, обозначить это всем заинтересованным лицам, чтобы это не стало потом неприятным сюрпризом. Тому же самому принципу стоит следовать при критичной ошибке в приложении. Например, если из-за череды ошибок сервер с приложением стал неработоспособным на существенный срок, то лучше сразу сообщить «в приложении проблема, мы знаем о ней и занимаемся ее устранением», чем надеяться на то, что клиент не придет с вопросом «коллеги, а что у нас с приложением?».
Разграничивать ответственность
Одной из ошибок новоиспеченных тимлидов нередко бывает гиперответственность относительно всех частей разработки, будь то общая архитектура приложения или получасовой перерасход времени на задачу у одного из разработчиков.
Постоянная тревога выматывает силы, перенапрягает нервы и быстро приближает выгорание.
Поэтому не стоит упускать из вида главные цели тимлида на проекте, а также тот факт, что тимлид не делает проект в одиночку. Состав команды может отличаться, и где-то действительно придется на себя брать задачи другой роли — помочь в аналитике если рук для описание бизнес-логики не хватает, написать сложный запрос к БД если ведущий разработчик загружен на других фичах, быстро подхватить, исследовать и исправить критичный баг. Но стоит стремиться к тому, чтобы каждый делал свое дело.
Тем более, как было описано выше, у роли тимлида и так довольно широкий круг ответственности, а ошибки или провалы в задачах могут привести к более серьезным последствиям, чем, к примеру, небольшие баги в коде. Поэтому и фокус у тимлида должен быть в первую очередь на своих стратегических задачах. К решению таких задач следует подходить тщательно, не торопясь, с подробным анализом и взвешиванием всех «за» и «против».
А вот не быть заваленным остальными задачами может помочь следующий совет.
Не бояться делегировать
Стремление тимлида сделать все самому из-за принципа «хочешь сделать что-то хорошо — сделай это сам» нередко приводит не только к уехавшим вперед срокам сдачи и затягиванию процесса, но и к стагнации сотрудников. Решая только однообразные, тривиальные задачи, разработчики либо привыкают к постоянному формошлепству и перестают развиваться, изучать новые технологии, либо начинают поглядывать в сторону других проектов или даже других компаний. А тимлид, который берет себе всё самое интересное, “зашивается”, не успевает то там, то здесь, перестает уделять должное внимание стратегическим задачам, оправдывая это нехваткой времени.
В отличной статье про делегирование автор много полезных и правильных вещей на эту тему сказал, поэтому здесь будет только основной из тезисов. Не стоит забывать, что делегирование — это не бинарный выбор «делегировать полностью» или «совсем не делегировать», а, скорее, спектр возможностей.
Например, неопытному джуну стоит передавать в работу хорошо описанную задачу, где будут подсвечены моменты, которым стоит уделить повышенное внимание, а также где будут расписаны ожидаемые изменения в рамках задачи. Более опытному разработчику можно подробно обрисовать в задаче бизнес-ниды и попросить самому детально расписать изменения, которые он считает обязательными для реализации. А матёрому спецу можно просто обозначить нужную часть из ТЗ и быть уверенным в том, что он при необходимости придет за уточнениями, распишет то, как будет решать задачу, предложит несколько вариантов для неоднозначных моментов, а затем в лучшем виде отдаст всё это на сверку.
После получения новой роли и принятия новых обязанностей тимлид естественным образом будет писать все меньше и меньше кода. Если же он овладеет навыками делегирования, то количество внесенных собственными руками изменений в проекте продолжит падать вниз. Это в свою очередь, нередко служит отправной точкой для саморефлексии: как рядовой разработчик он привык измерять свою эффективность в количестве написанного кода и реализованных фич, а в новой должности эта метрика падает. От этого могут начать подкрадываться мысли вроде «Еще один день, а я опять ничего не сделал. То на созвонах время трачу, то что-то проектирую, то согласовываю, то код проверяю, то пишу код — и ничего не успеваю». Чтобы отогнать такие мысли, стоит обратить внимание на последний совет в статье.
Хвалить себя — это нормально
Роль тимлида — важная и нужная роль на любом проекте, и без нее разработка чего-то крупнее микросервиса пойдет вразнос вскоре после начала. Не стоит про это забывать и ждать завершения крупного проекта, чтобы себя похвалить.
Если на проекте все идет тихо и спокойно, эпики закрываются примерно в срок — это в том числе ваша заслуга. Если в коде есть несколько модулей с различной функциональностью, но структура этих модулей настолько похожа, что без труда можно угадать что где лежит — это в том числе ваша заслуга. Если разработчики, код которых приходилось по многу раз исправлять, теперь выкатывают выставочного качества пулл-реквесты — это тоже в том числе ваша заслуга.
Время и возможности как для самокритики, так и для критики со стороны в будущем точно предоставятся. Сроки будут поджимать, код придется перекраивать, баги придется отлавливать теми или иными средствами.
Поэтому не забывайте хвалить себя, не забывайте хвалить команду. После сданного проекта, после выполненной фичи, после закрытого спринта — найдите время и слова чтобы подбодрить всех участников процесса, будь то разработчики, проект-менеджеры, аналитики или дизайнеры. Пусть сейчас LLM-ки активно перетягивают на себя одеяло, но на сегодняшний день главными в разработке все-таки остаются люди.
Послесловие
Роль тимлида нужна и важна, а вес задач, которые стоят перед ним при разработке проекта, сложно переоценить. И хоть от тимлида требуется повышенное чувство ответственности за проект и за команду, сверхспособности и сверхурочные часы работы для достижения целей не нужны. Достаточно просто хорошо выполнять поставленные перед ролью задачи. А мы надеемся, что данная статья вам в этом поможет!