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

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

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

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

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

- Разработчики принимают решения самостоятельно, руководствуясь тем, что им кажется лучше.

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод:

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

Похожие материалы
Социальные сети для блоггеров и вебмастеров. Социальные сети для веб-мастеров, нацелены исключительно на целевую аудиторию, на людей, которые занимаются бл...
Основные ошибки seo оптимизаторов Сейчас, почти каждый человек полагает что должен стать частью веб-сообщества. Стать активным пользователем, и ...
Логотип как визитная карточка компании По своей сути логотип для компании – это практически то же самое, что имя для человека. Ведь именно он создает...
Бесплатный Интернет-магазин - способ сэкономить? Собираясь зарабатывать в сети, многие люди останавливаются на идее открытия своего Интернет-магазина. Если это...
Категории раздела
Новое на форуме
Популярные материалы
Популярные теги