Почему не все должны быть тимлидами: мнение разработчика

Процесс разработки ПО будет эффективным, если в нём, помимо людей с достаточным уровнем навыков и компетенций, грамотно выстроена чёткая иерархия управления процессами. В продуктивной иерархии всегда существуют следующие роли:

1. разработчики — непосредственные участники команд разработок;
2. руководители команд разработки — тимлиды (TeamLead);
3. тестировщики;
4. тимлиды команд тестирования;
5. руководители направлений разработок (backend, frontend);
6. технические директора, архитекторы, аккаунты, руководители проектов и так далее.

Все перечисленные участники занимаются специфической и свойственной только им работой, поэтому несут соизмеримую с уровнем ответственности нагрузку. Но где и как в этой системе заканчивается разработка и начинается управление? Чем занимаются руководители команд программистов? Сегодня разберём это подробнее.

Кто такой тимлид

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

1. Из-за наиболее сильной экспертизы в команде в определенных вопросах реализации бизнес-функционала, предоставляющей право первоочередного участия.
2. Из-за нехватки свободных разработчиков. Банально, но факт. Задач всегда много, спринты короткие, у каждого плотный график. И несмотря на все особенности процесса разработки, тимлид ответственен не за количество исправленных ошибок, а за исполнение запланированных работ в заданные сроки. В конце спринта тимлид будет выпускать очередной релиз, куда будут входить все исправленные ошибки, реализованный и протестированный новый функционал.

А что именно должен делать тимлид, чтобы, собственно, приводить команду к нужному результату в нужные сроки? Копнём поглубже.

Почему тимлид — уже не совсем разработчик

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

1. первая — распределение задач. На входе у тимлида будет стоять «история» или «эпик». Провести эффективную декомпозицию истории под силу лишь опытным разработчикам, глубоко погружённым в существующую архитектуру и бизнес-логику. Сразу же начнут возникать вопросы у менее опытных разработчиков. Подобные проблемы являются тормозящим фактором в работе. Опытные разработчики будут вынуждены часто отвлекаться, что негативно скажется на общей производительности;
2. вторая — организация эффективного взаимодействия команды с другими участниками процесса: менеджерами проектов, аккаунтами, тестировщиками и т.д.. Это особенно важно в больших бизнес-проектах с большим числом команд, состоящих из большого числа разработчиков. Элементарно назначить созвоны и собрать всех заинтересованных лиц — та ещё задачка;
3. третья — взаимодействие по вопросам, касающихся индивидуальных особенностей человека, например, назначение задач в соответствии со скиллами, решение индивидуальных проблем, выдача обратной связи, собеседования с новичками, онбординг и т.д.;
4. четвёртая и, пожалуй, одна из наиболее важных — ответственность за соблюдение сроков разработки, регулярный релиз по завершению спринтов. Само собой разумеющимся будет являться факт того, что эффективнее будет объединить весь пласт озвученных проблем воедино и сконцентрировать их вокруг конкретного человека, чем «размазывать» по всей команде.

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

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

Почему тимлид — должность не для всех

Любой разработчик, работая продолжительное время, накапливает определённый профильный опыт и экспертизу в вопросах архитектуры проекта и бизнес-процессов. Забирая на себя все более сложные задачи и уменьшая время их выполнения с одновременным повышением качества разработки, сотрудник может зарекомендовать себя как профессионал и кандидат на роль менеджера определённой небольшой структурной единицы в большом коммерческом проекте. Но для каждого ли программиста такой путь — единственно верный?

Чтобы ответить на этот вопрос, стоит рассмотреть профессию тимлида с ракурса менеджмента. Бытует мнение, что тимлид — это следующая и вполне естественная ступень в развитии hard-скиллов разработчика. Однако это не совсем так.

Тимлид — это больше менеджер, управляющий, руководитель. К активному развитию навыков программирования это не имеет практически никакого отношения. Следует чётко разделять профессию разработчика и руководителя команды. Разработчик 98% своего времени тратит непосредственно на написание кода, утверждения планов, обсуждения подходов, тестирование и т.д.. Его не касаются проблемы декомпозиции «эпика» на «истории», обсуждение архитектурных аспектов и требований заказчика, планирование спринтов. Тимлид целиком погружён в озвученные вопросы, его задача — наиболее эффективно реализовать работу команды, приложив к этому максимум усилий и возможностей. Естественно предполагать, что в тимлиды приходят наиболее опытные разработчики грейдом не ниже Middle+.

Возникает закономерный вопрос — все ли опытные специалисты захотят становиться руководителями? Практика показывает, что нет. Причин тому несколько:

• Я — разработчик, мне нравится писать код, создавать себе задачи из «истории» и не забивать себе голову релизами.

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

• Я — разработчик, и я не хочу отвечать за чужой код.

Тимлид проводит code-review менее опытных разработчиков, возвращает задачи на доработку, если что-то пошло не так, выявляет в коде неправильные участки.

• Я — разработчик, и мне не хочется быть руководителем для других людей.

Управленческие навыки не являются обязательным soft-скиллом для программистов. У кого-то они есть изначально, например, за счёт харизмы, кто-то активно их развивает и учится, а кто-то и вовсе ими не обладает и не способен в принципе собрать вокруг себя команду.

• Я — разработчик, и мне не нужна лишняя ответственность.

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

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

У тимлида, как и у любого другого участника процесса разработки, существуют свои soft- и hard-скиллы, которые необходимо развивать. Современные реалии требуют от тимлида знаний в области Agile-управления (Scrum, Kanban), управления спринтами, проведения собраний, стендапов, обзоров итогов итераций и ретроспективы, эффективного управления бэклогом и расстановкой приоритетов.

Для повышения навыков проводятся различного рода конференции, например, TeamLead Conf, Мультиформатная конференция для тимлидов и руководителей, Lead/Manage. На них выступают ведущие спикеры из сферы IT, обсуждаются различные вопросы психологических подходов, управления командами, практики планирования спринтов в Scrum, Agile-собрания и так далее.

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