Три распространённые ошибки начинающего ведущего разрабочика

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

От автора перевода: заранее договоримся, что под словами «ведущий разработчик», «лидер команды» и «руководитель команды программистов» мы понимаем одну и ту же должность Tech Lead — человека, который возглавляет группу разработчиков и ответственен за их эффективную работу.

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

1. Постоянно писать код

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

• Разработчики принимают решения самостоятельно, руководствуясь тем, что им кажется лучше.
• Развёртывание (проекта) может закончится неудачей, так как разработчики не понимают технических ограничений и различий.
• Наихудший вариант: разработчики хотят постоянно переписывать код, не учитывая особенностей эксплуатации проекта в будущем и особенности его будущего развития.

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

2. Принятие всех технических решений

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

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

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

3. Отсутствие культивирования культуры в команде

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

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

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

Вывод

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

Дополнение от команды tproger

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

• Книга «Как пасти котов. Наставление для программистов, руководящих другими программистами», на сайте издательства.
• Книга «45 татуировок менеджера» — правила российского руководителя, на сайте издательства.
• Небольшая презентация «The Geek’s Guide to Leading Teams».